Re: on NAT-PT

[Pekka Savola <pekkas@netcore.fi>]

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.

On Mon, 20 Jan 2003, Erik Nordmark wrote:
> > 	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
> 
> 

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