Subject: [RRG] Six/One Router Design Clarifications

From: Christian Vogt <[email-masked]>
Date: Sat, 12 Jul 2008 16:42:36 +0300

On May 22, 2008, Robin Whittle wrote:

> Christian, you would have to convince me of several things before I
> could contemplate Six/One Router being a potential solution to the
> routing scaling problem [...]

Robin,

below are six questions about Six/One Router that you sent to this
mailing list on May 22 [1], plus my respective responses.  I apologize
for being slow in responding.  Your questions are very good and, as a
matter of fact, were the trigger for me starting to work on the paper
[2], which I announced yesterday.  I waited with this reply until the
paper is ready so that it could serve as a basis for this discussion.

[1]  http://www.ops.ietf.org/lists/rrg/2008/msg01283.html
[2]  http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

> 1 - It needs to work fine for IPv4 as well as IPv6 - which means it
>     can't require multiple subnets of routable space to correspond to
>     the one subnet of end-user space.

Six/One Router does require multiple sets of transit addresses for
multi-homed edge networks, one from each provider.  This is the cost
for the maximum packet overhead efficiency, which address rewriting
provides as opposed to tunneling.  The shortage of IPv4 addresses
therefore practically requires transit addresses to be IPv6.  Edge
addresses, however, can still be either IPv6 or IPv4.

IPv4-only edge networks that deploy Six/One Router consequently use
IPv4 edge addresses in combination with IPv6 transit addresses.  They
deploy Six/One routers that integrate the Stateless IP/ICMP
Translation algorithm (SIIT) [RFC 2765] for packet conversion between
IPv4 and IPv6.

Based on this setup, an upgraded, IPv4-only edge network can
communicate with both IPv4-only and IPv6-only remote edge networks:
Packets exchanged with remote IPv4-only edge networks go through two
SIITs -- one in the Six/One router of the originating edge network,
and one in the Six/One router of the receiving edge network.  Packets
exchanged with remote IPv6-only edge networks go through only one
SIIT, namely, in the Six/One router of the IPv4-only edge network.

SIIT and Six/One routers fit together well because (i) both rewrite
the IP header of packets, and (ii) both are stateless, hence do not
constitute a single point of failure.

> 2 - It needs to work without option headers.

It does.  Six/One routers only rewrite addresses.  They don't add or
read IP header extensions.

> 3 - It needs to enable packets from non-upgraded networks to reach
>     the destination host, as is achieved in Ivip with OITRDs (Open
>     ITRs in the DFZ) and in LISP with PTRs (Proxy Tunnel Routers).

It does.  The backwards compatibility method described in [2] is
designed for maximum independence of upgraded edge networks from the
rest of the Internet:  It allows edge networks to deploy Six/One
Router in a backwards-compatible manner without relying on special
infrastructure outside their own boundaries.  This is achieved based
on unilateral address rewriting on the border of an upgraded edge
network.  For packets exchanged between an upgraded and a legacy edge
network, the address of the host in the upgraded edge network is then
an edge address while the packets are within the boundaries of the
upgraded edge network, and a transit address while the packets are
outside those boundaries.  This is described in section 2.4
("Backwards Compatibility") of [2].

Of course, other backwards compatibility methods are possible.  E.g.,
the method in [2] could be replaced with OITRDs or proxies.

> 4 - It must not involve any routers looking into, or changing, the
>     contents of traffic packets.

No worries, it doesn't.  Six/One routers limit address rewriting to IP
headers of packets; they do not attempt to find and rewrite addresses
in packet payloads.

Does this potentially cause address inconsistencies between the IP
header and the payload in a transformed packet?  For communications
between two upgraded edge networks, it is clear that this is not the
case:  Address rewriting then happens bilaterally, and the inverse
rewriting by a remote Six/One router annuls any address
inconsistencies.

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.

> 5 - It should not involve any changes to the DNS, such as to make
>     the results for queries depend on the source of the query.

No worries, it doesn't.  Given a DNS query for a host in an upgraded
edge network, a DNS server always returns a set of standard A/AAAA
resource records that contain:

(a) the edge addresses of said host,

(b) the transit addresses of said host, to facilitate the backwards
     compatibility method described in [2].

