Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                          SUN Microsystems
Feb 21, 2003
Expires Aug 2, 2003



               Dual stack vs NAT-PT
      <draft-durand-v6ops-dualstack-vs-natpt-00>



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.



. 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.



. 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.



. 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.



. 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].



. Authors addresses

   Alain Durand
   SUN Microsystems, Inc
   17, Network Circle
   UMPK17-202
   Menlo Park, CA 94025
   USA
   Mail: Alain.Durand@sun.com


. 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