idnits 2.17.1 draft-boucadair-dslite-interco-v4v6-00.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 (April 29, 2009) is 5475 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 (-04) exists of draft-boucadair-behave-ipv6-portrange-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 (~~), 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 C. Jacquenet 4 Intended status: Informational JL. Grimault 5 Expires: October 31, 2009 M. Kassi Lahlou 6 P. Levis 7 France Telecom 8 April 29, 2009 10 Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment 11 draft-boucadair-dslite-interco-v4v6-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on October 31, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This memo describes a proposal to enhance DS-lite solution with an 60 additional feature to ease interconnection between IPv4 and IPv6 61 realms. When deployed, no dual-stack-enabled network is required for 62 the delivery of both IPv4 and IPv6 connectivity to customers. Only 63 IPv6 is required to be deployed in core and access networks. 64 Particularly, IPv6 transfer capabilities are used for the transfer of 65 IPv4-addressed packets in a completely stateless scheme between the 66 interconnection segment and the DS-lite CGN node(s). This memo 67 proposes an IPv4-inferred scheme to build IPv6 addresses. 69 The proposed solution allows Service Providers to maintain an IPv6- 70 only network. 72 Requirements Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.2. Contribution of this draft . . . . . . . . . . . . . . . . 4 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 5 86 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 7 87 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 7 88 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 7 89 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 8 90 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 8 91 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 10 92 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 10 93 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 10 94 3.4.3. Processing Operations . . . . . . . . . . . . . . . . 11 95 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 96 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 105 1. Introduction 107 1.1. Context 109 It is commonly agreed that IPv4 address shortage is a fact. Several 110 solutions have been proposed to cope with this sensitive issue. All 111 these solutions are based on IP address sharing and differ in where 112 the IP address sharing function is enforced. 114 The first category is denoted as Port Range 115 [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The 116 spirit of this category is to assign the same public IP address to 117 several customers' devices (called also port restricted devices) 118 together with a Port Range. Communications issued/destined to a 119 port-restricted device can be established only if the ports belong to 120 the provisioned Port Range. Dedicated means to provision the Port 121 Range have been proposed (see [I-D.bajko-pripaddrassign] and 122 [I-D.boucadair-pppext-portrange-option] for instance). 124 The second category is known as CGN (for Carrier Grade NAT). Two 125 main CGN flavors can be distinguished. Double NAT, in which two 126 levels of NAT are cascaded: one in the CPE and one in the network 127 (i.e. CGN). And DS-lite [I-D.ietf-softwire-dual-stack-lite] which 128 gets rid of the CPE NAT level. This solution requires a Dual Stack 129 CPE. Thus, a given CPE is assigned with an IPv6 prefix to be used 130 for its native IPv6 communications and also to encapsulate the IPv4 131 packets into IPv6 ones between the CPE and the DS-lite CGN. Note 132 that the deployment of DS-lite CGN equipment is not necessarily 133 centralized and several DS-lite CGN nodes may be deployed to handle 134 traffic issued/destined from/to end-user devices. 136 Whilst the DS-lite solution enhances the Double NAT scenario by 137 avoiding a NAT level and the allocation of a specific private IPv4 138 address to the CPE, it does not solve the IPv4-IPv6 interworking 139 issue. 141 1.2. Contribution of this draft 143 This memo proposes an extended DS-lite approach to solve both IPv4 144 address shortage and also to allow stateless IPv4-IPv6 145 interconnection. More precisely, this memo proposes to update DS- 146 lite nodes with new encapsulation and de-encapsulation capabilities 147 to be applied on the interface to core network of a given service 148 provider. Furthermore, a new function embedded in IPv6-IPv4 149 interconnection nodes (e.g. ASBR or a dedicated node) is also 150 introduced. The activation of the proposed solution allows a service 151 provider to operate a network which is IPv6-only. 153 [I-D.boucadair-behave-ipv6-portrange] introduces a slightly modified 154 IPv4-IPv6 interworking function (which takes into account the port 155 number information) compatible with the Port Range based solutions. 157 2. Terminology 159 This memo makes use of the following terms: 161 o DS-lite CGN node: refers to the CGN node which behaviour is 162 specified in [I-D.ietf-softwire-dual-stack-lite]. This node 163 embedded a CGN function. 165 o Access segment: This segment encloses both IP access and backhaul 166 network. 168 o Interconnection segment: Includes all nodes and resources which 169 are deployed at the border of a given AS (Autonomous System) a la 170 BGP (Border Gateway Protocol). 172 o Core segment: Denotes a set of IP networking capabilities and 173 resources which are between the interconnection and the access 174 segments. 176 o Customer Attachment Device: A customer may use a terminal or a CPE 177 to access its subscribed services. This device is referred to as 178 Customer Attachment Device. 180 o IP connectivity information: A set of information (e.g. IP 181 address, default gateway, etc) required to access IP transfer 182 delivery service. 184 3. Procedure 186 This section describes an updated DS-lite solution. 188 3.1. Overall Procedure 190 The overall proposed procedure is summarised hereafter: 192 o A new IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is 193 introduced. This function may be hosted in an ASBR or a dedicated 194 node located at the interconnection between IPv6 and IPv4 domains. 195 This function is responsible for encapsulating all received IPv4 196 datagrams in IPv6 ones and de-encapsulating IPv4-in-IPv6 197 datagrams. 199 o DS-lite CGN nodes are deployed in the access network. These nodes 200 are compliant with [I-D.ietf-softwire-dual-stack-lite]. In 201 addition, these nodes are enhanced with new IPv4-in-IPv6 202 encapsulation and de-encapsulation functions. These newly 203 introduced functions are stateless. Once these functions are 204 enabled, a given DS-lite node is responsible to handle IPv4-in- 205 IPv6 traffic in all its interfaces. No plain IPv4 traffic is 206 sent/received by the DS-lite CGN in all its interfaces. Only 207 IPv4-in-IPv6 packets are handled. 209 o Customer Attachment Devices are provisioned with an IPv6 prefix 210 that will not only be used for native IPv6 communication, but also 211 to encapsulate IPv4 datagrams. The proposed solution does no 212 require any modification on the customers side compared to what 213 has been listed in [I-D.ietf-softwire-dual-stack-lite]. 215 This figure provides an overview of the overall environment. 216 Customers are connected to the service domain via a CPE device. 217 Several DS-lite CGN nodes are deployed to manage the traffic issued/ 218 destined from/to end user device. The local domain is IPv6 only and 219 interconnection with adjacent IPv4 realms is implemented using IPv6- 220 IPv4 ICXF. 221 +--------------------------------+ 222 | Service Domain | +----------- 223 +----+ | +---------+ | IPv4 224 |CPE1|---------| |IPv6-IPv4|----| Domain A 225 +----+ | | ICXF | | 226 | +---------+ +----------- 227 | +-------+ | 228 | |DS-lite| | +----------- 229 +----+ | | CGN A | +---------+ | IPv4 230 |CPE2|---------| +-------+ |IPv6-IPv4|----| Domain B 231 +----+ | | ICXF | | 232 | +---------+ +----------- 233 | +-------+ | | 234 | |DS-lite| | | +----------- 235 +----+ | | CGN B | | | | IPv4 236 |CPEi|---------| +-------+ | +-------| Domain C 237 +----+ | | | 238 | | +----------- 239 +--------------------------------+ 241 |<---IPv6----------->|<-----IPv6------------->|<---IPv4---- 243 Figure 1: Environment Overview 245 The following sub-sections provide more details about the proposed 246 solution. 248 3.2. Customer Attachment Device 250 The Customer Attachment Device is provisioned with an IPv6 prefix and 251 the IPv6 address of a DS-lite CGN, by means of DHCPv6 for example. 252 For robustness reasons, the IPv6 address of a DS-Lite CGN is 253 recommended to be an anycast address. 255 A Customer Attachment Device encapsulates the privately addressed 256 IPv4 traffic in IPv6 datagrams. These messages are then forwarded 257 (without any NAT operation) towards a DS-lite CGN node. 259 As for incoming traffic, a Customer Attachment Device proceeds to de- 260 encapsulation operation. De-encapsulated datagrams are handled 261 locally or are forwarded to the appropriate machine connected to the 262 LAN behind the Customer Attachment Device. 264 The current specification does not require any modification on a DS- 265 lite compliant CPE. 267 3.3. DS-lite CGN Node 269 3.3.1. Provisioning Information 271 In addition to the required configuration information to activate DS- 272 lite mode described in [I-D.ietf-softwire-dual-stack-lite], DS-lite 273 CGN nodes are provisioned with: 275 o WKIPv6: an IPv6 prefix that can be assigned by IANA or extracted 276 from the prefix assigned to the service provider. This prefix is 277 used to build an IPv4-inferred IPv6 address. More information are 278 provided in Section 3.3.3. 280 o A set of IPv6 prefixes which are structured as WKIPv6+IPv4_addr: 282 * WKIPv6: the same as the one mentioned in the previous bullet. 284 * IPv4_addr is an IPv4 address used by the DS-lite CGN to enforce 285 its NAT44 operations. 287 * Several IPv4 addresses may be configured on a DS-lite node. 288 These IPv4 addresses may be aggregated, leading to aggregated 289 WKIPv6+IPv4_addr prefixes. 291 3.3.2. Routing Considerations 293 A DS-lite node (or a third party) advertises in IGP the IPv6 prefixes 294 it manages (i.e. the set of WKIPv6+IPv4_addr prefixes described 295 above). Such announcement is required so that all traffic destined 296 to an IPv6 address belonging to an IPv6 prefix configured on the DS- 297 lite CGN node MUST be forwarded to the DS-Lite node. 299 3.3.3. Processing Operations 301 Figure 2 shows the input and output of a DS-lite CGN node. 303 +-------------------+ 304 ----IPv6---\ | |----IPv6---\ 305 ----IPv4---\\| |----IPv4---\\ 306 -----------//| |-----------// 307 -----------/ | |-----------/ 308 | DS-Lite | 309 /----IPv6---| CGN | /----IPv6--- 310 //---IPv4----| |//---IPv4---- 311 \\-----------| |\\----------- 312 \-----------| | \----------- 313 +-------------------+ 315 Figure 2: Modified DS-lite CGN 317 Two main interfaces may be distinguished in a DS-lite CGN node: 319 a. Interface to the customer device. 321 b. Interface to core nodes. 323 The handling of the traffic received from a customer device is as 324 follows. 326 IPv4-in-IPv6 packets are de-encapsulated and then NAT operation is 327 applied. Once this operation is performed, the DS-lite node 328 encapsulates the NATed IPv4 datagrams in IPv6 ones using the 329 following information: 331 o Source IPv6 address: One of the DS-Lite node IPv6 addresses. 333 o Destination IPv6 address: WKIPv6+Original IPv4 address (i.e. the 334 destination IPv4 address contained in the encapsulated datagrams). 336 Encapsulated traffic is then forwarded until reaching another DS-lite 337 CGN node, if the traffic remains in the same domain, or an IPv6-IPv4 338 Interconnection equipment. 340 o If datagrams are received by a DS-lite node (e.g. See Figure 3), 341 it de-encapsulates them and handles the embedded IPv4 ones 342 according to [I-D.ietf-softwire-dual-stack-lite]. 344 o If received by an Interconnection node (e.g. See Figure 4), it 345 proceeds to a de-encapsulation operation and then the traffic is 346 forwarded to the next IPv4 destination according to installed IPv4 347 routes. 349 As illustrated in the figure, the communications between two CPEs 350 attached to a DS-lite enabled domain are implemented using IPv6 only 351 capabilities. IPv4 datagrams are encapsulated in IPv6 ones. The NAT 352 function is implemented by DS-lite CGN nodes. 354 +------+ +---------+ +---------+ +------+ 355 | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | 356 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | 357 | |---------//| |---------------//| |---------//| | 358 | |---------/ | |---------------/ | |---------/ | | 359 | CPE 1| | DS-lite | | DS-lite | | CPE2 | 360 | | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| | 361 | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | 362 | |\\---------| |\\---------------| |\\---------| | 363 | | \---------| | \---------------| | \---------| | 364 +------+ +---------+ +---------+ +------+ 366 Machines behind each CPE are not represented in the figure. 368 Figure 3: Flow Example involving two devices attached to the same DS- 369 lite enabled domain 371 The following figure illustrates an example of a CPE, located behind 372 a DS-lite CGN node, which establishes a communication with a remote 373 machine (referred to as RM) which is IPv4-only. 375 +------+ +---------+ +---------+ +------+ 376 | |--IPv6---\ | |------IPv6-----\ | | | | 377 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | 378 | |---------//| |---------------//| |---------/| | 379 | |---------/ | |---------------/ | | | | 380 | CPE 1| | DS-lite | |IPv6-IPv4| | RM | 381 | | /---IPv6--| CGN A | /-----IPv6------| ICXF | | | 382 | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | 383 | |\\---------| |\\---------------| |\---------| | 384 | | \---------| | \---------------| | | | 385 +------+ +---------+ +---------+ +------+ 387 Machines located behind CPE1 are not represented in the figure. 389 Figure 4: Flow Example involving only one device attached to a DS- 390 lite enabled domain 392 3.4. IPv6-IPv4 Interconnection Function 394 As mentioned above, a dedicated node called IPv6-IPv4 Interconnection 395 function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only 396 domain (which hosts a DS-lite CGN function) and an IPv4 one. This 397 function is required to interconnect both realms without introducing 398 any additional NAT operation in the path. 400 The following sub-sections provide more information about the 401 behaviour of this function. 403 3.4.1. Provisioning Information 405 An IPv6-IPv4 Interconnection node is provisioned with a WKIPv6 which 406 is an IPv6 prefix that can be assigned by IANA or be part of the 407 service provider's prefix. This prefix is used to build IPv4- 408 inferred IPv6 addresses (structured as WKIPv6+IPv4_addr). IPv4_addr 409 refers to an IPv4 address (or network) that can be reached through 410 the IPv6-IPv4 Interworking node. These IPv4 addresses may be static 411 or dynamic (e.g. learned via a dedicated protocol such as BGP). 413 3.4.2. Routing Considerations 415 Two modes may be envisaged: 417 o Static mode: IPv4-inferred IPv6 prefixes, structured as WKIPv6+ 418 IPv4_addr, are provided to IPv6-IPv4 ICXF through a dedicated 419 configuration means (e.g. CLI). 421 o Dynamic mode: IPv6-IPv4 ICXF is responsible to build IPv4-inferred 422 IPv6 prefixes which are structured as WKIPv6+IPv4_addr. 424 The aforementioned IPv4-inferred IPv6 prefixes are then advertised in 425 IGP. Thus, IPv4-encapsulated traffic will reach the appropriate 426 IPv6-IPv4 ICXF. 428 3.4.3. Processing Operations 430 Figure 5 shows the input and output of an IPv6-IPv4 ICXF. 432 +-------------------+ 433 ----IPv6---\ | | 434 ----IPv4---\\| |----IPv4---\ 435 -----------//| |-----------/ 436 -----------/ | | 437 | IPv6-IPv4 | 438 /----IPv6---| ICXF | 439 //---IPv4----| |/---IPv4---- 440 \\-----------| |\----------- 441 \-----------| | 442 +-------------------+ 444 Figure 5: IPv6-IPv4 Interworking Function 446 Concretely, when the interconnection node receives IPv4 traffic from 447 an adjacent domain, it encapsulates IPv4 datagrams in IPv6 using the 448 following information: 450 o Source IPv6 address: One of its own IPv6 addresses. 452 o Destination IPv6 address: WKIPv6+Original IPv4 address. 454 The traffic is then received by a DS-lite CGN node which de- 455 encapsulates the traffic and handles the embedded IPv4 one according 456 to current DS-lite specification [I-D.ietf-softwire-dual-stack-lite]. 458 As for the IPv6 received traffic, an Interconnection node proceeds to 459 a de-encapsulation operation and then the traffic is forwarded to the 460 next IPv4 destination according to installed IPv4 routes. 462 4. Design Considerations 464 The aforementioned functions (i.e. DS-lite CGN and IPv6-IPv4 ICXF) 465 may be hosted in the same node or distinct ones according to the 466 underlying topology constraints and dimensioning considerations. 467 Nevertheless for scalability reasons, it is not recommended to deploy 468 a DS-lite CGN function far (from the access network) in the network 469 since this would create a concentrator and then may be considered as 470 a single point of failure. Furthermore, the routing would not be 471 optimal, particularly for intra-domain traffic. 473 5. Conclusions 475 This proposal allows to migrate toward an IPv6-only network while 476 offering: 478 o Global IPv6 <==> IPv6 communications. 480 o Global IPv4 <==> IPv4 communications. 482 o A remote IPv6 host would reach a host connected to the DS-lite 483 enabled domain using IPv6. 485 o A remote IPv4 host would reach a host connected to the DS-lite 486 enabled domain using IPv4-in-IPv6. 488 Since end user's devices are DS(-lite), the appropriate connectivity 489 protocol (IPv4 or IPv6) is selected to issue outgoing traffic. 490 Therefore, IPv4-to-IPv6 and IPv6-to-IPv4 communications are not 491 considered as valid scenarios within the proposed architecture. 493 6. IANA Considerations 495 This document makes no request of IANA. 497 Note to RFC Editor: this section may be removed on publication as an 498 RFC. 500 7. Security Considerations 502 TBC 504 8. Acknowledgements 506 TBC 508 9. References 510 9.1. Normative References 512 [I-D.ietf-softwire-dual-stack-lite] 513 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 514 "Dual-stack lite broadband deployments post IPv4 515 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 516 in progress), March 2009. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 9.2. Informative References 523 [I-D.bajko-pripaddrassign] 524 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 525 "Port Restricted IP Address Assignment", 526 draft-bajko-pripaddrassign-01 (work in progress), 527 March 2009. 529 [I-D.boucadair-behave-ipv6-portrange] 530 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 531 and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in 532 the Context of IPv4 Address Shortage", 533 draft-boucadair-behave-ipv6-portrange-01 (work in 534 progress), March 2009. 536 [I-D.boucadair-port-range] 537 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 538 "IPv4 Connectivity Access in the Context of IPv4 Address 539 Exhaustion", draft-boucadair-port-range-01 (work in 540 progress), January 2009. 542 [I-D.boucadair-pppext-portrange-option] 543 Boucadair, M., Levis, P., Grimault, J., and A. 544 Villefranque, "Port Range Configuration Options for PPP 545 IPCP", draft-boucadair-pppext-portrange-option-00 (work in 546 progress), February 2009. 548 [I-D.ymbk-aplusp] 549 Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L. 550 Cittadini, "The A+P Approach to the IPv4 Address 551 Shortage", draft-ymbk-aplusp-03 (work in progress), 552 March 2009. 554 Authors' Addresses 556 Mohamed BOUCADAIR (editor) 557 France Telecom 558 3, Av Francois Chateaux 559 Rennes, 35000 560 France 562 Email: mohamed.boucadair@orange-ftgroup.com 564 Christian JACQUENET 565 France Telecom 567 Email: christian.jacquenet@orange-ftgroup.com 569 Jean Luc GRIMAULT 570 France Telecom 572 Email: jeanluc.grimault@orange-ftgroup.com 574 Mohammed KASSI LAHLOU 575 France Telecom 577 Email: mohamed.kassilahlou@orange-ftgroup.com 579 Pierre LEVIS 580 France Telecom 582 Email: pierre.levis@orange-ftgroup.com