The standard destination address selection algorithm [RFC 3484] in a
correspondent host then picks the right type of address, as explained
in section 2.4.1 of [2].

Should you replace the backwards compatibility method in [2]
with OITRDs or proxies, then DNS servers would return only edge
addresses, but no transit addresses.

> 6 - Also, I think that the idea of the ETR-like router having to
>     look up a remote database to figure out how to handle a received
>     packet is a major problem, leading to packet delays and
>     effectively to losses, unless the information can be found
>     locally.

Here, we disagree.  It is true that, for performance reasons, a
mapping lookup at the egress indirection router requires the mapping
information to be stored locally at the egress indirection router. But
this is not a new requirement.  Local storage of mapping information
is anyway a prerequisite if an address indirection architecture is to
deliver the same routing quality as today's Internet.  Specifically:

- The only loss- and delay-free method for edge-to-transit indirection
   is by keeping all mapping information locally at an ingress
   indirection router.  All other proposed methods that I am aware of
   may cause either loss or delay of the first packet.

- If we consequently assume that mapping information is stored locally
   to /ingress/ indirection routers, then it is straightforward to
   assume that the mapping information is also local to /egress/
   indirection routers.  After all, ingress and egress indirection
   routers are, at a minimum, located within the same network, and
   will for practical reasons in most cases be co-located in the same
   box.  Hence, locating the mapping information such that it is
   close to both types of indirection routers should be achievable.

- Finally, if mapping information is local to egress indirection
   routers, then egress indirection routers can do a mapping lookup
   per received packet without causing delay or loss.

Furthermore, having the mapping information local to egress
indirection routers facilitates a solution for mapping validation that
comes almost for free:  An egress indirection router can use the
available mapping information to check whether the mapping in a
received packet is correct.  The reason this comes almost for free is
that the mapping information must be trustworthy anyway.  It must be
protected against spoofing in order to protect ingress indirection
routers from being tricked into sending packets to the wrong
destination.  Re-using this protection for mapping validation at
egress indirection routers -- instead of using a separate mechanism
such as in-packet authentication data -- reduces complexity.

Using local mapping information to validate mappings is similar to the
source address validation of Unicast Reverse Path Forwarding, which is
widely used in today's Internet.  In both cases, routers make use of
forwarding information to verify a packet's origin.

Using local mapping information to validate mappings fits well
together with Six/One Router, where egress indirection routers have to
do a mapping lookup in order to perform the transit-to-edge
indirection.

I hope this has helped clarifying the design of Six/One Router.  In
any case, let me know if you have further questions.

Best,
- Christian

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jul 2008 09:06:59 +1200

Chrsitian

On 2008-07-13 01:42, Christian Vogt wrote:
...
> 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

---

From: "Tony Li" <[email-masked]>
Date: Tue, 15 Jul 2008 14:19:41 -0700

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

As has been said before, all of the translation options are basically
architected NAT.  

To adapt to this, applications can either perform NAT kludges or change to
truly operate on a separate and clear identifier.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jul 2008 09:27:38 +1200

> truly operate on a separate and clear identifier.

Well yes, but many of the solutions deliver the original packet,
and it seems that in the particular case Christian was describing,
Six/One Router would deliver a translated packet. That doesn't
happen with a map/encap solution.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 15 Jul 2008 14:51:36 -0700

|> As has been said before, all of the translation options are basically
|> architected NAT.  
|> 
|> To adapt to this, applications can either perform NAT 
|kludges or change to
|> truly operate on a separate and clear identifier.
|
|Well yes, but many of the solutions deliver the original packet,
|and it seems that in the particular case Christian was describing,
|Six/One Router would deliver a translated packet. That doesn't
|happen with a map/encap solution.

This can be viewed as a drawback of the map&encap solutions: no forward
progress in actually changing the root of the architecture.

;-)

Tony

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 15 Jul 2008 15:09:27 -0700

> |Well yes, but many of the solutions deliver the original 
> packet, and it 
> |seems that in the particular case Christian was describing, Six/One 
> |Router would deliver a translated packet. That doesn't happen with a 
> |map/encap solution.
> 
> 
> This can be viewed as a drawback of the map&encap solutions: 
> no forward progress in actually changing the root of the architecture.
> 
> ;-)
> 

