Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: April 26, 2009 Huawei USA October 23, 2008 Local Mobile Anchor Discovery Using DHCP draft-xia-netlmm-lma-discovery-00 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 April 26, 2009. Xia & Sarikaya Expires April 26, 2009 [Page 1] Internet-Draft LMA Discovery October 2008 Abstract This draft defines a DHCP-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic Host Configuration Protocol (DHCP) options are used allowing a Mobile Access Gateway (MAG) to request the LMA's IP address, Fully Qualified Domain Name (FQDN), or home network prefix via the DHCP response. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message Sequence . . . . . . . . . . . . . . . . . . . . . . . 4 4. DHCPv6 Relay Agent . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Relay agent configuration . . . . . . . . . . . . . . . . . 5 4.2. Transmission of DHCPv6 messages . . . . . . . . . . . . . . 5 4.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative references . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Xia & Sarikaya Expires April 26, 2009 [Page 2] Internet-Draft LMA Discovery October 2008 1. Introduction [I-D.giaretta-netlmm-mip-interactions] describes possible scenarios which require an interaction between PMIPv6 and MIPv6. In a similar scenario depicted in Figure 1 , some mobile nodes use Mobile IPv6 to manage their movements while others rely on a network-based mobility solution provided by the network. There is a common mobility anchor that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the type of the node. +---------+ +--------+ |LMA1/HA1 | |LMA2/HA2| +---------+ +--------+ //\\ \\ +----//--\\-------------\\------+ ( // \\ \\ ) ( // \\ \\ ) +-//--------\\-------------\\---+ // \\ \\ // \\ \\ // \\ \\ +----+ +----+ +--------+ |MAG1| |AR2 | |MAG3/AR3| +----+ +----+ +--------+ | | | [MN1] [MN2] [MN3] Figure 1: Hybrid deployment with MIPv6 and PMIPv6 Before a MAG or a MN can engage in mobility management signaling with the mobility anchor (LMA or HA), it SHOULD either know the IP address of the mobility anchor via pre-configuration, or dynamically discover it. [I-D.ietf-mip6-hiopt] defines DHCPv6 options which are used for acquiring the mobile anchor(HA) information from a DHCPv6 server in MIPv6, while this document describes a procedure that the MAG retrieves the information from the same server using the DHCP options in Proxy MIPv6. 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 [RFC2119]. Xia & Sarikaya Expires April 26, 2009 [Page 3] Internet-Draft LMA Discovery October 2008 The terminology in this document is based on the definitions in [RFC5213]. 3. Message Sequence Figure 2 shows the message sequence for dynamic LMA discovery using DHCPv6. The following details apply. +-----+ +------+ +------+ +------+ | | |NAS/ | | | | | | MN/ | |MAG/ | | DHCP | | AAA | |User | |DHCP | |Server| |Server| | | |client| | | | | +-----+ +------+ +------+ +------+ | | | | | 1 | 1 | | |<------------>|<---------------------->| Access Authentication | | | | | | 2 | | | |------------>| | Information Request | | | | | | 3 | | | |<------------| | Information Reply | | | | Figure 2: Dynamic LMA Using DHCP 1. The mobile node executes the network access authentication procedure (e.g., IEEE802.1X or IKEv2 SA establishment followed by EAP authentication) and it interacts with the NAS/MAG. The NAS/ MAG interacts with the AAA server to authenticate the mobile node. In the process of authorizing the mobile node, the AAA server verifies in the AAA profile that the mobile node is allowed to use the Proxy Mobile IPv6 service. The AAA server possibly assigns a LMA and returns this information to the NAS through Diameter [I-D.korhonen-dime-pmip6] or RADIUS [I-D.xia-netlmm-radius], thus, it is not necessary to continue with step 2 and 3. Otherwise, the NAS/MAG continues the following DHCP exchanges to inquire the home network information. 2. The NAS/MAG as a DHCP client sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message, the NAS/MAG SHALL include Home Network Identifier Option [I-D.ietf-mip6-hiopt] in the OPTION_ORO, and a Home Network Identifier Option with id-type set Xia & Sarikaya Expires April 26, 2009 [Page 4] Internet-Draft LMA Discovery October 2008 to 0. When the Sub-opt-code of the sub-option is set to 1 in the request, the Home Network Parameter field MUST contain an identifier to specify the home network requested by the mobile node. This field MUST be set in the form of a FQDN [RFC1035], encoded as specified in Section 8 of [RFC3315]. If the mobile node has a NAI, the FQDN can be constructed by concatenating a fixed string with the realm part of the NAI. This sub-option in the request SHOULD be copied into the Home Network Information option returned in the reply. The NAS/MAG SHALL also include the OPTION_CLIENTID to identify itself to the DHCP server. The DHCP Unique Identifier(DUID) can be generated based on the mobile node's link layer address or other information. How to create DUID is beyond the scope of this document. 3. The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID. The DHCP server also determines that the MAG is requesting home network information by looking at the Home Network Identifier Option (id-type 0). The DHCP server retrieves the allocated LMA, FQDN, and home network prefix, and includes them in the Home Network Information Option [I-D.ietf-mip6-hiopt] in the Information Reply Message that it sends to the DHCP client. 4. DHCPv6 Relay Agent A DHPCv6 relay agent function [RFC3315] SHOULD be used when NAS/MAG and the DHCP server are not connected directly. In this configuration, the relay agent function is co-located in the NAS/MAG with the DHCPv6 client function. Rather than using multicast to send DHCPv6 messages to the DHCPv6 server, the DHCPv6 client in the NAS/ MAG hands any outbound DHCPv6 messages to the co- located relay agent. Responses from the DHCPv6 server are delivered to the relay agent function in the NAS/MAG, which extracts the encapsulated message and delivers it to the DHCPv6 client in the NAS/MAG. 4.1. Relay agent configuration The use of the relay agent function in the NAS/MAG allows the NAS/MAG to unicast DHCPv6 messages to the DHCPv6 server. The relay agent must be configured with the address of the DHCPv6 server or another DHCPv6 relay agent that will forward message on to a DHCPv6 server. 4.2. Transmission of DHCPv6 messages In this configuration, when the DHCPv6 client in the NAS/MAG sends a message, it hands the message to the DHCPv6 relay agent in the NAS/ MAG. The relay agent encapsulates the message from the client in a Relay-forward message and sends the resulting DHCPv6 message to the Xia & Sarikaya Expires April 26, 2009 [Page 5] Internet-Draft LMA Discovery October 2008 DHCP server. The relay agent sets the fields in the Relay-forward message as follows: msg-type RELAY-FORW hop-count 1 link-address A non-link-local address from the upstream or loopback interface. peer-address A non-link-local address from the upstream or loopback interface. options MUST include a "Relay Message option" in which OPTION_ORO is included. 4.3. Receipt of DHCPv6 messages In this configuration, messages from the DHCPv6 server will be returned to the DHCPv6 relay agent, with the message for the DHCPv6 client encapsulated in the Relay Message option [RFC3315] in a Relay- reply message. The relay agent function extracts the message for the client from the Relay Message option and hands the message to the DHCPv6 client in the NAS/MAG. 5. Security Considerations This document describes the use of DHCPv6 for LMA discovery in Proxy Mobile IPv6 networks. It does not introduce any additional security concerns beyond those described in the "Security Considerations" section of the DHCPv6 base specification [RFC3315]. 6. IANA considerations None. 7. Acknowledgements TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xia & Sarikaya Expires April 26, 2009 [Page 6] Internet-Draft LMA Discovery October 2008 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 8.2. Informative references [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), April 2008. [I-D.ietf-mip6-hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-17 (work in progress), May 2008. [I-D.xia-netlmm-radius] Xia, F., Sarikaya, B., Korhonen, J., and S. Gundavelli, "RADIUS Proxy Mobile IPv6", draft-xia-netlmm-radius-02 (work in progress), February 2008. [I-D.korhonen-dime-pmip6] Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., and U. Meyer, "Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction", draft-korhonen-dime-pmip6-04 (work in progress), September 2008. [I-D.giaretta-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. Xia & Sarikaya Expires April 26, 2009 [Page 7] Internet-Draft LMA Discovery October 2008 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires April 26, 2009 [Page 8] Internet-Draft LMA Discovery October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Xia & Sarikaya Expires April 26, 2009 [Page 9]