Network Working Group B. Sarikaya Internet-Draft F. Xia Intended status: BCP Huawei USA Expires: August 20, 2010 February 16, 2010 DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks Abstract According to IPv6 operation in cellular networks, one prefix can only be assigned to one interface of a mobile node by an access router and different mobile nodes can't share a prefix. Managing Per-MN interface prefixes is likely to increase the processing load at the access router. Based on the idea that DHCPv6 servers can manage prefixes as well as addresses, we propose a new technique in which the access router offloads delegation and release tasks of the prefixes to an DHCPv6 server. The access router first requests a prefix for an incoming mobile node to the DHCPv6 server. The access router next advertises the prefix information to the mobile node with a Router Advertisement message. When the mobile node hands off, the prefix is returned to the DHCPv6 server. We also describe how less than /64 prefixes can be allocated. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 20, 2010. Sarikaya & Xia Expires August 20, 2010 [Page 1] Internet-Draft Prefix Delegation February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . . . . 4 3.1. Prefix Request Procedure for Stateless Address Configuration . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Prefix Request Procedure for Stateful Address Configuration . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Prefix Release Procedure . . . . . . . . . . . . . . . . . 7 3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 7 3.4.1. Renumbering Through Renew Message . . . . . . . . . . 7 3.4.2. Server Initiated Reconfiguration . . . . . . . . . . . 8 3.5. Miscellaneous Considerations . . . . . . . . . . . . . . . 8 3.5.1. Allocating Prefixes With Length Less Than /64 . . . . 8 3.5.2. Allocating More Than One Prefix . . . . . . . . . . . 8 3.5.3. Triggers for an AR to Initiate Prefix Request Procedure . . . . . . . . . . . . . . . . . . . . . . 9 3.5.4. How to Generate IAID . . . . . . . . . . . . . . . . . 9 3.5.5. Policy to Delegate Prefixes . . . . . . . . . . . . . 9 4. Prefix Delegation Using RADIUS and Diameter . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Protocol Variables . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Sarikaya & Xia Expires August 20, 2010 [Page 2] Internet-Draft Prefix Delegation February 2010 1. Introduction Figure 1 illustrates the key elements of a typical cellular access network. In a Long Term Evolution (LTE) network, access router is the serving gateway or the packet data network (PDN) gateway [23.401]. Customer | Access Provider | Wireless Core Premise | | (Backend Network) +------+ +-------------|DHCP | +-----+ +-----+ +------+ | +--------+ |Server| | UE |---(LTE)----| BS |-----+Access+---+ Edge | +------+ +-----+ +-----+ |Router| | Router +==>ISP Network +--+---+ +--------+ +-----+ +-----+ | | +------+ | UE |---(LTE)----| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 1: Key elements of a typical cellular access network User equipment (UE) attach to a base station (BS) through LTE air interface. A BS manages connectivity of UEs and extend connections to an Access Router (AR). The Access router is the first IP hop router of UEs. As to IPv6 addressing, there are two models, shared prefix and Per-MN interface prefix. In the shared prefix model, an IPv6 prefix is shared by multiple MNs. While in the Per-MN interface prefix model, a prefix is only assigned to one interface of the MN. Different MNs can't share a prefix, and an interface can have multiple prefixes. [RFC4968] briefly compares the two models. Per-MN interface prefix model has some advantages, such as, no complicated duplicate address detection (DAD), fit naturally to the point-to-point links and so on. In Per-MN interface prefix model, prefix management is an issue. When an MN attaches an AR, the AR requests one or more prefixes for the MN. When the MN detaches the AR, the prefixes should be released. When the MN becomes idle, the AR should hold the prefixes allocated. When an operator wants to renumber its network, prefixes with different lifetime are advertised to the MN. DHCPv6 is a preferable way to manage the prefixes. At the same time, AAA protocols, RADIUS and Diameter, can be used in prefix delegation. Sarikaya & Xia Expires August 20, 2010 [Page 3] Internet-Draft Prefix Delegation February 2010 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]. This document uses the terminology defined in [RFC3315], [RFC3633] and [23.401]. 3. Prefix Delegation Using DHCPv6 Access router refers to the cellular network entity that has DHCP Client. According to [23.401] DHCP Client is located in PDN Gateway. So AR is the PDN Gateway in LTE architecture. 3.1. Prefix Request Procedure for Stateless Address Configuration Sarikaya & Xia Expires August 20, 2010 [Page 4] Internet-Draft Prefix Delegation February 2010 +-------+ +-------+ +-----------+ | MN | | AR | |DHCP Server| +-------+ +-------+ +-----------+ | | | | 1 N/W Entry & Auth | | |<--------------------->| | | |2 Relay-forward/Solicit| | |---------------------> | | | | | |3 Relay-reply/Advertise| | |<--------------------- | | | | | |4 Relay-forward/Request| | |---------------------> | | | | | |5 Relay-reply/Reply | | |<--------------------- | |6 Initial Service Flow | | | Established | | |<--------------------->| | | | | | 7 Router Advertisement| | |<----------------------| | | | | | 8 MLD Join | | |---------------------->| | | | | | 9 DAD Procedure | | |<--------------------->| | | | | Figure 2: Prefix request There are two function modules in the AR, DHCP Client and DHCP Relay. DHCP messages should be relayed if the AR and a DHCP server are not connected directly, otherwise DHCP relay function in the AR is not necessary. Figure 2 illustrates the scenario that the AR and the DHCP Server aren't connected directly: 1. An MN performs initial network entry and authentication procedures. 2. On successful completion of Step 1, the AR initiates DHCP Solicit procedure to request prefixes for the MN. The AR creates and transmits a Solicit message as described in sections 17.1.1, "Creation of Solicit Messages" and 17.1.2, "Transmission of Solicit Messages" of RFC 3315. The AR creates an IA_PD and assigns it an IAID. The AR MUST include the IA_PD option in the Solicit message. Sarikaya & Xia Expires August 20, 2010 [Page 5] Internet-Draft Prefix Delegation February 2010 3. The DHCP server sends an Advertise message to the AR in the same way as described in section 17.2.2, "Creation and transmission of Advertise messages" of RFC 3315. 4. The AR uses the same message exchanges as described in section 18, "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to obtain or update prefixes from a DHCP server. The AR and the DHCP server use the IA_PD Prefix option to exchange information about prefixes in much the same way as IA Address options are used for assigned addresses. 5. AR stores the prefix information it received in the Reply message. 6. A virtual link is created for exchanging control traffic between MN and AR and becomes active. 7. The AR advertises prefixes to MN with router advertizement (RA) once the virtual link is active. 8. The MN constructs a solicited node multicast address for the corresponding Link Local Address and sends MLD Join request for the solicited node multicast address. 9. The MN starts verifying address uniqueness by sending a DAD NS on the virtual link. AR can check the address uniqueness within the virtual link scope. 4-way exchange between AR as requesting router (RR) and DHCP server as delegating router (DR) in Figure 2 MAY be reduced into a two message exchange using the Rapid Commit option [RFC3315]. AR includes a Rapid Commit option in the Solicit message. DR then sends a Reply message containing one or more prefixes. 3.2. Prefix Request Procedure for Stateful Address Configuration After the initial network entry and authentication, an initial service flow is established for the MN. DHCP Relay follows the procedure shown in Figure 2 to get the new prefix for this interface of MN. DHCPv6 client at the MN sends DHCP Request to DHCP Relay function at AR. AR MUST make sure that DHCP server assigns MN address from this prefix. AR as DHCP Relay forwards DHCP Request message in DHCP Relay Option and adds Option 82 to the message [RFC3046]. Option 82 MUST contain MN' prefix. DHCP server MUST process Option 82 and MUST assign an address to MN using the prefix in Option 82. DHCP server replies with Relay reply message. DHCP Relay sends DHCP Reply message to MN containing its address. MN configures its interface with the address assigned by DHCP server in DHCP Reply message. Sarikaya & Xia Expires August 20, 2010 [Page 6] Internet-Draft Prefix Delegation February 2010 3.3. Prefix Release Procedure +-------+ +-------+ +-----------+ | MN | | AR | |DHCP Server| +-------+ +-------+ +-----------+ | | | | 1 De-registration | | | Handover, or others | | |<--------------------->| | | |2 Relay-forward/Release| | |---------------------->| | | | | |3 Relay-reply/Reply | | |<--------------------- | | | | | | | Figure 3: Prefix Release Prefixes can be released in two ways, prefix aging or DHCP release procedure. In the former way, a prefix SHOULD not be used by an MN when the prefix ages, and the DHCP Server can delegate it to another MN. A prefix lifetime is delivered from the DHCPv6 server to the MN through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information option [RFC4861]. Figure 3 illustrates how the AR releases prefixes to an DHCP Server which isn't connected directly: 1. An MN detachment signaling, such as switch-off or handover, triggers prefix release procedure. 2. The AR initiates a Release message to give back the prefixes to the DHCP server. 3. The server responds with a Reply message, and then the prefixes can be reused by other MNs. 3.4. Renumbering 3.4.1. Renumbering Through Renew Message To extend the valid and preferred lifetimes for the prefixes associated with an MN, the AR sends a Renew message to the DHCP server. The server determines new lifetimes for the prefixes and returns the prefix to AR in a Reply message. The DHCP server MAY add new prefixes to the MN for renumbering in its Reply message. For a more detailed description of these message, refer to [RFC3633] and of renumbering, refer to [RFC4192]. Sarikaya & Xia Expires August 20, 2010 [Page 7] Internet-Draft Prefix Delegation February 2010 3.4.2. Server Initiated Reconfiguration DHCP server initiates a configuration message exchange with the AR by sending a Reconfigure message. The reconfigure message triggers the AR to send Renew message as described in Section 3.4.1. 3.5. Miscellaneous Considerations 3.5.1. Allocating Prefixes With Length Less Than /64 According to [RFC3314] one /64 prefix needs to be assigned to each mobile node. In some cases prefixes with length less than /64 need to be assigned to MNs. The protocol described in Section 3.1 can be easily tailored for the purpose of allocating prefixes with length less than /64. In Step 1, MN sends its identity during attach procedure, e.g. International Mobile Subscriber Identity (IMSI) or certain type of IMSI such as Provisional Connectivity ID (PCID) [23.812]. In Step 2, Requesting Router MAY consider the type of MN identity when sending DHCP Solicit message. For MNs that need to be assigned prefixes longer than /64, Requesting Router SHOULD include IA_PD Prefix Option into the created IA_PD. Requesting Router MUST set prefix-length field to a value less than 64, e.g. 60. More than one IA_PD Prefix option may be included in the Solicit message. In Step 5, Delegating Router sends a reply message containing the prefix(es) requested. There are many applications where prefixes with length less than /64 is needed. In Machine to Machine applications the host may act as machine to machine communication gateway, which has to assign IPv6 addresses to the sensors, switches, or other devices within the control area of the gateway. Each of these devices may require a different /64 prefix. Another application is the Mobile Router. Mobile Router gets Mobile Network Prefix(es) and advertizes these prefixes in the mobile network [RFC3963] 3.5.2. Allocating More Than One Prefix DHCPv6 PD described in Section 3.1 can be easily tailored to assign more than one prefix to MNs. Requesting Router SHOULD include more than one IA_PD Prefix options into the created IA_PD. This will result in Delegating Router assigning more than one prefix. The prefix length depends on the value assigned in prefix-length field of IA_PD Prefix option. Sarikaya & Xia Expires August 20, 2010 [Page 8] Internet-Draft Prefix Delegation February 2010 Machine to machine gateways [23.812] and Proxy Mobile IPv6 hosts [RFC5213] typically need more than one prefix assigned. Machine to machine gateways may need prefixes with length less than /64. 3.5.3. Triggers for an AR to Initiate Prefix Request Procedure There are some other triggers for an AR to initiate prefix request procedure besides network entry and authentication, such as, when an AR receives handover initiate (HI) message in FMIPv6 [RFC4068], or other handover signaling. After getting an incoming MN' necessary information (such as MAC address), the AR SHOULD initiate prefix request procedure as soon as possible. 3.5.4. How to Generate IAID IAID is 4 bytes in length and should be unique in an AR scope. Prefix table SHOULD be maintained. Prefix table contains IAID, MAC address and the prefix(es) assigned to MN. In LTE networks, International Mobile Subscriber Identity (IMNI) corrsponds to the MAC address. MAC address of the interface SHOULD be stored in the prefix table and this field is used as the key for searching the table. IAID SHOULD be set to Start_IAID, an integer of 4 octets. The following IAID generation algorithm is used: 1. Set this IAID value in IA_PD Prefix Option. Request prefix for this MN as in Section 3.1 or Section 3.2. 2. Store IAID, MAC address and the prefix(es) received in the next entry of the prefix table. 3. Increment IAID. Prefix table entry for an MN that handsover to another AR MUST be removed. IAID value is released to be reused. 3.5.5. Policy to Delegate Prefixes AR should broadcast the prefix(es) dynamically upstream as the route information of all the MNs connected to this AR. In point-to-point links, this causes high routing protocol traffic (IGMP, OSPF, etc.) due to Per-MN interface prefixes. To solve the problem, route aggregation SHOULD be used. For example, each AR can be assigned a /48 or /32 prefix (aggregate prefix, aka service provider common prefix) while each interface of MN can be assigned a /64 prefix. The /64 prefix is an extension of /48 one, for example, an AR's /48 prefix is 3FFE:FFFF:0::/48, an interface of MN is assigned 3FFE:FFFF: 0:2::/64 prefix. The AR only broadcasts it's /48 or /32 prefix information to Internet. Sarikaya & Xia Expires August 20, 2010 [Page 9] Internet-Draft Prefix Delegation February 2010 This policy can be enforced as follows: DHCP Relay MUST set the IPv6 Prefix field in IA_PD Prefix option in IA_PD option in the Relay Forward message to the aggregate prefix (/48, /32, or /16 prefix assigned to the AR). 4. Prefix Delegation Using RADIUS and Diameter In the bootstrapping procedure, an AR as RADIUS client sends Access- Request message with an MN' information to RADIUS server. If the MN passes the authentication, the RADIUS server MAY send Access-Accept message with prefix information to the AR using Framed-IPv6-Prefix attribute. There is no prefix delegation involved in this process. Using such a process AR can handle initial prefix assignments to MNs but managing lifetime of the prefixes is totally left to the AR. Also AR can not use Framed-IPv6-Prefix attribute based assignment for MNs that handover but no full authentication is executed. [RFC4818] defines a RADIUS attribute Delegated-IPv6-Prefix that carries an IPv6 prefix to be delegated. This attribute is usable within either RADIUS or Diameter. [RFC4818] recommends the delegating router to use AAA server to receive the prefixes to be delegated using Delegated-IPv6-Prefix attribute/AVP. DHCP server as the delegating router in Figure 2 MAY send an Access- Request packet containing Delegated-IPv6-Prefix attribute to the RADIUS server to request prefixes. In the Access-Request message, the delegating router MAY provide a hint by the AR that it would prefer a prefix, for example, a /48 prefix. The RADIUS server MAY delegate a /64 prefix which is an extension of the /48 prefix in an Access-Accept message containing Delegated-IPv6-Prefix attribute. The attribute can appear multiple times when RADIUS server assigns multiple prefixes. When Diameter is used, DHCP server as the delegating router in Figure 2 sends AA-Request message. AA-Request message MAY contain Delegated-IPv6-Prefix AVP. Diameter server replies with AA-Answer message. AA-Answer message MAY contain Delegated-IPv6-Prefix AVP. The AVP can appear multiple times when Diameter server assigns multiple prefixes to MN. The Delegated-IPv6-Prefix AVP MAY appear in an AA-Request packet as a hint by the AR to the Diameter server that it would prefer a prefix, for example, a /48 prefix. Diameter server MAY delegate in an AA-Answer message with a /64 prefix which is an extension of the /48 prefix. AR MUST advertize the prefix(es) to MN in RtrAdv message. Prefix release and site renumbering are open issues for RADIUS/ Sarikaya & Xia Expires August 20, 2010 [Page 10] Internet-Draft Prefix Delegation February 2010 Diameter protocols to manage prefixes. 5. Security Considerations This draft introduces no additional messages. Comparing to [RFC3633], [RFC2865] and [RFC3588] there is no additional threats to be introduced. DHCPv6, RADIUS and Diameter security procedures apply. 6. Protocol Variables Start_IAID 4 octet integer value. It can be initialized to ZERO. 7. IANA Considerations None. 8. Acknowledgements TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Sarikaya & Xia Expires August 20, 2010 [Page 11] Internet-Draft Prefix Delegation February 2010 [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. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 9.2. Informative References [23.401] "3GPP TS 23.401 V9.3.0, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9).", 2009. [23.812] "3GPP TR 23.812 V9.0.0, Feasibility Study on the Security Aspects of Remote Provisioning and Change of Subscription for M2M Equipment; (Release 9).", 2009. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007. Sarikaya & Xia Expires August 20, 2010 [Page 12] Internet-Draft Prefix Delegation February 2010 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires August 20, 2010 [Page 13]