idnits 2.17.1 draft-chen-softwire-ce-non-pd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2012) is 4309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-softwire-4rd (ref. 'I-D.ietf-softwire-4rd') == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-01 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-softwire-stateless-4v6-motivation-03 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Standards Track July 9, 2012 5 Expires: January 10, 2013 7 Parameter Provisioning with non-DHCP-PD in Carrier-side Stateless 8 Solution 9 draft-chen-softwire-ce-non-pd-00 11 Abstract 13 The deployment of carrier-side stateless solution requires some 14 particular considerations in mobile network contexts. The widely 15 existed legacy network restricts the development of IP address 16 provisioning based on DHCP-PD. The memo provided several potential 17 approaches to facilitate the issues and provide the possibilities 18 leveraging 3GPP mechanism. The stateless algorithm is required to be 19 updated depending to the preferred solution accordingly. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 10, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Using IID to carry EA-bits . . . . . . . . . . . . . . . . 4 65 2.3. Changing ND behaviour to deliver IPv6 prefix . . . . . . . 4 66 2.4. Combination of DHCPv4v6 Approach . . . . . . . . . . . . . 5 67 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The work item of carrier-side stateless has been chartered and 78 motivation has been described in 79 [I-D.ietf-softwire-stateless-4v6-motivation]. Several candidates 80 solutions have been designed to meet the demands, such as 81 4rd[I-D.ietf-softwire-4rd] and MAP-E, MAP-T[I-D.ietf-softwire-map]. 82 Regarding the configuration rule provisioning, a particular DHCPv6 83 option have been proposed to assign mapping rules to CE nodes. 84 Mapping rules may serve to derive IPv4 address depending on delegated 85 CE IPv6 prefix. Since the potential dependency between IPv4 and IPv6 86 is existing, CE IPv6 prefix inserted with EA-bits is presumably 87 delegated using DHCP-PD[RFC3633]. 89 IPv6 prefix delegation is a feature of 3GPP Release-10 and is not 90 covered by any earlier releases[RFC6459]. In another words, when the 91 case is coming down to a mobile network contexts, those provisioning 92 should require 3GPP Release 10 or beyond network, which is not 93 deployed anywhere today. Some implementations may consider the lack 94 of the functionalities to use static configuration on mobile 95 terminals, but such solution is not scale well, especially facing 96 several million of customers. Therefore, the absence of DHCP-PD may 97 become a push-back during the deployment in 3GPP network. 99 This document proposed a number of alternative solutions to the 100 problem, such that the softwires wg can discuss both of them. It is 101 expected that once the softwires wg converges on a preferred 102 solution, the other ones will be removed from the document. 104 2. Possible Solutions 106 2.1. Design Principles 108 In earlier Release 3GPP network, only the /64 prefix could be 109 allocated for each user via SLAAC[RFC4862]. Statelss DHCPv6[RFC3736] 110 is available in those network, but stateful DHCPv6[RFC3315] is not 111 supported. The following solutions is trying to leverage current 112 mobile network. Considering operational approaches to resolve the 113 problems, the document avoid introduce additional protocol changes to 114 existing devices in network sides. The potential changes on UE sides 115 could be easily implemented using user-land codes. A address block 116 could be reserved from addressing plan corresponding to Rule IPv6 117 prefix. Such CE-specific IPv6 prefix can't be delivered through 118 DHCP-PD, but could be achieved through following approaches. 120 2.2. Using IID to carry EA-bits 122 Without IPv6 prefix delegation, network could not assign a prefix 123 shorter than /64. Therefore, a IPv6 prefix with EA-bits might be 124 nowhere to get. One possible approach is to change current port 125 algorithm a bit to get EA-bits from interface identifier (IID), 126 because 3GPP network would assign a IID to user before a global IPv6 127 address is delivered. Referring to Section 9.2.1.1 in 3GPP 128 [TS23.060], IPv6 address allocation is experiencing two phases. 129 Mobile Gateway shall provide an interface identifier to the user in 130 advance to ensure that the link-local address generated by the user 131 does not collide with the link-local address of the mobile gateway. 132 Mobile gateway could deliver such IID so as to carry EA-bits. When 133 mapping rule has delivered to CE at second phase, CE nodes could 134 derive the EA-bits by shifting with length of u-bits and digging the 135 bits with EA length. 137 CE could synthesize a CE IPv6 prefix and address according the 138 algorithm respectively. The translation could be performed 139 afterwards with such CE-generated IPv6 address. Since the system 140 already reserve an address block, there is no address collision risks 141 when transmitting the packages. 143 The pros of the approach is this mechanism doesn't require any 144 changes to 3GPP network. The cons is that requires updates on 145 current algorithm. Distinguishing DHCP-PD and non-PD case is needed 146 to perform EA-bits generation. 148 2.3. Changing ND behaviour to deliver IPv6 prefix 150 IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in 151 [RFC4861] and [RFC4862], is widely available in earlier 3GPP network. 152 Since a IPv6 block have been reserved for CE prefix, this block can 153 be treated as on-line for specific user. Referring to Section 154 9.2.1.1 in 3GPP [TS23.060], UE may send router solicitation message 155 to the mobile gateway on point-to-point link at second phase. Normal 156 process of gateway is to assign a router advertisement message 157 containing /64 prefix heading to UE with A bit set in Prefix 158 Information option. In order to delivery the CE prefix through ND, 159 the gateway should response RA with prefix information option 160 including reserved CE prefix, length of which is usually shorter than 161 /64. The configuration of this prefix option should set O bit and 162 unset A bit. 164 CE receiving the option could set the prefix as CE IPv6 prefix. The 165 process of algorithm can be remained as-is. 167 The pros of the approach is to keep current algorithm with no 168 changes. The cons for that is to increase the provisioning 169 complexity on mobile gateway. 171 2.4. Combination of DHCPv4v6 Approach 173 3GPP network can't support the stateful DHCPv6[RFC3315] process. Any 174 process related to stateful would be failed in 3GPP network. 175 Therefore, the provisioning of mapping rules through DHCPv6 would be 176 restricted to stateless parameters provisioning, like rule IPv4 177 prefix and rule IPv6 prefix. Dynamic information should be retrieved 178 through another way. 3GPP network could support DHCPv4[RFC2131] by 179 indicating to the network within PDP(Packet Data Protocol) activation 180 protocol negotiations. That provides a possibility to carry port- 181 restricted information from DHCPv4 options. In such consideration, 182 port delegation with port mask allocation in 183 [I-D.bajko-pripaddrassign]can be combined with stateless 184 DHCPv6[RFC3736] to populate CE with complete mapping rules. 186 CE could synthesize a CE IPv6 prefix and address according the 187 algorithm respectively, because CE already received sufficient 188 information to generate IPv6 prefix automatically. The translation 189 could be performed afterwards with such CE-generated IPv6 address. 190 Since the system already reserve the address block, there is no 191 duplicated risks when transmitting the packages. 193 The combination of DHCPv4v6 would leverage 3GPP process and doesn't 194 require any change to existing 3GPP system. The cons for this 195 approach would potentially cause doubling PDP counts for earlier 196 release terminals before Release 8. The algorithm should also be 197 needed to update accordingly. 199 3. Conclusions 201 Three aforementioned solutions have been proposed to address issues 202 of non-DHCP-PD provisioning in mobile contexts. It required WG to 203 evaluate the solutions and determine the workaround for the issues. 204 The minimal impacts to 3GPP system are desirable for the preferable 205 solution. 207 4. IANA Considerations 209 This document makes no request of IANA. 211 5. Security Considerations 213 TBD 215 6. References 217 6.1. Normative References 219 [I-D.bajko-pripaddrassign] 220 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 221 "Port Restricted IP Address Assignment", 222 draft-bajko-pripaddrassign-04 (work in progress), 223 April 2012. 225 [I-D.ietf-softwire-4rd] 226 Despres, R., Penno, R., Lee, Y., Chen, G., and S. Jiang, 227 "IPv4 Residual Deployment via IPv6 - a unified Stateless 228 Solution (4rd)", draft-ietf-softwire-4rd-02 (work in 229 progress), June 2012. 231 [I-D.ietf-softwire-map] 232 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 233 S., and T. Murakami, "Mapping of Address and Port (MAP)", 234 draft-ietf-softwire-map-01 (work in progress), June 2012. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 240 RFC 2131, March 1997. 242 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 243 and M. Carney, "Dynamic Host Configuration Protocol for 244 IPv6 (DHCPv6)", RFC 3315, July 2003. 246 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 247 (DHCP) Service for IPv6", RFC 3736, April 2004. 249 [TS23.060] 250 "General Packet Radio Service (GPRS); Service description; 251 Stage 2", June 2012. 253 6.2. Informative References 255 [I-D.ietf-softwire-stateless-4v6-motivation] 256 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 257 Borges, I., and G. Chen, "Motivations for Carrier-side 258 Stateless IPv4 over IPv6 Migration Solutions", 259 draft-ietf-softwire-stateless-4v6-motivation-03 (work in 260 progress), June 2012. 262 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 263 Host Configuration Protocol (DHCP) version 6", RFC 3633, 264 December 2003. 266 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 267 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 268 September 2007. 270 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 271 Address Autoconfiguration", RFC 4862, September 2007. 273 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 274 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 275 Partnership Project (3GPP) Evolved Packet System (EPS)", 276 RFC 6459, January 2012. 278 Author's Address 280 Gang Chen 281 China Mobile 282 No.32 Xuanwumen West Street 283 Xicheng District 284 Beijing 100053 285 China 287 Email: phdgang@gmail.com