So the best solution would enable both using NAT techniques and/or
delivering the original packet? 

Just checking.... ;-) back at you.

-Darrel

---

From: Christian Vogt <[email-masked]>
Date: Wed, 16 Jul 2008 21:19:39 +0300

Brian E. Carpenter wrote:

> 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

---

From: Christian Vogt <[email-masked]>
Date: Wed, 16 Jul 2008 21:24:45 +0300

Brian -

> Well yes, but many of the solutions deliver the original packet, and
> it seems that in the particular case Christian was describing, Six/One
> Router would deliver a translated packet.

Right.  The particular case you are referring to is the case where
upgraded and legacy edge networks communicate.  The backwards
compatibility method that the Six/One Router paper proposes for this
case is unilateral address rewriting, and this has the described
affect of delivering a translated packet.

Of course, Six/One Router delivers the original packet unchanged in
case two upgraded edge networks communicate with each other.

> That doesn't happen with a map/encap solution.

It is actually a question of which backwards compatibility method you
use rather than a question of whether or not you use map-and-encap
(tunneling) for address indirection.  And this brings me to a more
general point:

We should differentiate between the address indirection method and the
backwards compatibility method, because the two are orthogonal to each
other.  And we should evaluate the best solution for either of these
independently of each other.

We have three main methods for backwards compatibility on the RRG
table, and all were proposed for a particular address indirection
method:  Proxying was proposed for LISP and Ivip, unilateral address
rewriting was proposed for Six/One Router, and per-provider deployment
was proposed for APT.  However, we should understand that neither of
these backwards compatibility methods is bound to a particular address
indirection method.  Any combination is feasible.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Jul 2008 15:27:04 +1200

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

> addresses and works without state.  This leaves issue (c).

Well, (c++) since you only described part of the application layer
problem.

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

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

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 16 Jul 2008 23:04:22 -0700

On Jul 15, 2008, at 2:06 PM, Brian E Carpenter wrote:

> for

it seems to me that a few issues need to be further sorted out here.

1/ what is the definition of "NAT" here in the context of IPv6?
I suppose it is a different one from v4 NAT that uses non-unique  
addresses?

2/ I wonder which position is being argued here regarding applications  
that embed IP addresses inside.  Independent from six/one router or  
not, it seems to me that, whether one likes it or not, IPv6-IPv4  
packet level translation is likely to be needed for some long time to  
come.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 16 Jul 2008 23:15:55 -0700

> when session IDs have no universality.

let me understand this better: my understanding is that six/one router  
(it ought to be renamed to just IPv6 Address translator, or 6AT)  
performs a one to one matching.  So although the exact value of the  
"ID" may not be exactly the same before or after an 6AT, nonetheless  
the session is uniquely identified -- would that be considered as  
having universality?

Lixia
PS: in the above I used Brian's terminology, but my personal view is  
that, in the long run, session layer should move away from using IP  
address entirely.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jul 2008 13:42:39 +1200

On 2008-07-17 18:04, Lixia Zhang wrote:
...
> 1/ what is the definition of "NAT" here in the context of IPv6? I suppose it is a different one from v4 NAT that uses
> non-unique addresses?

Well, there's no definition of IPv6 to IPv6 NAT (fortunately). But
as far as I can see, uniqueness is not really the problem - it's
simply the assumptions that are made in so many places that both ends
(or even all N ends) of a communication see the same addresses for
the same interfaces.

> 
> 2/ I wonder which position is being argued here regarding applications that embed IP addresses inside.  Independent from
> six/one router or not, it seems to me that, whether one likes it or not, IPv6-IPv4 packet level translation is likely to be
> needed for some long time to come.

Yes, so in the V6OPS and BEHAVE discussions of how to replace NAT-PT,
I think we've more or less agreed on a version of "first, do no harm"
which is "nothing in v6/v4 translation should do *more* harm than
a traditional v4/v4 NAT." That doesn't change the strong desire to avoid
v6/v6 NAT.

On 2008-07-17 18:15, Lixia Zhang wrote:

>>> 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.
> 
> let me understand this better: my understanding is that six/one router (it ought to be renamed to just IPv6 Address
> translator, or 6AT) performs a one to one matching.  So although the exact value of the "ID" may not be exactly the same
> before or after an 6AT, nonetheless the session is uniquely identified -- would that be considered as having universality?

