Subject: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

From: Christian Vogt <[email-masked]>
Date: Mon, 25 Feb 2008 09:54:01 +0200

Folks,

backwards compatibility has proven to be one of the bigger challenges
in the work of this RG.  It is hard in particular when identifiers are
to be provider-independent and therefore, for scalability reasons, non-
globally routable.  The use of tunneling exacerbates the problem because
the extra IP header makes packets unprocessable by recipients in legacy
edge networks.

I would like to propose Six/One Router [1], a network-based variant of
the original Six/One protocol, which avoids these problems through (1)
exclusive use of address translation (instead of tunneling), (2)
optional-to-support packet extensions (instead of mandatory-to-support
tunnel headers), and (3) the ability for hosts in upgraded edge networks
to be reached from legacy edge networks at a locator.

[1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router.pdf
     or via RRG homepage

Specifically, Six/One Router offers:

- Provider independence (independent of deployment elsewhere)

- Interworking between IPv4 and IPv6 (different IP versions on hosts,
  or path of different IP version than the common IP version of hosts)

- Backwards compatibility with legacy IPv4 and IPv6 Internet

Six/One Router interoperates with existing mapping resolution protocols,
such as NERD, APT Default Mappers, Cons, ALT, DNS Map.

A comprehensive analysis with respect to the RRG design goals is  
included
in the paper [1].

Your comments and opinions will be highly welcome.

- 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: Robin Whittle <[email-masked]>
Date: Wed, 27 Feb 2008 14:51:03 +1100

Short version:   I see many problems which would seem to
                 prevent Six/One Router from being feasible for
                 IPv4.  Some of these are also relevant for IPv6.

Hi Christian,

Here is my initial view of your Six/One Router proposal.

http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router.pdf

I wasn't able to completely follow some of what you wrote, but don't
think that affects this critique.

Slow DFZ handling of packets with option headers = header options

   Maybe you don't need option headers if you do a 1:1 mapping
   of the end-user address range in each ISP's address space,
   but that approach won't be acceptable in IPv4 due to the
   large amount of address space it chews.

   Last year, Bill Herrin proposed a system involving option
   headers, which I critiqued here:

     http://psg.com/lists/rrg/2007/msg00344.html

   I recall that the consensus view was that this would never
   be practical due to most (all? or at least some, and therefore
   too many) DFZ routers do not handle any packet with an
   option header at their normal rate.  They handle the packet
   via a slow CPU process.

   So I think that this is one reason your system can't be
   practical for IPv4.

   Maybe IPv6 option headers are not such a problem for DFZ
   routers.  Can anyone confirm this?

Packets are bigger with option headers

   Adding an option header leads to the PTMUD and Fragmentation
   woes which a map-encap scheme needs to handle.  See:

     http://tools.ietf.org/html/draft-templin-seal-03
     http://www.firstpr.com.au/ip/ivip/pmtud-frag/

   and recent discussions on this list between Fred, Iljitsch,
   me and others.

Modifying the DNS to give different results based on what
kind of network the requester is in  (2.4)

   Even if you knew the IP address of the requester, or the
   IP address of its top level NAT if it was behind one or
   more layers of NAT, you would need a really fancy
   database to decide whether the requester was in an
   upgraded network.  Your suggestion that routers could
   modify outgoing packets from upgraded networks to add
   a flag to DNS queries sounds tricky.

   Every caching nameserver with some requesters being in a
   normal network and some in an upgraded network would
   need to be modified to support two cached answers.
   (I am not sure how often this would occur, and I suppose
   you could have a BCP saying that upgraded networks must
   not use external caching nameservers which were not
   themselves upgraded.)

   Even if you could reliably decide this, and provide
   different answers (via some modified nameserver software)
   I don't see how you could ensure that these different
   answers would not have serious negative consequences for
   some or many applications.

Deep packet inspection and modification

   In section 2.2:

        If no inverse translation is known to take place
        at the remote edge network, Six/One routers
!!      translate addresses throughout an entire packet,
!!      including its payload, to avoid address
        inconsistencies.  This is necessary either when
        the remote edge network is legacy, or when the
        local and remote edge addresses are of different
        IP versions.

   I can't imagine how you could:

      1 - Define an algorithm for achieving these
          modifications for all widely used protocols,
          much less every protocol.

      2 - Devote so much CPU time in the ITR to doing
          this.

      3 - Do it without messing up the applications.

      4 - Do it at all with encrypted or cryptographically
          protected packets.

> Your comments and opinions will be highly welcome.

OK, sorry I see only problems with this.

  - Robin

---

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Mar 2008 22:56:39 +0200

Robin,

thanks for your review of Six/One Router!  Your comments are very  
useful.  Replying to them one by one...

> Slow DFZ handling of packets with option headers = header options

Would be interesting to find out how prevalent routers with slow-path  
processing of IPv4 header options are in the DFZ.  Here are two  
suggestion on how to do without them:

(1)  Use a new Six/One Router header, which looks to regular routers  
like a transport header, instead of an IP header option.  Make sure  
that the Six/One Router header is never used in packets sent to non- 
Six/One-Router-capable edge networks.  Whether or not a remote edge  
network supports Six/One Router can be found out via the mapping  
resolution system (i.e., DNS Map, NERD, CONS, etc.).

(2)  Do not use packet extensions at all, but use the source port and  
source transit address of a packet as a key to the right mapping  
information cached in a Six/One router.  A Six/One router cache can be  
initialized at the beginning of a new packet exchange by a separate  
packet that the Six/One router at the originating edge network sends  
to the Six/One router at the responding edge network.  For this to  
work, a source port has to be unique in combination with the source  
transit address, so it may have to be translated.  The port  
translation would be transparent to hosts, however, because the  
receiving Six/One router would reverse it.

I personally prefer the 1st approach because it does not rely on state  
cached by Six/One routers.  It thereby facilitates failover/handover  
between Six/One routers.

OTOH, a benefit of the 2nd approach is that packets do not increase in  
size when they enter transit space.  But this is a marginal benefit  
given that Six/One Router does not suffer path MTU problems anyway, as  
explained further down in this email.

>   routers.  Can anyone confirm this?

IPv6 Destination Options headers that are not used for source routing  
are not looked at by routers.  (Destination Options headers used for  
source routing can, for this matter, be considered a different header  
type with the same syntax as regular Destination Options headers.)

FWIW:  Both of the aforementioned techniques to avoid IPv4 header  
options could also be used for IPv6 packets, of course.

> Packets are bigger with option headers

Right.  But Six/One Router still avoids path MTU issues:

For packets sent from Six/One-Router-capable edge networks, all you  
need to do is reduce the MTU locally in those edge networks.  Consider  
this a part of Six/One Router deployment.

For packets sent from legacy edge networks, no special treatment is  
necessary because these packets are not enlarged along their path.   
This is an advantage over Ivip or LISP proxies, which do enlarge  
packets sent from legacy edge networks.

>   upgraded network.

There is no need for a database about potential requesters in DNS  
servers.  But requesters must have a means to tell a DNS server when  
they are interested in edge addresses instead of transit addresses.

Nevertheless, you are right that caching in DNS resolvers is a problem  
in the current Six/One Router specification.  I was actually going to  
update the specification with the following alternative approach:

- Use separate DNS records for edge and transit addresses.  Keep  
transit addresses in A/AAAA records, and put edge addresses into, say,  
A'/AAAA' records.

- Employ DNS proxies which, upon receiving or intercepting a DNS query  
for A/AAAA records, (a) forward a query for A'/AAAA' records, and (b)  
finally return the transit addresses from the retrieved A'/AAAA'  
records within A/AAAA records.  DNS proxy functionality would have to  
be implemented in Six/One routers, and may in addition be implemented  
in DNS servers inside Six/One-Router-capable edge networks.  Six/One  
routers use it to intercept DNS queries for A/AAAA records that are  
about to leave their edge network.  DNS servers inside Six/One-Router- 
capable edge network use it when resolving domain names on behalf of  
local hosts.

- A'/AAAA' records are syntactically identical to A/AAAA records.   
Therefore, step (b) in the previous bullet is simply a replacement of  
a record type number.

> Deep packet inspection and modification

You are certainly right that address translation has problems when  
done like NAT boxes do it today.  But I believe that its use in Six/ 
One Router is acceptable for three reasons:

- The problems you describe are limited to *unilateral* address  
translation.  Six/One Router uses unilateral address translation only  
for backwards compatibility.  The problems go away once Six/One Router  
is deployed on both sides of a packet exchange because address  
translations are then limited to IP headers and get reversed before  
packets reach the destination host.

- The problems with unilateral address translation (or unilateral use  
of Six/One Router) are already prevalent today, due to the wide  
deployment of NATs.  Therefore, unilateral use of Six/One Router would  
not make things worse in many situations.

- The introduction of IPv6 is likely to make NAT'ing more common  
because IPv4/IPv6 interworking will depend on it [1,2].  I see Six/One  
Router as a chance to avoid the problems of NAT'ing in those scenarios  
where Six/One Router is deployed bilaterally.

[1]  Iljitsch van Beijnum: Modified Network Address Translation -
      Protocol Translation. Internet draft, November 2007.
[2]  Brian Carpenter: Shimmed IPv4/IPv6 Address Network Translation
      Interface (SHANTI). Internet draft, November 2007.

- Christian

---

From: Randall Atkinson <[email-masked]>
Date: Mon, 3 Mar 2008 13:22:39 -0800

% Would be interesting to find out how prevalent routers with slow-path
% processing of IPv4 header options are in the DFZ.

Nearly all IPv4 routers of all types shunt any packet containing
any IPv4 option via CPU-based slow-path forwarding.  I do not
myself know of even 1 exception to this.  DFZ routers would
not generally be an exception to this.

In most cases, what happens is a header length check -- if the header
length is anything other than minimal legal IPv4 header size then
the packet goes to the CPU and leaves the hardware (or software)
fast path forwarding.

% IPv6 Destination Options headers that are not used
% for source routing are not looked at by routers.

s/are not looked/should not be looked/

One might want to run the experiment with some real routers
to verify the actual behaviour.

Ours ought not look at stuff inside an IPv6 Destination Option,
but I haven't verified this experimentally or by looking at
source code (I am in research, and am not working on products.)

I have no real idea either way what other implementations
might have done in this area.

Cheers,

Ran

---

From: <[email-masked]>
Date: Tue, 4 Mar 2008 10:38:56 -0000

Christian

Some questions & comments, having read this & the companion 3 page
'specification' doc.

1. in the spec, how does the Remote Edge Address get set?

2. I couldn't puzzle out whether the Six-One header Option (with the
original source/destination address before translation) is necessary, an
optimisation or necessary for the 'first pkt' but not thereafter?

