Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new BEHAVE charter

On Monday 20 October 2008 13:37:05 ext Iljitsch van Beijnum, you wrote:
> Interestingly, I did a small survey about whether people _expect_
> there to be NAT66 in the future and the majority said "yes".
>
> On the one hand we can do nothing and if all goes well there will be
> no IPv6 NAT so we're all happy because not doing anything made the
> right thing happen. (Although I've used a NAT66 implementation myself
> some years back, so there is at least one out there.)
>
> But if we do nothing, we run the risk that someone will do a quick
> search and replace on their NAT44 code and create a port overloading
> NAT66. The port overloading is 90% of the harmful stuff that NAT boxes
> do.
>
> What we could do is come up with a stateless, transport-agnostic 1-
> to-1 NAT66 spec so we at least avoid the port overloading and nothing
> much breaks except referrals.

I share your analysis that, _assuming_ we have NAT66, it should be 
transport-agnostic. IPv6 has a large enough address space, and we are 
painfully aware of the problems of transport-dependent NAT(44).

However, when I look at the reasons for deploying NAT:
1/ address space shortage
2/ inbound firewalling
3/ topology hiding
4/ prefix delegation "bypass"

(1) is a non-issue for IPv6. (2) is solved with stateful firewalling and does 
not require NAT. 1:1 NAT fails to solve (3) as it does hide the subnetting 
scheme, but fails to hide individual hosts. This leaves only (4). Did I miss 
anything?

I still believe we will see NAT66. Not because it's immediately useful. Rather 
because someone will figure out it's easy to adapt NAT44 code to do NAT66. 
For instance, much of the Linux Netfilter framework has become IP 
version-independent lately, with NAT being the only one big remaining 
IPv4-specific chunk.

I guess only time would tell whether a NAT66 1:1 spec would help prevent such 
the transport-dependent NAT66 being _deployed_. It cannot hurt to write that 
spec, I suppose. In any case, the abomination will be _implemented_ :-( It is 
too natural/easy/tempting.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim