Re: on NAT-PT

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 	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