Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystems Feb 21, 2003 Expires Aug 2, 2003 Dual stack vs NAT-PT Status of this memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. Abstract Outside of the IETF community, lot of people think that IPv4 to IPv6 transition consist merely at solving the problem of how does a v4 box communicate with a v6 box and vice versa. Within the IETF, the dual stack approach has long been defined. There is an ongoing discussion to understand if translation with tools like [NAT-PT] is absolutly needed to enable IPv6 nodes to communicate with an IPv4 node or if we can/should mandate IPv6 nodes to also deploy an IPv4 stack if/when they needs to communicate with IPv4 nodes. This draft is aimed at clarifying the discussion without taking side by studying in 3 cases the implications of mandating a dual-stack versus the implications of deploying a translation device. 1. Case 1: new network A first usage case is for new networks that would like to deploy IPv6 only. Today, we may not have all the pieces to do so, but it is reasonable to think that in the not so distant future, it would be possible. One immediate goal is be to make sure that things works at least as well as if that network had deployed private IPv4 address space instead, so this network wants to enable connections initiated from the inside to the "legacy" Internet. IPv4 connections initiated by the outside won't work, but it would also be the case if the network had used private IPv4 addresses. However, IPv6 connections initiated by either the inside or the outside would work, and this is considered a plus significant enough to justify deploying IPv6. The "use dual stack when talking to v4" strategy requires: - a v4 and a v6 stack on each device that would need to talk to the v4 world. - a way to allocate statically or dynamically v4 addresses to the devices - a way to forward (natively or with v4 over v6 tunnels) v4 packets to those devices. Tools like DSTM may be an interesting option. - v4-aware client applications - private v4 to global v4 translation at the edges if private addresses are used. The "translate IPv6 to IPv4" approach requires: - a v6 stack on all devices - IPv6-aware applications - v6 to v4 translation at the edges. - change of the trust model of DNS-sec where the v6 nodes will have to delegate the signature verifications to the recursive DNS server. Note: this is a consequence of the DNS-ALG described in RFC2766. It is actually possible to define NAT-PT without this DNS-ALG for connections initiated by the IPv6 side. More information on DNS- ALG issues can be found in [DNS-ALG-ISSUES]. Note that, except from the DNS-ALG part which is currently defined in RFC2766, IPv4 to IPv4 NAT and IPv6 to IPv4 NAT share essentially the same properties, so doing private v4 to global v4 translation does not have any significant advantage over doing global v6 to global v4 translation. 2. Case 2: heterogeneous multi-party application A second usage case is a multi-party peer-to-peer application with no rendez-vous points which would like to be IP version agnostic, that is, enabling IPv4-only nodes, IPv6-only nodes and dual stack nodes to participate in the same "call". Note that this kind of application usually does not work today if some of the peers are behind an IPv4 NAT. NAT communications initiated from the v4 side is a much more difficult problem to solve than NAT communications initiated from the v6 side as in the precedent case. The issue is to allocate a temporary v4 address for the v6 peer and return it via the DNS to the v4 peer. If this allocation is performed in the DNS server of the v6 peer, it opens the door to denial of service attacks, so it is a non starter. The alternative is to do the allocation in the recursive DNS server used by the v4 peer. It basically requires cooperation from the v4 peer's ISP to introduce a DNS-ALG. If DNSsec is deployed, it also requires the v4 node to delegate all signature verification to the recursive DNS server. The 'use the dual stack' approach requires: - All peers must use the same IP version. If unmodified IPv4 nodes are to be present in the call, it means that everybody must speak IPv4. An "interesting" case is what happen if all hosts in the call are IPv6 and a new IPv4-only host wants to join. - All peers must have global addresses. The "translate IPv4 to IPv6" option requires: - availability of v6 to v4 translation service, with cooperation of the IPv6 network - availability of v4 to v6 translation service, with cooperation of the IPv4 network infrastructure (DNS-ALG). - change of the trust model of DNS-sec where the v4 nodes will have to delegate the signature verifications to the recursive DNS server. 3. Case 3: end game scenario A third case is an end game scenario, where some legacy IPv4 only hosts or applications can not be upgraded to support IPv6 and the rest of the infrastructure is mainly IPv6. As shown in the previous case study, using NAT requires a DNS-ALG running with the help of the local IPv4 network. The idea behind it is that, if the host (or the application) cannot be modified, maybe the surrounding network infrastructure can be modified at a minimal cost to perform the DNS-ALG functionality. The 'use the dual stack' approach requires: - a global IPv4 address on all v6 servers that want to be reached by the un-upgradable hosts. The "translate IPv4 to IPv6" option requires: - cooperation from the local IPv4 infrastructure to support the DNS-ALG/NAT part - change of the trust model of DNS-sec where the v4 nodes will have to delegate the signature verifications to the recursive DNS server. 4. Security considerations NAT-based solution are known to cause problems with IPsec. The impact on DNS-sec is discussed in sections 1,2 & 3. A more complete discussion on DNSsec and NAT-PT can be found in [DNS-ALG-ISSUES]. 5. Authors addresses Alain Durand SUN Microsystems, Inc 17, Network Circle UMPK17-202 Menlo Park, CA 94025 USA Mail: Alain.Durand@sun.com 6. References [NAT-PT] Tsirtsis, G., Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000 [DNS-ALG-ISSUES] Durand, A., draft-durand-v6ops-natpt-dns-alg-issues-00.txt