Internet DRAFT - draft-wan-netlmm-pmip6-bootstrapping
draft-wan-netlmm-pmip6-bootstrapping
Network Working Group C. Wan
Internet-Draft Southeast University
Expires: January 21, 2008 C. Ye
W. Yan
Y. Pan
Huawei Technologies
July 20, 2007
The bootstrapping for Proxy mobile IPv6
draft-wan-netlmm-pmip-bootstrapping-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2008.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
Proxy Mobile IPv6 (PMIP) describes a protocol that is based on
network mobility management. Before the network provides service for
the mobile node, there exists a mechanism that the Mobile Access
Gateway gets a home agent address and a home address and establishes
IPsec security association with the mobile node's home agent. This
Wan, et al. Expires January 21, 2008 [Page 1]
Internet-Draft PMIP Bootstrapping July 2007
document addresses this problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Home agent address discovery . . . . . . . . . . . . . . . 6
4.2.1. Pre-configuration . . . . . . . . . . . . . . . . . . 6
4.2.2. DNS lookup . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Dynamic home agent address discovery . . . . . . . . . 7
4.3. IPsec Security Associations setup . . . . . . . . . . . . 7
4.4. Home Address assignment . . . . . . . . . . . . . . . . . 9
4.4.1. Pre-configuration . . . . . . . . . . . . . . . . . . 9
4.4.2. Auto-configuration by the Mobile Access Gateway . . . 10
4.4.3. Assignment by the home agent . . . . . . . . . . . . . 10
5. Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Wan, et al. Expires January 21, 2008 [Page 2]
Internet-Draft PMIP Bootstrapping July 2007
1. Introduction
Mobile IPv6 (MIPv6) [RFC3775] specifies a localized mobility
management mechanism for mobile IPv6 node. It requires the mobile
node to know its home agent address, its home address for setting up
IPsec security association between the mobile node and its home agent
in order to protect mobile IPv6 signaling
[draft-ietf-mip6-bootstrapping-split-04]. It also requires
cryptographic materials between the mobile node and its home agent or
between the mobile node and AAA server to set up such a security
association. These cryptographic materials may be pre-configured in
the mobile node, the home agent or AAA server, which are used to set
up the security association between the mobile node and its home
agent.
Proxy Mobile IPv6 (PMIP) [draft-ietf-netlmm-proxymip6-01.txt],
however, describes a protocol that is based on network mobility
management. To provide mobility support to any IPv6 host within a
restricted and topologically localized portion of the network and
without requiring the participation of the host, proxy mobile IP
(PMIP) introduces a new function entity, the Mobile Access Gateway
(MAG), which performs mobile IPv6 signaling message on behalf of
mobile node.
Proxy mobile IPv6 requires the Mobile Access Gateway to send proxy
mobile signaling to the home agent on behalf of the mobile node.
That is, proxy mobile signaling is between the Mobile Access Gateway
and the mobile node's home agent. Therefore, the IPsec security
association should be set up between the Mobile Access Gateway and
the mobile node's home agent in order to protect the proxy mobile
signaling. IPsec Security association setup in proxy mobile IPv6
domain is different from security association setup in mobile IPv6
domain; in mobile IPv6, the security association is between the
mobile node and its home agent and it may be established during the
mobile node's bootstrapping. In proxy mobile IPv6, the security
association is between the Mobile Access Gateway and the mobile
node's home agent, so when the mobile node roams from a Mobile Access
Gateway to another, the IPsec security association may need to be re-
established.
As described above, in the mobile IPv6, cryptographic materials may
be configured between the mobile node and AAA server, or between the
mobile node and its home agent. During IKEv2 [IKEv2] exchange, the
mobile node can use these cryptographic materials to authenticate the
mobile node to the home agent or AAA server. However in proxy mobile
IPv6, to set up such a security association, it is little value to
pre-configure cryptographic materials between the Mobile Access
Gateway and the home agent or between the Mobile Access Gateway and
Wan, et al. Expires January 21, 2008 [Page 3]
Internet-Draft PMIP Bootstrapping July 2007
the AAA server.
This document describes a solution on bootstrapping under PMIP domain
including home agent discovery, home address assignment and IPsec
security association setup etc.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 RFC2119.
[STANDARDS]
Local Mobility Anchor (LMA):
Local Mobility Anchor is the home agent for the mobile node in the
Proxy Mobile IPv6 domain. It is the topological anchor point for
the mobile node's home prefix and is the entity that manages the
mobile node's reachability state. It is important to understand
that the LMA has the functional capabilities of a home agent as
defined in Mobile IPv6 base specification [RFC-3775] and with the
additional required capabilities for supporting Proxy Mobile IPv6
as defined in [draft-ietf-netlmm-nohost-req-05.txt].
Mobile Access Gateway (MAG):
Mobile Access Gateway (MAG) is the proxy mobility agent in the
network which manages the mobility related signaling for a mobile
node that is attached to its access link. It is the entity
responsible for tracking the mobile node's attachment to the link
and for signaling the mobile node's local mobility anchor.
Mobile Node (MN):
TThis document uses the term mobile node to refer to an IPv6 host.
This specification does not require the mobile node to have the
Mobile IPv6 client stack.
AAA:
Authentication, Authorization, and Accounting, AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In
this document, the terms "AAA server" and "backend authentication
server" are used interchangeably.
Wan, et al. Expires January 21, 2008 [Page 4]
Internet-Draft PMIP Bootstrapping July 2007
3. Goals
The goals for this document are listed below:
To authenticate mutually between the mobile node and AAA server. The
Mobile Access Gateway gets the mobile node's profile in security from
AAA server. The Mobile Access Gateway knows if it performs the proxy
mobile signaling on behalf of the mobile node based on the mobile
node's profile. And also, a shared key is generated between the
Mobile Access Gateway and AAA server so that it can be used to set up
the IPsec security association between the Mobile Access Gateway and
the home agent.
To establish the security association between the Mobile Access
Gateway and the home agent (HA-MAG SA), for the Mobile Access Gateway
performs the proxy mobile signaling on behalf of the mobile node, the
HA-MAG SA is used to protect the proxy mobile signalings, such as
Proxy Binding Update and Proxy Binding Acknowledgment, between the
Mobile Access Gateway and the home agent. IKEv2 may be used to
establish such a security association.
To discovery the home agent address. The Mobile Access Gateway needs
to discovery the home address. Three methods are introduced for
discovering the home agent address in this document, pre-
configuration, DNS lookup and Dynamic Home Agent Address Discovery
(DHAAD). The Mobile Access Gateway can obtain the home agent address
by pre-configuration, but it is little value for the PMIP scale
deployment to get the home agent address by pre-configuration. So it
is recommended to dynamically obtain the home agent address (e.g.
DNS lookup and DHAAD).
To get the mobile node's HoA. The PMIP specification supports that
the home agent traffics data packets based on the home address. The
Mobile Access Gateway can get the home address from the mobile's
profile. The home address can also be assigned by the home address
or the Mobile Access Gateway during the IKE exchange of the
bootstrapping.
4. Protocol operations
4.1. Authentication
The access authentication is the first step where EAP and AAA
protocol may be involved in this process. Once the mobile node boots
up, it should send an identifier (e.g. NAI) to the Mobile Access
Gateway to get network attachment. Upon receiving the identifier,
the Mobile Access Gateway exchanges information with AAAH using AAA
Wan, et al. Expires January 21, 2008 [Page 5]
Internet-Draft PMIP Bootstrapping July 2007
protocol (e.g. RADIUS, Diameter). During authentication, EAP method
(for instance, EAP-TLS) [EAP-TLS] may be used for the mutual
authentication between the mobile node and AAA server and also for
generating MSK and EMSK if the PSK is not used. After authenticating
successfully, the AAAH sends the authentication successful result to
the mobile node via the Mobile Access Gateway and authorizes that the
mobile node can access the proxy mobile IPv6 network. And also the
AAAH sends the mobile node's profile to the Mobile Access Gateway so
that the Mobile Access Gateway see if it must perform proxy mobile
signaling on behalf of the mobile node.
According to [EAP], EAP method generates MSK and EMSK. MSK is
derived between the EAP peer and server and can be used to generate
other hierarchy level key while EMSK is never shred with a third
party and may be used for other AAA keys [EAP-KMF]. In this
document, a shared key which will be used for establishing IPsec SA
is generated between the mobile node and AAA server based on the EMSK
as a result of access authentication. AAA server delivers the shared
key to the Mobile Access Gateway so that the Mobile Access Gateway
can use it during establishing the IPsec security association between
the proxy mobile node and the home agent.
4.2. Home agent address discovery
Typically, after successful access authentication, the Mobile Access
Gateway obtains the mobile's profile which stores the mobile node's
information and parameters. Depending on these parameters and the
mobile node's information, the Mobile Access Gateway decides how to
obtain the mobile node's home agent address during the bootstrapping.
How a Mobile Access Gateway obtains the mobile node's home agent when
the mobile node roams from a Mobile Access Gateway to another is out
of scope in this document.
4.2.1. Pre-configuration
If the home agent address information is pre-configured in the mobile
node's profile, the Mobile Access Gateway can obtain the home agent
address from the profile after access authentication. In [PMIP], it
is recommended to pre-configure the mobile node's home agent
information in the mobile node's profile, where the Mobile Access
Gateway can obtain it after access authentication.
4.2.2. DNS lookup
Sometimes, however, there is not the home agent address information
but the domain name of the Mobility Service Provider in the mobile
node's profile. In this case, the Mobile Access Gateway can obtain
the information on Home Agent service from the DNS server whose
Wan, et al. Expires January 21, 2008 [Page 6]
Internet-Draft PMIP Bootstrapping July 2007
address can be pre-configured on the profile or obtained through
DHCPv6 [DHCP] from the visited link.
DNS lookup method may obtain the mobile node's home agent address by
Home Agent Name or by service name. In the former, the Mobile Access
Gateway obtains the Fully Qualified Domain Name of the Home Agent
from the mobile node's profile. The Mobile Access Gateway sends a
user request message with setting the QNAME to the name of the Home
Agent and the QTYPE to 'AAAA' (indicating a IPv6 address) and QCLASS
to 'IN' to DNS server. On receiving the response to the user request
message from the DNS server, the proxy mobile node obtains its home
agent from the ANSWER of response message.
In the later, the Mobile Access Gateway obtains service name from the
mobile node's profile. The Mobile Access Gateway sends a request
message with setting the QNAME to the name of service name and the
QTYPE to 'SRV' or 'HA'. According to different QTYPE, DNS server
will return a different the list of home agent. If QTYPE is 'SRV',
DNS server will return a list of service name which includes home
agents of this domain. The Mobile Access Gateway is responsible for
choosing a proper home agent based on the preference and weight
values of the DNS SRV record. There is a little different between
using SRV and HA. When setting QTYPE to 'HA', the DNS server only
returns a list of pure home agent and the 'HA' record must be pre-
established. Establishing such a 'HA' record is out of the scope in
this document. To avoid additionally requiring, it is recommended
that the IP addresses of home agents should be included in AAAA
records.
4.2.3. Dynamic home agent address discovery
If there is an unique Home Agent in home link, Dynamic Home Agent
Address Discovery is also a recommended way to get the mobile node's
home agent address. The Mobile Access Gateway can use Dynamic Home
Agent Address Discovery scheme to discover the home agent address.
In this case, the Mobile Access Gateway sends an ICMP Home Agent
Address Discovery Request message to the Mobile IPv6 Home Agent
anycast address for its home IP subnet prefix. Upon receiving Home
Agent Address Discovery Request message, the home agent should return
an ICMP Home Agent Address Discovery Reply message to the Mobile
Access Gateway with the source address of the Reply packet set to one
of its global unicast addresses. The further details of Dynamic Home
Agent Address Discovery may be found in [RFC3775].
4.3. IPsec Security Associations setup
Before the Mobile Access Gateway sends proxy mobile signaling, a/some
security association(s) must be established to protect the proxy
Wan, et al. Expires January 21, 2008 [Page 7]
Internet-Draft PMIP Bootstrapping July 2007
mobile signaling. In proxy mobile domain, there is actual mobile
signaling between the Mobile Access Gateway and the home agent, so an
IPsec SA should be established between the Mobile Access Gateway nd
the home agent. As described above, however, Proxy mobile IPv6
requires that the Mobile Access Gateway (MAG) performs the mobile
IPv6 signaling which is also called Proxy Mobile IPv6 Signaling on
behalf of the mobile node. Typically, the HA-MAG IPsec security
association (SA) is established after the access authentication by
using IKEv2 or other mechanisms to protect the Proxy Binding Update
and Proxy Binding Acknowledgment messages between the Mobile Access
Gateway and the home agent.
If there is a SA which is used for PMIP signaling between the MAG and
the LMA before the MN connects to the MAG, the MAG MUST not re-
establish a SA between them . If not, typically, the Mobile Access
Gateway initiates an IKEv2 exchange. If a shared key is pre-
configured between the Mobile Access Gateway and the home agent, the
Mobile Access Gateway may use the key for mutual authentication
[IEKv2]. Figure 1 shows the message flow under the case. In message
3 and 4, the option AUTH value is computed as:
AUTH = prf(prf(Shared key, "Key Pad for IKEv2"), <msg>)
Where shared key is the shared key pre-configured.
Initiator (the MAG) Responder (the HA,LMA)
----------- -----------
(1)HDR, SAi1, KEi, Ni-->
<-- HDR, SAr1, KEr, Nr, [CERTREQ](2)
(3)HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr }(4)
Figure 1 the flow of IKEv2 exchange using shared key
However, it is a little advantageous for PMIP scale deployment to
have pre-shared secure previously between the proxy agent and the
home agent. Additionally, the MAG serving the mobile may be
different when the mobile node bootstraps every time. So it is
strongly recommended that shared authentication materials should be
generated during access authentication so that they can be used for
authentication during IKEv2 exchange. After access authentication,
the shared authentication materials can be generated and stored in
the Mobile Access Gateway and AAA server. The IKEv2 exchange may use
EAP methods defined in RFC 3748 [EAP]. If these methods may not
mutual and only can be used to authenticate the initiator to the
responder EAP, they must be used in conjunction with a public key
Wan, et al. Expires January 21, 2008 [Page 8]
Internet-Draft PMIP Bootstrapping July 2007
signature based authentication of the responder to the initiator.
Figure 2 shows the message flow under the case.
Initiator (the MAG) Responder (the HA)
----------- -----------
(1)HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ](2)
--------------------- EAP exchange ---------------------
(3)HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, EAP }(4)
.
.
.
(5)HDR, SK -->
<-- HDR, SK {EAP (success)}(6)
--------------------------------------------------------
(7)HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr }(8)
Figure 2 the flow of IKEv2 exchange using EAP
The home agent will only perform DAD for the home address when the
Mobile Access Gateway has supplied a valid binding if there is
Shared-Prefix model. If DAD fails, the home agent should rejects the
Binding Update and send a Binding Acknowledgement with status 134 to
indicate DAD fails. Upon receiving the Binding Acknowledgement, the
Mobile Access Gateway must terminate the IKE_AUTH exchange and then
initiates a new IKE_SA_INIT and IKE_AUTH exchange. When DAD fails, a
new home address should also be generated by the home agent as
described in section 4.4.3 of this document.
4.4. Home Address assignment
Before running the proxy mobile, the Mobile Access Gateway should
also get the mobile node's home address. The Mobile Access Gateway
can obtain the home address from the mobile node's profile after
access authentication, where the home address is pre-configured. The
Mobile Access Gateway can also dynamically get the home address
during the IKEv2 exchange.
4.4.1. Pre-configuration
The home address information is configured previously in the mobile's
Wan, et al. Expires January 21, 2008 [Page 9]
Internet-Draft PMIP Bootstrapping July 2007
profile. After access authentication, the Mobile Access Gateway gets
the home agent from the mobile's profile. It is valuable for the
mobile's roam in the proxy MIP domain to pre-configure the home
address. However, the method of pre-configuring the home address is
disadvantage for the scale deployment of PMIP. It is recommended to
dynamically obtain the mobile's home address in this document.
4.4.2. Auto-configuration by the Mobile Access Gateway
The Mobile Access Gateway can auto-configure a home address for the
mobile node by the exchange with the home agent. First, the Mobile
Access Gateway gets the mobile's home prefix and the home prefix
length from the mobile's profile and the others. Once getting the
home prefix information, the Mobile Access Gateway generates a home
address based on the home prefix and sends the home agent to the home
agent in a Configuration Payload where CFG Type is set to CFG_REQUEST
and Attribute Type is set to INTERNAL_IP6_ADDRESS. If the home agent
determines that the home address provided by the Mobile Access
Gateway is valid, it has response to the request including an
INTERNAL_IP6_ADDRESS with the same address. If the home address is
not valid, the home agent must assign a different home address for
the mobile and sends the new address which is included in
INTERNAL_IP6_ADDRESS attribute to the Mobile Access Gateway. Upon
receiving the address, the Mobile Access Gateway must use the newly
assigned home address.
4.4.3. Assignment by the home agent
The Mobile Access Gateway can dynamically configure a home address by
including a Configuration Payload in the IKE_AUTH exchange, with a
request for an address from the home link [IKE-MIP]. During IKEv2
exchange, the Mobile Access Gateway may request a home address by
sending Configuration Payload with setting CFG Type to CFG_REQUEST
and Attribute Type to INTERNAL_IP6_ADDRESS. Further, if the Mobile
Access Gateway wants to get multiple home addresses, it may include
multiple instances of the INTERNAL_IP6_ADDRESS. On receiving the
request message, the home agent allocates a home address and returns
the home address which is included Configuration Attributes to the
Mobile Access Gateway. The home agent may use a local database or
contact a DHCPv6 server on the home link to allocate a home address.
In case the home agent is unable to allocate a home address for the
mobile node during the IKE_AUTH exchange, it MUST send a Notify
Payload with an NTERNAL_ADDRESS_FAILURE message. When the Mobile
Access Gateway receives a Notify Payload with an
INTERNAL_ADDRESS_FAILURE message, it should try to auto-configure a
home address as described in section 4.4.2 of this document.
Wan, et al. Expires January 21, 2008 [Page 10]
Internet-Draft PMIP Bootstrapping July 2007
5. Handover
In Proxy MIP domain, a new MAG MUST get neccessary mobile parameters
when the MN moves from current MAG to the new MAG. It is recommended
to use MN's policy profile to get these parameters in [PMIP].
However, it is disadvantageous for PMIP scale deployment to use the
method.
This document recommends that the MAG gets the MN's neccessary
parameters by using other methods, for example, the MAG can get MN's
parameters from the MN during access authentication, where these
paratmeters can be provided by notification[EAP-Noti]. The method
using notification can reduce the handover latency .
6. Security Considerations
During access authentication, AAA server may generate a shared key
which will be used for the IKEv2 exchange. If EAP is used for mutual
authentication between the Mobile Access Gateway and the home agent,
the AAA server must push the shared key to the Mobile Access Gateway.
It is assumes there is a pre-established Security association (PSA)
between the Mobile Access Gateway and AAA server for protecting the
shared key distribution [Sec-Mobile]. The PSA establishment is out
of scope for security considerations.
During IKEv2 exchange, the Mobile Access Gateway gets the home
address and home agent address. Security considerations for
obtaining the two addresses can be found in [IKE-MIP6] and [BT-
MIPv6]. This document has never introduced a new security threat.
7. IANA Consideration
This document does not require any actions by IANA.
8. References
8.1. Normative References
[DHCP] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", Dec. 2003.
[DIAM-EAP]
Eronen, P., Hiller, T., and G. Zorm, "Diameter Extensible
Authentication Protocol (EAP) Application", Feb. 2004.
Wan, et al. Expires January 21, 2008 [Page 11]
Internet-Draft PMIP Bootstrapping July 2007
[EAP-Noti]
Pan, Y., Li, C., and C. Ye, "Transmission MIPv6
Authorization and Configuration Info By EAP Notification
Message", July 2007.
[EAP-TLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", Oct. 1999.
[IKE-MIP6]
Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the
revised IPsec Architecture", Dec 2006.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Jan 2004.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", Sep. 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", June 2004.
[draft-ietf-mip6-bootstrapping-split-04]
Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", Oct 2006.
[draft-ietf-netlmm-proxymip6-01.txt]
Leung, K., Devarapalli, V., and K. Chowdhury, "Proxy
Mobile IPv6", Jan 2007.
8.2. Informative References
[STANDARDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Oct 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>.
[Sec-Mobile]
Nakhjiri, madjid. and Mahsa. Nakhjiri, "AAA and network
security for mobile access: radius, diameter, EAP, PKI and
IP mobility", Jan 2005.
[draft-ietf-netlmm-nohost-req-05.txt]
Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., and M. Liebsch, "Goals for Network-based Localized
Mobility Management", Oct 2006.
Wan, et al. Expires January 21, 2008 [Page 12]
Internet-Draft PMIP Bootstrapping July 2007
Authors' Addresses
Chagnsheng Wan
Southeast University
department of information science and engineering ,Southeast University.
Nanjing, China 210096
Phone:
Fax:
Email: wanchangsheng@ustc.edu
URI:
Chengping Ye
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, China 210009
Phone: +86-25-84565458
Email: yechengping@huawei.com
Wei Yan
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, China 210009
Phone: +86-25-84565458
Email: peteryan@huawei.com
Yunbo Pan
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, 210009
China
Phone: +86-25-84565456
Email: panyunbo@huawei.com
Wan, et al. Expires January 21, 2008 [Page 13]
Internet-Draft PMIP Bootstrapping July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wan, et al. Expires January 21, 2008 [Page 14]
