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 [EMAIL PROTECTED] 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