In my opinion, not if the two ends have a different opinion
about the addresses being used, because we use addresses as
identifiers.

> 
> Lixia PS: in the above I used Brian's terminology, but my personal view is that, in the long run, session layer should move
> away from using IP address entirely.

I completely agree, but the problem is that this isn't how the
Internet has been constructed. I'm very pessimistic about changing
this (and it surely isn't the routing community that can change all
the applications).

     Brian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 19:42:49 +0300

On Jul 23, 2008, Jari Arkko wrote:

> I think Christian's Six/One Router translates only in the case that
> you talk to legacy nodes.

Yes, only in the case when you talk to a host in a legacy edge
network.

When two hosts in upgraded edge networks communicate, addresses are
rewritten bilaterally such that the second rewrite is the inverse of
the first.  The result is the same as with tunneling.  The difference
is that it works without an additional IP header.

- Christian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Jul 2008 09:53:40 -0700

> is that it works without an additional IP header.

Not true. The packet, when traveling in the core, doesn't contain the  
original addresses. With tunneling, it does.

And if you have ACLs anywhere in boxes after the translator, they need  
to change when the translate addresses change. With tunneling, when  
the inner header addresses are EIDs that are portable, you can change  
the outer header addresses and the ACLs in the core never have to  
change.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Jul 2008 10:39:54 -0700

> Hi Dino -
> With "the result is the same", I was referring to what hosts see end
> to end:  both tunneling and rewriting are transparent and stateless.
> Yes, that was unclear, sorry.

Yes, that would be necessary.  ;-)

> The fact that IP addresses are not carried in packets is something I
> see as an advantage because it does without extra packet overhead (no
> extra bandwidth, no MTU issues).  And...

The overhead is worth the ability to do debugging and management. NATs  
are hard to manage but people put up with them because in the 99%  
case, they connect one subnet to the world and are at the extreme edge  
of the network. Moving NAT functionality anywhere else is probably  
going to be a non-starter for sizable network.

Now, if you put the translated address in a mapping database, then we  
can talk.  ;-) But you still have the debugging problem in the core.  
People love their sniffer tooks like SPAN, wireshark, etc...

> ...ACLs in the Internet core can use transit addresses just as well as
> edge addresses because both uniquely identify a host.

But the point is you broke the level of indirection you introduced. If  
the transit address changes, you have to change the ACL. You make the  
ACL operate on the object that doesn't change. That is EIDs, which are  
fixed.

> A core ACL needs only a single transit address per host in the general
> case, i.e., when the ACL is in an edge network's immediate provider.

Most ACLs are not host-based either. That's another management  
nightmare. So that won't work.

Dino

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 21:22:26 +0300

Dino -

> Moving NAT functionality anywhere else is probably going to be a
> non-starter for sizable network.

Don't agree.  Translation is less complex than tunneling if it is
stateless.  And translation in Six/One Router is stateless.

> ACL operate on the object that doesn't change. That is EIDs, which are

I would argue you are breaking the level of indirection if you operate
on edge addresses while in transit space... :-)

Anyway, the transit addresses in core ACLs are fixed, just as EIDs, if
you are in the edge network's immediate provider.  If you are in an
upstream provider, you would very likely WANT to differentiate packets
based on which provider they went through.  You can easily do this
based on the prefix of a transit address.

> nightmare. So that won't work.

Hold on.  It doesn't matter whether the ACL is host-based or at
coarser granularity.  For any edge address or edge address prefix (EID
or EID prefix) that you may put in an edge ACL, there is exactly one
transit address or transit address prefix, respectively, that you
would put into an equivalent core ACL.  No need to have nightmares.

Talking about performance:  An ACL that can limit its looks to a
single place in the IP header (i.e., with translation) can likely be
more efficient that an ACL that needs to look into an inner IP header
behind a pair of LISP and UDP headers.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 20:58:07 +0300

Brian,

sorry for responding with delay.

I do agree with the disadvantages of translation that you are naming.
But let me re-emphasize that my arguing in favor of translation is on
the basis of this being a deployment tool, not a permanent mechanism.

I believe we agree that, of the three issues with NATs,...

(1) non-unique addresses make it hard to contact hosts behind a NAT

