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

From: Robin Whittle <[email-masked]>
Date: Tue, 10 Jun 2008 23:28:33 +1000

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 [email-masked] 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

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Jun 2008 12:51:25 -0700

[Apologies for the length]

Robin,

> service when they could also choose an ordinary IPv4 service?

The vast majority of end users don't care about IPv4 or IPv6.  They  
buy "Internet service" and assume what their ISP gives them works with  
the devices they use to get their work done/surf their pr0n.  If the  
end user is unable to get their work done/surf their pr0n, they will  
call their ISP and complain.  As such, I imagine deploying IPv6 to end  
users right now is actually dis-incentivized, particularly at larger  
ISPs due to the costs associated with customer complaints.

> I don't see how

I don't believe RRG is assuming IPv6-only.  I believe RRG is assuming  
dual-stack with (at least) a more scalable IPv6 routing infrastructure  
that may also be applicable to IPv4.

My personal view is that it is _extremely_ unlikely any non-trivial  
technology change can be deployed that significantly alters the IPv4  
infrastructure in any reasonable timeframe.  Instead, what we'll see  
is incremental, evolutionary improvements along the lines of bigger/ 
faster/more expensive routers, additional filtering mechanisms, FIB  
compression, BGP enhancements, etc., along with vastly increased use  
of NAT.

At this point, what I suspect is a realistic best case scenario  
(ignoring mandates and special communities like cell phones):

Assume:

1. increased cost in obtaining IPv4 addresses due to the IPv4 free  
pool runout.

This will naturally drive:

2. increased IPv4 address space utilization efficiency

which includes

3. deployment of IPv6 internally within ISP infrastructures so that  
any IPv4 addresses used in those infrastructures can be re-purposed to  
revenue generating customers (with IPv4 tunneled through IPv6)

and

4. increased deployment of IPv4 NAT (including multi-layer NAT), e.g.,  
only offering customers a single dynamically-assigned public IPv4  
address

with (3) enabling:

5. IPv6 connectivity being provided to end users (since it would be  
essentially zero cost, assuming the CPE supports it)

and (4) encouraging:

6. IPv6-only use since NAT tends to be challenging for lots of  
applications people are increasingly tending to use (e.g., P2P).

I'd argue (1), (2), and (4) are extremely likely regardless of what  
the future might hold.  (3) is a bit of a reach, but hopefully ISPs  
will see it in their best interests to go the IPv6 route instead of  
the RFC 1918 IPv4 route to do this.  The big question marks are (5)  
and (6).  It may be that ISPs can't rationalize providing an  
"additional service" without charging more for it or that people apply  
more and more hacks to make NAT more palatable.  However assuming this  
fanciful scenario pans out, at this point, you have IPv6-enabled end  
users and IPv6-enabled transport.

What is (and has always been) missing is IPv6-enabled content. One  
possible scenario to address this: as IPv4 continues to get sliced and  
diced, ISPs will be forced to start deploying more and more draconian  
filters in order to keep their routers from falling over/converging in  
reasonable timeframes.  As more filters are deployed, content  
providers will begin to see reductions in customers and thus will be  
incentivized to provide IPv6-only content.

So, if you buy into this scenario, fixing IPv4 routing would actually  
be detrimental to moving to IPv6 as there would be no observable loss  
of customers to content providers to drive them to spend the money to  
deploy IPv6.  A bit of a reach, I know.  However if somehow you do fix  
IPv4 routing, all you would be enabling is the increased use of NAT --  
there simply is not enough IPv4 address space to meet projected demand  
without NAT.  While I am not particularly a NAT-hater, I dislike the  
direction it tends to lead (e.g., walled gardens).

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2008 11:35:03 +1200

> with the IPv4 Internet.  What other approaches are there? 

1. IPv4-over-IPv6 tunnels. That assumes that the host with IPv6-only
connectivity is a dual stack host, which applies to about 100%
of IPv6 hosts today. Current work in IETF SOFTWIRE WG.

2. Application level proxies, for the major applications. This
is running code for SMTP, HTTP and other cases.
For many consumer scenarios, this is sufficient.

3. Translation that's better than NAT-PT. See
draft-ietf-v6ops-nat64-pb-statement-req and
draft-bagnulo-behave-nat64 for the latest IETF work on this.

The RRG shouldn't be worrying about this area IMHO.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 10 Jun 2008 18:12:26 -0700

Hi Robin,

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

Others have replied to most of the points that you raised.  As to this one,
I'll just point out that most hosts interact with a very small number of
servers.  If a large number of public web servers (e.g., Google, CNN, Yahoo,
Amazon, etc.) and basic private servers for DNS, SMTP, IMAP and POP have v6
support, many folks would be quite happily working on v6.  The number of
applications that require true any-to-any v6 support is pretty small (e.g.,
p2p protocols).

Thus, I think that once we get the infrastructure actually working with v6,
it will be entirely possible to dual-stack individual hosts without too much
difficulty.

Regards,
Tony