[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Six/One Router Design Clarifications


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.

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).

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.

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.

- 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).

[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