Abstract
This document describes a method of extending IPv6 so that small end-user sites with multiple connections to the Internet can take full advantage of the benefits of multihoming without announcing their own prefix into the Default-Free Zone and without requiring support from any of their Internet providers.
Originating Host
Any host which supports Routeless Multihoming should start in destination mode. In destination mode, it must listen for multihoming requests on the Multihoming Request Port (MRP), UDP port 1234. Originating hosts must treat destination hosts as if they do not support Routeless Multihoming until they receive a valid response to a multihoming request sent to the destination's MRP.
An originating host which supports Routeless Multihoming should on acquiring IPv6 addresses determine whether it posesses global-scope addresses located within more than one subnet. If it exists in only one global subnet, it should assume it is not in a multihomed environment and employ Routeless Multihoming only in destination mode.
If the host is configured with global scope addresses in at least two subnets, the originating host will request configuration from the nearest Remote Route Arbiting Device by sending a configuration request packet to the best available route for the RRAD's anycast address. The originating host will remain in destination mode until it receives valid configuration from an RRAD.
If the originating host does not receive a valid response to its configuration request from the RRAD within 10 seconds, it may attempt to communicate with the RRAD over less preferred routes until all such routes have been tried. If the originating host finds a valid RRAD via a less preferred route, it may enter full routeless multihoming mode, however it should continue to attempt to contact the RRAD via the preferred route at intervals not less than 60 seconds and not more than 600.
The following example traffic will continue packet by packet through the explanation in the hopes of making it more clear.
Originating host: 2000:1::1, 2000:2::2
RRAD address: RRAD::1, 2000:3::3
Packet 1: UDP from 2000:1::1,7777 to RRAD::1,1235. Configuration request.
I am also 2000:2::2
Packet 2: UDP from RRAD::1,1235 to 2000:1::1,7777. Configuration reply: TTL 60, priority 0
(consult before), consult: 2000:3::3 port 1236
Full Routeless Multihoming Mode
When a host in Full mode wishes to contact a remote IPv6 host it must check the configuration received from the RRAD. If the configuration specifies that it should consult the RRAD before originating a packet then it should request an optimal route selection from the RRAD. Once the RRAD indicates the preferred originating address (and therefore route) and which of the potential destinations is preferred, it should originate normal IPv6 packets to the destination address from the selected source address using the routing path associated with that originating address.
If the configuration specifies that it should consult the RRAD after originating a packet then it should select the source address per normal IPv6 rules and originate packets to the destination immediately. It will then request route selection from the RRAD if the destination is found to support Routeless Multihoming.
Continuing the example: the originating host wishes to contact a destination at 2000:4::4
Packet 3: UDP from 2000:1::1,11111 to 2000:3::3,1236. Request Route Select
source 2000:1::1 priority 100 or 2000:2::2 priority 100 destination 2000:4::4 priority
100, request ID 7788.
Packet 4: UDP from 2000:3::3,1236 to 2000:1::1,11111. Route Select Response use
source 2000:2::2 destination 2000:4::4 request ID 7788 ttl 60.
Packet 5: TCP from 2000:2::2,2222 to 2000:4::4,23 SYN.
Packet 6: TCP from 2000:4::4,23 to 2000:2::2,2222 SYNACK.
Parallel to the normal packet activity to and from the destination, the source may send an Initiation message to the Mutlihoming Request Port using the same source and destination address as the normal packets. This originating message will contain a randomly selected 32-bit message id and may contain an optional RSA public key. The message may be retried up to three times if no response is received. If an unreachable message is returned, the originating host must assume that the destination host does not support Routeless Multihoming and cease sending requests. It should cache knowledge of negative support and may retain this knowledge not more than 600 seconds after the last packet is sent to the destination.
Continuing the example:
Packet 7: UDP from 2000:2::2,1234 to 2000:4::4,1234. Initiate Routeless
Multihoming: id 55 key zzzaaa
Packet 8: TCP from 2000:2::2,2222 to 2000:4::4,23 ACK.
If the destination host supports Routeless Multihoming, it will respond to the Initiation message with a Destination Address List (DAL). The DAL will contain the 32 bit message id and a list of all IP addresses the destination host considers valid for itself. For each address the DAL will also contain a priority indicating which IP addresses the originating host should prefer. If the Initiation message contained an RSA public key and the destination host supports cryptography, the entire DAL message will be encrypted with the key from the Initiation message and the Confirmation message will also include the destination hosts's public key.
After sending the DAL, the destination host will consider packets from the originating host to any of the destination hosts's IP addresses to be the same as if they had been sent to the IP address the originating host originally chose. The destination host will resend the DAL up to three times while waiting for an Acceptance message.
Continuing the example: The destination host is also assigned 2000:5::5 via a better provider.
Packet 9: UDP from 2000:4::4,1234 to 2000:2::2,1234. DAL id 55 key aaabbb
I am 2000:4::4 priority 120 and 2000:5::5 priority 100
Packet 10: TCP from 2000:4::4,23 to 2000:2::2,2222. Content1: "examplecompany.com
login: "
When the originating host receives the DAL message, it immediately responds with an Source Address List message (SAL). The SAL will contain the 32 bit message id, the list of IP addresses the originating host considers valid for itself and the priority for each. If the DAL included a public key, the entire SAL will be encrypted. After sending the SAL, the originating host will consider packets from any of the destination host's IP addresses to any of the originating hosts's IP addresses to be the same as if they had been sent to the IP address the originating host originally chose. The originating host will resend the SAL message up to three times while waiting for an Confirmed message.
Continuing the example:
Packet 11: UDP from 2000:2::2,1234 to 2000:4::4,1234. SAL id 55 I am
2000:2::2 priority 100 and 2000:1::1 priority 120
Packet 12: TCP from 2000:2::2,2222 to 2000:4::4,23 ACK1
When the destination host receives the SAL it should respond with a single Confirmation message so that the originating host knows to stop sending the SAL message. Once that is done, either or both sides may consult the routing arbiter for a better route.
Continuing the example: The originating host's routing arbiter decides that the destination's other IP address offers a better route using the source's other IP address.
Packet 11: UDP from 2000:4::4,1234 to 2000:2::2,1234. Confirmed id 55
Packet 12: UDP from 2000:1::1,11111 to 2000:3::3,1236. Request Route Select source
2000:1::1 priority 100 or 2000:2::2 priority 100 destination 2000:4::4 priority 120 or
2000:5::5 priority 100, request ID 7789.
Packet 13: UDP from 2000:3::3,1236 to 2000:1::1,11111. Route Select Response use
source 2000:1::1 destination 2000:5::5 request ID 778 ttl 60.
Packet 14: TCP from 2000:1::1,2222 to 2000:5::5,23. Content2: "bill\n"
Packet 15: TCP from 2000:4::4,23 to 2000:2::2,2222. ACK2. Content99:
"password: "
Packet 16: TCP from 2000:1::1,2222 to 2000:5::5,23. ACK99.
Both the originating and destination hosts should cache knowledge of the others' IP addresses for at least 60 seconds. Where a connection-oriented protocol like TCP is in use, they MUST cache the knowledge until the TCP socket is terminated.
If an application requests additional packets to the original IP address used by the other side, the originating host may use the cached information to make an optimal route selection. If the new packets are to one of the "also valid" addresses for the other side, it must not use the cached information. The other side may have lied and claimed ownership of an IP address not assigned to it. It must initiate an entire new Routeless Multihoming request.
Over the course of the communication, one side or the other may discover that one of their IP addresses is no longer capable of reaching the other side or that it has additional IP addresses which may be used. In this case, that side may issue a new Source Address List packet regardless of whether the side is the originating or destination host. The new SAL packet will contain the same id as the original negotiation and will be encrypted with the other side's public key. It must originate from at least one of the addresses it previously informed the other side was valid.
Packet 400: UDP from 2000:1::1,1234 to 2000:5::5,1234. SAL id 55 I am
2000:1::1 priority 100
Packet 401: UDP from 2000:4::4,1234 to 2000:1::1,1234. Confirmed id 55
The Remote Route Arbiting Device (RRAD)
The RRAD helps IPv6 hosts supporting Routeless Multihoming determine which source address and router to choose for a particular destination. It answers to the anycast address RRAD::1 and must offer a /64 route to this address to all adjacent routers. It listens on the RRAD Configuration Port (UDP port 1235) for configuration requests and on a selected RRAD Route Selection UDP Port (RSP) for route selection requests.
Contents of an RRAD configuration response packet:
An RRAD operates in one of four modes: Disabled, Local Static, Local Dynamic and Remote Proxy.
Disabled Mode
An RRAD operating in Disabled mode should advise any host requesting configuration that Routeless Multihoming is disabled and offer a timeout not longer than 3600 seconds for which the disablement is valid. Hosts receiving such a configuration should remain in destination mode.
Local Static
In local static mode, the RRAD makes a static choice about route selection based on local policy. It might, for example indicate that the route via one upstream provider is always preferred to a route to the backup provider.
The RRAD should implement a reasonable method for verifying that the upstream connections remain accessible, such as ping polling. If an upstream connection is inaccessible, the RRAD should not include it in Route Selection responses.
Local Dynamic
In local dynamic mode, the RRAD posesses full BGP tables from all upstream providers. After applying local policy, it can make an intelligent decision about which upstream route to select. Because its use of BGP informs it about accessibility along each upstream path, it should not attempt to otherwise poll for reachability.
RRAD should communicate with upstream BGP sources using Autonomous System number 1. The upstream sources must not accept any routes from the RRAD.
Remote Proxy
In remote proxy mode, the RRAD contains a local static configuration but may also consult upstream devices with additional knowledge such as a device with a full BGP table.
In remote proxy mode, the RRAD should respond to route selection requests immediately with the best available knowledge based on its static and cached information. This immediate response should have short (5-30 second) time to live. The RRAD should then contact its upstream sources for additional knowledge. Once it receives responses but not more than 10 seconds later, it should send an additional response packet to the requestor indicating the preferred path with the normal timeout.
Consult before or consult after?
If the host consults the RRAD before initiating packets to a remote IPv6 host, it can take advantage of outbound route optimization even if the remote IPv6 host does not support Routeless Multihoming. This comes at a price: the first packet must be delayed until the RRAD has selected a route.
In general, hosts should send Route Selection Requests to RRADs on the local subnet before originating packets to remote hosts as the local RRADs can be expected to respond promptly. RRADs available only via a WAN will be slower to respond and should normally only be consulted after the destination host indicates its support for Routeless Multihoming.
When one of the organizations' upstream links malfunctions, the RRAD should switch to instructing hosts to consult it first. This will allow reasonable function of the hosts on the network for the duration of the service outage.