On 2008-08-04 02:09, Noel Chiappa wrote: > > From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > > >>> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf