Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Informational April 7, 2008 Expires: October 9, 2008 A Scalable IPv4-IPv6 Transition Architecture Need for an address-port-borrowing-protocol (APBP) draft-despres-v6ops-apbp-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 October 9, 2008. Abstract This document discusses, for the IPv4-IPv6 coexistence period, the combined requirement that: (1) legacy IPv4 hosts can establish IPv4 transport connections 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 October 9, 2008 [Page 1] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A simple configuration to be supported - need for an APBP . . 4 3. Anycast and unicast IPv6 addresses of APBP servers . . . . . . 5 4. Upward compatibility with other mechanisms - APBP DHCPv6 option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Other supported configurations . . . . . . . . . . . . . . . . 6 5.1. Other transport and upper-level protocols . . . . . . . . 6 5.2. Pure IPv4 end-to-end connections in dual-stack hosts at no public-IPv4 address . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Risk of denial of service attacks . . . . . . . . . . . . 8 6.2. Reuse of obsolete address-port combinations . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Despres Expires October 9, 2008 [Page 2] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 1. Introduction It is now well recognized that, during the transition period from IPv4 to IPv6 [RFC0791] [RFC2460], somme 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 at an IPv6-only 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 the support IPv4-only hosts in sites having IPv6-only public addresses. It also proposes that the complement in IPv6-capable hosts, for their support of IPv4 connections, be simplified, so as to include needing no NAT (and a fortiori no ALG), and to be functionally more powerful, leaving no restriction on which application level protocols can be used. For this, it builds on concepts introduced with the Dual Stack Transition Mechanism (DSTM) which has been introduced as early as in 2000, but became obsolete in IETF documents in 2005. A detailed description of the proposed APBP protocol is beyond the scope of this draft, but no major difficulty is expected to specify one. 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. Despres Expires October 9, 2008 [Page 3] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 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 scalability objective we have retained can be satisfied. An IPv4- only client host is in a site that only has an IPv6 prefix (no public-IPv4 address). It needs to establish an File Transfer Protocol (FTP) connection which a server at a public-IPv4 address. 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 the scalability objective excludes that such a NAT be needed in the ISP infrastructure, it must be in the CPE router of the site. There, it must be able to send to the server IPv4 packets that have their definitive source address, which must be PUBLIC IPv4. This address has therefore to be borrowed from some IPv6-IPv4 ISP gateway, where interfaces to both IPv6 and IPv4 routing domains are available. Between the CPE router and this ISP gateway, IPv4 packets will have to be encapsulated in IPv6 ones. Since public-IPv4 addresses have become a precious resource, borrowing a public-IPv4 address with complete exclusivity for the duration of an FTP connection would be a waste. The CPE router should rather borrow address-port combinations, letting the same address free to be used by other hosts (or the same one) for connections using different ports. In summary, to satisfy the scalability objective of no NAT with ALG in ISP infrastructures for the configuration of Figure 1, an address- port-borrowing-protocol (APBP) is needed. With it, CPE routers, acting as APBP clients borrow address-port combinations from ISP gateways acting as APBP servers. Between APBP clients and APBP servers, IPv4 packets are encapsulated in IPv6 packets. Despres Expires October 9, 2008 [Page 4] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 IPv4-ONLY HOST CPE Router IPv6-IPv4 IPv4-capable HOST ISP Gateway * FTP Client * FTP server .-----. .-----. | | * IPv4-IPv4 NAT | | | | * FTP ALG | | | | * APBP client * APBP server | | | | .---------. .-------. | | | 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 if the stack is dual stack, it has no means obtain a temporary IPv4 public address. o The PROTOCOL STACK is IPv4-only. 3. Anycast and unicast IPv6 addresses of APBP servers For ISP gateways to securely release address-port combinations that are no longer in use, all packets of a given connection must traverse the same ISP gateway, and some form of keep-alive control has to be exercised. On the other hand, different connections established by a given client need not to traverse the same ISP gateway. APBP ISP gateways should therefore have two IPv6 addresses: Despres Expires October 9, 2008 [Page 5] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 o an ANYCAST address, to be used by a client host when it needs to borrow a new address-port combination; o a UNICAST address, to be used by APBP clients as IPv6 destination of IPv4 packets they encapsulate, and to be advertised for this by APBP servers when they lend address-port combinations. 4. Upward compatibility with other mechanisms - APBP DHCPv6 option Upward compatibility of the new mechanism with existing ones must be ensured as follows: o APBP-capable CPE routers must activate APBP if and only if attached to APBP-capable ISP infrastructures. o The behavior of APBP-unable CPE routers must be independent from whether they are attached to APBP-capable or APBP-unable ISP infrastructures. This can be achieved with an APBP specific DHCPv6 option [RFC3315]. This option: (1) is advertised by APBP-capable ISP infrastructures; (2) must have been received by APBP-capable CPE routers before they activate the APBP logic; (3) is ignored by APBP-unable CPE routers (like any DHCPv6 option the code of which is unknown by these routers). Besides its upward compatibility role, the APBP DHCPv6 option is used to indicate to APBP-clients the IPv6 anycast address of APBP servers of their ISPs. 5. Other supported configurations APBP, which has been shown to be necessary for the particular configuration of Section 2, is also applicable to many other configurations. 5.1. Other transport and upper-level protocols 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. Thus, any protocol combination that works across a given IPv4-IPv4 NAT between a private-IPv4 domain and a public-IPv4 domain will also work between a private-IPv4 domain and an IPv6 domain, provided that: Despres Expires October 9, 2008 [Page 6] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 (1) this NAT is completed with an APBP-client function, (2) the local ISP supports APBP servers. Note that among these protocols there are the particular ones that make port reservations in NATs for hosts in private-IPv4 domains to become accessible from the outside (UPnP, STUN etc.). 5.2. Pure IPv4 end-to-end connections in dual-stack hosts at no public- IPv4 address 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). No NAT being needed on the end-to-end path, packets keep their IPv4 source and destination IPv4 addresses and ports unchanged from source to destination. Thus, ALL IPv4-capable applications, which necessarily work with public-IPv4 addresses at both ends, also work across the IPv6 domain of this configuration. APBP-capable IPv6-IPv4 IPv4-only host Dual-Stack Host ISP Gateway * APBP client .-----. .-----. | | <== E2E IPv4 transport connection ==> | | | | | | | | Possible * APBP server | | | | 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 Despres Expires October 9, 2008 [Page 7] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 Applications that need to dynamically advertise their address-port combinations, e.g. for callbacks or referrals, obtain these combinations, when APBP is used, 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. A client application calls getsockname() after having made a connect() function call, which has triggered the needed APBP address- port combination request. A server application calls getsockname() after having made a bind() function call with INADDR_ANY as local IPv4 address, which has triggered the needed APBP address-port combination request. 6. Security Considerations 6.1. Risk of denial of service attacks Like any ISP provided function using limited resources, APBP servers may be subject to denial of service attacks. The amount of traffic needed for such attacks is however significantly greater than that needed for NATs with ALGs, for two reasons : o For a new connection, it is an ANYCAST address which, in the APBP case, is used to reach the ISP gateway in charge of a connection. This facilitates load sharing among many ISP gateways, possibly largely remote from one another. o The amount of processing per data packet needed for APBP can be significantly smaller than that needed for NATs (no transport- level checksums to deal with, and no ALGs needed). 6.2. Reuse of obsolete address-port combinations APBP servers, like NATs, have to maintain stateful information about currently used address-port combinations. Precautions are therefore needed to ensure that, when an address-port combination is reused, no confusion be possible between packets of a new connection and packets of old ones. For this, APBP clients must check that encapsulated IPv4 packets they receive do belong to the right active application socket. They can do it securely if IPv4 packets are encapsulated in UDP datagrams (themselves encapsulated in IPv6 packets), and if UDP ports Despres Expires October 9, 2008 [Page 8] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 of APBP-clients point to the concerned application sockets. With this precaution, no danger of confusion is foreseen between packets of old and new connections that use the same address-port combination. 7. IANA Considerations The following assignments by IANA are desirable: o A UDP port number for the APBP-server application (Section 6.2). o A DHCPv6 option code for APBP-capable ISP infrastructures to advertise their capability (Section 4). 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, as early as in 2000, 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 October 9, 2008 [Page 9] Internet-Draft IPv4-IPv6 transition scalability - APBP April 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 October 9, 2008 [Page 10] Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008 Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Phone: +33 6 72 74 94 88 Email: remi.despres@free.fr Despres Expires October 9, 2008 [Page 11] Internet-Draft IPv4-IPv6 transition scalability - APBP April 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 October 9, 2008 [Page 12]