Re: [RRG] Six/One Router Design Clarifications

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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 rrg-request@psg.com 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