Subject: Re: on NAT-PT

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Jan 2003 00:59:35 +0100 (CET)

> 	there are some concerns raised in the working group meeting
> 	with respect to NAT-PT.  it seems to me that the concerns does not
> 	have enough technical ground (or there are some confusions in
> 	understanding how NAT-PT works).  i don't see the need for revising
> 	NAT-PT at all.  some clarifications on the document might be nice,
> 	but no major re-work is needed, IMHO.

Sorry for the delay in responding.

As a WG contrinutor I disagree.
I think both NAT-PT and SIIT should be moved to historic or at least
to a status where their deployment is not recommended.
(And I think I understand Rob's comments that NAT-PT might be useful
when the network is mostly IPv6 with some IPv4 islands needing
NAT-PT functionality, but that isn't what NAT-PT is being proposed for today.
Resurrecting it when we need that functionality would be fine.)

The primary reason for this is unnecessary complexity.

I assert that 90-99% of the cases where they are used one can instead
use dual-stack hosts (and routers) with private IPv4 addresses and
a good old IPv4 NAT.

This has makes IPv6 add less complexity than having network operators
not only have to understand and deal with the bad behaviors of
their IPv4 NATs, also have to deal with the, likely slightly different,
bad behaviors of NAT-PT boxes.

Also, I expect NAT functionality to evolve over time because folks are
using it and feeling the pain. But such improvement, whether done in the NAT
boxes or by specifying and implementing protocols which work across
the NAT, will be done first for IPv4 NATs with the NAT-PT functionality
lagging.

Two examples is STUN and IPsec. STUN can be used to cross IPv4 NAT boxes,
but it is explicitly designed to not work with NAT-PT boxes since the
protocol can not carry IPv6 addresses.
There are non-standard IPsec implementations which work across IPv4 NATs,
but I don't know of any that work across NAT-PT. And the IPsec WG
might one day standardize this, but I expect any NAT-PT variant will
be deferred in standardization or productization.

So I think the preferred scheme for this type of interoperability should
be what we already have - IPv4 private addresses and IPv4 NATs.
With IPv6 end-to-end communication when communicating with IPv6 peers.

Of course, there is 1-10% of cases when this is unattractive e.g. due
to the need to route IPv4 inside the domain and it would make sense for the
WG to try to understand that space better. In some of those cases
I think the dual routing will be simpler than having a new type of NAT device
to deal with. In other cases it might be sufficient to have proxy functionality
at the v4/v6 boundary and no NAT (e.g. SIP, HTTP, SMTP)

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Jan 2003 06:20:54 +0200 (EET)

I totally agree with Erik.  NAT-PT/SIIT seem like mechanisms which could
be useful if you want to artificially remove IPv4 even when the hosts do
want to use IPv4.

I many transition mechanism solutions I keep asking why should it be this 
complex.  We should be able to advocate e.g. dual-stack capabilities.

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

---

From: [email-masked]
Date: Mon, 20 Jan 2003 17:11:17 +0900

>complex.  We should be able to advocate e.g. dual-stack capabilities.

	i do not really advocating NAT-PT itself, so i personally am okay to
	see it go away.  but there are scenarios such as 3GPP/cellular ones
	that tries to deploy IPv6-only clients.  do you recommend them to
	do dual stack instead, or?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Jan 2003 14:46:09 +0200 (EET)

> 	do dual stack instead, or?

There are those 1-10% of cases where 3GPP might fit.

But if we don't want that, providing ALG's to 3GPP and requiring they will
have to use v6 for the rest could be acceptable too.  But really, 3GPP (as
long as you don't connect your laptops to your phones :-) is a rather
restricted scenario in which NAT-PT could be acceptable.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 20 Jan 2003 10:21:25 -0500

>As a WG contributor I disagree.

Also as an individual contributor...

I agree with Erik.  I haven't seen a case yet where NAT-PT cannot be
replaced with a less damaging and simpler mechanism (or combination
of mechanisms), such as dual-stack hosts and tunneling.

>[...]

Exactly.  Any node that needs to make a connection to an IPv4-only
node or service must include an IPv4 stack.  Any node that needs to
connect to an IPv6-only node or service must include an IPv6 stack.
Nodes that need to do both must be dual-stack.  It just make sense.

NAT-PT also has some problems that would be a serious limitation for
almost any deployment, such as the inability for two nodes on the
IPv6-only side of a NAT-PT box to establish an IPv4 connection to
each other.

>at the v4/v6 boundary and no NAT (e.g. SIP, HTTP, SMTP)

There are also other alternatives that would not require IPv4
routing within the domain.  For example, a dual stack host running
in an IPv6-only infrastructure could set-up an IPv4 in IPv6 tunnel to the
a dual-stack router on the edge of the IPv6-only network.  The IPv4 address
for the dual-stack host could be dynamically allocated/leased, allowing a
large number of nodes that occasionally use IPv4 to share a smaller
number of IPv4 addresses.  DSTM offers one example of this type of
mechanism.

The proxy alternative may make sense for the 3GPP IMS case, as this
is a special case where only certain services are required to be
IPv6-only.  IMS-capable handsets may still be capable of opening
IPv4 PDP contexts for communication with non-IMS IPv4 nodes and
services.

I don't think that we've explored these alternatives enough to know
which would make the most sense for the 3GPP IMS situation, and I
don't think that we should settle on NAT-PT as the solution for that
scenario until we have actively looked for alternatives that avoid the
problems of NAT-PT.

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 09:58:17 +0100 (CET)

> number of IPv4 addresses.  DSTM offers one example of this type of

Yes, I think the ability to use DHCPv* to setup tunnels (that terminate
within the same admin domain) is a useful tool, the same way that tunnel 
broker/TSP is a useful tool to setup tunnels that cross admin boundaries
(where some authentication/sign-in is needed). I think that is the key
essence of DSTM.

But I'm not certain one can get much IPv4 address reuse by using short
leases. It depends on the traffic pattern and type of applications
folks use and since that is quite unpredictable the conservative thing
would be to design for the worse case which I think means one IPv4 address
per IPv6 address.

Still, this could be combined with a v4NAT for sharing IPv4 addresses.
I think this is lower complexity than NAT-PT/SIIT since it just piles
boxes (or functions if folks want to implement them in the same
box) after eachother with no interaction between them.
Thus you'd have a box terminating the IPv4 in IPv6 tunnel, and after that
a v4NAT. Thus you avoid running IPv4 except between the tunnel box and
the v4NAT (and externally).

  Erik