durand-v6ops-dualstack-vs-natpt-00

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I think it's useful to try to describe some scenarios from the dual-stack 
vs nat-pt perspective.  I didn't bother to check editorial issues, here 
are a few comments that struck me while reading the draft.

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

==> if v6 deployments are desirable, with really high usage rate of v6, it
would appear to be most desirable to deploy private IP addresses with one or
a few public v4 addresses they map to at the border: the v4 traffic should
be minimum anyway!  In other cases, e.g. TCP relay could be performed for
specific legacy apps.

2. Case 2: heterogeneous multi-party application

   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.

==> when deploying multi-party apps, translation is not useful, due to
reasons given.  The only real possibilities are v4 or v6-only, as you 
point out/imply.

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.

==> TCP relay seems to be a better alternative in this case (== no problem
with DNS ALG), to enable access to few apps and nodes

   to understand if translation with tools like [NAT-PT] is absolutly

==> no refs in the abstract

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings