Internet Engineering Task Force R. Despres Internet-Draft September 28, 2008 Intended status: Informational Expires: April 1, 2009 IPv4-IPv6 Coexistence Scenarios based on Stateless Address Mapping draft-despres-sam-scenarios-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2009. Abstract As each global IPv4 address will be shared among more and more customers, and as more and more NATs will be deployed in ISP infrastructures, the lack of end-to-end transparency and the limited scalability of some NATs are likely to cause increasing difficulties to customers and to ISPs. This document introduces IPv4-IPv6 coexistence scenarios where IPv4 addresses are shared with good scalability and, in favorable configurations, with full IPv4 end-to- end transparency. For this, the key tool is the Stateless Address Mapping (SAM) of draft-despres-SAM-00, with in particular its extended IPv4 addressing (IPv4E) in which port prefixes are used as IPv4 address extensions. For each considered scenario, Static Address Mappers (SAMs) are deployed at scenario specific places. Despres Expires April 1, 2009 [Page 1]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SAM based scenarios . . . . . . . . . . . . . . . 5 4. Examples of SAM ISP configurations . . . . . . . . . . . . . . 6 4.1. ISP infrastructure with private IPv4 internal routing . . 7 4.2. ISP infrastructure with private IPv4 and IPv6 internal routings . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. ISP infrastructure with only IPv6 internal routing . . . . 9 5. SAM CPE internal architecture . . . . . . . . . . . . . . . . 10 6. SAM host internal architecture . . . . . . . . . . . . . . . . 12 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Despres Expires April 1, 2009 [Page 2]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 1. Introduction As each global IPv4 address will be shared among more and more customers, and as more and more NATs will be deployed in ISP infrastructures, the lack of end-to-end transparency and the limited scalability of such NATs are likely to cause increasing difficulties to customers and to ISPs. This document introduces IPv4-IPv6 coexistence scenarios where IPv4 addresses are shared with good ISP infrastructure scalability and, in favorable configurations, with full IPv4 end-to-end transparency. For this, the key tool is the Stateless Address Mapping (SAM) of draft-despres-SAM-00, with in particular its extended IPv4 addressing (IPv4E) in which port prefixes are used as IPv4 address extensions. Section 3 describes four IPv4-IPv6 inter-working scenarios. For each one, it indicates which ISP functions are stateless, ensuring the good scalability, and where available port ranges are restricted. Section 4 describes three ISP infrastructure configurations which are compatible with scenarios of Section 3, and which, for backward compatibility with non SAM solutions, are also compatible with many other scenarios. These configurations differ in that ISP routing is only private IPv4, is only IPv6, or is both private IPv4 and IPv6. Section 5 describes a CPE internal architecture which is compatible with scenarios of Section 3 and, for backward compatible with non SAM solutions, which is is also compatible with many other scenarios. Section 6 describes a host internal architecture which is compatible with all scenarios of Section 3, and which, for backward compatibility with non SAM solutions, is also compatible with many other scenarios. Despres Expires April 1, 2009 [Page 3]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 2. Acronyms PACKET TYPES 4 : global IPv4 4P : ISP private IPv4 4S : customer-site private IPv4 6 : global IPv6 a/b : IPva encapsulated in IPvb v : address family 4 or 6 NEWORK COMPONENTS CPE : customer premise equipment SAM CPE : a router CPE which supports SAM at its site and/or ISP interfaces SAM ISP GW : an ISP gateway to the global Internet which supports SAM CGN44 : a NAT of an ISP, from 4P to 4, at its border to the global Internet CGN4/64 : a NAT of an ISP, from 4S/6 to 4, at its border to the global Internet PE : ISP edge nodes, facing customer sites PREFIXES AND ADDRESSES Gv : anycast address, in the ISP infrastructure, of gateways to the global Internet Hv : Header of all v addresses in the considered ISP infrastructure Nv : v unicast address of a CGN of the ISP P6 : IPv6 prefix, in the global Internet, of SAMs of the ISP P4a : IPv4 prefix, in the global Internet, of SAMs of the ISP P4b : IPv4 prefix of ISP NAT in the global Internet Svi : v prefix of customer site i in the ISP infrastructure Despres Expires April 1, 2009 [Page 4]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 3. Examples of SAM based scenarios Considered scenarios are presented in of Figure 1 and Figure 2. They all concern communication between host that cannot have global IPv4 address of their own, and remote hosts addresses of which are global IPv4, each end being able to initiate connections. None of the scenario involves a CGN. In scenarios A to C, sites themselves have no global IPv4 addresses. Scenarios B to D provide IPv4 packet transparency between considered hosts and the global Internet, so that this transparency is end-to-end if remote hosts have the same property. SCENARIO A +--------+ Global +------+ +---------+ | SAM | Internet | host |--site 4S--| SAM CPE |-- ISP 4P ----| ISP GW |<--- 4 ---> +------+ +---------+ or 6 +--------+ <--- 4S ----> NAT+SAM <-- 4/4P or 4/6 --> SAM <----- 4 ---> : : Port restricted NAT ---' '--- Stateless GW SCENARIO B +------+ +--------+ Global | SAM | | SAM | Internet | host |------------------------ ISP 4P ----| ISP GW |<--- 4 ---> +------+ or 6 +--------+ SAM <------------------------ 4/4P or 4/6 --> SAM <----- 4 ---> : : '- Port restricted '--- Stateless GW socket interface <-------------- transparency to global v4 packets ------------> SCENARIOS A AND B Figure 1 Despres Expires April 1, 2009 [Page 5]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 SCENARIO C +------+ +--------+ Global | SAM | +---------+ | SAM | Internet | host |--site 4S--| SAM CPE |-- ISP 4P ----| ISP GW |<--- 4 ---> +------+ or 6 +---------+ or 6 +--------+ SAM <-4/4S or 4/6->SAM1 SAM2<-- 4/4P or 4/6 --> SAM <----- 4 ---> : : : '- Port restricted '- Stateless CPE '--- Stateless GW socket interface <-------------- transparency to global v4 packets ------------> SCENARIO D +------+ Peering Global | SAM | +---------+ point Internet | host |--site 4S--| SAM CPE |------ ISP 4-------O--------- 4 ---> +------+ or 6 +---------+ SAM <--- 4/4S ---> SAM <------------------- 4 -----------------> : '- Port restricted socket interface <-------------- transparency to global v4 packets ------------> SCENARIOS C AND D Figure 2 4. Examples of SAM ISP configurations In Figures of the following subsections, routing prefixes xx are shown with simple arrows xx --> style. Types of packets that may arrive on these routes are shown above double arrows made of equal signs. Packet types and parameters are as defined in Section 2. Understanding which services are offered to customer sites in each of these configurations doesn't necessitate to know details of how SAMs make their address mappings and encapsulations-decapsulations. These details are available in [draft-despres-SAM-00]. Despres Expires April 1, 2009 [Page 6]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 4.1. ISP infrastructure with private IPv4 internal routing If an ISP, to deploy customer sites without global IPv4 addresses, uses only a private IPv4 address space for its internal routing, it needs a CGN44 between its infrastructure and the global Internet. It can, in addition, support SAMs at its border with IPv4 and IPv6 global Internets [Figure 3]. Doing it adds global IPv4E connectivity and IPv6 connectivity to customer sites where CPEs are SAM capable (router or hosts). +-------------------------------+ | | | | SAM CPE | 6/4P | 6 DHCP | 4/4P +---+ 4 | | <=======>|SAM|<=======> parameters | G4 ---> +---+ <--- P4a B4i,H4,C4 | | <--- P6 | | | | | ( PRIVATE IPv4 ROUTING ) | V | | | | 6/4P | 6/4P | 4/4P | 4/4P | 4P | 4P | <=======>O<===========> | customer | <--- S4i | site i | | | | | 4P +-----+ 4 | <=======>|CGN44|<=====> | 0.0.0.0/0 ---> +-----+ <--- P4b | | +-------------------------------+ Length of CPE port prefixes: p = l(T4a) - l(H4) Example: p = 12 - 8 = 4 EXAMPLE OF ISP CONFIGURATION WITH ONLY PRIVATE IPV4 ROUTING Figure 3 Despres Expires April 1, 2009 [Page 7]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 4.2. ISP infrastructure with private IPv4 and IPv6 internal routings If an ISP, to deploy customer sites without global IPv4 addresses, uses both a private IPv4 and the IPv6 address spaces for its internal routing, it provides IPv6 connectivity to its customer sites, and can operate a CGN44 between its infrastructure and the global Internet for its IPv4 only CPEs. It can, in addition, support SAMs at its border with IPv4 global Internet [Figure 4]. Doing it adds global IPv4E connectivity to CPEs that are SAM capable (router or hosts). . +-------------------------------+ | | | 4/4P +---+ 4 | <=======>|SAM|<=======> SAM CPE | G4 ---> +---+ <--- P4a DHCP | G6 ---> | parameters | | B4i,H4,C4 | 6 | 6 B6i,H6,C6 | <===========>O<=======> | | 0::/0 ---> | <--- P6 | | | V | ( IPv6 & PRIVATE IPV4 | | ROUTINGS ) | 6 | 6 | 4P | 4P | 4/4P | 4/4P | <=======>O<===========> | customer | <--- S4i | site i | <--- S6i | | | | 4P +-----+ 4 | <=======>|CGN44|<=====> | 0.0.0.0/0 ---> +-----+ <--- P4b | | +-------------------------------+ 4P : private IPv4 of the Provider Length of CPE port prefixes: idem IPv4 Routing alone EXAMPLE OF ISP CONFIGURATION WITH IPV6 AND PRIVATE IPV4 ROUTINGS Figure 4 Despres Expires April 1, 2009 [Page 8]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 4.3. ISP infrastructure with only IPv6 internal routing If an ISP, to deploy customer sites without global IPv4 addresses, uses only the IPv6 address space for its internal routing, it cannot support IPv4 only customers with a CGN44. If it support SAMs and a CGN4/64 at its border with IPv4 global Internet, and if it also supports SAMs in its PEs, it adds global IPv4E connectivity to CPEs that are SAM capable (router or hosts), and adds IPv4 connectivity via a NAT to IPv4-only CPEs. +-------------------------------+ | | | 4/6 +---+ 4 | <=======>|SAM|<=======> | G6 ---> +---+ <--- P4a | | SAM CPE | 6 | 6 DHCP | <===========>o<=======> parameters | 0::/0 ---> | <--- P6 B6i,H6,C6,N6 | | | | ( IPv6 ROUTING ) | V | | | 6 | 6 | 4S/6 | 4P or 4S| 4P/6 | 4/6 +---+ 4/6 | <=======>|SAM|<=======> | customer +---+ <--- S6i | site i | | | 4S/6 | | 4P/6 +-------+ 4 | <=======>|CGN4/64|<====> | N6 ---> +-------+ <-- P4b | | +-------------------------------+ 4P : private IPv4 of the Provider 4S : private IPv4 of the customer Site Length of CPE port prefixes: p = l(B6i) - l(H6) - (32 - T4a) Example: p = 60 - 36 - (32 - 12) = 4 EXAMPLE OF ISP CONFIGURATION WITH ONLY IPV6 ROUTING Figure 5 Despres Expires April 1, 2009 [Page 9]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 5. SAM CPE internal architecture Router CPEs can exist in many variants because of the variety of packet types that ISP can support at their customer site interfaces, because of the variety of routing families that customers may desire to support in their sites, and because some ISPs that supply CPEs to their customers may prefer to have NATs in their infrastructures rather than in CPEs (the DS lite approach). The generic internal architecture which is proposed in Figure 6 is intended to cover all useful cases. Its operation in each particular case is governed by: (1) the presence or absence of a NAT in the CPE; (2) SAM parameters which determine which packet types are supported at ISP interfaces; (3) which packet types have to be routed in customer sites (4S, 6, or both 4S and 6). Figure 6 details processing paths that each packet follows depending on: (1) which side it comes from; (2) what was its type when received; (3) what is the transmit type that is compatible with the receipt one, among those that are available at the forwarding interface (depending on configured SAM parameters). CPE parameters should be configurable both manually, and automatically using IPv4 DHCP and/or DHCPv6. SAM CPEs should also be able to provide in DHCP all SAM parameters that may be needed by SAM hosts. Despres Expires April 1, 2009 [Page 10]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 Possible packet types Possible ISP supported in the customer site packet types | | | 4P | | +-+ ->4 4b | | | | .---------------------------. V V 4P |N| | | 6/4P .-------|A|---: | 6/4P 6/4S | |T| | ->4/6 | 6/4 4/4P | | | | ->4P 4a | 4S/4P 4/4S | +-+ '---------------. | 4P 4P | | | 4/4P 4S |4S 4S | | 4 <---->:-----------------------------: 6/4P :<----> | +-+ | +-+ 6/4 | |6/4S | | | | | 4/4P | |4/4S | | 4b | | | 4 | '------|S|--------------------'--|S|------' |A| |A| 4S/6 |M| ->6/4P |M| 4/6 | | ->6/4 <-6/4S | | 4/6 .------| |--.-----------------.--| |------. | +-+ | | +-+ | | | ->6 6<- | | 4S/6 | '------. .------' | 6 4/6 | | | | 4S/6 6 | : : | 4/6 <---->: 6->6/4P \ / :<----> | 6->6/4 / \ 4S/6 | :------------------' '-------------------: | | | 6->6 6 | '-----------------------------------------' ->x : processing path to be taken if SAM parameters show that type x is possible at the forwarding interface A FLEXIBLE USE SAM CPE ARCHITECTURE Figure 6 Despres Expires April 1, 2009 [Page 11]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 6. SAM host internal architecture Figure 7 presents a generic SAM host architecture. With it, a host can work in non SAM environments as well as in SAM environments, thus preserving the backward compatibility that is necessary for incremental deployment. Socket programming interface : .-- Restricted ports if ->4/4P or ->4/6 : | Local address = 10.0.0.0.1 if -> 4H/6 : | : | : +--+ ->4P 4P 6/4P : |v4| ->4 4 6/4 : | | .-------------------------. 4P : |S | | | 4/4P : |o | | | 4 IPv4 <---->|c |-----: :<------> : |k | | ->4H/6 6/4P | : |e | | ->4/6 +---+ 6/4 | : |t | | ->4/4P | | 4/4P | : |s | '---------| |-----------' : +--+ | S | : ->6/4 | A | : +--+ ->6/4P | M | : |v6| .---------| |-----------. : | | | | | | 4H/6 : |S | | +---+ | 4/6 : |o | | | 6 IPv6 <---->|c |-----: :<------> : |k | | | : |e | | ->6 | : |t | '-------------------------' : |s | : +--+ INTERNAL ARCHITECTURE OF A SAM-CAPABLE CPE Figure 7 The logic is expected to be straightforward enough for operating systems of mobile phones and PCs to have it included it in not too distant a future, in any case well before the end of the coexistence period. Despres Expires April 1, 2009 [Page 12]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 A host that has SAM compatibility has the benefit that it can support server applications that are reachable by IPv4-only hosts, even when this PC gets doesn't get a a global IPv4 address of its own. This remains true if it is behind a SAM CPE that has only a port restricted IPv4 address. Another expected benefit is that, with restoration of end-to-end transparency to IPv4 packets, protocols that need it or work better with it (e.g. SCTP) can work not only in IPv6 with unrestricted ports, but also in IPv4 with restricted ports. Concerning the effect of restricted port ranges, it should be noted that reserving a local port for each outgoing connection, as apparently most socket modules do, leaves plenty of room for optimization: if a local socket used for a given connection identified by its 5-tuple [source and destination addresses & ports and protocol], it can be reused for different 5-tuples. Thus, the number of ports needed by each host can be drastically reduced. Whether this optimization has no risk to interfere with existing NAT traversal techniques like ICE has however to be checked. 7. Security considerations 8. IANA Considerations 9. Acknowledgements So far, the SAM approach has essentially been worked out by the author, with various intermediate stages like the so called Address Borrowing Protocol and the Global Address Protocol, respectively presented in IETF 71 and IETF 72, without any sponsoring or company contract and without seeking intellectual property protection. He therefore wishes to expresses its first acknowledgment to his wife: she accepted that traveling and other expenses be supported by the uni-personal enterprise of the author, the money of which cannot be distinguished from family money. One important and recent progress of the approach has been the recognition that, with the flexibility of DHCP, no new protocol would be necessary to automate SAM parameter settings. Acknowledgment is due to Gabor Bajko and Teemu Savolainen for pointing it out at IETF 72. 10. Informative References [draft-despres-SAM-00] Despres Expires April 1, 2009 [Page 13]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 "Stateless Address Mapping (SAM) - Work in progress", September 2008. Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires April 1, 2009 [Page 14]
Internet-Draft v4-v6 Coexistence - SAM Scenarios September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Despres Expires April 1, 2009 [Page 15]