3. I was also a bit unclear on step 5b of outgoing pkts, where you
translate the source address in the entire pkt including payload. Is
this necessary, an optimisation or necessary for the 'first pkt' but not
thereafter? Is this a standard NAT/ALG function?

4. in your analysis doc [ref 1 below] I wasn't completely convinced by
the scalability section (3.1). I can believe that the transit (ie
global) routing system is more stable. But haven't you shifted this
problem to the mapping system - it now has to cope with changes in
edge/transit mappings? (does this necessarily make things easier?) 

It's interesting to me that there's similarity, at a high level, between
Six-one router & the IVIP/LISP/etc family. Both require a separate
mapping function (is that right?). Also Six/one's header option is not
dissimilar to tunnelling (different ways of encoding the same info - but
with different implications for processing at each end & at the transit
routers [header option bad?], pkt size). I think Christian you're also
claiming that the tunnelling approaches require a special router (ETR)
at the destination network (which obviously doesn't exist for legacy
networks & so is problematic) whilst having a six/one router at the
destination network is not a reqt.

Thanks
Phil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian
> Vogt
> Sent: 25 February 2008 07:54
> To: Routing Research Group Mailing List
> Subject: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6
> Interworking, Backwards-Compatibility
> 
> Folks,
> 
> [1]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2008 13:39:47 +1300

