[RRG] NAT-PT and other approaches to IPv6 adoption

[Robin Whittle <rw@firstpr.com.au>]

Since widespread IPv6-only adoption in some time frame might make it
not worthwhile to develop a solution for IPv4, the question of IPv6
transition mechanisms is crucial for the RRG.

NAT-PT is one approach to enabling an IPv6-only host to communicate
with the IPv4 Internet.  What other approaches are there?  If there
are none, then IPv6-only hosts are only going to be viable for most
end-users in an environment where almost all other hosts have IPv6
addresses.

That is an enormous chicken and egg problem, and the current very
low adoption rate of IPv6, even for dual-stack, gives me no reason
to think there is a substantial chicken to lay a real egg, or such
an egg to grow into a chicken.  There is just an imaginary chicken
and her imaginary egg, which some folks can easily imagine coming to
life.  I can't imagine this occurring in the next decade, except
perhaps for captive customers in certain countries and with
cellphones which don't need to run the full set of IPv4 application
protocols.

A diagrammatic explanation of NAT-PT is here:

 http://www.lucastomicki.net/naptd.php
 http://www.lucastomicki.net/naptd.docs.php
 (My previous message linked to other NAT-PT things.)

This Linux NAT-PT has three separate pools of IPv4 addresses for
translating three classes of packets: TCP, UDP and ICMP.  What about
SCTP?

RFC 4966 (2007-07) changes the status of the NAT-PT RFC 2766 to
"historic".  It lists many problems and doesn't recommend an
alternative.


Are there any reports on practical systems which provide usable
Internet services today with IPv6-only addresses, even with some use
of IPv4 space to provide limited connectivity to the IPv4 Internet
via NAT-PT or some other mechanism?

If someone cites Application Level Gateways, please provide
specifics and discuss the problems of having such
application-specific things in the network itself.  Also, there are
problems with any such IPv6 to IPv6 ALG or NAT, as mentioned at:
http://tools.ietf.org/html/rfc4966#page-5:

/----

  Issues that are independent of the use of a DNS-ALG and are,
  therefore, applicable to any form of an IPv6-IPv4 translator:

  *  Disruption of all protocols that embed IP addresses (and/or
     ports) in packet payloads or apply integrity mechanisms using
     IP addresses (and ports).

  *  Inability to redirect traffic for protocols that lack
     demultiplexing capabilities or are not built on top of specific
     transport-layer protocols in situations where one NAPT-PT is
     translating for multiple IPv6 hosts.

  *  Requirement for applications to use keepalive mechanisms to
     workaround connectivity issues caused by premature NAT-PT state
     timeout.

  *  Loss of information due to incompatible semantics between IPv4
     and IPv6 versions of headers and protocols.

  *  Need for additional state and/or packet reconstruction in
     NAPT-PT translators dealing with packet fragmentation.

  *  Interaction with SCTP and multihoming.

  *  Need for NAT-PT to act as proxy for correspondent node when
     IPv6 node is mobile, with consequent restrictions on mobility.

  *  NAT-PT not being able to handle multicast traffic.

  Issues that are exacerbated by the use of a DNS-ALG and are,
  therefore, also applicable to any form of an IPv6-IPv4 translator:

  *  Constraints on network topology.

  *  Scalability concerns together with introduction of a single
     point of failure and a security attack nexus.

  *  Lack of address mapping persistence: Some applications require
     address retention between sessions.  The user traffic will be
     disrupted if a different mapping is used.  The use of the DNS-
     ALG to create address mappings with limited lifetimes means
     that applications must start using the address shortly after
     the mapping is created, as well as keep it alive once they
     start using it.

  *  Creation of a DoS (Denial of Service) threat relating to
     exhaustion of memory and address/port pool resources on the
     translator.

\----

Is there a test-bed showing how IPv6-only services can be
implemented such that ordinary end-users would pay for such a
service when they could also choose an ordinary IPv4 service?

Without something really substantial or promising, I don't see how
the RRG can assume that IPv6-only adoption and consequent migration
from IPv4 will happen anything like soon enough that the IPv4
routing scaling problem doesn't need to be solved.

I will observe radio silence for at least 24 hours.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg