On 2008-07-17 06:19, Christian Vogt wrote: > > Brian E. Carpenter wrote: > >>> For communications between upgraded and legacy edge networks, address >>> rewriting happens unilaterally on the border of the upgraded edge >>> network. To avoid address inconsistencies between IP header and >>> payload also in this case, Six/One Router relies on application >>> functionality for network address translator traversal. Applications >>> that may be affected by such address inconsistencies depend on this >>> functionality already today, due to the existing deployment of network >>> address translators. It is hence safe to assume that those >>> applications, which use addresses in packet payloads, also support >>> network address translator traversal. >> >> I don't find this OK in an IPv6 environment. We've worked very hard >> for years to make sure that IPv6 deployment doesn't require NAT, and >> it is not a correct assumption that applications can support NAT >> kludges for IPv6 just because they must do so for IPv4 (including >> IPv6-IPv4 packet level translation). > > > Brian, > > you are implying that stateless unilateral address rewriting, which > the Six/One Router paper [1] proposes for backwards compatibility, is > as evil as classic NAT'ing. I would like to question this. > > I know you are very critical of NAT'ing, and rightly so because > NAT'ing has three fundamental shortfalls: > > (a) NAT'ing makes it hard to contact hosts behind a NAT because hosts > behind a NAT use non-unique addresses. > > (b) NAT'ing reduces the ability of the network to re-route traffic in > the event of a path failure because it creates a state in the > network that communication sessions depend on. > > (c) NAT'ing requires applications that use address referrals in packet > payloads to implements NAT traversal capabilities.
(c) is only part of the problem caused by the Internet's conflation of the locator and identifier functions - the application layer is full of this problem, and only a few very well-defined applications can be fixed up by an ALG as a result. I really don't see any reason to drag this problem into IPv6. The idea is to get away from the need for horrible things like STUN, not to perpetuate them. > > But it would not be correct to conclude that stateless unilateral > address rewriting has the same issues. In fact, as I had explained in > earlier emails, issues (a) and (b) are not present in stateless > unilateral address rewriting because this uses only globally unique > addresses and works without state. This leaves issue (c). Well, (c++) since you only described part of the application layer problem. > > The excerpt from my email to which you are responding (which is > re-cited at the very top of this email) argues that also issue (c) is > non-critical due to the existence of NAT traversal functionality in > applications. You argue that this is not necessarily so, and I agree > with you that this would be a drawback of unilateral address rewriting > as a backwards compatibility method. I think it is much more serious than a drawback. But, on the other hand, we are at the beginning of IPv6 deployment. I'm not convinced that we can't evade this problem somehow. > > But you have yet to convince me that applications won't use NAT > traversal for IPv6. It won't be hard to change an existing IPv4 NAT > traversal code base to IPv6, so doing it in order to improve the > functioning of an application in NAT'ed environments would be > straightforward in my opinion. But this is exactly what we must fight to avoid, so that all the distortions of the session architecture created by NAT do not get a chance to distort the v6 world too. > - Christian > > > PS: FWIW, I understand issue (c) as being of less grave nature than > issues (a) and (b). Issue (c) is an implementation issue, NOT an > architectural issue like issues (a) and (b). Absolutely not. It's an architectural issue in the session layer, when session IDs have no universality. Brian > > [1] > http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf > > > -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