I'm wondering what is the high-level conceptual gap between
this proposal and Proxy Shim6 (draft-bagnulo-pshim6-02.txt).
They seem to be aiming at a very similar result, except that
Proxy Shim6 doesn't rely on any new map beyond what is
implied by certain DNS RRs. They're both forms of what
I've thought of as "architected NAT" since the original
8+8 proposal.

    Brian

On 2008-02-25 20:54, Christian Vogt wrote:
> A comprehensive analysis with respect to the RRG design goals is included
> in the paper [1].
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 5 Mar 2008 20:28:20 +0200

Brian -

Six/One Router and Proxy Shim6 use similar techniques -- such as  
packet extension headers, unilateral NAT'ing, DNS proxying --, but the  
way these are put together is different in the following aspects:

(1)  The use of unilateral and bilateral address translation in Six/ 
One Router, instead of Proxy Shim6's combination of "implicit"  
tunneling (where the inner tunnel header is replaced by an index to  
state in the proxies) and unilateral address translation, enables  
packet exchanges where one address is translated bilaterally and the  
other unilaterally.  This is useful when a host contacts a peer by  
locator (which it may have gotten via a referral), although both hosts  
are in upgraded edge networks and would better use IDs.  The end-to- 
end semantics of the initiator's ID can then be retained through  
bilateral translation, whereas the responders ID can necessarily be  
translated only unilaterally.  Proxy Shim6 does not allow this case in  
its current version.

