Network Working Group B. Sarikaya Internet-Draft F. Xia Intended status: Informational Huawei USA Expires: December 18, 2011 T. Lemon Nominum June 16, 2011 DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks draft-sarikaya-v6ops-prefix-delegation-07.txt Abstract As interest on IPv6 deployment is increasing in cellular networks several migration issues are being raised and IPv6 prefix management is the one addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we address prefix management issues such as the access router offloading delegation and release tasks of the prefixes to a DHCPv6 server using DHCPv6 Prefix Delegation. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g. with a Router Advertisement or using DHCP. We also describe prefix management using Authentication Authorization and Accounting servers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 18, 2011. Copyright Notice Copyright (c) 2011 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 Sarikaya, et al. Expires December 18, 2011 [Page 1] Internet-Draft Prefix Delegation June 2011 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 Simplified 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. MN as Requesting Router in Prefix Delegation . . . . . . . 7 3.4. Prefix Release Procedure . . . . . . . . . . . . . . . . . 8 3.5. Miscellaneous Considerations . . . . . . . . . . . . . . . 8 3.5.1. How to Generate IAID . . . . . . . . . . . . . . . . . 8 3.5.2. Policy to Delegate Prefixes . . . . . . . . . . . . . 9 4. Prefix Delegation Using RADIUS and Diameter . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Sarikaya, et al. Expires December 18, 2011 [Page 2] Internet-Draft Prefix Delegation June 2011 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 packet data network (PDN) gateway [ThreeGPP23401]. +-------------+ | +------+ | | |DHCP | | +-----+ +-----+ +------+ +------+ | |Server| | +------+ | MN |---| BS |---+Access+--+Access+-+ +------+ +-+Border| +-----+ +-----+ | GW | |Router| |IP Network(s)| |Router+-Internet +--+---+ +--+---+ | | +------+ | | +-------------+ +-----+ +-----+ | | +------+ | MN |---| BS |------+ | |AAA | +-----+ +-----+ +--- |Server| +------+ Figure 1: Key elements of a typical cellular network Mobile node (MN) attaches to a base station (BS) through LTE air interface. A BS manages connectivity of UEs and extends connections to an Access Gateway (GW), e.g. the serving gateway (S-GW) in an LTE network. The access gateway and the Access Router (AR) are connected with an IP network. The access router is the first hop router of MNs and it is in charge of address/prefix management. Access router is connected to an IP network which is owned by the operator which is connected to the public Internet via a Border Router. The network contains servers for subscriber management including Quality of Service, billing and accounting as well as Dynamic Host Configuration Protocol (DHCP) server [I-D.ietf-v6ops-v6-in-mobile-networks]. As to IPv6 addressing, because mobile network links are point-to- point (p2p) Per-MN interface prefix model is used [RFC3314], [RFC3316]. 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. This document describes how to use DHCPv6 Prefix Delegation (PD) in mobile networks such as networks based on standards developed by the 3rd Generation Partnership Project (3GPP) and it could easily be Sarikaya, et al. Expires December 18, 2011 [Page 3] Internet-Draft Prefix Delegation June 2011 adopted to Worldwide Interoperability for Microwave Access (WiMAX) Forum as well. In view of migration to IPv6, the number of mobile nodes connected to the network at a given time may become very high. Traditional techniques such as prefix pools are not scalable. In such cases DHCPv6 PD becomes the viable approach to take. 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]. This document uses the terminology defined in [RFC3315], [RFC3314]. [RFC3316] and [RFC3633]. 3. Prefix Delegation Using DHCPv6 Access router refers to the cellular network entity that has DHCP Client. According to [ThreeGPP23401] 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 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: Sarikaya, et al. Expires December 18, 2011 [Page 4] Internet-Draft Prefix Delegation June 2011 +-------+ +----------------------+ +-----------+ | MN | | AR | |DHCP Server| +-------+ |DHCP | Relay | +-----------+ | |Client | Agent | | | +----------------------+ | |1 Initial NW Entry | | |or attach procedure| | |<----------------->| | | |2 Solicit | | |---------> Relay-forward | | | --------------->| | | 3 Relay-reply | | |Advertise <---------------| | |<-------- | | |4 Request | | |---------> Relay-forward | | | --------------->| | | 5 Relay-reply | | |Repl <---------------| | |<-------- | |6 Attach | | | Completed | | |<----------------->| | |7 Router | | | Solicitation | | |------------------>| | | 8 Router | | | Advertisement | | |<------------------| | Figure 2: Prefix request 1. An MN (UE=User Equipment in 3GPP) performs initial network entry and authentication procedures, a.k.a. attach procedure. 2. On successful completion of Step 1, the AR initiates DHCP Solicit procedure to request prefixes for the MN. The DHCP Client in 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 [RFC3315]. The DHCP Client in AR that supports DHCPv6 Prefix Delegation [RFC3633] creates an Identity Association for Prefix Delegation (IA_PD) and assigns it an Identity Association IDentifier (IAID). The client MUST include the IA_PD option in the Solicit message. DHCP Client as Requesting Router MUST set prefix-length field to 64 to request a /64 prefix. Next, the Relay Agent in AR sends Relay-Forward message to the DHCP Server encapsulating Solicit message. Sarikaya, et al. Expires December 18, 2011 [Page 5] Internet-Draft Prefix Delegation June 2011 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 [RFC3315]. Advertise message with IA_PD shows that the DHCP server is capable of delegating prefixes. This message is received encapsulated in Relay-Reply message by the Relay Agent in AR and sent as Advertise message to the DHCP Client in AR. 4. The AR (DHCP Client and Relay Agent) uses the same message exchanges as described in section 18, "DHCP Client-Initiated Configuration Exchange" of [RFC3315] and [RFC3633] to obtain or update prefixes from the DHCP server. The AR (DHCP Client and Relay Agent) 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. This is accomplished by the AR sending a DHCP Request message and the DHCP server sending a DHCP Reply message. 5. AR stores the prefix information it received in the Reply message. 6. A connection between MN and AR is established and the link becomes active. This step completes the PDP Context Activation Procedure in UMTS and PDN connection establishment in LTE networks. 7. The MN MAY send a Router Solicitation message to solicit the AR to send a Router Advertisement message. 8. The AR advertises the prefixes received in IA_PD option to MN with router advertisement (RA) once the PDP Context/PDN connection is established or in response to Router Solicitation message sent from the MN. 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]. DHCP Client in AR acting as RR 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 Stateful address configuration requires a different architecture than shown in Figure 2. There are two function modules in the AR, DHCP Server and DHCP Client. After the initial attach is completed, a connection to the AR is established for the MN. DHCP Client function at the AR as requesting router and DHCP server as delegating router follow Steps 2 through 5 of the procedure shown in Figure 2 to get the new prefix for this interface of MN from IA_PD Option exchange defined in [RFC3633]. Sarikaya, et al. Expires December 18, 2011 [Page 6] Internet-Draft Prefix Delegation June 2011 DHCPv6 client at the MN sends DHCP Request to AR. DHCP Server function at the AR MUST use the IA_PD option received in DHCP PD exchange to assign an address to MN. IA_PD option MUST contain the prefix. AR sends DHCP Reply message to MN containing IA address option (IAADDR). Figure 3 shows the message sequence. MN configures its interface with the address assigned by DHCP server in DHCP Reply message. In Figure 3 AR may be the home gateway of a fixed network to which MN gets connected during MN's handover. +----------+ +--------------+ +-----------+ | MN | | AR | |DHCP Server| | |DHCP | | DHCP |DHCP | +-----------+ | |Client| |Server|Client | +----------+ +--------------+ | Initial NW Entry | | |or attach procedure | | |<-----------------> | | | | DHCP PD exchange | | | similar to Steps 2-5 | | Solicit | of Figure 2 (IA_PD) | |---------------------->| | | Advertise | | |<----------------------| | | Request | | |---------------------->| | | | | | | | | | use prefix in IA_PD | | Reply | to assign IAADDR | |<--------------------- | | Figure 3: Stateful Address Configuration Following PD 3.3. MN as Requesting Router in Prefix Delegation AR may use DHCPv6 prefix delegation exchange to get a delegated prefix shorter than /64 by setting prefix-length field to a value less than 64, e.g. 56 to get a /56 prefix. Each newly attaching MN first goes through the steps in Figure 2 in which AR requests a shorter prefix to establish a default connection with the AR. MN may next request additional /64 prefixes from the AR using DHCPv6 prefix delegation where MN is the requesting router and AR is the delegating router [I-D.ietf-v6ops-3gpp-eps]. In this case the call Sarikaya, et al. Expires December 18, 2011 [Page 7] Internet-Draft Prefix Delegation June 2011 flow is similar to Figure 3. Solicit message must include the IA_PD option with prefix-length field set to 64. MN may request more than one /64 prefixes. AR as delegating router must delegate these prefixes excluding the prefix assigned to the default connection. 3.4. Prefix Release Procedure 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 4 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. +-------+ +-------+ +-----------+ | MN | | AR | |DHCP Server| +-------+ +-------+ +-----------+ | | | | 1 De-registration | | | Handover, or others | | |<--------------------->| | | |2 Relay-forward/Release| | |---------------------->| | | | | |3 Relay-reply/Reply | | |<--------------------- | | | | | | | Figure 4: Prefix Release 3.5. Miscellaneous Considerations 3.5.1. 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 station Equipment Identity (IMEI) uniquely identifies MN's interface and thus corresponds to the MAC address. Sarikaya, et al. Expires December 18, 2011 [Page 8] Internet-Draft Prefix Delegation June 2011 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.2. 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 (IGP, 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 2001:DB8:0::/48, an interface of MN is assigned 2001:DB8:0: 2::/64 prefix. The AR only broadcasts it's /48 or /32 prefix information to Internet. 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 initial network entry procedure Figure 2, AR as Remote Authentication Dial In User Service (RADIUS) client sends Access- Request message with 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. AAA server also provides routing information to be configured for MN on the AR using Framed-IPv6-Route attribute. Using such a process AR can handle initial prefix assignments to MNs but managing lifetime of the prefixes is totally left to the AR. Framed- IPv6-Prefix is not designed to support delegation of IPv6 prefixes. For this Delegated-IPv6-Prefix attribute can be used which is Sarikaya, et al. Expires December 18, 2011 [Page 9] Internet-Draft Prefix Delegation June 2011 discussed next. [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 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 delegates multiple prefixes to the delegating router. The delegating router sends the prefixes to the requesting router using IA_PD Option and AR as RR uses them for MN's as described in Section 3. 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. As in the case of RADIUS, the delegating router sends the prefixes to the requesting router using IA_PD Option and AR as RR uses them for MN's as described in Section 3. 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. IANA Considerations None. Sarikaya, et al. Expires December 18, 2011 [Page 10] Internet-Draft Prefix Delegation June 2011 7. Acknowledgements We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole Troan, Qin Wu, Jouni Korhonen, Cameron Byrne and Jason Lin who provided in depth reviews of this document that have led to several improvements. 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. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [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. [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 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. [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. Sarikaya, et al. Expires December 18, 2011 [Page 11] Internet-Draft Prefix Delegation June 2011 8.2. Informative References [I-D.ietf-v6ops-3gpp-eps] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet System", draft-ietf-v6ops-3gpp-eps-01 (work in progress), May 2011. [I-D.ietf-v6ops-v6-in-mobile-networks] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", draft-ietf-v6ops-v6-in-mobile-networks-05 (work in progress), May 2011. [ThreeGPP23401] "3GPP TS 23.401 V10.3.0, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 10).", 2011. Authors' Addresses Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano, TX 75074 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 Ted Lemon Nominum 2000 Seaport Blvd Redwood City, CA 94063 Phone: Email: mellon@nominum.com Sarikaya, et al. Expires December 18, 2011 [Page 12]