[RRG] Update on Six/One Router + A Call for Your Comments

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

Dear Folks,

this is an update on our recent work on Six/One Router.  The primary
goal of this work has been to make Six/One routers stateless, so as to
enable route changes between Six/One routers without requiring state
synchronization between the Six/One routers.

At the same time, this is a solicitation for your valued feedback.  We
found statelessness straightforward to realize for packet exchanges
where both hosts use each other's edge address (AKA "identifier"). But
packet exchanges where a host addresses its peer by transit address
(AKA "locator") turned out to be less straightforward. (Recall that,
for backwards-compatibility, Six/One Router enables hosts in upgraded
(Six/One-Router-capable) edge networks to be reachable at a transit
address.  This makes the hosts reachable from the legacy Internet.)

Below is a description of the challenge, followed by possible
solutions.  Your feedback will allow for a better assessment of which
of the solutions are most appropriate.  A supplementary slide deck,
illustrating challenge and solutions, is available at:

http://users.piuha.net/chvogt/misc/stateless-sixone-router.pdf

CHALLENGE

One obvious method to make Six/One Router stateless is via 1-to-1
mappings between edge addresses and transit addresses.  This prevents
ambiguities in translating between address types, and thereby removes
the need for Six/One routers to hold translation state.

However, pure 1-to-1 mappings means that every transit address maps
onto exactly one edge address, and every edge address maps onto
exactly one transit address.  Pure 1-to-1 mappings hence necessitate a
separate edge address prefix per provider.

If edge networks were to have a single edge address prefix, then each
edge address would map onto multiple transit addresses, namely, one
per provider.  This creates an ambiguity for Six/One routers to
translate an edge address back onto a transit address for packets
leaving an edge network:  Onto which transit address should the source
edge address in those packets be mapped?

The ambiguity is a problem where a host contacts another one by
transit address.  Six/One routers must then ensure that this host sees
the same transit address also in packets it receives.  The ambiguity
is *not* a problem for packet exchanges where both hosts use each
other's edge addresses.  It is then transparent to the hosts onto
which transit addresses these edge addresses are temporarily mapped
while the packets are in flight.

Slides 1 and 2 in the slide deck referenced above illustrate the
challenge:  Host A, located in an upgraded edge network, can be
reached at multiple addresses -- at an edge address (ABC::1) if the
contacting edge network is upgraded as well, or at one of possibly
multiple transit addresses (1000::1 or 2000::1).  Independent of which
address is used by a contacting host B, a Six/One router on the border
of host A's edge network translates the address used by host B into
host A's edge address ABC::1.  The challenge is then for Six/One
routers to reverse-translate edge address ABC::1 in egress packets
back onto the address that was used by host B.  Two questions must be
answered:

(A)  Did host B use an edge address or a transit address from host A?

(B)  If it used a transit address, which one?  (1000::1 or 2000::1)

Enabling a Six/One router to answer question (A) is simple, and slides
3-5 in the accompanying slide deck show how:  Enforce that host A
always uses the same address type (edge address or transit address)
for host B as host B also uses for host A.  The Six/One router can
then conclude, based on the type of destination address in an egress
packet, which type of source address host B is expecting in the
packet.  Introducing a special prefix for edge addresses (e.g., a
well-known 8-bit prefix) would help the Six/One router in identifying
the type of the destination address.

The challenge is with question (B) when hosts address each other by
transit address (see slide 6).  Egress packets don't include
information based on which a Six/One router could tell which source
address type host B is expecting in a packet.  So how can it be
ensured that packets received by host B have a source address that
equals the destination address in packets sent by host B?

POSSIBLE SOLUTIONS

Below are possible solutions that enable Six/One routers to answer
question (B) when hosts address each other by transit address.  Slide
7 summarizes the solutions; slides 8-14 illustrate and analyze them.

(Note, again, that the challenge does not apply when both hosts
address each other by edge address.  The ambiguity in transit
addresses is then transparent to the hosts.)

(1)  Separate edge address prefix per provider (slides 8-10)

     This is pure 1-to-1 mapping between edge and transit addresses.
     I.e., each edge address has a canonical mapping onto the transit
     address from exactly one provider.  The destination edge address
     for ingress packets can then be chosen such that it maps to the
     ingress provider.  This enables a Six/One router to identify the
     right source transit address for egress packets.  This also
     enables the edge-network-internal routing system to route egress
     packets back to the ingress provider.

(2)  Translation of remote addresses (slides 11-12)

     Six/One routers translate host B's address in ingress
     packets onto address from the ingress provider.  Egress packets
     are then guaranteed to be forwarded via this same provider. State
     must be maintained at the provider so that the translation of the
     remote address can be reversed.

(3)  Translation of remote port numbers (slide 13)

     Six/One routers translate host B's port number in ingress packets
     such that the (hash) function used for egress traffic load-
     balancing in the edge network will forward egress packets back to
     the ingress provider.  State must be maintained at the provider
     so that the translation of the remote port can be reversed.

(4)  Single transit address per host in DNS (slide 14)

     Hosts have transit addresses from only a single provider in DNS
     (apart from their edge address, which is in DNS as well).  The
     ingress provider is then uniquely determined when hosts use each
     other's transit addresses.  This enables a Six/One router to
     identify the right source transit address for egress packets.
     This also enables the edge-network-internal routing system to
     route egress packets back to the ingress provider.

Many thanks in advance for sharing your thoughts.  Many thanks also to
Jari Arkko, Mikko Särelä, Kristian Slavov, Petri Jokela, Jan Melen,
and Patrik Salmela for a fruitful a-priori discussion of this topic!

- 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