[RRG] Six/One Router Design Clarifications

[Christian Vogt <christian.vogt@nomadiclab.com>]

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