(2)  The pure use of address translation also enables seamless  
integration of the IPv4/IPv6 interworking techniques currently  
developed in v6ops [M-NAT, SHANTI], because those are also based on  
address translation.  This means that you can also allow IPv6 hosts to  
communicate with IPv4 hosts.  (Of course, you are still bound by the  
well-known limits of translation-based IPv4/IPv6 interworking  
techniques, but v6ops is working on improving them.)

(3)  For packet exchanges between upgraded edge networks, Six/One  
Router carries all translation state in extension headers.  This  
improves robustness in the presence of handovers or failovers between  
Six/One routers.  Proxy Shim6 depends on state kept in proxies (I  
called it "implicit" tunneling above), so for a handover or failover  
to work, a new proxy must somehow learn the state in the previous proxy.

(4)  Six/One routers are located on-path (on edge network border  
links), whereas Shim6 proxies are in general off-path.  The advantage  
of off-path proxies is that traffic from multiple providers can go via  
a single proxy.  But this requires special routes and tunnels within  
an edge network to ensure that traffic goes via a proxy and via the  
right provider.  Six/One Router does not depend on special routes or  
tunnels.

(5)  Six/One Router verifies ID-to-locator mappings via the mapping  
resolution system rather than through cryptographic properties of IP  
addresses [HBA, CGA] as in Proxy Shim6.  This makes address  
configuration less complex, provides higher flexibility (e.g., it also  
enables use of Stateless Address Autoconfiguration), and allows sites  
to keep their existing addresses when upgrading to Six/One Router.

Having said this, I believe that Proxy Shim6 could well be modified  
such that it supports the above-mentioned features of Six/One Router.   
Given that Proxy Shim6 and Six/One Router already share many  
techniques, the necessary modifications seem quite feasible.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Mar 2008 10:39:17 +0200

Philip,

thank you for reviewing the Six/One Router documents; deeply
appreciate this.  Going through your comments one-by-one...

> 1. in the spec, how does the Remote Edge Address get set?

This is the destination address of a packet when sent by a host in
an upgraded edge network.

> optimisation or necessary for the 'first pkt' but not thereafter?

It is necessary; you need it for two things:

- For multiplexing multiple edge addresses ("IDs") onto a single
   transit address ("locator").  The header option then indicates
   which edge address a packet is destined to.

   If the header option cannot be used because one edge network is
   legacy, the Six/One router at the upgraded edge network uses a
   port/address combination from the packet exchange as a pointer
   to the right edge address.  This may require port translation,
   as in today's NATs.

- To indicate whether addresses have to be translated throughout an
   entire packet or only in the IP header.  In the normal case,
   Six/One routers translate only the IP header in packets if they
   know that the other edge network supports Six/One Router as well.
   But if a host contacts a peer by transit address, even though both
   hosts are in upgraded edge networks and would more appropriately
   use edge addresses, then this transit address will not be translated
   at the initiator's side, and must hence be translated throughout the
   entire packet at the recipient's side.  This may happen when the
   initiating host is referred to the transit address by another host.
   The Six/One header option is an indication for this because its
   original destination address is in this case the same as the
   destination address in the IP header.

> thereafter? Is this a standard NAT/ALG function?

I must update this because, based on the discussion on this mailing
list, we changed the method by which a Six/One Router detects whether
a remote edge network supports Six/One Router.

