Re: IPv6 NAT?

[Rémi Després]

Iljitsch van Beijnum wrote : It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. You really don't want to do that for stuff like the web where you can easily end up setting up a dozen new TCP sessions in a second. (Web designers use insanely wasteful techniques with multiple external _javascript_s and style sheets per page, often loaded from different domains, not to mention the persistent use of spacer images.) Duplicate address detection takes too much time to make this useful, and the creation of such a large number of addresses makes DAD all the more important. I share the view that, with only the Duplicate Address Discovery protocol as is, this would be very inefficient. Some work would be needed to complement the DAD protocol in order to improve its efficiency for this kind of application. A number of addresses can at least be acquired in advance, to avoid delays when they have to be used, but this would clearly not be good enough. My feeling is that DAD protocol complements are possible such that  the extended privacy we talk about would become practicable. But it seems  unclear at this stage whether, in order to reach the same privacy and security objective, people will prefer to work on the IPv6 NAT paradygm, or on an Extended Privacy Address paradygm, or on both in parallel,  My point here is just to discuss an ALTERNATIVE to IPv6 NATs with those who believe they are unavoidable. You also don't want to do it for applications that require referrals, such as peer-to-peer. Right. For these applications, addresses to be reached must be published somewhere, e.g. in the DNS. They appear as DESTINATION addresses of newly established connections. They therefore don't conflict with the"one new address for each outgoing connection" rule. (The rule concerns SOURCE addresses, a point which was implicit in what I wrote, but which may be worth making clearer) . RD

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