idnits 2.17.1 draft-boucadair-dslite-interco-v4v6-01.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 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (May 18, 2009) is 5457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-00 == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-01 == Outdated reference: A later version (-02) exists of draft-boucadair-port-range-01 == Outdated reference: A later version (-09) exists of draft-boucadair-pppext-portrange-option-00 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-03 Summary: 2 errors (**), 0 flaws (~~), 7 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 C. Jacquenet 4 Intended status: Informational JL. Grimault 5 Expires: November 19, 2009 M. Kassi Lahlou 6 P. Levis 7 France Telecom 8 D. Cheng 9 Huawei Technologies Co., Ltd. 10 May 18, 2009 12 Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment 13 draft-boucadair-dslite-interco-v4v6-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on November 19, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This memo describes a proposal to enhance DS-lite solution with an 61 additional feature to ease interconnection between IPv4 and IPv6 62 realms. When deployed, no dual-stack-enabled network is required for 63 the delivery of both IPv4 and IPv6 connectivity to customers. Only 64 IPv6 is required to be deployed in core and access networks. 65 Particularly, IPv6 transfer capabilities are used for the transfer of 66 IPv4-addressed packets in a completely stateless scheme between the 67 interconnection segment and the DS-lite CGN node(s). 69 Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.2. Contribution of this draft . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 6 83 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 7 84 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 8 85 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 8 86 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 8 87 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 8 88 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 11 89 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 11 90 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 11 91 3.4.3. Processing Operations . . . . . . . . . . . . . . . . 12 92 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 93 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 102 1. Introduction 104 1.1. Context 106 It is commonly agreed that IPv4 address shortage is a fact. Several 107 solutions have been proposed to cope with this sensitive issue. All 108 these solutions are based on IP address sharing and differ in where 109 the IP address sharing function is enforced. 111 The first category is denoted as Port Range 112 [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The 113 spirit of this category is to assign the same public IP address to 114 several customers' devices (called also port restricted devices) 115 together with a Port Range. Communications issued/destined to a 116 port-restricted device can be established only if the ports belong to 117 the provisioned Port Range. Dedicated means to provision the Port 118 Range have been proposed (see [I-D.bajko-pripaddrassign] and 119 [I-D.boucadair-pppext-portrange-option] for instance). 121 The second category is known as CGN (for Carrier Grade NAT). Two 122 main CGN flavors can be distinguished. Double NAT, in which two 123 levels of NAT are cascaded: one in the CPE and one in the network 124 (i.e. CGN). And DS-lite [I-D.ietf-softwire-dual-stack-lite] which 125 gets rid of the CPE NAT level. This solution requires a Dual Stack 126 CPE. Thus, a given CPE is assigned with an IPv6 prefix to be used 127 for its native IPv6 communications and also to encapsulate the IPv4 128 packets into IPv6 ones between the CPE and the DS-lite CGN. Note 129 that the deployment of DS-lite CGN equipment is not necessarily 130 centralized and several DS-lite CGN nodes may be deployed to handle 131 traffic issued/destined from/to end-user devices. 133 Current DS-lite specification does not solve the IPv4-IPv6 134 Interconnection issue. This is one of the motivations of the effort 135 documented in this memo. 137 1.2. Contribution of this draft 139 This memo proposes an extended DS-lite approach to solve both IPv4 140 address shortage and also to allow stateless IPv4-IPv6 141 interconnection. More precisely, this memo proposes to update DS- 142 lite nodes with new encapsulation and de-encapsulation capabilities 143 to be applied on the interface to core network of a given service 144 provider. Furthermore, a new function embedded in IPv6-IPv4 145 interconnection nodes (e.g. ASBR or a dedicated node) is also 146 introduced. The activation of the proposed solution allows a service 147 provider to operate a network which is IPv6-only. 149 In this memo, a stateless IPv6-IPv4 Interconnection Function (IPv6- 150 IPv4 ICXF) is explicitly defined. An ICXF-capable node resides in an 151 IPv6-only network but also connects to one or more IPv4 networks. It 152 can encapsulate IPv4 datagrams received from a connected IPv4 network 153 in IPv6 and then send the IPv4-inferred IPv6 datagram towards a DS- 154 Lite CGN device located in the IPv6 network. The ICXF-capable router 155 can also de-capsulate an IPv4 datagram from an IPv6 datagram, and 156 then forward the IPv4 datagram accordingly. The encapsulation/ 157 de-capsulation capabilities are facilitated by an IPv4-inferred IPv6 158 address scheme which is further detailed in this document. Specific 159 forwarding capabilities are also described in this memo. 161 Some enhancements are added to a DS-lite CGN node. A DS-lite CGN 162 node may not directly connect to an IPv4 network and in this case, an 163 IPv4 datagram originated from customer side and applied with NAT 164 logic, is encapsulated in an IPv6 datagram and forwarded in the IPv6 165 network further towards an ICXF-capable router. And upon receiving 166 an IPv4-inferred IPv6 datagram, it would de-capsulate the IPv4 167 datagram, apply NAT logic and then forward the packet to the DS-lite 168 interface with the same behavior as defined in 169 [I-D.ietf-softwire-dual-stack-lite]. 171 Other functions are also described in this memo, so as to strengthen 172 the operation of DS-Lite extensions. Multiple DS-lite CGN nodes 173 and/or ICXF-capable routers may be deployed in a single IPv6 network, 174 where while the former is desirably closer to customers, the latter 175 can reside on ASBR closer to IPv4 networks. 177 2. Terminology 179 This memo makes use of the following terms: 181 o DS-lite CGN node: refers to the CGN node which behaviour is 182 specified in [I-D.ietf-softwire-dual-stack-lite]. This node 183 embedded a CGN function. 185 o Access segment: This segment encloses both IP access and backhaul 186 network. 188 o Interconnection segment: Includes all nodes and resources which 189 are deployed at the border of a given AS (Autonomous System) a la 190 BGP (Border Gateway Protocol). 192 o Core segment: Denotes a set of IP networking capabilities and 193 resources which are between the interconnection and the access 194 segments. 196 o Customer Attachment Device: A customer may use a terminal or a CPE 197 to access its subscribed services. This device is referred to as 198 Customer Attachment Device. 200 o IP connectivity information: A set of information (e.g. IP 201 address, default gateway, etc) required to access IP transfer 202 delivery service. 204 3. Procedure 206 This section describes an updated DS-lite solution. 208 3.1. Overall Procedure 210 The overall proposed procedure is summarised hereafter: 212 o A new IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is 213 introduced. This function may be hosted in an ASBR or a dedicated 214 node located at the interconnection between IPv6 and IPv4 domains. 215 This function is responsible for encapsulating all received IPv4 216 datagrams in IPv6 ones and de-encapsulating IPv4-in-IPv6 217 datagrams. 219 o DS-lite CGN nodes are deployed in the access network. These nodes 220 are compliant with [I-D.ietf-softwire-dual-stack-lite]. In 221 addition, these nodes are enhanced with new IPv4-in-IPv6 222 encapsulation and de-encapsulation functions. These newly 223 introduced functions are stateless. Once these functions are 224 enabled, a given DS-lite node is responsible to handle IPv4-in- 225 IPv6 traffic in all its interfaces. No plain IPv4 traffic is 226 sent/received by the DS-lite CGN in all its interfaces. Only 227 IPv4-in-IPv6 packets are handled. As a result this enhancement, a 228 DS-lite CGN node may not directly connect to an IPv4 domain. 230 o Customer Attachment Devices are provisioned with an IPv6 prefix 231 that will not only be used for native IPv6 communication, but also 232 to encapsulate IPv4 datagrams. The proposed solution does not 233 require any modification on the customers side compared to what 234 has been listed in [I-D.ietf-softwire-dual-stack-lite]. 236 This figure provides an overview of the overall environment. 237 Customers are connected to the service domain via a CPE device. 238 Several DS-lite CGN nodes are deployed to manage the traffic issued/ 239 destined from/to end user device. The local domain is IPv6 only and 240 interconnection with adjacent IPv4 realms is implemented using IPv6- 241 IPv4 ICXF. 242 +--------------------------------+ 243 | Service Domain | +----------- 244 +----+ | +---------+ | IPv4 245 |CPE1|---------| |IPv6-IPv4|----| Domain A 246 +----+ | | ICXF | | 247 | +---------+ +----------- 248 | +-------+ | 249 | |DS-lite| | +----------- 250 +----+ | | CGN A | +---------+ | IPv4 251 |CPE2|---------| +-------+ |IPv6-IPv4|----| Domain B 252 +----+ | | ICXF | | 253 | +---------+ +----------- 254 | +-------+ | | 255 | |DS-lite| | | +----------- 256 +----+ | | CGN B | | | | IPv4 257 |CPEi|---------| +-------+ | +-------| Domain C 258 +----+ | | | 259 | | +----------- 260 +--------------------------------+ 262 |<---IPv6----------->|<-----IPv6------------->|<---IPv4---- 264 Figure 1: Environment Overview 266 The following sub-sections provide more details about the proposed 267 solution. 269 3.2. Customer Attachment Device 271 The Customer Attachment Device is provisioned with an IPv6 prefix and 272 the IPv6 address of a DS-lite CGN, by means of DHCPv6 for example. 273 For robustness reasons, the IPv6 address of a DS-Lite CGN is 274 recommended to be an anycast address. 276 A Customer Attachment Device encapsulates the privately addressed 277 IPv4 traffic in IPv6 datagrams. These messages are then forwarded 278 (without any NAT operation) towards a DS-lite CGN node. 280 As for incoming traffic, a Customer Attachment Device proceeds to de- 281 encapsulation operation. De-encapsulated datagrams are handled 282 locally or are forwarded to the appropriate machine connected to the 283 LAN behind the Customer Attachment Device. 285 The current specification does not require any modification on a DS- 286 lite compliant CPE. 288 3.3. DS-lite CGN Node 290 3.3.1. Provisioning Information 292 In addition to the required configuration information to activate DS- 293 lite mode described in [I-D.ietf-softwire-dual-stack-lite], DS-lite 294 CGN nodes are provisioned with: 296 o WKIPv6: an IPv6 prefix that can be assigned by IANA or extracted 297 from the prefix assigned to the service provider. This prefix is 298 used to build an IPv4-inferred IPv6 address. More information are 299 provided in Section 3.3.3. 301 o A set of IPv6 prefixes which are structured as WKIPv6+IPv4_addr: 303 * WKIPv6: the same as the one mentioned in the previous bullet. 305 * IPv4_addr is an IPv4 address used by the DS-lite CGN to enforce 306 its NAT44 operations. 308 * Several IPv4 addresses may be configured on a DS-lite node. 309 These IPv4 addresses may be aggregated, leading to aggregated 310 WKIPv6+IPv4_addr prefixes. 312 * Each IPv4 address here is served as an IPv4 source address for 313 IPv4 hosts behind CPE (after applying NAT44 logic) in order to 314 communicate with other hosts located in remote IPv4 domains 315 (refer to Figure 1). 317 3.3.2. Routing Considerations 319 A DS-lite node (or a third party) advertises in IGP the IPv6 prefixes 320 it manages (i.e. the set of WKIPv6+IPv4_addr prefixes described 321 above). Such announcement is required so that all traffic destined 322 to an IPv6 address belonging to an IPv6 prefix configured on the DS- 323 lite CGN node MUST be forwarded to the DS-Lite node. 325 3.3.3. Processing Operations 327 Figure 2 shows the input and output of a DS-lite CGN node. 329 +-------------------+ 330 ----IPv6---\ | |----IPv6---\ 331 ----IPv4---\\| |----IPv4---\\ 332 -----------//| |-----------// 333 -----------/ | |-----------/ 334 | DS-Lite | 335 /----IPv6---| CGN | /----IPv6--- 336 //---IPv4----| |//---IPv4---- 337 \\-----------| |\\----------- 338 \-----------| | \----------- 339 +-------------------+ 341 Figure 2: Modified DS-lite CGN 343 Two main interfaces may be distinguished in a DS-lite CGN node: 345 a. Interface to the customer device, i.e., DS-lite interface, per 346 [I-D.ietf-softwire-dual-stack-lite]. 348 b. Interface to core nodes. Note this DS-lite CGN node does not 349 directly connect to an IPv4 domain. 351 The handling of the traffic received from a customer device is as 352 follows. 354 IPv4-in-IPv6 packets are de-encapsulated and then NAT operation is 355 applied. Once this operation is performed, the DS-lite node 356 encapsulates the NATed IPv4 datagrams in IPv6 ones using the 357 following information: 359 o Source IPv6 address: One of the DS-Lite node IPv6 addresses. This 360 source IPv6 address is a global IPv6 address configured on an 361 interface of the DS-lite CGN (e.g., loopback). 363 o Destination IPv6 address: WKIPv6+Original IPv4 address (i.e. the 364 destination IPv4 address contained in the encapsulated datagrams). 366 Encapsulated traffic is then forwarded until reaching another DS-lite 367 CGN node, if the traffic remains in the same domain, or an IPv6-IPv4 368 Interconnection equipment. 370 o If datagrams are received by a DS-lite node (e.g. See Figure 3), 371 it de-encapsulates them and handles the embedded IPv4 ones 372 according to [I-D.ietf-softwire-dual-stack-lite]. 374 o If received by an Interconnection node (e.g. See Figure 4), it 375 proceeds to a de-encapsulation operation and then the traffic is 376 forwarded to the next IPv4 destination according to installed IPv4 377 routes. 379 As illustrated in the figure, the communications between two CPEs 380 attached to a DS-lite enabled domain are implemented using IPv6 only 381 capabilities. IPv4 datagrams are encapsulated in IPv6 ones. The NAT 382 function is implemented by DS-lite CGN nodes. 384 +------+ +---------+ +---------+ +------+ 385 | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | 386 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | 387 | |---------//| |---------------//| |---------//| | 388 | |---------/ | |---------------/ | |---------/ | | 389 | CPE 1| | DS-lite | | DS-lite | | CPE2 | 390 | | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| | 391 | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | 392 | |\\---------| |\\---------------| |\\---------| | 393 | | \---------| | \---------------| | \---------| | 394 +------+ +---------+ +---------+ +------+ 396 Machines behind each CPE are not represented in the figure. 398 Figure 3: Flow Example involving two devices attached to the same DS- 399 lite enabled domain 401 The following figure illustrates an example of a CPE, located behind 402 a DS-lite CGN node, which establishes a communication with a remote 403 machine (referred to as RM) which is IPv4-only. 405 +------+ +---------+ +---------+ +------+ 406 | |--IPv6---\ | |------IPv6-----\ | | | | 407 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | 408 | |---------//| |---------------//| |---------/| | 409 | |---------/ | |---------------/ | | | | 410 | CPE 1| | DS-lite | |IPv6-IPv4| | RM | 411 | | /---IPv6--| CGN A | /-----IPv6------| ICXF | | | 412 | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | 413 | |\\---------| |\\---------------| |\---------| | 414 | | \---------| | \---------------| | | | 415 +------+ +---------+ +---------+ +------+ 417 Machines located behind CPE1 are not represented in the figure. 419 Figure 4: Flow Example involving only one device attached to a DS- 420 lite enabled domain 422 3.4. IPv6-IPv4 Interconnection Function 424 As mentioned above, a dedicated node called IPv6-IPv4 Interconnection 425 function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only 426 domain (which hosts a DS-lite CGN function) and an IPv4 one. This 427 function is required to interconnect both realms without introducing 428 any additional NAT operation in the path. 430 The following sub-sections provide more information about the 431 behaviour of this function. 433 3.4.1. Provisioning Information 435 An IPv6-IPv4 Interconnection node is provisioned with a WKIPv6 which 436 is an IPv6 prefix that can be assigned by IANA or be part of the 437 service provider's prefix. This prefix is used to build IPv4- 438 inferred IPv6 addresses (structured as WKIPv6+IPv4_addr). IPv4_addr 439 refers to an IPv4 address (or network) that can be reached through 440 the IPv6-IPv4 Interworking node. These IPv4 addresses may be static 441 or dynamic (e.g. learned via a dedicated protocol such as BGP). 443 3.4.2. Routing Considerations 445 Two modes may be envisaged: 447 o Static mode: IPv4-inferred IPv6 prefixes, structured as WKIPv6+ 448 IPv4_addr, are provided to IPv6-IPv4 ICXF through a dedicated 449 configuration means (e.g. CLI). 451 o Dynamic mode: IPv6-IPv4 ICXF is responsible to build IPv4-inferred 452 IPv6 prefixes which are structured as WKIPv6+IPv4_addr. These 453 addresses represent IPv4 reachable destinations in the IPv6-only 454 realm. 456 The IPv4-inferred IPv6 reachability information will be dynamically 457 advertised within the domain, to make sure that IPv4-addressed 458 traffic that will be encapsulated in IPv6 datagrams will be forwarded 459 to the relevant IPv4-IPv6 ICXF-enabled router. For scalability 460 reasons, IPv4-inferred IPv6 reachability information may be 461 advertised using i-BGP to avoid redistributing BGP routes in IGP. 463 Note that the IPv6-IPv4 ICXF-capable node does not assign those 464 addresses to its interfaces. 466 3.4.3. Processing Operations 468 Figure 5 shows the input and output of an IPv6-IPv4 ICXF. 470 +-------------------+ 471 ----IPv6---\ | | 472 ----IPv4---\\| |----IPv4---\ 473 -----------//| |-----------/ 474 -----------/ | | 475 | IPv6-IPv4 | 476 /----IPv6---| ICXF | 477 //---IPv4----| |/---IPv4---- 478 \\-----------| |\----------- 479 \-----------| | 480 +-------------------+ 482 Figure 5: IPv6-IPv4 Interworking Function 484 Concretely, when the interconnection node receives IPv4 traffic from 485 an adjacent domain, it encapsulates IPv4 datagrams in IPv6 using the 486 following information: 488 o Source IPv6 address: One of its own IPv6 addresses. 490 o Destination IPv6 address: WKIPv6+Original IPv4 address. 492 The traffic is then received by a DS-lite CGN node which de- 493 encapsulates the traffic and handles the embedded IPv4 one according 494 to current DS-lite specification [I-D.ietf-softwire-dual-stack-lite]. 496 As for the IPv6 received traffic, an Interconnection node proceeds to 497 a de-encapsulation operation and then the traffic is forwarded to the 498 next IPv4 destination according to installed IPv4 routes. 500 4. Design Considerations 502 The aforementioned functions (i.e. DS-lite CGN and IPv6-IPv4 ICXF) 503 may be hosted in the same node or distinct ones according to the 504 underlying topology constraints and dimensioning considerations. 505 Nevertheless for scalability reasons, it is not recommended to deploy 506 a DS-lite CGN function far (from the access network) in the network 507 since this would create a concentrator and then may be considered as 508 a single point of failure. Furthermore, the routing would not be 509 optimal, particularly for intra-domain traffic. 511 5. Conclusions 513 This proposal allows to migrate toward an IPv6-only network while 514 offering: 516 o Global IPv6 <==> IPv6 communications. 518 o Global IPv4 <==> IPv4 communications. 520 o A remote IPv6 host would reach a host connected to the DS-lite 521 enabled domain using IPv6. 523 o A remote IPv4 host would reach a host connected to the DS-lite 524 enabled domain using IPv4-in-IPv6. 526 Since end user's devices are DS(-lite), the appropriate connectivity 527 protocol (IPv4 or IPv6) is selected to issue outgoing traffic. 528 Therefore, IPv4-to-IPv6 and IPv6-to-IPv4 communications are not 529 considered as valid scenarios within the proposed architecture. 531 6. IANA Considerations 533 This document makes no request of IANA. 535 Note to RFC Editor: this section may be removed on publication as an 536 RFC. 538 7. Security Considerations 540 TBC 542 8. Acknowledgements 544 TBC 546 9. References 548 9.1. Normative References 550 [I-D.ietf-softwire-dual-stack-lite] 551 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 552 "Dual-stack lite broadband deployments post IPv4 553 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 554 in progress), March 2009. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 9.2. Informative References 561 [I-D.bajko-pripaddrassign] 562 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 563 "Port Restricted IP Address Assignment", 564 draft-bajko-pripaddrassign-01 (work in progress), 565 March 2009. 567 [I-D.boucadair-port-range] 568 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 569 "IPv4 Connectivity Access in the Context of IPv4 Address 570 Exhaustion", draft-boucadair-port-range-01 (work in 571 progress), January 2009. 573 [I-D.boucadair-pppext-portrange-option] 574 Boucadair, M., Levis, P., Grimault, J., and A. 575 Villefranque, "Port Range Configuration Options for PPP 576 IPCP", draft-boucadair-pppext-portrange-option-00 (work in 577 progress), February 2009. 579 [I-D.ymbk-aplusp] 580 Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L. 581 Cittadini, "The A+P Approach to the IPv4 Address 582 Shortage", draft-ymbk-aplusp-03 (work in progress), 583 March 2009. 585 Authors' Addresses 587 Mohamed BOUCADAIR (editor) 588 France Telecom 589 3, Av Francois Chateaux 590 Rennes, 35000 591 France 593 Email: mohamed.boucadair@orange-ftgroup.com 595 Christian JACQUENET 596 France Telecom 598 Email: christian.jacquenet@orange-ftgroup.com 599 Jean Luc GRIMAULT 600 France Telecom 602 Email: jeanluc.grimault@orange-ftgroup.com 604 Mohammed KASSI LAHLOU 605 France Telecom 607 Email: mohamed.kassilahlou@orange-ftgroup.com 609 Pierre LEVIS 610 France Telecom 612 Email: pierre.levis@orange-ftgroup.com 614 Dean Cheng 615 Huawei Technologies Co., Ltd. 617 Phone: 618 Fax: 619 Email: Chengd@huawei.com 620 URI: