Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: May 17, 2008 November 14, 2007 Modified Network Address Translation - Protocol Translation draft-van-beijnum-modified-nat-pt-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 May 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A smooth transition from IPv4 to IPv6 requires that either all hosts are upgraded to dual stack before the first hosts can become IPv6- only, or that there be some mechanism for IPv6-only hosts to talk to IPv4-only hosts. Expecting the former within a reasonable timeframe isn't realistic, based on current adoption of dual stack combined with the latest projections for the IPv4 depletion that point to a date early in the next decade. And the IETF has recently deprecated the main mechanism that allows the latter: NAT-PT. van Beijnum Expires May 17, 2008 [Page 1] Internet-Draft Modified NAT-PT November 2007 This document proposes modifications to NAT-PT that address the reasons why the mechanism was deprecated. This should allow future deployment of the modified NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the option to run their networks largely IPv6-only. 1. Introduction The original NAT-PT mechanism outlined in [RFC2766] couples three underlying techniques to arrive at a comprehensive solution that allows IPv6-only hosts to initiate connections or associations towards IPv4-only hosts: o Stateless IP and ICMP Translation [RFC2765] o Network Address / Port Translation o A DNS Application Layer Gateway [RFC2694] Basically, when an IPv6 host wants to connect to a service, it looks up the associated host/service name in the DNS. If no AAAA records are available for the name in question, the DNS ALG synthesizes an AAAA record based on the A record for the host/service and a prefix that's routed to a translation device. The IPv6 host initiates communication towards the resulting IPv6 address. The associated packets end up at the translator, which recovers the original IPv4 destination address, translates between IPv6 and IPv4, performs IPv4 NAT and sends the resulting packet to the IPv4 destination. Return packets are translated back and sent to the IPv6 host. [RFC4966] explains why this is problematic. The main objections boil down to hosts being exposed to an unexpected environment, issues with referrals in the absense of relevant Application Layer Gateways, generation of synthetic DNS responses that may be harmful if not properly contained and constraints on network topology. This document proposes two different approaches to mitigate this problem: one where the IPv6-side is aware of the translation, and one where the IPv4-side is aware of the translation. The former is useful to give hosts with only IPv6 connectivity access to the IPv4- only internet, the latter is an easy way to make services available over IPv6 with very few changes to the IPv4 infrastructure providing that service. Although this document goes into some detail, it's intended as a discussion document; as such, not every aspect is completely worked out. Readers are encouraged to also review [I-D.carpenter-shanti]. van Beijnum Expires May 17, 2008 [Page 2] Internet-Draft Modified NAT-PT November 2007 In some circles, a distinction is made between Network Address Translation (NAT) which only translates just addresses, and Network Address/Port Translation (NAPT) which translates both addresses and TCP/UDP port numbers. No such distinction is made here; "NAT" is used to refer to both types of translation. 2. Operation with modifications on the IPv6 side There are two modifications possible. The only one mandated by this document is the use of A records. 3. Use of A records In the original NAT-PT design a DNS ALG would create synthetic AAAA DNS records for FQDNs that only have A records. This behavior is no longer supported; IPv6 hosts that want to communicate with IPv4 hosts must now look up the A records themselves and create a synthetic IPv6 destination address from the IPv4 address bits and a /96 prefix that is routed to the translator. The /96 prefix and hence the translation device used may be configured administratively, but an anycasted default prefix (TBD) is made available so that IPv6 hosts can use a topologically close translation device without configuration. 3.1. Use of a synthetic IPv4 source address Optionally, IPv6-only hosts may support IPv4 (and IPv6-mapped IPv4) socket calls for compatibility with applications that don't support native IPv6 communication and/or need to be aware of the fact that communication is happening over IPv4 and is subject to NAT. A natural way to indicate this is through the use of an IPv4 source address from [RFC1918] space. An IPv6-only host implementing IPv4 compatible socket calls picks one of its global scope IPv6 addresses as the source address for MNAT-PT. It then generates a local IPv4 address in the prefix 172.31.0.0/16, where the lower 16 bits are chosen such that a TCP or UDP checksum computed over the IPv6 addresses that appear on the wire are the same as those resulting from the synthetic IPv4 source address and the IPv4 destination address. This means that the value of the lower 16 bits in the synthetic IPv4 address are generated through the one's complement addition of the 16-bit words that make up the 96 bit prefix used for IPv4 destinations reachable through the translator and the selected IPv6 source address. Then, a one's complement subtraction of the value van Beijnum Expires May 17, 2008 [Page 3] Internet-Draft Modified NAT-PT November 2007 44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix. The result of this is that TCP and UDP checksums computed over both the IPv4 and MNAT-PT IPv6 representations of packets destined for the translator are the same. UDP packets MUST have a valid checksum. The resulting synthetic IPv4 address is internally used as the source address in all IPv4 processing. 3.2. Operation Packets towards to-be-translated IPv4 destinations are transmitted over the network as usual. The translation device performs SIIT translation and IPv4 NAT. The possible artificial IPv4 source address is ignored during these steps, since it is not required by either of them except as a means to (de)multiplex packets to/from different hosts. However, since different hosts served by the same translation device may have selected the same artificial IPv4 address, (de)multiplexing based on this value won't work well. So the SIIT and NAT functions must be integrated such that the NAT (de)multiplexes based on the real IPv6 source address rather than the artificial IPv4 address. 4. Operation with modifications on the IPv4 side In complex networks, such as large scale content distribution networks, it is very hard to upgrade the entire infrastructure to IPv6. In these cases, it can be beneficial to deploy SIIT at the edge of an administrative domain in order to make services available over IPv6 while maintaining a largely unmodified IPv4 network internally. Since it's not possible to encode an IPv6 address into an IPv4 address, operation is slightly differently here: a range of IPv4 addresses dynamically mapped to the IPv6 addresses that the IPv4 host communicates with. Mappings can created in several ways: 1. When an incoming packet from an IPv6 host arrives 2. When the IPv4 host explicitly request a mapping over a control connection 3. When the IPv4 host sets up a TCP session to the translation device and requests a mapping in-band (like the HTTP CONNECT method) 4. As a side effect from DNS lookups Because 3. is already readily available in HTTP proxies and [RFC4966] outlines problems with DNS ALGs and also because this doesn't support van Beijnum Expires May 17, 2008 [Page 4] Internet-Draft Modified NAT-PT November 2007 referrals by address, 3. and 4. will not be discussed any further. 4.1. Mapping creation for incoming IPv6 packets When an incoming IPv6 packet arrives, the translation device selects an available IPv4 address from the pool of addresses (presumably, these are [RFC1918] addresses). It then either maps the IPv6 source address to the selected IPv4 address regardless of protocol and port information, or it creates a mapping for a single UDP association or TCP session. The former has the advantage that multiple sessions/ associations can be translated without creating more mapping state, and that non-UDP/TCP protocols can be accommodated. Overloading IPv4 addresses from the pool allows for more mappings for a given pool size. The destination IPv6 address is replaced with the IPv4 address for the intended host. Optionally, it is possible to have one IPv6 destination address map to more than one IPv4 address; in this case, the translation device also tracks which IPv6 destination address is forwarded to which IPv4 destination. The IPv4 host receiving the translated packets can either operate as an unmodified IPv4 host, in which case it can run protocols that don't embed IP addresses in the communication. However, if addresses must be embedded, the IPv4 host must be made aware of the translation, recover the original IPv6 addresses used and present these to the application. The IPv6 addresses are recovered through a control connection towards the translation device. 4.2. Explicit mapping creation Explicit mapping creation over a control connection happens when the IPv4 host wants to initiate communication towards an IPv6 destination. (Note that when IPv4 addresses from the pool aren't overloaded, it's possible for the IPv4 host to set up new sessions towards an IPv6 host it's already communicating with.) When applications on the IPv4 host use connect(), send() and similar primitives towards IPv6 destinations, the TCP/IP stack must delay these calls while it asks the translation device to create a mapping towards the requested destination. When the mapping is created, the TCP/IP stack continues to process the socket calls but creates IPv4 packets towards the pool address that belongs to the created mapping. 5. The control connection Optionally, A control connection is used to create mappings, recover real addresses, perform authentication and detect loss of state in the translation device. Very likely, a suitable existing light- weight protocol can be reused for this. van Beijnum Expires May 17, 2008 [Page 5] Internet-Draft Modified NAT-PT November 2007 Discussion: do we want to perform generic NAT traversal functions though the control connection, or do we want to use existing uPnP and NAT-PMP protocols for this? There are security issues with these protocols, but they are widely used in home networks. The use of protocols like STUN is also possible, but these aren't widely deployed in home networks. 6. Disadvantages The disadvantage of this mechanism is that it requires the host on one side of the connection and NAT-PT devices to be modified to support the mechanism. As such, deployment is non-trivial. 7. Advantages There are several advantages. An important one is that NAT issues only come up when the host is communicating towards IPv4 addresses. As such, it's trivial for applications to limit NAT workaround code to sessions towards IPv4 destinations and assume global addressability for IPv6 destinations. Since there is no DNS ALG, there are no issues with possible leakage of synthetic AAAA records. Both IPv4 applications that use IPv4 socket calls and IPv6 applications that use IPv6 socket calls with IPv6-mapped IPv4 addresses can work over MNAT-PT. Alternatively, light-weight implementations may omit all IPv4 code except the ability to resolve A records. 7.1. Advantages over providing real NATed IPv4 connectivity An obvious way to enjoy many of the same benefits would be to build a network that supports both IPv6 and IPv4 with NATed connectivity. However, this means that there must be an IPv4 network infrastructure in place in the form of IPv4 routers and IPv4 address provisioning (DHCP). Today, this is easy to do in smaller installations if there is a single public IPv4 address available. However, in larger networks the planning of private IPv4 addressing can become cumbersome, and when IPv4 addresses are scarce, it may be unavoidable to implement multiple levels of NAT. Multiple levels of NAT at the very least impose the limits of the most restrictive NAT, and also make hole punching that is used to be able to receive incoming connections much harder as a single set of port numbers must be shared by a larger number of hosts. NAT traversal technologies may or may not support multiple layers of NAT. With MNAT-PT, it's only necessary to provision IPv6 connectivity and addressing, which is easier to plan for because unlike IPv4, a van Beijnum Expires May 17, 2008 [Page 6] Internet-Draft Modified NAT-PT November 2007 standard /64 IPv6 subnet supports arbitrary numbers of hosts. The translation device that performs NAT and the hosts making use of the MNAT-PT service can be located with few topological constraints, so multiple layers of NAT are much easier to avoid. 8. Evaluation of RFC4966 concerns This section provides an overview of the issues raised in [RFC4966] and how they apply to the use of modified NAT-PT with modifications on the IPv6 side. 8.1. Issues with Lack of Address Persistence To-be-translated IPv4 destination addresses map to the same IPv6 destination address until the host selects a different /96 prefix. However, if addresses are stored in their IPv4 form, this doesn't lead to broken referrals. Issues with mapping persistence from the IPv4 side to the IPv6 side are the same as with regular NAT and can be solved in the same way: by having the application or OS set up a persistent mapping that allows incoming connections. 8.2. DoS Attacks on Memory and Address/Port Pools Denial-of-service issues are mostly the same as with regular NAT. When a non-anycast translator is used, it's likely that authentication through a control connection is required, allowing for easy rejection of to-be-translated traffic coming from addresses that don't have an active control connection. However, unless the IPv6 source host and the translator are prepared to set up an IPsec tunnel, there is no way to reject to-be-translated traffic which spoofs the source address of a host with an active control connection. If the source host uses an IPv6 source address for this communication that it doesn't use for other types of communication, only on-path attackers or hosts on the same subnet have easy knowledge of the source address in question. 8.3. Issues Directly Related to Use of DNS-ALG N/A. 8.4. Impact on IPv6 Application Development Applications see regular IPv4 destination addresses for to-be- translated destinations so they can engage IP version specific code paths as required. The presence of the [RFC1918] synthetic source address makes it possible for applications to use NAT workarounds for to-be-translated destinations. The extra work the application needs van Beijnum Expires May 17, 2008 [Page 7] Internet-Draft Modified NAT-PT November 2007 to do here is the same as it would when running on a dual stack host. Alternatively, TCP/IP stacks may forego implementing the synthetic IPv4 source address and/or applications may choose to remain ignorant of whether they're communicating with an IPv4 or IPv6 correspondent. In those cases, address-based referrals are likely to break for IPv4 destinations unless the MNAT-PT translator employs an Application Layer Gateway for the protocol that's used. 9. IANA considerations None at this time. 10. Security considerations Security considerations need to be worked out in a revision of this document. 11. References 11.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. 11.2. Informative References [I-D.carpenter-shanti] Carpenter, B., "Shimmed IPv4/IPv6 Address Network van Beijnum Expires May 17, 2008 [Page 8] Internet-Draft Modified NAT-PT November 2007 Translation Interface (SHANTI)", draft-carpenter-shanti-01 (work in progress), November 2007. Appendix A. Document and discussion information The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the v6ops mailinglist or directly to the author. Author's Address Iljitsch van Beijnum IMDEA Networks Av. Universidad 30 Leganes, Madrid 28911 ES Phone: +34-91-6246245 Email: iljitsch@muada.com van Beijnum Expires May 17, 2008 [Page 9] Internet-Draft Modified NAT-PT November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). van Beijnum Expires May 17, 2008 [Page 10]