idnits 2.17.1 draft-boucadair-behave-ipv6-portrange-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 63 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with non-RFC3849-compliant IPv6 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-01 == Outdated reference: A later version (-01) exists of draft-boucadair-dhcpv6-shared-address-option-00 == Outdated reference: A later version (-09) exists of draft-boucadair-pppext-portrange-option-01 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-01 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft P. Levis 4 Intended status: Informational J-L. Grimault 5 Expires: April 23, 2010 A. Villefranque 6 M. Kassi-Lahlou 7 France Telecom 8 G. Bajko 9 Nokia 10 Y. Lee 11 Comcast 12 T. Melia 13 Alcatel-Lucent 14 O. Vautrin 15 Juniper 16 October 20, 2009 18 Flexible IPv6 Migration Scenarios in the Context of IPv4 Address 19 Shortage 20 draft-boucadair-behave-ipv6-portrange-04 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may contain material 26 from IETF Documents or IETF Contributions published or made publicly 27 available before November 10, 2008. The person(s) controlling the 28 copyright in some of this material may not have granted the IETF 29 Trust the right to allow modifications of such material outside the 30 IETF Standards Process. Without obtaining an adequate license from 31 the person(s) controlling the copyright in such materials, this 32 document may not be modified outside the IETF Standards Process, and 33 derivative works of it may not be created outside the IETF Standards 34 Process, except to format it for publication as an RFC or to 35 translate it into languages other than English. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on April 23, 2010. 55 Copyright Notice 57 Copyright (c) 2009 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents in effect on the date of 62 publication of this document (http://trustee.ietf.org/license-info). 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. 66 Abstract 68 This memo presents a solution to solve IPv4 address shortage and ease 69 IPv4-IPv6 interconnection. The document presents a set of 70 incremental steps for the deployment of IPv6 as a means to solve IPv4 71 address exhaustion. Stateless IPv4/IPv6 address mapping functions 72 are introduced and IPv4-IPv6 interconnection scenarios presented. 73 This memo advocates for a more proactive approach for the deployment 74 of IPv6 into operational networks. 76 This memo specifies the IPv6 variant of the A+P. Both encapsulation 77 and translation scheme are covered. Moreover, two modes are 78 elaborated: the binding mode (compatible mode with DS-lite) and the 79 stateless mode. 81 Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 1.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5 91 1.2. To what extent does IPv6 solve the problem? . . . . . . . 5 92 1.3. Towards a proactive approach . . . . . . . . . . . . . . . 6 93 1.4. Contribution of this draft . . . . . . . . . . . . . . . . 7 94 1.5. Positioning this Draft . . . . . . . . . . . . . . . . . . 7 95 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 3. Reminder of the Port Range Solution . . . . . . . . . . . . . 9 97 4. IPv6-IPv4 Address Mapping Formalism . . . . . . . . . . . . . 10 98 4.1. IPv6 Prefix: Another IPv4-mapped Prefix Scheme . . . . . . 10 99 4.2. IPv4 to IPv6 Address Mapping Function . . . . . . . . . . 12 100 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 13 101 4.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 13 102 4.3. IPv6 to IPv4 Address Mapping Function . . . . . . . . . . 13 103 4.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 104 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14 105 5. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 14 106 5.1. Stateless A+P Mapping gateway (SMAP) Function 107 description . . . . . . . . . . . . . . . . . . . . . . . 14 108 5.2. Implementation modes . . . . . . . . . . . . . . . . . . . 16 109 5.2.1. SMAP to route incoming traffic destined to a 110 shared IPv4 address . . . . . . . . . . . . . . . . . 16 111 5.2.2. No IPv4 capabilities are used anymore between two 112 SMAP-enabled nodes . . . . . . . . . . . . . . . . . . 17 113 5.3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 17 114 5.4. SMAP and PRR . . . . . . . . . . . . . . . . . . . . . . . 19 115 6. IPv6 Migration Scenarios . . . . . . . . . . . . . . . . . . . 19 116 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 6.2. IPv6 Prefixes and Addresses . . . . . . . . . . . . . . . 20 118 6.3. On Stateless and Binding Table Modes . . . . . . . . . . . 21 119 6.3.1. Stateless Mode . . . . . . . . . . . . . . . . . . . . 21 120 6.3.2. Binding Table Mode . . . . . . . . . . . . . . . . . . 22 121 6.4. Step_0: IPv6 at Access Network . . . . . . . . . . . . . . 22 122 6.4.1. Context . . . . . . . . . . . . . . . . . . . . . . . 23 123 6.4.2. Overall Procedure . . . . . . . . . . . . . . . . . . 23 124 6.4.3. Focus on Communication Establishment . . . . . . . . . 26 125 6.4.4. Typical Flow Example . . . . . . . . . . . . . . . . . 27 126 6.5. Step_1: IPv6 a Means to Transfer Incoming IPv4 Packets . . 28 127 6.5.1. Context . . . . . . . . . . . . . . . . . . . . . . . 28 128 6.5.2. Overall Procedure . . . . . . . . . . . . . . . . . . 28 129 6.6. Step_2: Only IPv6 Is Used For Both Incoming and 130 Outgoing Traffic . . . . . . . . . . . . . . . . . . . . . 31 131 6.6.1. Context . . . . . . . . . . . . . . . . . . . . . . . 31 132 6.6.2. The IPv6 Encapsulation-Based Mode . . . . . . . . . . 32 133 6.6.3. The IPv6 Translation-Based Mode . . . . . . . . . . . 37 134 6.7. Analysis and IPv6 Migration Scenarios . . . . . . . . . . 42 136 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 137 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 138 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 139 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 140 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 141 10.2. Informative References . . . . . . . . . . . . . . . . . . 46 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 144 1. Introduction 146 1.1. IPv4 Address Exhaustion 148 It is commonly agreed by the Internet community that the exhaustion 149 of public IPv4 addresses is an ineluctable fact. Regular alarms and 150 reports have been emitted by the IETF particularly by the reports 151 presented within the GROW working group (Global Routing Operations 152 Working Group) meetings. 154 G. Huston introduced an extrapolation model to forecast the 155 exhaustion date of IPv4 addresses managed by IANA. This effort 156 indicates that if the current tendency of consumption continues at 157 the same pace, IPv4 addresses exhaustion of IANA's pool would occur 158 in 2011, while RIRs'pool would be exhausted in mid-2012. The state 159 of the current consumption of public IPv4 addresses is daily updated 160 and is available at this URL: 161 http://www.potaroo.net/tools/ipv4/index.html. 163 1.2. To what extent does IPv6 solve the problem? 165 In this context, the community was mobilized in the past to adopt a 166 promising solution (in particular with the definition of IPv6). IPv6 167 has been introduced for several years as the next version of the IP 168 protocol. This new version offers an abundance of IP addresses as 169 well as several enhancements compared to IPv4. IPv6 specifications 170 are mature and current work within the IETF is related to operational 171 aspects. Despite this effort, IPv6 is not globally activated by 172 service providers for both financial and strategic reasons. 174 However, even if a service provider activates IPv6, it will be 175 confronted with the problem to ensure a global connectivity towards 176 nowadays Internet v4. Mechanisms such as NAT-PT (Network Address 177 Translation Protocol Translation) were introduced to ensure the 178 interconnection between two heterogeneous realms (i.e. IPv4/IPv6) 179 and to ensure a continuity of IP communications (i.e. End-to-end). 180 These solutions are stateful and are not suitable to interconnect an 181 IPv6 domain with a dominant Internet which is IPv4-only. Further 182 work should be undertaken with IETF to elaborate lightweight and 183 hopefully stateless solution to ease IPv4-IPv6 interconnection. 184 Moreover, Service providers should adopt clear strategies so as to 185 ease the adoption of IPv6 and to decrease the complexity related to 186 IPv4-IPv6 interconnection which is one of the critical issues to be 187 taken into account when designing service platforms. 189 Last, it is worth to mention that migrating to IPv6 is a service 190 provider issue and not the one of its customers. The ultimate 191 requirement of the customers (mainly residential and mass market) is 192 to benefit from a global IP connectivity. How this connectivity is 193 engineered and put into effect is of the business of the IP 194 connectivity service providers. Of course, some corporate customers 195 would specify the nature of their IP connectivity and reduce the 196 interconnection engineering complexity of their interconnection nodes 197 with the domain of their IP connectivity service provider(s). From 198 this standpoint, service providers should be more proactive in order 199 to avoid a crisis scenario where no IP addresses are available to be 200 assigned to their customers. 202 1.3. Towards a proactive approach 204 The introduction of IPv6 into public networks becomes a reality. 205 Several Internet providers have enabled IPv6 in their routers and 206 launched therefore their IPv6 migration operations. The portion of 207 the IPv6-enabled routers differs between SPs. The current trade is 208 that operators offer dual connectivity to their customers, i.e. IPv4 209 and IPv6 access. IPv4 connectivity usage should be gradually 210 decreased in favour of IPv6 one. This convergence phase towards a 211 pure IPv6 connectivity will take several years depending on the 212 policies adopted by service providers. For operators that adopt an 213 aggressive position with regards to the activation of IPv6, this 214 transition phase could be small compared to passive operators. 215 Nevertheless the overall Internet IPv6 coverage will be long. This 216 is due mainly to the significant number of involved actors to be 217 convinced for a full migration towards IPv6, the significant number 218 of existing ASes (more than 30000), etc. Moreover, customers do not 219 have any reason to modify their local architecture (e.g., a given 220 organisation does not have any motivations to migrate its FTP or HTTP 221 servers towards IPv6). Operators must expect a long work of 222 accompaniment for the migration towards IPv6. The final migration 223 towards IPv6 would take several years (at least 10 years). 225 This migration to IPv6 should be incremental and not implemented in 226 one shot. For these reasons, service providers should elaborate 227 migration scenarios so as to achieve a transparent migration. This 228 transparency is required because end-users should not be aware on the 229 underlying technology used to deliver their subscribed services and 230 the complexity related to service engineering should be hidden to 231 end-users. Furthermore, service providers should use means to 232 prioritise IPv6 traffic and the invocation of IPv6 transfer 233 capabilities without relying on end-users behaviour. IPv6 transfer 234 capabilities should be exploited and not considered as dormant ones. 235 If no proactive means/procedures are adopted, the ratio of IPv6 236 traffic will depend on the behaviour of end-users and also on 237 available IPv6 services. 239 Furthermore, in the perspective of IPv6 migration, the maintenance 240 and the operating of dual connectivity infrastructure would therefore 241 be required for a long period. This option is not to be encouraged 242 within service providers since it does not optimise both OPEX/CAPEX. 243 Both technical skills should be maintained within each individual 244 organisation. As an alternative, this document proposes a proactive 245 and incremental deployment approach which consists at: 247 - Activation of IPv6 and port range IPv4 solution at the same time. 248 Port-restricted devices are provisioned with an IPv6 prefix, a shared 249 IPv4 public address and a port range. 251 - Activation of stateless functions and use of IPv6 to carry IPv4 252 traffic from/to port-restricted devices. 254 - Migration to IPv6-only core network. 256 - Maintain stateless IPv4-IPv6 interconnection functions at 257 interconnection segment to not alter intra-domain paths. 259 1.4. Contribution of this draft 261 This memo defines several solutions to solve the IPv4 address 262 shortage problem and to migrate to IPv6 without requiring stateful 263 nodes. It proposes also several migration paths. This target IPv6 264 deployment is a long term objective and can be reached incrementally 265 through one or several intermediate steps. These intermediate steps 266 perimeters differ from a service provider to another one depending on 267 the service opportunities targeted by enabling IPv6-related 268 capabilities and also on the level of risks on the already running 269 (IPv4-based) services. Risks on existing services should be 270 assessed. Careful or aggressive position may be adopted by each 271 service provider. Service providers are free to deploy the step/the 272 migration path suitable to their context and objectives, etc. This 273 document only sketches scenarios and interconnection configurations. 274 Voluntarily, no frozen architecture is described. Several options 275 are supported. 277 This document provides: 279 o solution specification 281 o and deployment scenarios together with migrations paths. 283 1.5. Positioning this Draft 285 This draft proposes a solution to solve both IPv4 address exhaustion 286 and IPv4-IPv6 interconnection. Unlike 287 [I-D.ietf-softwire-dual-stack-lite], no additional NAT is required to 288 be deployed at the service provider's network. Both encapsulation 289 and translation modes are presented in this memo. 291 A set of issues related to IPv4 Internet access in the context of 292 public IPv4 address exhaustion are identified and described in 293 [I-D.levis-behave-ipv4-shortage-framework]. 295 2. Terminology 297 Within the context of this draft, the following terminology is used: 299 o Access segment: This segment encloses both IP access and backhaul 300 network. Within this document, this access segment encompass an 301 access PoP. 303 o Core network: Denotes a set of IP networking capabilities and 304 resources which are between the interconnection and the access 305 segments. 307 o Interconnection segment: Includes all nodes and resources which 308 are deployed at the border of a given AS (Autonomous System) a la 309 BGP (Border Gateway Protocol). 311 o PRR: Stands for Port Range Router. This function is responsible 312 to handle a port-based routing. This function may retrieve the 313 port value and use it to determine which routing action is to be 314 executed or use it together with the destination IP address to 315 build an IPv6 address. 317 o Interconnection PRR (i-PRR): A PRR which is deployed at 318 interconnection segment. 320 o Access PRR (a-PRR): A PRR which is deployed at access segment. 322 o SMAP: Stands for Stateless A+P Mapping. This function is 323 responsible to encapsulate (Resp. decapsulate), in a stateless 324 scheme, IPv4 packets in (Resp. from) IPv6 ones. A SMAP function 325 may be hosted in a PRR, end-user device, etc. 327 o Port-restricted device (PRD): A device which is able to constrain 328 its source port number to be within a given Port Range. A port 329 restricted device may be of several types such as: 331 * CPE (Customer Premise Equipment)/HGW (Home Gateway) 333 * PDA (Personal Digital Assistant) 334 * Mobile terminal 336 3. Reminder of the Port Range Solution 338 This section is a reminder of the solution presented in 339 [I-D.boucadair-port-range]. 341 The main principle of the solution is to assign the same IP address 342 (called Primary IP Address) to several end-users' devices and to 343 constraint the source port numbers to be used by each device. In 344 addition to the assigned IP address to access IP connectivity 345 services, an additional parameter, called Port Range, is also 346 assigned to the customer's device. For outbound communications, a 347 given port restricted device proceeds to its classical operations 348 except the constraint to control the source port number assignment so 349 as to be within the Port Range. The traffic is then routed without 350 any modification inside the Service Provider's domain and delivered 351 to its final destination. For inbound communications, the traffic is 352 trapped by a dedicated function called: Port Range Router (PRR). 353 This function may be embedded in current routers or hosted by new 354 nodes to be integrated in the IP infrastructure of these service 355 providers. Appropriate routing tuning policies are enforced so as to 356 drive the inbound traffic to cross a PRR. Each PRR correlate the 357 Primary IP Address and information about the allowed port values with 358 a specific identifier called: routing identifier (e.g., Private IPv4 359 address, IPv6 address, point-to-point link identifier, etc). This 360 routing identifier is used to route the packets to the suitable 361 device among all those having the same IP address. 363 Port-restricted devices are provisioned with port range to be used, 364 especially the Port Mask to be applied when selecting a port value as 365 a source port. A Port Mask defines a set of ports that all have in 366 common a subset of pre-positioned bits. This set of ports is also 367 called Port Range. Two port numbers are said to belong to the same 368 Port Range if and only if, they have the same Port Mask. A Port Mask 369 is composed of a Port Range Value and a Port Range Mask. 371 o The Port Range Value indicates the value of the significant bits 372 of the Port Mask. The Port Range Value is coded as follows: 374 * The significant bits may take a value of 0 or 1. 376 * All the other bits (non significant ones) are set to 0. 378 o The Port Range Mask indicates, by the bit(s) set to 1, the 379 position of the significant bits of the Port Range Value. 381 0 1 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Mask 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | | 387 | | | (3 significant bits) 388 v v v 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Value 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |0 0 1 x x x x x x x x x x x x x| Usable ports (x may take a value of 0 or 1). 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 1: Example of Port Range Mask and Port Range Value 399 An example of port range is provided in Figure 1. Ports belonging to 400 this port range must have the 1st bit (Resp. the 2nd and 3rd), from 401 the left, set to 0 (Resp. 0 and 1). The Port Mask is represented as: 402 001xxxxxxxxxxxxx. 404 4. IPv6-IPv4 Address Mapping Formalism 406 This section discusses issues related to the building of an IPv6 407 prefix or IPv6 address using IPv4-related information: 409 4.1. IPv6 Prefix: Another IPv4-mapped Prefix Scheme 411 [I-D.boucadair-port-range] proposes to assign the same public IPv4 412 address together with a port range to several devices. In order to 413 discriminate those devices, an additional identifier called, routing 414 identifier, is required. This identifier may be a secondary IPv4 415 address, PPP session identifier, etc. This document assumes that 416 this identifier is an IPv6 address. This prefix is built using IPv4- 417 related information as illustrated in Figure 2. 419 +------------------------+----------+---------+ 420 | Pref6 | @IPv4 | PRM | 421 +------------------------+----------+---------+ 422 Max. 423 <-----------n bits------> < 32 bits> <16 bits > 424 <-----------------64 bits max.----------------> 426 Figure 2: IPv6 prefix enclosing an IPv4 address and a port range 428 1. The length of this prefix is recommended to be less than 64 bits; 430 2. Pref6: is a sub-prefix belonging to the service provider or well- 431 known prefix allocated by IANA for this service. The length of 432 this field is variable (may be different from a service provider 433 to another if not allocated by IANA). The Pref6 prefix used to 434 build an IPv4-mapped IPv6 prefix may not be the same as the one 435 used to execute the IPv4-to-IPv6 mapping function introduced in 436 Section 4.2. 438 3. @IPv4 field encloses the shared IPv4 address. The length of this 439 field is 32 bits; 441 4. PRM field includes the value of the significant bits of the Port 442 Range. The maximum length of this field is 16 bits. But, in 443 deployment scenarios this field may be 3, 4 or 5 bits. If n bits 444 are used to build the PRM, the same IPv4 address may be shared 445 between 2^n port-restricted devices. 447 For illustration purposes two examples are provided below. 449 Let suppose that a service provider dedicates the 2a01:c0a8::/29 to 450 build an IPv4-inferred IPv6 prefix. In this example, we suppose that 451 8 port restricted devices share the same public address 452 193.51.145.206 owing to a port range mask with three significant bits 453 (i.e. the three first bits are used to build the port mask. The 454 remaining 13 bits may take a 0 or 1 value ), yielding 8192 (2^16/2^3) 455 possible ports per each port-restricted device. The corresponding 456 IPv6Pref prefixes for these 8 port-restricted devices are thus the 457 following ones: 459 - 1st port-restricted device (Port Mask: 000xxxxxxxxxxxxx): 461 IPv6Pref = 2a01:c0a 1 11000001001100111001000111001110 000 :: 462 --------193.51.145.206---------- PRM 464 IPv6Pref = 2a01:c0aE:099C:8E70::/64 466 - 2nd port-restricted device (Port Mask: 001xxxxxxxxxxxxx): 468 IPv6Pref = 2a01:c0a 1 11000001001100111001000111001110 001 :: 469 --------193.51.145.206---------- PRM 471 IPv6Pref = 2a01:c0aE:099C:8E71::/64 473 - ... 475 - 8th port-restricted device (Port Mask: 111xxxxxxxxxxxxx): 477 IPv6Pref = 2a01:c0a 1 11000001001100111001000111001110 111 :: 478 --------193.51.145.206---------- PRM 480 IPv6Pref = 2a01:c0aE:099C:8E77::/64 482 In this second example, let suppose that the service provider 483 dedicates the 2a01:c::/20 prefix to build an IPv4-mapped IPv6 prefix. 484 If we consider that 193.51.145.206 address is shared between 16 (2^4, 485 4 bits are used as the significant bits of the port range) port- 486 restricted devices. The 16 port-restricted devices sharing that 487 address have the following IPv6Pref prefixes (only the first prefix 488 is represented below): 490 - 1st port-restricted device (Port Mask: 0000xxxxxxxxxxxx): 492 IPv6Pref = 2a01:c 11000001001100111001000111001110 0000 :: 493 --------193.51.145.206---------- PRM- 495 IPv6Pref = 2a01:cc13:391c:e0::/56 497 - ... 499 4.2. IPv4 to IPv6 Address Mapping Function 500 4.2.1. Overview 502 Within this memo, IPv4-to-IPv6 address mapping function denotes a 503 function which uses IPv4-related information, as conveyed in a 504 received IPv4 packet, to generate IPv6 one. This function generates 505 an IPv6 address which builds as illustrated in Figure 3. 507 o Pref6 is configured by the service provider. 509 o Then, the next 32 bits are set to the value of the destination 510 IPv4 address; 512 o The next 16 bits are set to the value of the destination port 513 number; 515 o The remaining bits are then set to zeros. 517 +----------------------------------------------------------------------...+ 518 | Pref6 |Dest. IPv4 |Dest. | 0:0:0:0 | 519 | |address |port | | 520 +----------------------------------------------------------------------...+ 522 Figure 3: Pref6A Address Format 524 4.2.2. Example 526 Let suppose that a given device is provided with the Pref6 prefix 527 equal to 2a01:c0a8::/29. Then the corresponding IPv6 address, using 528 the IPv4-to-IPv6 address mapping function, to the IPv4 address equal 529 to 193.51.145.206 and the port number equal to 19039 530 (0100101001011111) is the following: 532 IPv6PrefA=2a01:c0a 1 11000001001100111001000111001110 0100101001011111 :: 533 --------193.51.145.206--------- -----port------- 535 IPv6PrefA=2a01:c0aE:099C:8E72:52F8::/128 537 This IPv6 address falls in the IPv6 prefix of the second port- 538 restricted device (port range 001) as listed in the previous section. 540 4.3. IPv6 to IPv4 Address Mapping Function 541 4.3.1. Overview 543 Unlike the previous function, the IPv6-to-IPv4 address mapping 544 functions generates an IPv4 address together with a port number from 545 the header and the transport part of a received IPv6 packet as 546 follows: 548 o The destination IPv4 address corresponds to the 32 bits which 549 follow a per-configured Provider prefix; 551 o Destination port number is equal to the one of the received IPv6 552 packet. 554 4.3.2. Example 556 Let suppose that the Pref6 prefix equal to 2a01:c0a8::/29 is used. 557 Then the corresponding IPv4 address, resulting from the IPv6-to-IPv4 558 address mapping function applied to the address 2a01:c0aE:099C:8E71: 559 A5F8::/128 is 193.51.145.206 since: 561 2a01:c0aE:099C:8E71:A5F8 = 563 2a01:c0a 1 11000001001100111001000111001110 0100101001011111 :: 564 --------193.51.145.206--------- -----port------- 566 5. Stateless A+P Mapping Function 568 5.1. Stateless A+P Mapping gateway (SMAP) Function description 570 Stateless A+P Mapping gateway (SMAP) consists in two basic functions 571 as described in Figure 4. 573 1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4 574 address, in IPv6 one. The IPv6 source address is constructed 575 (see Section 4.2) from the IPv4 source address and port number 576 plus the IPv6 prefix which has been provisioned to the node 577 performing the SMAP function. The destination IPv6 address is 578 constructed using the shared IPv4 destination address and port 579 number plus the IPv6 prefix which has been provisioned to the 580 SMAP function and which is dedicated to IPv4 destination 581 addresses. 583 2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones which 584 have IPv6 source addresses belonging to the prefix of the node 585 performing the SMAP function. Extracted IPv4 packets are then 586 forwarded to the point identified by the IPv4 destination address 587 and port number. 589 +-------------------+ 590 | |----IPv6---\ 591 ----IPv4---\| |----IPv4---\\ 592 -----------/| |-----------// 593 | |-----------/ 594 | SMAP | 595 | | /--IPv6----- 596 /---IPv4----| |//---IPv4---- 597 \-----------| |\\----------- 598 | | \----------- 599 +-------------------+ 601 Figure 4: Stateless A+P Mapping Gateway Function 603 A SMAP-enabled node will perform the stateless 6/4 mapping function 604 for all public shared IPv4 addresses for which it was designated as a 605 stateless 6/4 mapping gateway. 607 To perform stateless 6/4 mapping function a SMAP gateway must: 609 o be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway 610 uses this prefix to construct IPv6 source addresses for all IPv4 611 shared addresses for which it was designated as a SMAP gateway. 612 The IPv6 prefix may be provisioned statically or dynamically 613 (e.g., DHCP) 615 o be able to know the IPv6 prefix of the node serving as another 616 SMAP gateway for IPv4 destination addresses. This prefix may be 617 known in various ways: 619 * Default or Well known prefix which was provisioned statically 620 or dynamically; 622 * Retained at the reception of incoming IPv4-in-IPv6 encapsulated 623 packets; 625 * Discovered at the communication starting thanks to mechanisms 626 as DNS resolution for example. 628 When the SMAP-enabled node receives IPv4 packets with IPv4 source 629 addresses for which it was not designated as a SMAP gateway, it will 630 not perform stateless 6/4 mapping function for those packets. Those 631 packets will be handled in a classical way (i.e., forwarded, dropped 632 or locally processed). 634 When the SMAP-enabled node receives IPv6 packets with IPv6 addresses 635 which do not match with its IPv6 prefix, it will not perform the 636 stateless 6/4 mapping function for those packets. Those packets will 637 be handled in a classical way (i.e., forwarded, dropped or locally 638 processed). 640 5.2. Implementation modes 642 Stateless mapping function may be achieved in two main modes. Those 643 modes consist in mapping the traffic only in one direction or in the 644 two directions as described below. 646 5.2.1. SMAP to route incoming traffic destined to a shared IPv4 address 648 IPv4 traffic with shared IPv4 source addresses are forwarded by the 649 node A without performing stateless mapping function. This traffic 650 will reach its destination thanks to a classical routing. In the 651 opposite direction, the traffic sent by the destination has to pass 652 by the node B which performs the stateless mapping function 653 (encapsulating in IPv6 packets) before forwarding to the node A. The 654 node A performs the stateless mapping function (extract IP v4 655 packets) before forwarding IPv4 packets to the points identified by 656 the IPv4 destination addresses and port number. In this case, both 657 IPv4 and IPv6 traffic are routed in the network between the nodes A 658 and B. 660 +----------+ 661 --IPv4---|----------|------------IPv4--------------------\ 662 ---------|----------|------------------------------------/ 663 | | 664 | +------+ | +------+ 665 | | | | /----IPv6-----| | 666 /--IPv4--| | SMAP | |//---IPv4---- | SMAP |/---IPv4---- 667 \--------| | | |\\----------- | |\----------- 668 | | | | \-------------| | 669 | +------+ | +------+ 670 | | 671 +----------+ 672 node A node B 674 Figure 5: First Configuration 676 5.2.2. No IPv4 capabilities are used anymore between two SMAP-enabled 677 nodes 679 In this configuration, the node A performs the stateless mapping 680 function on the received IPv4 traffic (encapsulated in IPv6 packets) 681 before forwarding to the node B. The node B performs the stateless 682 mapping function on the received IPv6 traffics (extracting IPv4 683 packets) before forwarding the IPv4 traffic to the destination 684 identified by the IPv4 destination address and port number. In the 685 opposite direction and as previously, the node B performs the 686 stateless mapping function on the received IPv4 traffics 687 (encapsulating in IPv6 packets) before forwarding to the node A. The 688 node A performs the stateless mapping function on the received IPv6 689 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic 690 to the point identified by the IPv4 destination address and port 691 number. In this case, only IPv6 traffic is managed in the network 692 segment between the nodes A and B. 694 +------+ +------+ 695 | |----IPv6---\ | | 696 ----IPv4---\| |----IPv4---\\| |----IPv4---\ 697 -----------/| |-----------//| |-----------/ 698 | |-----------/ | | 699 | SMAP | | SMAP | 700 | | /----IPv6---| | 701 /---IPv4----| |//---IPv4----| |/---IPv4---- 702 \-----------| |\\-----------| |\----------- 703 | | \-----------| | 704 +------+ +------+ 705 node A node B 707 Figure 6: Second Configuration 709 5.3. Deployment Scenarios 711 Several deployment scenarios of the SMAP function may be envisaged in 712 the context of Port Range based solutions: 714 o A SMAP function is embedded in a port-restricted device. Other 715 SMAP-enabled nodes are deployed in the boundaries between IPv6- 716 enabled realms and IPv4 ones. This scenario may be particularly 717 deployed for intra-domain communications so as to interconnect 718 heterogeneous realms (i.e., IPv6/IPv4) within the same AS. 720 o A SMAP function is embedded in a port-restricted device. Other 721 SMAP-enabled nodes are deployed in the interconnection segment 722 (with adjacent IPv4-only ones) of a given AS. This deployment 723 scenario is more suitable for service providers targeting the 724 deployment of IPv6 since it eases the migration to full IPv6. 725 Core nodes are not required to activate anymore both IPv4 and IPv6 726 transfer capabilities. 728 Other considerations regarding the interconnection of SMAP-enabled 729 domains should be elaborated. The following provides a non 730 exhaustive list of interconnection schemes. 732 o The interconnection of two domains implementing the SMAP function 733 may be deployed via IPv4 Internet (Figure 7): This means that IPv4 734 packets encapsulated in IPv6 one are transferred using IPv6 until 735 reaching the first SMAP-node. Then these packets are de- 736 encapsulated and are forwarded using IPv4 transfer capabilities. 737 A remote SMAP-enabled node will receive those packets and proceeds 738 to an IPv4-in-IPv6 encapsulation. These packets are then routed 739 normally until reaching the port-restricted devices which de- 740 encapsulates the packets. 742 +------+ +------+ +--------+ +------+ +------+ 743 | |--IPv6---\ | | | | | |---IPv6--\ | | 744 | |--IPv4---\\| |---|-IPv4---|--\| |---IPv4--\\| | 745 | |---------//| |---|--------|--/| |---------//| | 746 | |---------/ | | |Internet| | |---------/ | | 747 | SMAP | | SMAP | | IPv4 | | SMAP | | SMAP | 748 | | /---IPv6--| | | | | | /---IPv6--| | 749 | |//---IPv4--| |/--|-IPv4---|---| |//--IPv4---| | 750 | |\\---------| |\--|--------|---| |\\---------| | 751 | | \---------| | | | | | \---------| | 752 +------+ +------+ +--------+ +------+ +------+ 753 Source node A node B Destination 755 Figure 7: Interconnection Scenario 1 757 o A second scheme is to interconnect two realms implementing the 758 SMAP function using IPv6 (Figure 8). Two sub-scenarios are 759 identified: 761 * An IPv6 prefix (i.e., Pref6) assigned by IANA is used for this 762 service. If appropriate routing configuration have been 763 enforced, then the IPv6 encapsulated packets will be routed 764 until the final destination. 766 * If an IPv6 belonging a service provider prefix is used. This 767 will be covered in the next versions of the document. 769 +------+ +------------+ +------+ 770 | | | | | | 771 | |----IPv6-----|----IPv6----|----IPv6----\ | | 772 | |----IPv4-----|------------|----IPv4----\\| | 773 | |-------------|------------|------------//| | 774 | |-------------|------------|------------/ | | 775 | SMAP | | Internet v6| | SMAP | 776 | | /-----IPv6--|------------|-----IPv6-----| | 777 | |//---IPv4----|------------|-------IPv4---| | 778 | |\\-----------|------------|--------------| | 779 | | \-----------|------------|--------------| | 780 | | | | | | 781 +------+ +------------+ +------+ 782 Source Destination 784 Figure 8: Interconnection Scenario 2 786 5.4. SMAP and PRR 788 Within this draft, a PRR-enabled node implements both SMAP function 789 and required functions to handle fragmentation and other protocols 790 which do not require a transport protocol. More details about 791 fragmentation may be found at [I-D.boucadair-port-range]. 793 In the remaining part, the text refers only to PRR and not SMAP. 795 6. IPv6 Migration Scenarios 797 6.1. Overview 799 This section proposes a set of migration steps in the context of IPv4 800 address exhaustion and IPv6 deployment. Both objectives are taken 801 into account. 803 The proposed steps are informational. An analysis of these steps and 804 proposed IPv6 migration paths are discussed in Section 6.7. 806 The following figure (i.e., (Figure 9)) provides an overview of 807 network segments and the localisation of PRR-enabled nodes. One or 808 several PRR may be enabled. PRD1 and PRD2 are two port-restricted 809 devices which have been provisioned with the same IP1 public address 810 and two distinct port ranges (PR1 and PR2). 812 +---------+ +---------------------+ +----------+ +---------+ 813 +----+ | | | | | +-----+ | |IPv4 | 814 |PRD1|----| |--| |--| |i-PRR| |--|Internet | 815 +----+ | +-----+ | | | | | | | +---------+ 816 IP1, PR1 | |a-PRR| | | core network | | +-----+ | 817 | +-----+ | | | | | 818 +----+ | | | | | | +---------+ 819 |PRD2|----| | | | | |--|IPv6 | 820 +----+ | | | | | | |Internet | 821 IP1, PR2 +---------+ +---------------------+ +----------+ +---------+ 822 access/ interconnection 823 backhaul segment 825 Figure 9: Reference Architecture 827 6.2. IPv6 Prefixes and Addresses 829 Different types of IPv6 prefixes and addresses are used in the scope 830 of the solutions described in the document (i.e., Step_0 831 (Section 6.4), Step_1 (Section 6.5) and Step_2 (Section 6.6)). 832 Theses prefixes and addresses are listed hereafter: 834 1. IPv6Pref: A prefix allocated to the port-restricted device. A 835 packet sent to addresses belonging to this prefix are routed 836 toward this port-restricted device. IPv6Pref prefix addresses 837 may also be used to send and receive native IPv6 traffic. In 838 stateless IPv6-IPv4 Address Mapping mode (as explained above), 839 the IPv6Pref structure is related to the IPv4 address plus port 840 range. In binding mode, IPv6Pref and IPv4 address plus port 841 range are independent. 843 2. IPv6PrefA: An address belonging to IPv6Pref prefix used to send 844 IPv4-in-IPv6 traffic. 846 3. Pref6: An IPv6 prefix (e.g., /24, /32) common to all of the IPv6 847 packets which must be routed to a PRR function. It is for 848 further study to decide whether this prefix is to be: 850 A. Service provider scope 852 B. or common to all service providers (to be defined by IANA). 854 Both alternatives are compatible with the proposed solutions. 856 4. Pref6A: An address belonging to the Pref6 prefix. A Pref6A 857 address includes the Pref6 prefix on its left most part followed 858 by the destination IPv4 address and destination port number, as 859 shown in Figure 3. When a binding table is implemented, a given 860 a-PRR has to transform a destination address Pref6A to a 861 destination address IPv6PrefA, it proceeds as illustrated in 862 Figure 10. 864 +-------------------------------------+-------------------------------------+ 865 | | | | | 866 | Pref6 |public IPv4 |Dest. | 0:0:0:0 | 867 | |address |port | | 868 +---------------------------------------------------------------------------+ 869 | || | 870 || 871 vv 872 +--------------------------------------------------+ 873 | binding table | 874 | | 875 |(...) | 876 | [public IPv4 address, Port Range] => IPv6PrefA | 877 |(...) || | 878 +---------------------------------------------||---+ 879 || 880 /====================/ 881 || 882 \/ 883 +---------------------------------------------------------------------------+ 884 | | 885 | IPv6PrefA | 886 | | 887 +---------------------------------------------------------------------------+ 889 Figure 10: Fetching IPv6PrefA from WKIPv6A 891 The following sections describe three migration steps and a set of 892 proposed migration paths. The proposed solutions are stateless at 893 interconnection segment. A binding table may be implemented to meet 894 requirements of service providers which do not want to closely 895 correlate their IPv6 address plan and the IPv4 one. More details are 896 provided below. 898 6.3. On Stateless and Binding Table Modes 900 6.3.1. Stateless Mode 902 Complete stateless mapping implies that the IPv4 address and the 903 significant bits coding the port range are reflected inside the IPv6 904 prefix assigned to the port-restricted device. Two alternatives are 905 offered when such a stateless mapping is to be enabled: 907 - either using the IPv6 prefix already used for native IPv6 908 traffic, 910 - or provide two prefixes to the port-restricted device: one for 911 the native IPv6 traffic and one for the IPv4 traffic. 913 Note that: 915 - Providing two IPv6 prefixes has the advantages of allowing a /64 916 prefix for the port-restricted device along with another prefix 917 (e.g., a /56 or /64) for native IPv6 traffic. This alternative 918 spares the service provider to relate the native IPv6 traffic 919 addressing plan to the IPv4 addressing plan. The drawback is the 920 burden to allocate two prefixes to each port-restricted device and 921 to route them. In addition, an address selection issue may be 922 encountered. 924 - Providing one prefix for both needs (e.g., a /56 or a /64) 925 spares the service provider to handle two types of IPv6 prefix for 926 the port-restricted device and in routing tables. But the 927 drawback is that it somewhat links strongly the IPv4 addressing 928 plan to the allocated IPv6 prefixes. 930 6.3.2. Binding Table Mode 932 Another alternative is to assign a "normal" IPv6 prefix to the port- 933 restricted device and to use a binding table, which can be hosted by 934 a service node, to correlate the (shared IPv4 address, Port Range) 935 with an IPv6 address part of the assigned IPv6 prefix. For 936 scalability reasons, this table should be instantiated within PRR- 937 enabled nodes which are close to the port-restricted devices. The 938 number of required entries if hosted at interconnection segment would 939 be equal to the amount of subscribed users (one per port-restricted 940 device). 942 The stateless mode is recommended. 944 6.4. Step_0: IPv6 at Access Network 946 This step is described in [I-D.boucadair-port-range]. This step 947 assumes that IPv6 is used to convey incoming traffic to its final 948 destination. For this reason, an IPv6 address is used as the routing 949 identifier. More information about this step is provided below. 951 6.4.1. Context 953 This step can be deployed at earlier stages of IPv6 deployment. The 954 impact on routing (especially path optimisation) and also offered 955 services is the same as for the Port Range solution described in 956 [I-D.boucadair-port-range]. The service brokenness risk is 957 optimized. IPv6 is used in this step as a means to convey incoming 958 IPv4 traffic. Within this step, IPv6 is used in the access segment 959 to deliver the received IPv4 traffic. 961 When this step is deployed, at least 50% of the handled traffic 962 (incoming+outgoing), at the IP access segment, of a service 963 provider's domain is achieved using IPv6 capabilities. IPv4 964 capabilities are used only for outgoing traffic. 966 Native IPv6 connectivity may also be offered to end-users. 968 6.4.2. Overall Procedure 970 This section discusses additional points related to IPv6 usage in the 971 context of the Port Range solution described in 972 [I-D.boucadair-port-range]. 974 6.4.2.1. Provisioning Operations 976 This section lists the set of information required for a port- 977 restricted device to access the connectivity service. 979 6.4.2.1.1. IP Connectivity Information 981 Each port-restricted device is assigned with: 983 1. A shared public IPv4 address. In addition to this address, a 984 port range is also assigned to the device. 986 2. An IPv6 prefix: denominated in the rest as IPv6Pref. This prefix 987 is allocated to the port-restricted device and it is used to 988 discriminate (a given device) among all those having the same 989 public IPv4 address. This address may be used also to send and 990 receive native IPv6 traffic or a second prefix may be assigned 991 specific for native IPv6 traffic. 993 6.4.2.1.2. Provisioning procedure 995 To convey IPv4 configuration information, one of these solutions may 996 be implemented: 998 1. Activate DHCP and support port range options as described in 999 [I-D.bajko-pripaddrassign]; 1001 2. Use PPP and support the IPCP Port Range Configuration Options as 1002 specified in [I-D.boucadair-pppext-portrange-option]. 1004 To convey IPv6 configuration information, DHCPv6 [RFC3315] may be 1005 activated. When several IPv4-inferred IPv6 address structures are 1006 supported, options defined in 1007 [I-D.boucadair-dhcpv6-shared-address-option] can be used. 1009 6.4.2.2. Port Restricted Device's behaviour and supported functions 1011 A port-restricted device may be a host, a CPE, etc. 1013 6.4.2.2.1. Port Restriction Behaviour 1015 The behaviour of the port-restricted device is as follows: 1017 1. If the port-restricted device hosts a NAT function: For incoming 1018 traffic, the port-restricted device checks if the destination 1019 port number is within the Port Range, otherwise the packet is 1020 dropped. When the destination port number of a received packet 1021 (from outside the LAN) falls inside the Port Range, classical NAT 1022 operations are enforced and the packet is then routed to its 1023 final destination in the LAN. 1025 2. Otherwise, the port-restricted device is an end-user host: the 1026 device restricts its source port numbers to be with the assigned 1027 Port Range. Received IPv4 packets with a destination port number 1028 outside the Port Range must be dropped. 1030 6.4.2.2.2. Handling Outgoing traffic 1032 The same procedure as described in [I-D.boucadair-port-range] 1033 applies. In addition to the normal NAT operations, the port- 1034 restricted device ensures that the source port number is within the 1035 allowed Port Range. 1037 6.4.2.2.3. Handling Incoming traffic 1039 For incoming traffic, two cases may be considered: 1041 1. IPv6 encapsulated traffic: for encapsulated IPv6 packets, the 1042 port-restricted device de-encapsulates the packets and extracts 1043 the embedded IPv4 one. The original IPv4 packets is then treated 1044 and handled locally. If the destination port of that packet is 1045 within the Port Range of that port-restricted device, and 1046 depending on the local NAT implementation if any, the packet may 1047 be accepted and then proceed to classical NAT operation. 1048 Otherwise, the packet is dropped. 1050 2. IPv6 native traffic: No constraint is required. The traffic 1051 should be routed to it final destination, if the port-restricted 1052 device is a CPE. 1054 6.4.2.3. PRR Behaviour 1056 6.4.2.3.1. Supported functions 1058 In addition to the functions listed in [I-D.boucadair-port-range], 1059 the PRR must support an IPv6 encapsulation function. 1061 6.4.2.3.2. Localization 1063 The PRR function is deployed under the same conditions as the ones 1064 discussed in [I-D.boucadair-port-range]. 1066 6.4.2.3.3. Behaviour 1068 The PRR intervenes only for incoming traffic destined to a shared 1069 IPv4 address. 1071 a. If a binding table is implemented: This binding table stores the 1072 required information to route the traffic destined to a shared IP 1073 address to the appropriate port-restricted device among all those 1074 sharing the same IP address. An IPv6 prefix may be used as 1075 routing identifier. In this case, the structure of the binding 1076 table is: (shared IPv4 address, Port Range) ==> IPv6 prefix. 1077 Instead of the IPv6 prefix itself (IPv6Pref), the binding table 1078 may contain a specific address under IPv6Pref (called in the rest 1079 IPv6PrefA). When a binding table is adopted, the IPv6 prefix 1080 assigned to a port-restricted device is not constrained. There 1081 is no need for the service provider to allocate two different 1082 IPv6 prefixes to the port-restricted devices (one for native IPv6 1083 traffic and another one for the IPv4 encapsulated traffic). Only 1084 one may suffice for the two needs. 1086 b. Stateless mapping: The service provider assigns an IPv4 shared 1087 address, a port range and an IPv6 prefix with IPv6 prefix 1088 containing explicitly the IPv4 address and the significant bits 1089 of the port range (i.e., Bits used to built the Port Range Mask, 1090 see [I-D.bajko-pripaddrassign]). When a stateless mapping is 1091 adopted, it is possible that the service provider has to cope 1092 with constraints when allocating the IPv6 prefix and the shared 1093 IPv4 address to the port-restricted devices. As a matter of fact 1094 the IPv6 prefix must reflect the shared IPv4 address. 1095 Alternatively the service provider may instead allocate two 1096 different prefixes for the two needs (IPv6 native traffic and 1097 IPv4 encapsulated traffic). 1099 In the remaining part of this section, "PRR retrieves the 1100 corresponding IPv6 prefix address" means that: 1102 a. If a binding table is implemented: the PRR looks-up through this 1103 table and retrieves the IPv6Pref or IPv6PrefA corresponding to 1104 (IPv4 address, Port Range). If IPv6Pref is retrieved, the PRR 1105 builds an IPv6Pref address in complementing the IPv6Pref with a 1106 fixed bit sequence chosen by the service provider to be always 1107 the same complementary bit sequence for all port-restricted 1108 devices. . 1110 b. Stateless mode: an IPv6 prefix address (i.e., IPv6PrefA) is built 1111 using the IPv4 address and the destination port number. 1113 In both cases, when the PRR has got/built the corresponding IPv6PrefA 1114 , the PRR encapsulates the original packets in an IPv6 one with a 1115 destination IP address equal to the IPv6Pref address. The source 1116 IPv6 address is an address of the PRR. It may be an anycast IPv6 1117 address or unicast one. 1119 This packet is then routed according to instantiated IGP routes. 1121 6.4.2.4. Routing considerations 1123 The same IGP considerations as detailed in [I-D.boucadair-port-range] 1124 should be taken into account. In addition to these considerations, 1125 IPv6 routes should be installed to reach port-restricted devices from 1126 an IPv6-enabled PRR. 1128 6.4.3. Focus on Communication Establishment 1130 6.4.3.1. Outgoing IPv4 Communications 1132 Outgoing IPv4 traffic is handled as described in 1133 [I-D.boucadair-port-range]. The traffic issued from a port- 1134 restricted device is routed to its final destination. The traffic is 1135 not altered and is transferred to its final destination. 1137 6.4.3.2. Incoming IPv4 Communications 1139 Owing to IGP configuration, the traffic destined to a shared IP 1140 address must cross a PRR. This latter encapsulates the received IPv4 1141 packets in IPv6 ones as described in Section 6.4.2.3.3. The traffic 1142 is then routed using the IPv6PrefA as a destination address. The 1143 traffic is received by the device among those sharing the same IPv4 1144 address (because this port-restricted device is allocated with this 1145 IPv6Pref). A de-encapsulation operation is then executed as 1146 described in Section 6.4.2.2. If the de-encapsulated IPv4 traffic is 1147 destined to a port within the assigned Port Range, the traffic is 1148 accepted, otherwise it is dropped. 1150 6.4.3.3. Outgoing IPv6 Communications 1152 Since the port-restricted device is IPv6-enabled, native IPv6 1153 communications may be offered. This assumes that the service 1154 provider has deployed means for IPv6 transfer capability. The same 1155 prefix used to convey incoming IPv4 traffic (IPv6Pref) may be used 1156 also to send and receive native IPv6 traffic. Alternatively, a 1157 second IPv6 prefix may be assigned to that purpose. 1159 6.4.3.4. Incoming IPv6 Communications 1161 Native IPv6 communications are supported. 1163 6.4.4. Typical Flow Example 1165 In order to illustrate this step, let consider the example shown in 1166 the following figure (Figure 11). M1 is a machine behind a port- 1167 restricted device (called CPE as Customer Port restricted Equipment 1168 in the example and Figure 11). 1170 M1 wants to establish an IPv4 communication with RM (Remote Machine). 1171 To do so, an IPv4 packet is issued by M1. This packet has as source 1172 IP address equal to Pri_IPv4. The packet is then received by CPE. 1173 This latter enforces its NAT operations. As a result, an IPv4 packet 1174 with a source IP address equal to Pub_IPv4 and a source port number 1175 within the Port Range of CPE is sent. The resulting packet is 1176 forwarded according to IPv4 transfer capabilities until reaching its 1177 final destination RM. 1179 As a response, RM sends an IPv4 packet destined to Pub_IPv4 and a 1180 destination port number equal to the source port number of the 1181 received packet. This message is received by PRR. The PRR 1182 encapsulates the received IPv4 packet in an IPv6 one. The resulting 1183 IPv6 packet is then forwarded. The encapsulated packet is received 1184 by the appropriate CPE among those having the same IPv4 address. A 1185 de-encapsulation is enforced. The original IPv4 packet is extracted. 1186 Once classical NAT operations are executed, the CPE forwards the IPv4 1187 packet to M1. 1189 +--+ +---+ +--+ 1190 |M1| |CPE| |RM| 1191 +--+ +---+ +--+ 1192 | | | 1193 |==Pri_IPv4_Out==>|===============Pub_IPv4_Out===============>| 1194 | | | 1195 | | +---+ | 1196 | | |PRR| | 1197 | | +---+ | 1198 | | | | 1199 |<==Pri_IPv4_In===|<==IPv6_Enc(Pub_IPv4_In)==|<==Pub_IPv4_In==| 1200 | | | | 1202 Figure 11: Flow Example (Step 0): Inter-domain 1204 6.5. Step_1: IPv6 a Means to Transfer Incoming IPv4 Packets 1206 6.5.1. Context 1208 Step_1 is characterized by the activation of two levels of PRR 1209 functions in several segments of a given service provider's network. 1210 Some PRR-enabled nodes are deployed close to the port-restricted 1211 devices (e.g., In the access or backhaul network) whilst others are 1212 installed at the interconnection segment of the service provider's 1213 network as shown in Figure 9. 1215 The objective of this step is to maximize the invocation of IPv6 1216 capabilities, particularly to convey incoming IPv4 traffic until 1217 delivery to final destination (e.g., port-restricted device). 1219 6.5.2. Overall Procedure 1221 Step_1 works exactly the same way as that the Step_0, apart what is 1222 specified in this section. In particular, there are none difference 1223 between Step_0 and Step_1 at the level of the port-restricted device. 1225 6.5.2.1. Routing considerations 1227 - a-PRR: As in Step_0, a-PRR announces the shared IPv4 prefixes it 1228 serves. In addition, in case of binding table mode, it announces 1229 in IGP the aggregates of all the Pref6A addresses of the port- 1230 restricted devices it serves so that IPv4-in-IPv6 packets reach 1231 this a-PRR. 1233 - i-PRR: i-PRR announces in EGP (if embedded in an ASBR node) or 1234 in IGP (if deployed behind an ASBR), all (aggregated) IPv4 1235 prefixes of all port-restricted devices it can route packets to 1236 (via a-PRR in case of binding table). Depending of the structure 1237 of the service provider network, some i-PRR-enabled nodes may be 1238 positioned inside the service provider network to encapsulate more 1239 IPv4 traffic into IPv6. For example, from a region A to another 1240 region B of the service provider's network. 1242 6.5.2.2. Behaviour of a-PPR and i-PRR 1244 Figure 12 show the respective role of a-PRR and i-PRR-enabled nodes. 1245 The labels of the arrows are explained in further sub-sections. 1247 - CPE1 (Customer Port restricted Equipment) is a port-restricted 1248 device 'served' by a-PRR (means that a-PRR announces in IGP the 1249 assigned shared IPv4 address to CPE1). 1251 - CPE2 is a device of another customer connected to the network 1252 managed by the same service provider. It may be either another 1253 port-restricted device or a device with a plain IPv4 address. 1255 - RM is a remote machine located outside the AS managed by the 1256 service provider. 1258 +----+ +-----+ +-----+ 1259 |CPE1| |i-PRR| | RM | 1260 +----+ +-----+ +-----+ 1261 | | | 1262 |<=====IPv6PrefA_Enc(Pub_IPv4_In)=======|<===Pub_IPv4_In===| 1263 | | | 1264 | | | 1265 | +-----+ 1266 | |a-PRR| 1267 | +-----+ +----+ 1268 | | |CPE2| 1269 | | +----+ 1270 | | | 1271 |<==IPv6PrefA_Enc |<==Pub_IPv4_In==| 1272 | (Pub_IPv4_In)==| | 1273 | | | 1275 Figure 12: Step_1: Stateless mode 1277 +----+ +-----+ +-----+ +-----+ 1278 |CPE1| |a-PRR| |i-PRR| | RM | 1279 +----+ +-----+ +-----+ +-----+ 1280 | | | | 1281 |<==IPv6PrefA_Enc |<==Pref6A_Enc |<===Pub_IPv4_In===| 1282 | (Pub_IPv4_In)==| (Pub_IPv4_In)=| | 1283 | | | | 1284 | | 1285 | | 1286 | | +----+ 1287 | | |CPE2| 1288 | | +----+ 1289 | | | 1290 |<==IPv6PrefA_Enc |<==Pub_IPv4_In==| 1291 | (Pub_IPv4_In)==| | 1292 | | | 1294 Figure 13: Step_1: Binding table mode 1296 6.5.2.2.1. Localization 1298 The PRR function is deployed under the same conditions as in Step_0 1299 but as previously mentioned more PRR-enabled nodes are deployed 1300 within the service provider's network. 1302 6.5.2.2.2. Stateless Mapping Mode 1304 In case the service provider assigns an IPv4 shared address, a port 1305 range and an IPv6 prefix containing explicitly the IPv4 address and 1306 the significant bits of the port range, i-PRR-nodes are able to build 1307 the IPv6Pref address of the port-restricted device using the IPv4 1308 destination address and destination port bits of received IPv4 1309 packets. 1311 Hence, i-PPR behaviour is the same one as the PRR one described in 1312 Step_0, when stateless mapping is enforced. In that case, the IPv4- 1313 in-IPv6 packet does not pass through the a-PRR but it is routed 1314 directly to the port-restricted device (e.g., To CPE1 as depicted in 1315 Figure 12). 1317 6.5.2.2.3. Binding Table Mode 1319 This behaviour is illustrated in Figure 13. 1321 If a binding table is implemented within a-PRR, i-PRR-enabled nodes 1322 can not hold all the binding table entries corresponding to all the 1323 port-restricted devices it may route traffic for. Consequently, it 1324 has to route the IPv4 traffic towards the a-PRR of which the port- 1325 restricted device depends. More precisely, a given i-PRR 1326 encapsulates the incoming IPv4 traffic in IPv6 packets using the 1327 following addresses: 1329 - The source IPv6 address is one of the global IPv6 addresses of 1330 the i-PRR. 1332 - The destination IPv6 is built by i-PRR using an address under 1333 the Pref6 prefix conforming to the formalism defined in 1334 Section 4.2. This address, called Pref6A, includes the Pref6 1335 prefix on its left most part and the destination IPv4 address and 1336 destination port number in this right most part. 1338 Thus, an i-PRR-enabled node routes normally this IPv4-in-IPv6 packet 1339 (labeled Pref6A_Enc (Pub_IPv4_In) in Figure 13) using IPv6 transfer 1340 capabilities. The packet is routed towards the a-PRR serving the 1341 recipient port-restricted device (CPE1 is Figure 13) since 1342 appropriate routing configuration has been enforced (see 1343 Section 6.5.2.1). 1345 Upon receipt of that packet, the a-PRR proceeds as follows: 1347 - It retrieves the IPv4 shared address and port bits parts of the 1348 Pref6A address. Then, with these parts it looks-up through its 1349 binding table to fetch the IPv6PrefA corresponding to the couple 1350 (IPv4 address, Port Range). 1352 - Once retrieved, the a-PRR positions the IPv6PrefA address as the 1353 destination address in place of the Pref6A address and forwards 1354 the packet. The IPv4-in-IPv6 packet is routed until reaching the 1355 port-restricted device (CPE1 in Figure 13). 1357 As shown in Figure 13 (bottom part), when another machine (CPE2) 1358 within the same service provider's domain sends traffic to the port- 1359 restricted device CPE1, the working of a-PRR is the same one as that 1360 of the PRR is Step_0. 1362 6.6. Step_2: Only IPv6 Is Used For Both Incoming and Outgoing Traffic 1364 6.6.1. Context 1366 This step is suitable for service providers wishing to migrate to 1367 full IPv6 and to offer a global connectivity using IPv6. This step 1368 provides a lightweight procedure to interconnect IPv6 with IPv4 1369 realms. This procedure may be fully stateless or require a binding 1370 table. This table does not include session-based information. 1372 Only IPv6 connectivity is used inside the service provider's domain; 1373 IPv4 capabilities are deactivated. No parallel IPv4 and IPv6 1374 operational tasks will be maintained anymore in the core segment. 1376 Two implementation modes may be envisaged: 1378 1. Encapsulation-based mode: This mode suggests using both inbound 1379 and outbound IPv6 encapsulation to carry IPv4 traffic (received 1380 from the remaining IPv4-only realms). This mode is almost 1381 similar to Step_1 for handling incoming IPv4 packets. Unlike 1382 Step_1, the required operations to build the outgoing 1383 encapsulated packets is also supported in this step. 1385 2. Translation-based mode: Unlike the first mode, this one assumes 1386 that there is no need to maintain both IPv4 and IPv6 stacks in 1387 the CPE. It is recommended to implement this mode when mature 1388 IPv6 deployment has been observed and that IPv6 realms become 1389 more important than IPv4-only ones. 1391 More information about these two modes is provided in the sub- 1392 sections hereafter. 1394 6.6.2. The IPv6 Encapsulation-Based Mode 1396 6.6.2.1. Provisioning Operations 1398 6.6.2.1.1. IP Connectivity Information 1400 In addition to the information required for Step_1, a Pref6 IPv6 1401 prefix may e configured on the port-restricted device. This prefix 1402 is to be used when running the IPv4-to-IPv6 mapping function required 1403 to encapsulate IPv4 traffic in IPv6 one. 1405 6.6.2.1.2. Provisioning Procedure 1407 Idem as Step_1. 1409 6.6.2.2. Routing Considerations 1411 IPv4 IGP protocols are not anymore enabled in the core network. Only 1412 IPv6 routing table is maintained by involved routers. 1414 Inter-domain IPv4 connectivity is maintained with IPv4-only realms. 1415 IPv4 network prefixes are mapped to IPv6 prefixes (using a Pref6 1416 configured by the service provider) which are injected in the 1417 deployed IPv6 IGP protocol. 1419 A given a-PRR MUST advertise in IGP the aggregated IPv6 prefixes it 1420 handles. Doing so, all intra-domain IPv6 packets will cross that 1421 PRR. 1423 6.6.2.3. Port Restricted Device's Behaviour and Supported Functions 1425 6.6.2.3.1. Port Range Restriction 1427 Idem as Step_1. 1429 6.6.2.3.2. Handling Outgoing Traffic 1431 Unlike Step_1, outgoing IPv4 traffic is encapsulated in IPv4-in-IPv6 1432 packets. Concretely, the port-restricted device executes its port 1433 restricted NAT operations (if any). The resulting IPv4 packet is 1434 then encapsulated in an IPv6 packet. The port-restricted device 1435 selects an IPv6 address from its assigned IPv6 prefix (IPv6Pref). 1436 This address IPv6PrefA is used as the source IPv6 address of the 1437 encapsulated packet. 1439 Two options may be considered to build the destination IPv6 address 1440 of the encapsulated packet as listed below: 1442 1. The port-restricted device is provisioned to use an anycast IPv6 1443 address. This anycast IPv6 address is configured on internal 1444 interfaces of all PRRs. This mode is may be implemented when the 1445 port-restricted device is not able to build a destination IPv6 1446 address reflecting the IPv4 address and port of its correspondent 1447 (i.e., the port-restricted device does not support the mapping 1448 function defined in Section 4.2). 1450 2. The port-restricted device is able to build an IPv6 address using 1451 a Pref6 prefix (which may be distinct than the one used to build 1452 mapped IPv6 prefixes by i-PRRs), the destination IPv4 address and 1453 the destination port number. 1455 No constraints are to be followed for outgoing native IPv6 traffic. 1457 6.6.2.3.3. Handling Incoming Traffic 1459 Idem as Step_1. 1461 6.6.2.4. PRR Behaviour 1463 6.6.2.4.1. Supported Functions 1465 In addition to the functions supported in Step_1, an IPv4-in-IPv6 de- 1466 encapsulation function must be supported by a-PRR. 1468 6.6.2.4.2. Localization 1470 Idem as Step_1. 1472 6.6.2.4.3. Behaviour: Stateless Mode 1474 The behaviour of both access and interconnection PRRs is elaborated 1475 below: 1477 1. If an anycast IPv6 address is configured on interfaces of all 1478 a-PRRs: 1480 * An (access) PRR will receive the encapsulated packet issued 1481 from port-restricted devices. The packet is de-encapsulated 1482 and the original IPv4 one is retrieved. Then, the (access) 1483 PRR builds a destination IPv6 address using a Pref6 prefix, 1484 the destination IPv4 address and the destination port number. 1485 The original IPv4 packet is then encapsulated in IPv6 packet 1486 with a source IPv6 address of the (access) PRR and the 1487 destination IPv6 address equal to the newly built one. The 1488 packet is forwarded to next hop according to IPv6 routing 1489 table. If the correspondent is not a port-restricted device, 1490 the packet is intercepted by a-PRR or a i-PRR depending of 1491 where the correspondent is located. This a-PRR or i-PRR 1492 proceeds to the de-encapsulation operation. The extracted 1493 IPv4 packet is then forwarded to the IPv4 correspondent. This 1494 encapsulated packet is received by an (access/ 1495 interconnection) PRR which proceeds to a de-encapsulation 1496 operation. The extracted IPv4 packet is then forwarded to the 1497 next IPv4 hop. 1499 * Incoming IPv4 traffic is intercepted by an (interconnection) 1500 PRR. The PRR encapsulates the received IPv4 packet in an IPv6 1501 one using the following information: 1503 + The source IPv6 address is one of the global IPv6 addresses 1504 of the PRR. 1506 + The destination IPv6 is built by the PRR using the 1507 formalism defined in Section 4.2. This address is build 1508 using a Pref6 prefix, the destination IPv4 address and the 1509 destination port number. The appropriate port-restricted 1510 device, among those having the same IPv4 address, will 1511 receive the packet. This is illustrated in Figure 14. 1513 +---+ +-----+ +-----+ +--+ 1514 |CPE| |a-PRR| |i-PRR| |RM| 1515 +---+ +-----+ +-----+ +--+ 1516 | | | | 1517 |=IPv6_Enc(Pub_IPv4_Out)==>|=Pref6A_Enc(Pub_IPv4_Out)==>|==Pub_IPv4_Out=>| 1518 | | | | 1519 | | | | 1520 |<=========IPv6PrefA_Enc(Pub_IPv4_In)===================|<==Pub_IPv4_In==| 1521 | | | | 1522 | | | | 1524 LAN messages are not represented in the figure. 1526 Figure 14: Encapsulation Mode: Anycast addresses are 1527 assigned to all PRR 1529 2. Otherwise, all internal IPv4 traffic is encapsulated by the port 1530 restricted device in IPv4-in-IPv6 packets (the destination IPv6 1531 address is the one built by the port-restricted device, see 1532 Section 4.2). As in the first bullet, the packet is forwarded to 1533 next hop according to IPv6 routing table. If the correspondent 1534 is not a port-restricted device, the packet is intercepted by 1535 a-PRR or a i-PRR depending of where the correspondent is located. 1536 This a-PRR or i-PRR proceeds to the de-encapsulation operation. 1537 The extracted IPv4 packet is then forwarded to the IPv4 1538 correspondent. The same behaviour as for the first bullet 1539 applies for incoming IPv4 traffic. A flow is illustrated in 1540 Figure 15. 1542 +---+ +-----+ +--+ 1543 |CPE| |i-PRR| |RM| 1544 +---+ +-----+ +--+ 1545 | | | 1546 |=======Pref6A_Enc(Pub_IPv4_Out)================>|====Pub_IPv4_Out=>| 1547 | | | 1548 | | | 1549 |<======IPv6PrefA_Enc(Pub_IPv4_In)===============|<==Pub_IPv4_In====| 1550 | | | 1552 Figure 15: Encapsulation Mode: the port restricted device builds 1553 a destination IPv6 address 1555 6.6.2.4.4. Behaviour: Binding Table Mode 1557 The behaviour of both access and interconnection PRRs is elaborated 1558 below: 1560 1. If an anycast IPv6 address is configured on interfaces of all 1561 a-PRRs: 1563 * An (access) PRR will receive the encapsulated packets issued 1564 from port-restricted devices. The packets are de-encapsulated 1565 and the original IPv4 is retrieved. Then, the (access) PRR 1566 builds a destination IPv6 address using a Pref6 prefix and the 1567 destination IPv4 address. The original IPv4 packets are then 1568 encapsulated in IPv6 packet with a source IPv6 address of the 1569 (access) PRR and the destination IPv6 address equal to the 1570 newly built one. The packet is forwarded to next hop 1571 according to IPv6 routing table. The packet is intercepted by 1572 a-PRR or a i-PRR depending of where the correspondent is 1573 located. This a-PRR or i-PRR proceeds to the de-encapsulation 1574 operation. The extracted IPv4 packet is then forwarded to the 1575 IPv4 correspondent. 1577 * Incoming IPv4 traffic is intercepted by an (interconnection) 1578 PRR. The PRR encapsulates the received IPv4 packet in an IPv6 1579 one using the following information: 1581 + The source IPv6 address is one of the global IPv6 addresses 1582 of the PRR. 1584 + The destination IPv6 is built by the PRR using the 1585 formalism defined in Section 4.2. This address is build 1586 using a Pref6 prefix, the destination IPv4 address and the 1587 destination port number. The appropriate a-PRR managing 1588 the destination port-restricted device, among those having 1589 the same IPv4 address, will receive the packet. This is 1590 illustrated in Figure 16. The PRR de-encapsulates the 1591 packet and retrieves the original IPv4 packet. The access 1592 PRR retrieves the destination address IPv6PrefA stored in 1593 its binding table and forwards the packet to the port 1594 restricted device. 1596 +---+ +-----+ +-----+ +--+ 1597 |CPE| |a-PRR| |i-PRR| |RM| 1598 +---+ +-----+ +-----+ +--+ 1599 | | | | 1600 |==IPv6_Enc(Pub_IPv4_Out)=>|=Pref6A_Enc(Pub_IPv4_Out)==>|==Pub_IPv4_Out=>| 1601 | | | | 1602 |<==IPv6_Enc(Pub_IPv4_In)==|<==Pref6A_Enc(Pub_IPv4_In)==|<==Pub_IPv4_In==| 1603 | | | | 1605 LAN messages are not represented in the figure. 1607 Figure 16: Encapsulation Mode with a Binding table 1608 (Anycast) 1610 2. Otherwise, all internal IPv4 traffic is encapsulated by the port 1611 restricted device in IPv4-in-IPv6 packets. As in the first 1612 bullet, the packet is forwarded to next hop according to its IPv6 1613 routing table. The packet is intercepted by a-PRR or a i-PRR 1614 depending of where the correspondent is located. This a-PRR or 1615 i-PRR proceeds to the de-encapsulation operation. The extracted 1616 IPv4 packet is then forwarded to the IPv4 correspondent. The 1617 same behaviour as for the first bullet applies for incoming IPv4 1618 traffic. A flow example is illustrated in Figure 17. 1620 +---+ +-----+ +--+ 1621 |CPE| |i-PRR| |RM| 1622 +---+ +-----+ +--+ 1623 | | | 1624 |================Pref6A_Enc(Pub_IPv4_Out)===============>|=Pub_IPv4_Out=>| 1625 | | | 1626 | +-----+ | | 1627 | |a-PRR| | | 1628 | +-----+ | | 1629 | | | | 1630 |<=IPv6PrefA_Enc(Pub_IPv4_In)|<=Pref6A_Enc(Pub_IPv4_In)==|<=Pub_IPv4_In==| 1631 | | | | 1633 Figure 17: Encapsulation Mode with a Binding table 1635 6.6.3. The IPv6 Translation-Based Mode 1637 6.6.3.1. Context and Conditions 1639 This mode assumes that IPv6-only terminals are deployed behind port- 1640 restricted devices. Particularly, all DNS resolution requests are 1641 AAAA ones [RFC3363] . Only IPv6 addresses are conveyed in DNS 1642 responses to requesting machines. 1644 A dedicated ALG should be supported by the DNS infrastructure 1645 deployed by the service provider. The main function of this ALG is 1646 to form an IPv6 address based on a Pref6 prefix and a resolved IPv4 1647 address, when no AAAA RR are available in the DNS system (following 1648 the formalism described in Section 4.2). The Pref6 prefix is 1649 configured by the service provider so as to identify that the 1650 resulting IPv6 address is not a native one. We refer to this IPv6 1651 prefix as Pref6_v4. The procedure is illustrated in Figure 18. 1653 +--+ +---+ +---+ 1654 |M1| |CPE| |DNS| 1655 +--+ +---+ +---+ 1656 | | | 1657 |==(1)Request(AAAA)==>|==(2)Request(AAAA)==>| 1658 | | | 1659 | | +------ALG------+ 1660 | | |No available | 1661 | | |AAAA Records, | 1662 | | +------| |------+ 1663 | | | | | | 1664 | | +-------v-------+ 1665 | | | Return IPv4@ | 1666 | | | Build IPv6@ | 1667 | | +-------+-------+ 1668 | | | 1669 |<=(4)Response(IPv6@)=|<=(3)Response(IPv6@)=| 1670 | | | 1672 Figure 18: DNS ALG 1674 In the remaining part of this section, it is assumed that M1 has 1675 retrieved an IPv6 address to contact. 1677 6.6.3.2. Flow Example 1679 Figure 19 shows a message exchange that occurs in the context of 1680 IPv6-IPv4 communications. 1682 +--+ +---+ +-----+ +--+ 1683 |M1| |CPE| |i-PRR| |RM| 1684 +--+ +---+ +-----+ +--+ 1685 | | | | 1686 |==(1)IPv6_Out==>|==(2)IPv6_Out===>|==(3)Pub_IPv4_Out==>| 1687 | | | | 1688 |<==(6)IPv6_In===|<==(5)IPv6_In====|<===(4)Pub_IPv4_In==| 1689 | | | | 1691 Figure 19: Translation Mode 1693 Intra-domain communications are placed using IPv6 transfer 1694 capabilities. When the remote destination is an IPv4 (which is 1695 represented by an IPv6 address), the following exchanges are 1696 observed: 1698 1. M1 issues an IPv6 message destined to RM. 1700 2. Once received by the CPE, this latter checks if the destination 1701 address belongs to the Pref6_v4 prefix. If this is the case, a 1702 NAT66 operation is executed. As a result, a new IPv6 packet is 1703 generated. 1705 3. This message is received by the interconnection PRR. It 1706 retrieves IPv4 information based on IPv6 one and translates the 1707 packet to a new IPv4 one. 1709 4. This message is then routed using IPv4 capabilities of the 1710 connected IPv4-only realm. 1712 5. Once received by RM, an answer may be issued. An IPv4 packet is 1713 then sent. 1715 6. This IPv4 packet is received by i-PRR. It then proceeds to a 1716 stateless NAT46 operation. The newly built IPv6 packet is 1717 forwarded to the next hop. 1719 7. Owing to underlying IGP configuration, the packet is received by 1720 the appropriate CPE which checks its NAT66 table. 1722 8. Because a session has been instantiated, a NAT66 operation is 1723 executed. The resulting IPv6 packet is then received by M1. 1725 6.6.3.3. Provisioning Operations 1726 6.6.3.3.1. IP Connectivity Information 1728 Unlike previous steps, no IPv4 connectivity is provided to customers. 1729 None IPv4 packets are sent, neither by the end-user's device within 1730 the LAN nor by the CPE itself. 1732 IP connectivity is exclusively offered owing to IPv6 transfer 1733 capabilities. Thus, no IPv4 connectivity information is conveyed to 1734 end-user's device. In the meantime, an IPv6 prefix (IPv6Pref) is 1735 assigned to the end-user device (CPE or terminal). This assigned 1736 IPv6 prefix follows the constraints listed in Section 4. 1738 As already mentioned in Section 6.3, the service provider may 1739 allocate to the customer's device a second prefix IPv6 prefix which 1740 is not IPv4-mapped. 1742 6.6.3.3.2. Provisioning Procedure 1744 In addition to what has been mentioned for Step_1 (IPv6 part), a 1745 specific policy should be installed so as to "guide" the behaviour of 1746 the NAT66 function introduced in "Handling Outgoing Traffic" section. 1748 This specific policy needs to be aware of the port range allocated to 1749 the port-restricted device. It is for further study to defined how 1750 the port range can be allocated through IPv6 means (e.g., through a 1751 new DHCPv6 option). 1753 6.6.3.4. Port Restricted Device's Behaviour and Supported Functions 1755 6.6.3.4.1. Port Range Restriction 1757 The port restriction is applied only if the destination IPv6 address 1758 belongs to the Pref6_v4 prefix. Otherwise, no port restriction is 1759 enforced, since it is assumed to be a native IPv6 communication. 1761 A new NAT66 function should be supported by the CPE. This NAT66 is 1762 not required to be supported if a directly connected terminal is 1763 used. But then, its address selection process should follow the 1764 recommendations listed in "Handling Outgoing Traffic" sub-section. 1766 6.6.3.4.2. Handling Outgoing Traffic 1768 The following procedure is applied: 1770 o If the destination IPv6 address belongs to the Pref6_v4 prefix 1771 (this means the destination is not a native IPv6 host and an IPv6- 1772 IPv4 interconnection node will be crossed in the delivery path), 1773 the port-restricted device proceeds to NAT66 operations. 1775 Concretely: 1777 * A port number from the Port Range is selected, this port 1778 replaces the original source port number in the transport part 1779 of the received IPv6 packet; 1781 * A source IPv6 address IPv6PrefA is selected under IPv6Pref (see 1782 Section 4) in such a way that the port value contained in the 1783 port part of this IPv6PrefA address is equal to the selected 1784 port number; 1786 * The received IPv6 (from a machine in the LAN) packet is then 1787 translated to a new IPv6 one with the newly built IPv6PrefA 1788 address as source address and the newly selected source port 1789 number in transport part. 1791 o Otherwise, the packet is forwarded to the next IPv6 hop. 1793 6.6.3.4.3. Handling Incoming Traffic 1795 The following procedure is applied: 1797 o If the source IPv6 address belongs to the Pref6_v4 prefix, the 1798 port-restricted device proceeds to NAT66 operations according to 1799 its active NAT sessions. 1801 o Otherwise, the packet is forwarded to the next IPv6 hop in the 1802 LAN. 1804 6.6.3.5. PRR Behaviour 1806 6.6.3.5.1. Supported Functions 1808 Unlike previous steps, no encapsulation function is required to be 1809 supported by the PRR. Nevertheless, a stateless IPv6-IPv4 (and vice 1810 versa) translation must be supported. 1812 6.6.3.5.2. Localization 1814 No PRRs are required anymore to be maintained in the access segment. 1815 Only PRRs located in the interconnection segment should be deployed. 1816 These nodes should be near ASBRs used to interconnect with IPv4-only 1817 realms. 1819 6.6.3.5.3. Behaviour 1821 The behaviour of the PRR is as follows: 1823 1. Traffic received from an IPv4-only realm: The PRR extracts 1824 destination IPv4 address, source IPv4 address, destination port 1825 number and source port number. A new IPv6 packet is generated 1826 following these rules: 1828 * The destination and source port numbers of the generated 1829 packet are the same as the original IPv4 one. 1831 * The destination IPv6 address follows the formalisms described 1832 in Section 4.2 using a Pref6 configured by the service 1833 provider. 1835 * The source IPv6 address follows the formalism described in 1836 Section 4.2 using a Pref6 provided by the service provider. 1838 2. Traffic destined to an IPv4-only realm: A new IPv4 packet is 1839 generated according to these rules: 1841 * The destination and source port numbers of the generated 1842 packet are the same as the original IPv6 one. 1844 * The destination IPv4 address is extracted from the destination 1845 IPv6 address of the received IPv6 packet. See Section 4.3 for 1846 more information about the used IPv6-to-IPv4 address mapping 1847 function. 1849 * The source IPv4 address is extracted from the source IPv6 1850 address of the received IPv6 packet using the IPv6-to-IPv4 1851 address mapping function defined in Section 4.3. 1853 6.6.3.6. Routing Considerations 1855 IPv4 IGP protocols are not anymore enabled in the core network. Only 1856 IPv6 routing table is maintained by involved routers. 1858 Inter-domain IPv4 connectivity is maintained with IPv4-only realms. 1859 IPv4 network prefixes are mapped to IPv6 prefixes (using a Pref6 1860 prefix provided by the local service provider) which are injected in 1861 the IPv6 IGP deployed protocol. 1863 6.7. Analysis and IPv6 Migration Scenarios 1865 As aforementioned, the deployment of IPv6 is not a problem per se. 1866 The main issue is how to ensure a smooth interconnection between IPv4 1867 and IPv6 realms. interconnection functions and procedures should be 1868 deployed. Currently proposed mechanisms rely on stateful 1869 interconnection nodes (e.g., NAT44 CGN or DS-lite CGN) or requires 1870 that dual-stack nodes (including end hosts and intermediary service 1871 nodes) are deployed everywhere. The first category suffers from a 1872 performance issue and the second one is not realistic approach (since 1873 the adoption of IPv6 may require several years). 1875 This document presents solutions which solve the problem of IPv4 1876 address shortage and which prepare the migration to IPv6. As 1877 described in previous sections, three steps have been identified and 1878 specified. Table 1 gives an overview of the supported IP version per 1879 network segment and for each step. The proposed solution requires 1880 the migration of core segments to IPv6. Dual stacks would be 1881 maintained only at interconnection segments. Table 2 presents the 1882 ratio of IPv6 traffic when the solution is deployed. This table 1883 illustrates the invocation of IPv6 capabilities for the delivery of 1884 IP connectivity service. Owing to the deployment of the proposed 1885 solution, service providers have deterministic means to increase IPv6 1886 traffic. 1888 +--------+--------------+--------------+-----------------+ 1889 | Step | Access | Core | Interconnection | 1890 +--------+--------------+--------------+-----------------+ 1891 | Step_0 | DS Network | IPv4 Network | IPv4 Network | 1892 | Step_1 | DS Network | DS Network | DS Network | 1893 | Step_2 | IPv6 Network | IPv6 Network | DS Network | 1894 +--------+--------------+--------------+-----------------+ 1896 Table 1: Supported IP version per network segment 1898 +------------------------+---------------------+--------------------+ 1899 | Step | %IPv6 traffic | %IPv6 traffic core | 1900 | | Access | | 1901 +------------------------+---------------------+--------------------+ 1902 | Step_0 | at least 50% | variable | 1903 | Step_1 | at least 50% | at least 50% | 1904 | Step_2 (Encapsulation) | 100% | 100% | 1905 | Step_2 (Translation) | 100% | 100% | 1906 +------------------------+---------------------+--------------------+ 1908 Table 2: % of IPv6 1910 Table 3 lists the required function/node to be supported in order to 1911 ensure heterogeneous communication involving peers located in both 1912 IPv4 and IPv6 realms. Core network segment does not require the 1913 deployment of non IPv6 standards elements. Stateless functions 1914 (denoted as PRR in this document) are introduced first at access 1915 segment and then in the interconnection segment. Intra-domain 1916 communications are optimised from an IGP perspective. The presence 1917 of a-PRR allows a natural traffic distribution among deployed nodes. 1918 IPv4 traffic received from adjacent domains is handled by the i-PRR 1919 and then routed to its final destination possibly through the a-PRR 1920 depending of the configuration (binding table with one line per port- 1921 restricted device or stateless mapping between shared IPv4 address 1922 and IPv6 prefixes). 1924 +------------------------+------------+------+-----------------+ 1925 | Step | Access | Core | Interconnection | 1926 +------------------------+------------+------+-----------------+ 1927 | Step_0 | a-PRR | None | None | 1928 | Step_1 | a-PRR | None | i-PRR | 1929 | Step_2 (Encapsulation) | a-PRR/None | None | i-PRR | 1930 | Step_2 (Translation) | None | None | i-PRR | 1931 +------------------------+------------+------+-----------------+ 1933 Table 3: Required nodes per network segment 1935 Table 4 lists the required functions to be enabled in the context of 1936 each step. 1938 +-----------------+-------------------------+-----------------------+ 1939 | Step | port-restricted device | a/i-PRR | 1940 +-----------------+-------------------------+-----------------------+ 1941 | Step_0 | Port Restricted IPv4, | Stateless | 1942 | | IPv4-in-IPv6 | IPv4-in-IPv6 | 1943 | | de-encapsulation | encapsulation | 1944 | Step_1 | Port Restricted IPv4, | stateless | 1945 | | IPv4-in-IPv6 | IPv4-in-IPv6 | 1946 | | de-encapsulation | encapsulation | 1947 | Step_2 | Port Restricted IPv4, | Stateless | 1948 | (Encapsulation) | IPv4-in-IPv6 | IPv4-in-IPv6 | 1949 | | encapsulation, | encapsulation, | 1950 | | IPv4-in-IPv6 | IPv4-in-IPv6 | 1951 | | de-encapsulation | de-encapsulation | 1952 | Step_2 | Port Restricted NAT66 | Stateless NAT46/NAT64 | 1953 | (Translation) | | | 1954 +-----------------+-------------------------+-----------------------+ 1956 Table 4: Required Functions 1958 Various migration paths may be adopted by service providers based on 1959 backward compatibility considerations and also to the service 1960 portfolio. 1962 For service providers which offer already an IPv4-based connectivity 1963 service, several migration paths may be followed, depending on the 1964 service provider's objectives and profile, to adopt IPv6 without 1965 breaking global connectivity (i.e., Reach both IPv4 and IPv6 realms): 1967 1. Deploy IPv6 with no major risks on currently offered services: a 1968 candidate migration path would be (ordered steps): 1970 A. Deploy first the procedure described in 1971 [I-D.boucadair-port-range]. Then, IPv6 may be activated in 1972 the access segment when deploying Step_0. Once IPv6 is 1973 deployed in core network, the service provider should 1974 activate Step_1 mainly by deploying PRR at interconnection 1975 segments. Once the connectivity service is stable, a final 1976 step would be to adopt Step_2 (encapsulation mode) and then 1977 Step_2 (translation mode). 1979 B. Deploy first Step_0, then adopt Step_1. Once the service is 1980 stable, move to Step_2 (encapsulation mode) and latter to 1981 Step_2 (translation mode). 1983 2. Aggressive position with regards to IPv6 deployment: For this 1984 category of service providers, the migration path would be either 1986 A. either deploy Step_1 then Step_2 (encapsulation mode) and 1987 finally Step_2 (translation mode). 1989 B. or deploy Step_2 (encapsulation mode) and then Step_2 1990 (translation mode). 1992 For new service providers which do not have backward compatibility 1993 requirement, the following deployment path may be adopted to ensure a 1994 global IPv4/IPv6 connectivity service. 1996 Deploy Step_2 (encapsulation mode) and then migrate to Step_2 1997 (translation mode). 1999 7. IANA Considerations 2001 TBC. 2003 8. Security Considerations 2005 TBC. 2007 9. Acknowledgements 2009 The authors would like to thank Pierrick MORAND and Eric BURGEY for 2010 their review, support and suggestions. 2012 10. References 2014 10.1. Normative References 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2017 Requirement Levels", BCP 14, RFC 2119, March 1997. 2019 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2020 and M. Carney, "Dynamic Host Configuration Protocol for 2021 IPv6 (DHCPv6)", RFC 3315, July 2003. 2023 10.2. Informative References 2025 [I-D.bajko-pripaddrassign] 2026 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 2027 "Port Restricted IP Address Assignment", 2028 draft-bajko-pripaddrassign-01 (work in progress), 2029 March 2009. 2031 [I-D.boucadair-dhcpv6-shared-address-option] 2032 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 2033 and G. Bajko, "Dynamic Host Configuration Protocol 2034 (DHCPv6) Options for Shared IP Addresses Solutions", 2035 draft-boucadair-dhcpv6-shared-address-option-00 (work in 2036 progress), May 2009. 2038 [I-D.boucadair-port-range] 2039 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 2040 "IPv4 Connectivity Access in the Context of IPv4 Address 2041 Exhaustion: Port Range based IP Architecture", 2042 draft-boucadair-port-range-02 (work in progress), 2043 July 2009. 2045 [I-D.boucadair-pppext-portrange-option] 2046 Boucadair, M., Levis, P., Grimault, J., and A. 2047 Villefranque, "Port Range Configuration Options for PPP 2048 IPCP", draft-boucadair-pppext-portrange-option-01 (work in 2049 progress), July 2009. 2051 [I-D.ietf-softwire-dual-stack-lite] 2052 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 2053 Y., and R. Bush, "Dual-stack lite broadband deployments 2054 post IPv4 exhaustion", 2055 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 2056 July 2009. 2058 [I-D.levis-behave-ipv4-shortage-framework] 2059 Levis, P., Boucadair, M., Grimault, J., and A. 2061 Villefranque, "IPv4 Address Shortage: Needs and Open 2062 Issues", draft-levis-behave-ipv4-shortage-framework-02 2063 (work in progress), June 2009. 2065 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 2066 Hain, "Representing Internet Protocol version 6 (IPv6) 2067 Addresses in the Domain Name System (DNS)", RFC 3363, 2068 August 2002. 2070 Authors' Addresses 2072 Mohamed Boucadair (editor) 2073 France Telecom 2074 3, Av Francois Chateau 2075 Rennes 35000 2076 France 2078 Email: mohamed.boucadair@orange-ftgroup.com 2080 Pierre Levis 2081 France Telecom 2083 Email: pierre.levis@orange-ftgroup.com 2085 Jean-Luc Grimault 2086 France Telecom 2088 Email: jeanluc.grimault@orange-ftgroup.com 2090 Alain Villefranque 2091 France Telecom 2093 Email: alain.villefranque@orange-ftgroup.com 2095 Mohamed Kassi-Lahlou 2096 France Telecom 2098 Email: mohamed.kassilahlou@orange-ftgroup.com 2099 Gabor Bajko 2100 Nokia 2101 USA 2103 Email: Gabor.Bajko@nokia.com 2104 URI: 2106 Yiu L. Lee 2107 Comcast 2108 U.S.A. 2110 Email: yiu_lee@cable.comcast.com 2111 URI: http://www.comcast.com 2113 Telemaco Melia 2114 Alcatel-Lucent 2115 France 2117 Email: Telemaco.Melia@alcatel-lucent.com 2118 URI: 2120 Olivier Vautrin 2121 Juniper 2123 Email: ovautrin@juniper.net