Re: avoiding pitfalls in v4/v6 NAT (was Re: About IETF communication skills)

On 2008-08-04 02:09, Noel Chiappa wrote:
>     > From: Keith Moore <moore@network-heretics.com>
> 
>     >>> these limitations don't inherently apply to NAT between v4 and v6,
> 
>     >> I thought the inherent problems ... would apply to an IPv4-IPv6 NAT,
>     >> when such a device is used to allow a group of hosts with only IPv6
>     >> addresses to communicate with IPv4-only machines. What am I missing?
> 
>     > one of the worst assumptions in v4 NAT design was the assumption that
>     > the endpoints don't need to know about the NATs. By now it should be
>     > obvious that for a great many reasons, they do. For example, they
>     > clearly need to know about the address binding across the NAT
>     > ...
>     > For similar reasons you can make the management of the address:port
>     > binding an explicit agreement between the host or app and the NAT.
>     > ...
>     > Explicit management of address bindings goes a long way toward getting
>     > rid of the fragility due to address bindings in the NAT.
> 
> Ah, got it. I hadn't realized this was what you meant by "NAT between v4 and
> v6", because to me these are the kind of things that (in IPv4) were being
> explored by the middle-box (MidCom) WG, so I think of them as 'middle box
> functionality', not 'NAT' (since to me, part of what NAT means is that 'you
> don't have to modify the hosts').
> 
>     > The cost of this is that you need an established relationship between a
>     > host and its v4/v6 NAT
> 
> Not just that, but to make this really useful, you'd have to add this 'NAT
> interaction' stuff to the core IPv6 spec, get it added to all IPv6
> implementations, and then get it deployed to all existing IPv6-capable boxes.
> 
> Leaving aside the engineering/logistical difficulties involved in doing all
> that, it seems to me that this would basically amount to formally 'adding NAT
> to IPv6', which is a claim made in the story which some people were saying
> was inaccurate. The fact that it's not necesarily used in v6/v6 interactions
> is an awfully fine hair to split, to claim that 'well, we're not actually
> adding NAT to IPv6'. If it's in the core spec, it's in IPv6.
> 
> (And that v6/v6 exemption might not stand, if people deal with v6's inability
> to give them provider independence, due to its retention of the obsoleteq
> IPv4 single-namespace architecture, by using v6-v6 NATs to give them provider
> independece - which is a big driver for v4-v4 NATs, I gather.)
> 
> Anyway, it seems like the story is more accurate than many people realized...
> Either this functionality is added to the IPv6 core spec, or the IPv6/v4 NAT
> boxes (which many people now seem to feel are required for a viable
> deployment plan) will display the same crippling problems as v4/v4 NAT...

Certainly, my conclusion while working on
http://tools.ietf.org/id/draft-carpenter-shanti
(which is not an active proposal, so no need for a critique ;-)
and I suspect Remi's conclusion while working on
http://tools.ietf.org/id/draft-despres-v6ops-apbp
was very similar - the architectural holes can best be plugged
if the v6 host knows the translation that is in effect. But there's
a strong school of thought that we need to be able to deal
with RFC2460 hosts, i.e v6 hosts that have no such knowledge.

   Brian
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf