Network Working Group G. Chen Internet-Draft China Mobile Intended status: Standards Track July 9, 2012 Expires: January 10, 2013 Parameter Provisioning with non-DHCP-PD in Carrier-side Stateless Solution draft-chen-softwire-ce-non-pd-00 Abstract The deployment of carrier-side stateless solution requires some particular considerations in mobile network contexts. The widely existed legacy network restricts the development of IP address provisioning based on DHCP-PD. The memo provided several potential approaches to facilitate the issues and provide the possibilities leveraging 3GPP mechanism. The stateless algorithm is required to be updated depending to the preferred solution accordingly. Requirements Language 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 RFC 2119 [RFC2119]. 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 January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Chen Expires January 10, 2013 [Page 1] Internet-Draft ce-non-PD July 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . . 3 2.2. Using IID to carry EA-bits . . . . . . . . . . . . . . . . 4 2.3. Changing ND behaviour to deliver IPv6 prefix . . . . . . . 4 2.4. Combination of DHCPv4v6 Approach . . . . . . . . . . . . . 5 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Chen Expires January 10, 2013 [Page 2] Internet-Draft ce-non-PD July 2012 1. Introduction The work item of carrier-side stateless has been chartered and motivation has been described in [I-D.ietf-softwire-stateless-4v6-motivation]. Several candidates solutions have been designed to meet the demands, such as 4rd[I-D.ietf-softwire-4rd] and MAP-E, MAP-T[I-D.ietf-softwire-map]. Regarding the configuration rule provisioning, a particular DHCPv6 option have been proposed to assign mapping rules to CE nodes. Mapping rules may serve to derive IPv4 address depending on delegated CE IPv6 prefix. Since the potential dependency between IPv4 and IPv6 is existing, CE IPv6 prefix inserted with EA-bits is presumably delegated using DHCP-PD[RFC3633]. IPv6 prefix delegation is a feature of 3GPP Release-10 and is not covered by any earlier releases[RFC6459]. In another words, when the case is coming down to a mobile network contexts, those provisioning should require 3GPP Release 10 or beyond network, which is not deployed anywhere today. Some implementations may consider the lack of the functionalities to use static configuration on mobile terminals, but such solution is not scale well, especially facing several million of customers. Therefore, the absence of DHCP-PD may become a push-back during the deployment in 3GPP network. This document proposed a number of alternative solutions to the problem, such that the softwires wg can discuss both of them. It is expected that once the softwires wg converges on a preferred solution, the other ones will be removed from the document. 2. Possible Solutions 2.1. Design Principles In earlier Release 3GPP network, only the /64 prefix could be allocated for each user via SLAAC[RFC4862]. Statelss DHCPv6[RFC3736] is available in those network, but stateful DHCPv6[RFC3315] is not supported. The following solutions is trying to leverage current mobile network. Considering operational approaches to resolve the problems, the document avoid introduce additional protocol changes to existing devices in network sides. The potential changes on UE sides could be easily implemented using user-land codes. A address block could be reserved from addressing plan corresponding to Rule IPv6 prefix. Such CE-specific IPv6 prefix can't be delivered through DHCP-PD, but could be achieved through following approaches. Chen Expires January 10, 2013 [Page 3] Internet-Draft ce-non-PD July 2012 2.2. Using IID to carry EA-bits Without IPv6 prefix delegation, network could not assign a prefix shorter than /64. Therefore, a IPv6 prefix with EA-bits might be nowhere to get. One possible approach is to change current port algorithm a bit to get EA-bits from interface identifier (IID), because 3GPP network would assign a IID to user before a global IPv6 address is delivered. Referring to Section 9.2.1.1 in 3GPP [TS23.060], IPv6 address allocation is experiencing two phases. Mobile Gateway shall provide an interface identifier to the user in advance to ensure that the link-local address generated by the user does not collide with the link-local address of the mobile gateway. Mobile gateway could deliver such IID so as to carry EA-bits. When mapping rule has delivered to CE at second phase, CE nodes could derive the EA-bits by shifting with length of u-bits and digging the bits with EA length. CE could synthesize a CE IPv6 prefix and address according the algorithm respectively. The translation could be performed afterwards with such CE-generated IPv6 address. Since the system already reserve an address block, there is no address collision risks when transmitting the packages. The pros of the approach is this mechanism doesn't require any changes to 3GPP network. The cons is that requires updates on current algorithm. Distinguishing DHCP-PD and non-PD case is needed to perform EA-bits generation. 2.3. Changing ND behaviour to deliver IPv6 prefix IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in [RFC4861] and [RFC4862], is widely available in earlier 3GPP network. Since a IPv6 block have been reserved for CE prefix, this block can be treated as on-line for specific user. Referring to Section 9.2.1.1 in 3GPP [TS23.060], UE may send router solicitation message to the mobile gateway on point-to-point link at second phase. Normal process of gateway is to assign a router advertisement message containing /64 prefix heading to UE with A bit set in Prefix Information option. In order to delivery the CE prefix through ND, the gateway should response RA with prefix information option including reserved CE prefix, length of which is usually shorter than /64. The configuration of this prefix option should set O bit and unset A bit. CE receiving the option could set the prefix as CE IPv6 prefix. The process of algorithm can be remained as-is. The pros of the approach is to keep current algorithm with no Chen Expires January 10, 2013 [Page 4] Internet-Draft ce-non-PD July 2012 changes. The cons for that is to increase the provisioning complexity on mobile gateway. 2.4. Combination of DHCPv4v6 Approach 3GPP network can't support the stateful DHCPv6[RFC3315] process. Any process related to stateful would be failed in 3GPP network. Therefore, the provisioning of mapping rules through DHCPv6 would be restricted to stateless parameters provisioning, like rule IPv4 prefix and rule IPv6 prefix. Dynamic information should be retrieved through another way. 3GPP network could support DHCPv4[RFC2131] by indicating to the network within PDP(Packet Data Protocol) activation protocol negotiations. That provides a possibility to carry port- restricted information from DHCPv4 options. In such consideration, port delegation with port mask allocation in [I-D.bajko-pripaddrassign]can be combined with stateless DHCPv6[RFC3736] to populate CE with complete mapping rules. CE could synthesize a CE IPv6 prefix and address according the algorithm respectively, because CE already received sufficient information to generate IPv6 prefix automatically. The translation could be performed afterwards with such CE-generated IPv6 address. Since the system already reserve the address block, there is no duplicated risks when transmitting the packages. The combination of DHCPv4v6 would leverage 3GPP process and doesn't require any change to existing 3GPP system. The cons for this approach would potentially cause doubling PDP counts for earlier release terminals before Release 8. The algorithm should also be needed to update accordingly. 3. Conclusions Three aforementioned solutions have been proposed to address issues of non-DHCP-PD provisioning in mobile contexts. It required WG to evaluate the solutions and determine the workaround for the issues. The minimal impacts to 3GPP system are desirable for the preferable solution. 4. IANA Considerations This document makes no request of IANA. Chen Expires January 10, 2013 [Page 5] Internet-Draft ce-non-PD July 2012 5. Security Considerations TBD 6. References 6.1. Normative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-04 (work in progress), April 2012. [I-D.ietf-softwire-4rd] Despres, R., Penno, R., Lee, Y., Chen, G., and S. Jiang, "IPv4 Residual Deployment via IPv6 - a unified Stateless Solution (4rd)", draft-ietf-softwire-4rd-02 (work in progress), June 2012. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, S., and T. Murakami, "Mapping of Address and Port (MAP)", draft-ietf-softwire-map-01 (work in progress), June 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [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. [TS23.060] "General Packet Radio Service (GPRS); Service description; Stage 2", June 2012. 6.2. Informative References [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Chen Expires January 10, 2013 [Page 6] Internet-Draft ce-non-PD July 2012 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-softwire-stateless-4v6-motivation-03 (work in progress), June 2012. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [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. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. Author's Address Gang Chen China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China Email: phdgang@gmail.com Chen Expires January 10, 2013 [Page 7]