Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Informational July 14, 2008 Expires: January 15, 2009 A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing-protocol (APBP) draft-despres-v6ops-apbp-01 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 January 15, 2009. Abstract This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connection s from customer sites having IPv6-only permanent addresses; (2) for good scalability, no network address translations (NATs), and a fortiori no application level gateways (ALGs), need to be supported within network infrastructures. To satisfy this requirement, it is concluded that an address-port-borrowing-protocol (APBP) is needed. Despres Expires January 15, 2009 [Page 1] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A simple configuration to be supported - need for an APBP . . 4 3. Other supported transport connections . . . . . . . . . . . . 5 4. Other supported configurations . . . . . . . . . . . . . . . . 6 5. Some protocol considerations . . . . . . . . . . . . . . . . . 7 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Despres Expires January 15, 2009 [Page 2] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 1. Introduction It is now well recognized that, during the transition period from IPv4 to IPv6 [RFC0791] [RFC2460], some IPv4 transport connections (TCP, UDP, etc.) will have to be established across some IPv6-only infrastructures [Bagnulo-Baker]. Various approaches have been proposed recently for a number of identified transition configurations, namely [SHANTI] [NAT64] [NATv4v6v4] [ALD] [sNAT-PT] [MNAT-PT]. SHANTI has the scalability property that no network address translator (NAT) and a fortiori no application layer gateway (ALG) is needed in internet service providers (ISP) infrastructures. It uses for this, without naming it, a type of protocol which we call here address-port-borrowing-protocol (APBP). With such a protocol, a host that has no public IPv4 address can borrow, from its ISP infrastructure, the address-port combinations it needs to establish IPv4 connections with public-IPv4 addresses. In the client-server configuration of SHANTI, IPv6-capable client hosts, complemented to support SHANTI, establish IPv4 connections with IPv4-only servers. The complement in these hosts includes an internal IPv6-to-IPv4 NAT (with an ALG for all application protocols that need it). This draft proposes to keep the scalability property of SHANTI (No NAT needed in ISP infrastructures), but with a scope extended to support IPv4-only hosts in sites that have no public IPv4 addresses. It also proposes that the SHANTI complement in IPv6-capable hosts, for their support of IPv4 connections: o be simplified, so as to not include a NAT (and a fortiori an ALG) o be functionally more powerful, leaving no restriction on which upper layer protocols can be used (SCTP compatibility in particular) For this, SCTP builds on concepts introduced with the Dual Stack Transition Mechanism (DSTM) which has been introduced in draft-toutain-ngtrans-dstm-00 (expired in 1999) and last documented in draft-bound-dstm-exp-04 (expired in April 2006). A detailed description of the proposed APBP protocol is beyond the scope of this draft, but no major difficulty is expected to specify it. Despres Expires January 15, 2009 [Page 3] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 The proposed architecture being new, and having not been validated on any implementation, is likely to need refinements, and possibly corrections. It is submitted for a first round of reactions. 2. A simple configuration to be supported - need for an APBP We first consider a simple configuration among those that will need to be supported during the transition period, and analyze how the objective of no NAT in the ISP infrastructure can be satisfied Figure 1. An IPv4-only host is in a site that has an IPv6 prefix and has no public IPv4 address. It needs to establish a File Transfer Protocol connection (FTP) whith a server located somewhere on the IPv4 Internet. Since the client has only a PRIVATE IPv4 address, and since the server must only see a PUBLIC IPv4 address to send packets back to its clients, there must be a NAT somewhere between the two endpoints. This NAT has to include ALG for FTP. Since we took as a requirement that no NAT be needed in the ISP infrastructure, NAT capability must be supported in the CPE router of the site. For this NAT to be able to build IPv4 packets having their public IPv4 source address, this address has to be borrowed from some ISP gateway that has interfaces to both IPv6 and public IPv4 routing domains. Between the CPE router and this ISP gateway, IPv4 packets will have to be encapsulated in IPv6 packets. Since public IPv4 addresses have become a scarce resource, and since most customer sites need only a few of the 64K possible ports which can be associated with their IP address, a better usage of public IPv4 addresses is achievable if what is borrowed from ISP gateways is not than just an address, but rather a combination including one address an a range of ports permitted to be associated with it. Thus, the same globally unique IPv4 addresses can be used by other customer sites, for connections using different ports. In summary, to satisfy the objective of no NAT with ALG in ISP infrastructures in the configuration of Figure 1, an address-port- borrowing-protocol (APBP) is needed. With it, CPE routers act as APBP clients. They borrow address-port combinations from ISP gateways that act as APBP servers. Between APBP clients and APBP servers, IPv4 packets are encapsulated in IPv6 packets. Despres Expires January 15, 2009 [Page 4] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 IPv4-ONLY HOST CPE Router IPv6-IPv4 IPv4-capable HOST ISP Gateway * FTP Client <====> <========== FTP / TCP ==========> * FTP server .-----. .-----. | | | | | | * IPv4-IPv4 NAT | | | | * FTP ALG | | | | * APBP client * APBP server | | | | .---------. <= APBP=> .-------. | | | 4 | | 4 4/6| |4/6 4 | | 4 | '--+--' '-+-----+-' '-+---+-' '--+--' | | | | | | '----------' '---------------' '---- . . . ---' Private-IPv4 IPv6 ONLY Public IPv4 \____________________/ \______-__________/ Customer site ISP infrastructure A SIMPLE CONFIGURATION TO BE SUPPORTED (APBP = address-port-borrowing-protocol) Figure 1 Note that the reason why the client host is IPv4-only for the considered connection can be one of the following: o The APPLICATION is IPv4-only, and the host has no public IPv4 address (the protocol stack can be IPv4-only or dual stack). o The PROTOCOL STACK is IPv4-only (the application can be IPv4-ony or IPv4 and IPv6). 3. Other supported transport connections All other transport protocols than TCP and all other application- level protocols than FTP that are supported in the IPv4-IPv4 NAT of the CPE router are possible on the physical configuration of Figure 1. Transport connections in the reverse direction are also possible, if the NAT has assigned some address-port combinations for them, typically by means of one of the existing protocols existing for this (STUN, UPnP, NAT-PMP, etc.). Despres Expires January 15, 2009 [Page 5] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 More generally, any protocol combination that works today across a IPv4-IPv4 NAT of a given type will also work, with the same type of IPv4-IPv4 NAT in any site having no public IPv4 address provided that: 1. The site has an IPv6 prefix. 2. The local ISP supports APBP servers. 3. This IPv4-IPv4 NAT is complemented with an APBP-client function. 4. Other supported configurations If the support of the APBP-client function is added to a dual-stack host, and if this host is attached to an ISP infrastructure where APBP is supported, this host can establish pure IPv4 end-to-end transport connections with IPv4-only remote hosts (Figure 2). APBP-capable IPv6-IPv4 IPv4-only host Dual-Stack Host ISP Gateway <======= E2E IPv4 transport connection =======> * APBP client <== APBP ==> * APBP server .-----. .-----. | | Possible | | | | IPv6-capable .-------. | | | 4/6 | CPE router |4/6 4 | | 4 | '--+--' | '-+---+-' '--+--' | V | | | '---------- . . . ----------' '---- . . . --' IPv6 IPv6 Public IPv4 \_________________/ \________________/ Customer site ISP infrastructure APBP BETWEEN ABPB-CAPABLE DUAL-STACK HOSTS AND ISP GATEWAYS Figure 2 No NAT being needed on the end-to-end path, packets keep their IPv4 Despres Expires January 15, 2009 [Page 6] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 source and destination IPv4 addresses and ports unchanged from source to destination. All IPv4 capable applications that need public-IPv4 addresses at both ends can work across the IPv6 domain of this configuration. In this configuration, applications that need to dynamically advertise their address-port combinations, e.g. for callbacks or referrals, obtain these combinations at their socket programming interface as usual. With Windows Sockets, for example, local address-port combinations are obtained by applications as results of getsockname() function calls. Client applications make these calls after having made connect() function calls. Server applications call make them after their bind() function calls with INADDR_ANY as local IPv4 addresses. 5. Some protocol considerations Since some server applications check that several related transport connections initiated by a same client do come from the same IP addresses, APBP clients should borrow only one public IP address, and manage a set of ports to be used with this address. For simplicity, and to minimize interactions between APBP clients and servers, these ports should be obtained in significant quantity at each request. This quantity necessarily depends on policies of ISPs that operate APBP servers. Typically, a maximum quantity per customer site would help preventing denial of service attacks. Provision could be made in the protocol for APBP clients to increase and decrease from time to time the number of their borrowed ports according to fluctuations of their needs. In APBP clients, port management may be optimized so as to increase the number of transport connections that are possible with a given number of ports. In particular, port reuse based on endpoint dependent mappings may be envisaged for ports that are assigned to outgoing transport connections known not to need endpoint independent mapping (DNS, HTTP, SMTP, POP3, NNTP, Telnet, SNMP, etc.). To avoid that APBP client failures would cause indefinite port reservations in APBP servers, some keep-alive mechanism should be part of the protocol. Also, APBP clients should explicitly release their borrowed address-ports when they have been using none for a significant time. For scalability of the APBP server function, the destination address used by APBP clients to request address-ports sets when they have Despres Expires January 15, 2009 [Page 7] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 none yet,would advantageously be an anycast address. Responses to these requests should then indicate unicast addresses of particular APBP server instances that have responded (further exchanges of encapsulated IPv4 packets must be with these particular instances, where the particular address-ports that have been obtained are managed). 6. Security considerations If a third party would be able to act as an ISP APBP server, it would be able to intercept all the end-to-end traffic that uses an public IPv4 address borrowed from it. This can however be made impossible if, in infrastructures of ISPs that support APBP, precautions are taken so that addresses of APBP servers cannot be counterfeited from customer sites. 7. IANA Considerations The protocol has still to be specified in details, but it can be expected that a UDP port number will be needed for the supervisory part of APBP. Also, having a standardized anycast address to reach APBP servers would be simpler than depending on an ISP dependent parameter, plus maybe a DHCPv6 option to advertise it. 8. Acknowledgements This draft is in continuity with previous works that influenced it, or at least anticipated some of its contents. In particular, the work of Laurent Toutain and his colleagues on DSTM had a significant influence. Myung-Ki Shin's work on the port option of DSTM in 2002 was unknown by the author, but anticipated the idea of address-port combination borrowed by IPv6-capable hosts. Brian Carpenter was first, as far as the author knows, to post a draft where address-port combinations were borrowed directly from ISP gateways. Despres Expires January 15, 2009 [Page 8] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 9. References 9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 9.2. Informative References [ALD] "draft-woodyatt-ald-02 (work in progress)", December 2007. [Bagnulo-Baker] "draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in progress)", February 2008. [DSTM] "Dual Stack Transition Mechanism - http://www.ipv6.rennes.enst-bretagne.fr/dstm/". [MNAT-PT] "draft-v6ops-van-beijnum-mnat-pt-00 (work in progress)", February 2008. [NAT64] "draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in progress)", November 2007. [NATv4v6v4] "draft-durand-v6ops-natv4v6v4-00 (work in progress)", November 2007. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [SHANTI] "draft-carpenter-shanti-01.txt (work in progress)", November 2007. [sNAT-PT] "draft-miyata-v6ops-snatpt-00 (work in progress)", February 2008. Despres Expires January 15, 2009 [Page 9] Internet-Draft IPv4-IPv6 transition scalability - APBP July 2008 Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires January 15, 2009 [Page 10] Internet-Draft IPv4-IPv6 transition scalability - APBP July 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 January 15, 2009 [Page 11]