(2) state inside the network prevents re-routing of traffic

(3) non-end-to-end addresses require NAT traversal by applications

...the backwards compatibility mode of Six/One Router avoids the first
two because it is stateless and uses only globally unique addresses.

What remains is issue (3).  I believe we agree that no future routing
architecture should have this issue on a permanent basis.  Where we
disagree is whether the issue is acceptable for backwards compatibility
and deployment.

Lixia has named it:  Whether we deem issue (3) acceptable or not, the
issue will be present in IPv6 anyway because hosts will have to
traverse IPv4/IPv6 NAT-PTs.  The functionality that applications
*require* because of NAT-PTs is exactly the functionality that Six/One
Router's backwards compatibility mode will re-use.

Furthermore, the time period during which NAT-PTs will be needed will
likely outlast the time period during which Six/One Router's backwards
compatibility mode will be used, due to the yet-small deployment of
IPv6 compared to that of IPv4.  (This is a personal opinion, though.)

Brian, I fully understand and agree with the concerns you have with
translation.  Where our opinions differ is the extent to which
translation is acceptable as a deployment aid.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 20:32:44 +0300

Hi Dino -

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jul 2008 17:30:48 +0300

Brian,

> happen with a map/encap solution.

Actually, it is not that simple. If you look at the entire design and 
not just one aspect of it, you have to consider:

(a) whether you'll deliver the packet intact or not
(b) whether (and how) you can talk to peers in the existing internet
(c) and so on

The map/encap solution that would operate in the global Internet have 
been able to deal with (b) in two ways: by assuming the deployment of 
friendly and accessible-by-anyone tunnel proxies, or by using 
translation. The group has not been able to convince itself that the 
former has deployment incentives, and the latter coincides with the 
translation designs. In fact, I think Christian's Six/One Router 
translates only in the case that you talk to legacy nodes. If so, that 
approach is in fact exactly the same as the current map/encap designs.

(But I agree with you that translation is problematic. Even if you get 
rid of many of the problems associated with traditional NATs.)

Jari

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Jul 2008 13:48:08 -0700

Snipped ...

>Hold on.  It doesn't matter whether the ACL is host-based or 
>at coarser granularity.  For any edge address or edge address 
>prefix (EID or EID prefix) that you may put in an edge ACL, 
>there is exactly one transit address or transit address 
>prefix, respectively, that you would put into an equivalent 
>core ACL.  No need to have nightmares.
>
>Talking about performance:  An ACL that can limit its looks to 
>a single place in the IP header (i.e., with translation) can 
>likely be more efficient that an ACL that needs to look into 
>an inner IP header behind a pair of LISP and UDP headers.

JD:  In any map & encap scheme, won't a transit space router have to
deal with a multiplicity of packet formats (e.g., both encapsulated and
non-encapsulated packets) and won't it be a performance hit to figure
out a packet's format and then look for the correct fields within it?

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 20:32:44 +0300

Hi Dino -

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Jul 2008 20:58:07 +0300

Brian,

- Christian

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 24 Jul 2008 10:51:39 +1200

[sending again from an alternative address - gmail is
being rejected by the RRG list again, and the whitelister
refuses to whitelist gmail this time]

Hi Christian,

> Router's backwards compatibility mode will re-use.

Yes, even with the replacements for NAT-PT that are being
discussed over in V6OPS and BEHAVE, the underlying NAT issues
of ALGs, helpers, and port mapping will remain. My concern is that
once we admit those code paths to a pure IPv6 world, we will never get
rid of them and the path to NAT CPE will be open.

> IPv6 compared to that of IPv4.  (This is a personal opinion, though.)

I agree.

> translation is acceptable as a deployment aid.

Yes
    Brian

---

From: "Tony Li" <[email-masked]>
Date: Wed, 23 Jul 2008 21:46:23 -0700

Brian, 

|My concern is that
|once we admit those code paths to a pure IPv6 world, we will never get
|rid of them and the path to NAT CPE will be open.

I believe that history has shown that we do not have code admission control.

;-)

Therefore, every possible program, concept, or idea will eventually be
tried.  Good, bad or indifferent.  Since the IAB chooses not to control the
architecture of the Internet, unrestrained evolutionary growth with maximum
mutability is the only possible outcome.  Such is the result of Kobe.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Thu, 24 Jul 2008 12:14:46 +0300

