> From: Keith Moore <moore(_at_)network-heretics(_dot_)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...
Noel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf