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"), ) 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, . [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]