> out a packet's format and then look for the correct fields within it?

Yep, exactly.

And you avoid this performance hit with translation-based schemes, where
it is always sufficient to look at the addresses in the IP header.

- Christian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 18:20:04 -0700

Not true, if you have fixed headers with well known code-points, you  
can get to the data you need to parse. It's been done that way for  
decades at very high speeds. What hasn't been done at high-speeds is a  
translator.

With enough thrust anything can fly, but it's easier to do a  
decapsulator than a translator.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Thu, 24 Jul 2008 18:40:22 -0700

|With enough thrust anything can fly, but it's easier to do a  
|decapsulator than a translator.

Why?

Intrinsically, they seem to be roughly on the same order of magnitude of
difficulty.

For a decapsulator, you crack the outer header, lookup, accept, crack the
inner header, lookup and forward.

For a translator, you crack the outer header, lookup, rewrite, and forward.

Seems not too different...

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 22:31:43 -0700

> |decapsulator than a translator.

Well for one, you have to do a 5-tuple lookup because most NATs have  
both ports as part of the lookup key. And for two, it's usually  
another data structure that has the translation table. And typically  
in hardware implementations that is not the same DRAM. So there is an  
extra cost there. Third, you have to fix the pseudo-header checksum.  
Fourth, you have to fix payload like the all important ICMP  
unreachable so traceroute works.

This is all very hard to do in an ASIC. In a programmable forwarding  
engine it is simpler if you can do packet writes. But that is rarely  
the case.

> Intrinsically, they seem to be roughly on the same order of  

Disagree. Encapsulation is prepending a header, just like you would  
when an IP router forwards a packet from one Ethernet to another  
Ethernet. Ditto for the decap side.

> inner header, lookup and forward.

Wrong.

> For a translator, you crack the outer header, lookup, rewrite, and  

No, you have to do more work. See above.

> Seems not too different...

Very different. I have implemented both and my experience says  
translation is much harder.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 23:26:43 -0700

>> inner header, lookup and forward.

This was a typo. What you wrote isn't wrong. I was referring to the  

Dino

---

From: "Tony Li" <[email-masked]>
Date: Fri, 25 Jul 2008 01:04:42 -0700

Hi Dino,

|Well for one, you have to do a 5-tuple lookup because most NATs have  
|both ports as part of the lookup key. 

Ok, but a 5-tuple lookup is not conceptually 'harder' than an address
lookup.  In fact, if you simply treat the 5-tuple as a big concatenated key,
you can easily to a tree lookup algorithm.  Or, if you like, since there's
no longest match requirement, you can do other things...

|And for two, it's usually  
|another data structure that has the translation table. And typically  
|in hardware implementations that is not the same DRAM. So there is an  
|extra cost there. 

Fair, but this hardly a big deal.  For reasonably sized sites, the
translation table can be quite small.  Look at the NAT table in a Linksys
cable router today.  

|Third, you have to fix the pseudo-header checksum.  

Trivial, since it can be precomputed (didn't we discuss exactly this in
2000? ;-).

|Fourth, you have to fix payload like the all important ICMP  
|unreachable so traceroute works.

Again, not rocket science.

|This is all very hard to do in an ASIC. In a programmable forwarding  
|engine it is simpler if you can do packet writes. But that is rarely  
|the case.

Ummm.... Please take another look around at the current generation of
forwarding engines.  Writes are now common.  

|> Intrinsically, they seem to be roughly on the same order of  
|> magnitude of
|> difficulty.
|
|Disagree. Encapsulation is prepending a header, just like you would  
|when an IP router forwards a packet from one Ethernet to another  
|Ethernet. Ditto for the decap side.

Ok, let's agree to disagree then.

|Very different. I have implemented both and my experience says  
|translation is much harder.

Please note that I'm not talking about difficulty of implementation.  In
some real sense, that's almost irrelevant.  I'm thinking of the actual
computational load to forward one packet.

Given a flexible packet processor today, could you write code to do
encapsulation, write code to do translation, optimize both, and have the
encapsulation run 10X faster?  Somehow, I'm just not seeing it.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jul 2008 15:52:09 +0300

Dino -

based on what you write below, I suggest you read the Six/One Router
design paper [1] before you speculate more on how to implement it.

> both ports as part of the lookup key.

A Six/One router does not use ports.  And lookups are based on only a
64-bit address prefix extracted from an IP header; NOT on a 5-tuple.

Furthermore, for local addresses (i.e., addresses belonging to a
Six/One router's own edge network), there is no lookup at all.  Because
the address prefix mapping is static in that case.

Again:  Six/One routers rewrite only address prefixes, no ports, no
checksums.  And lookups, where needed, are based on only a single
address prefix, but no ports.  This is the reason Six/One routers can
be stateless -- much different from NATs.

> And for two, it's usually another data structure that has the
> translation table. And typically in hardware implementations that is
> not the same DRAM. So there is an extra cost there.

This is the case for a NAT; it can be different for a Six/One router.

The reason is that NATs are stateful, whereas Six/One routers are not.
Hence NATs have different implementation requirements than Six/One
routers.

> Third, you have to fix the pseudo-header checksum.

Nope.  Six/One routers don't have to fix checksums.

This is quite clear for packet exchanges between two upgraded edge
networks, because the inverse address rewriting at the receiving
Six/One router then re-establishes the original packet.

How the original checksum can be maintained for packet exchanges with
legacy edge networks is described in section 2.4.4 of the Six/One
Router design paper.

> Fourth, you have to fix payload like the all important ICMP  

You have to do the same with encapsulation.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jul 2008 15:53:31 +0300

> translation table can be quite small.  Look at the NAT table in a  

Based on the email I sent to Dino (and this list) a minute ago, it  
should
now be clear that a Six/One Router translation table is exactly the same
as a LISP mapping table.

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Jul 2008 09:08:24 -0700

I have to agree with Dino about this, and IMHO the
performance question is a red herring. My code has
been done in the linux kernel, which I realize is far
different than optimized fast-path router hardware,
but based on what I see there parsing headers is a
miniscule component of what goes on in terms of the
bigger picture of forwarding a packet.

Fred
[email-masked] 

>-----Original Message-----
>From: Dino Farinacci [mailto:[email-masked]] 
>Sent: Thursday, July 24, 2008 6:20 PM
>To: Christian Vogt
>Cc: Drake, John E; Routing Research Group Mailing List
>Subject: Re: [RRG] Six/One Router Design Clarifications
>
>>> deal with a multiplicity of packet formats (e.g., both 
>encapsulated  
>>> and

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 12:21:35 -0700

Well, consider my comments as feedback from an implementor.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 12:30:30 -0700

> design paper [1] before you speculate more on how to implement it.

I implemented translation in LISP so I am not speculating. What you  
are doing in Six/One is no different than LISP.

> 64-bit address prefix extracted from an IP header; NOT on a 5-tuple.

Either does LISP. The issue about ports was because talking about  
stateful NATs which haven't been implemented.

I do realize that for Loc/ID translation it is simpler. We have done  
the simpler version for LISP.

Connect to http://www.lisp4.net, you'll see it in action.

> Hence NATs have different implementation requirements than Six/One

You must keep another table so you can translate a packet egressing a  
site from one address to another. If you don't do that, then the  
global address must be imbedded in the source address, which we can go  
off and talk about how you would do that.

> Nope.  Six/One routers don't have to fix checksums.

Then it means you can't have a Six/One site talk to a non-Six/One  
site. If so, you don't have an incremental solution.

> You have to do the same with encapsulation.

You do not have to change the payload for the encapsulation case.

Dino

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jul 2008 02:12:03 +0300 (EEST)

(perhaps I shouldn't have done catching up on rrg mails, but..)

On Fri, 25 Jul 2008, Dino Farinacci wrote:
[long list of encap/decap vs translation discussions omitted]
>> You have to do the same with encapsulation.

One thing I didn't see mentioned here is probably relevant. 
Encap/decap has a potential to be much more difficult if fragmentation 
would be incurred (especially outer header fragmentation); I have hard 
time seeing how you could even implement a line-speed decapsulator 
that would reassemble fragments as required by Full Standard IP RFCs.

The same problem could happen if you translated v4->v6 as well (i.e., 
payload size shrinkage).

See draft-touch-intarea-tunnels-00 and rfc4459.

As a result for encap/decap schemes I specifically want to see how 
they 100% avoid fragmentation, or describe how they deal with it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Tony Li" <[email-masked]>
Date: Tue, 29 Jul 2008 00:27:49 +0100

Hi Pekka,

|Encap/decap has a potential to be much more difficult if fragmentation 
|would be incurred (especially outer header fragmentation); I have hard 
|time seeing how you could even implement a line-speed decapsulator 
|that would reassemble fragments as required by Full Standard IP RFCs.

This would be reasonably doable.  The algorithm is quite well known
(including the well-known bugs) and having hardware execute this algorithm
is not going to be overly difficult.  Start by translating a working C
implementation into Verilog and ...

For line rate (for interesting values of line rate), you'd need to buffer
the fragments in static RAM, but this too can be done today.  

|As a result for encap/decap schemes I specifically want to see how 
|they 100% avoid fragmentation, or describe how they deal with it.

Cue Fred.  ;-)

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jul 2008 02:38:58 +0300 (EEST)

> the fragments in static RAM, but this too can be done today.

The point is, how do you buffer 120 secs (MSL) of 10 Gbit/s (or more) 
of (possibly massively) out-of-order fragments?  Or if it doesn't 
support 120 secs, how long could it support?

---

From: "Tony Li" <[email-masked]>
Date: Tue, 29 Jul 2008 05:42:54 +0100

|On Tue, 29 Jul 2008, Tony Li wrote:
|> For line rate (for interesting values of line rate), you'd 
|need to buffer
|> the fragments in static RAM, but this too can be done today.
|
|The point is, how do you buffer 120 secs (MSL) of 10 Gbit/s (or more) 
|of (possibly massively) out-of-order fragments?  Or if it doesn't 
|support 120 secs, how long could it support?

Fair.  Fractions of a second in on-chip SRAM.  Much more if you tweak the
algorithm to keep control in SRAM and the actual data in DRAM, but still
only on the order of 10GB today.  Still, that should be about 10s.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 29 Jul 2008 02:21:14 -0700

As a quick summary of what I saw so far on this thread of exchanges:  
to step up a level and focus on the "the highest level branching  
point" decision, our recent draft explains our current categorization  
of this highest level branch: separation vs elimination, i.e.  
separating edge/PI prefixes out of the transit core routing, versus  
eliminating edge/PI prefixes entirely (i.e. provider-topology  
aggregatable addresses go all the way inside host/transport)

in this categorization, six/one router's translation approach falls  
into the same separation category as map & encap.

I see great discussions regarding the pro's and con's from comparing  
encapsulation and translation; personally I view "encapsulation" as  
architecturally cleaner, but as the saying goes, every coin has 2  
sides, so we also want to see clearly the other side of the coin (the  
cost), and to see whether there are circumstances where translation  
approach would be considered.
Protocol designs are engineering, and engineering is about making the  
right trade-offs.  I feel that the current discussions on these trade- 
offs may well carry into IETF engineering phase after RRG makes our  
highest level design recommendation.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 29 Jul 2008 02:49:32 -0700

a quick reply to specifics:

On Jul 17, 2008, at 6:42 PM, Brian E Carpenter wrote:

>>>> PS:  FWIW, I understand issue (c) as being of less grave nature  
>>>> than issues (a) and (b).  Issue (c) is an implementation
>> let me understand this better: my understanding is that six/one  
>> router (it ought to be renamed to just IPv6 Address
>> translator, or 6AT) performs a one to one matching.  So although  
>> the exact value of the "ID" may not be exactly the same
>> before or after an 6AT, nonetheless the session is uniquely  
>> identified -- would that be considered as having universality?
>

this issue may become moot, in lieu of next point below:

>> Lixia PS: in the above I used Brian's terminology, but my personal  
>> view is that, in the long run, session layer should move

I think we should always separate the two issues:
1/ what's out there today
2/ where we want to go
in order to progress forward.
I agree that changes are challenging and cannot happen quickly  
(physics says that the inertia is linearly proportional to the mass;  
for us it's probably not linear).  But another fact is that IETF is  
busy developing new protocols:)
The world evolves, protocols and architectures should too accordingly.

Lixia