In the specification paper, the assumption is still that a Six/One
router has no means of detecting remote Six/One Router support if a
packet is sent to a transit address.  The packet must therefore be
kept processable by a remote host for the case that the remote edge
network is legacy.  This means that also the payload is subject to
address translation, and that the extension header must be an option.

But due to the advantages of using extension headers instead of header
options in IPv4, as pointed out by Robin, the new approach is to have
Six/One routers always discover whether a remote edge network supports
Six/One Router.  And they use the mapping resolution system for that
purpose.  Packet payloads must then be translated if and only if the
remote edge network is legacy, and extension headers must be added in
that and only that case.

> edge/transit mappings? (does this necessarily make things easier?)

Six/One Router does not impose more frequent updates on the mapping
resolution system than other address indirection proposals such as LISP,
APT, Ivip.  In all cases, the mapping resolution system only provides a
set of feasible address mappings.  The selection of a particular
mapping, initially and possibly subsequently due to traffic engineering,
has to be done end-to-end.  Three possibilities:

The mapping for a packet's destination address is chosen by...

(a) the sending side

(b) the sending side initially, but the receiving side controls all
     subsequent re-selections

(c) the receiving side, both initially and subsequently

In cases (a) and (b) the sending side should probe the available
destination address mappings that it has gotten via mapping resolution.
It should do so initially in case (b), and also periodically thereafter
in case (b).  In cases (b) and (c), the receiving side must signal
preferred reachability information to the sending side.

Which approach to follow is something that I think should be more
carefully discussed on this mailing list.  This is a general topic that
is not specific to Six/One Router.  It may be a delicate topic because
it is about the distribution of routing power.

> destination network is not a reqt.

You are right.  If both edge networks in a packet exchange are
upgraded, then LISP, APT, Ivip, Proxy Shim6, and Six/One Router all
perform either classic tunneling or an equivalent of it.  The
differences become apparent when one edge network is legacy.  With
classic tunneling, you need a special router that takes care of the
legacy edge network, albeit that router might not directly attach to
the legacy edge network (such as in Ivip or with LISP proxies).  With
address translation, you don't need such a special router.  You fall
back from bilateral to unilateral translation instead.

Of course, nobody prevents you from installing a "proxy" Six/One router
close to a legacy edge network.  That would enable bilateral address
translation even for packet exchanges with legacy edge networks, the
benefit being the end-to-end use of the IP addresses involved.  But
the proxy Six/One router would be optional, not mandatory as in
classic tunneling approaches.

Philip, thanks a lot for your review.  I am going to update the
specification paper with the clarifications that your review has
identified as necessary.

- Christian

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 19:50:54 -0000

Christian,
Thanks for your answers, a couple of follow-ups/

> remote edge network is legacy, and extension headers must be added in

as nearly everything's legacy to start with, I'd like to understand the
performance implications better? Is this something that could be
deployed at current NATs /firewalls /DPI boxes? (I tend to think of
Six/one router as a super NAT) - any idea what the performance
implications on them would be? (eg if have to install 2* NAT/firewalls,
then the benefit to that party has to be >2*  ?)

> it is about the distribution of routing power.

yes, I agree that some discussion would be excellent - I think the
analysis can be done at a fairly general level (ie without getting into
how specific protocol proposal x works). Certainly agree the
distribution of routing /policy power (and the capability) is important
- at least to recognise that changes to it are a migration barrier. 

phil

---

From: Christian Vogt <[email-masked]>
Date: Fri, 21 Mar 2008 19:00:26 +0200

Phil -

> then the benefit to that party has to be >2*  ?)

You are right, a Six/One Router would basically take the place where  
NATs are used today, preferably on the border of an edge network such  
that all addresses within the edge network are kept provider- 
independent.

On performance:  For packets exchanged with legacy edge networks, a  
Six/One router pursues the same processing as a normal NAT, plus  
mapping resolution.  For packets exchanged with upgraded edge  
networks, a Six/One router pursues the same processing as a tunnel  
router, plus mapping resolution.

>> [...]

>> carefully discussed on this mailing list.  This is a general topic  
>> that is not specific to Six/One Router.  It may be a delicate topic  
>> because it is about the distribution of routing power.
>

Might be a migration barrier or a migration facilitator, depending on  
what is desired.  But to get a good understanding of which one it will  
be, we need to discuss the matter -- very much agree with you.

- Christian