Thoughts on address selection

[Fred Baker <[e-mail]>]

I'm following up on the discussion just had in 6man regarding address  
selection. I have this awful feeling that we are fighting off the  
alligators and forgetting to drain the swamp.

Correct me if I am wrong. The objectives being the source address  
selection algorithm are to:
   1) keep a datagram within as local a routing domain as possible
   2) to facilitate the lowest possible RTT during an exchange
   3) to work around issues caused by ingress filtering (BCP 38/84)

In short, we recommend that the source, which knows its own addresses,  
compare them to the known addresses of a potential destination, and  
choose the address pair that have the largest number of contiguous  
prefix bits in common. This achieves (1), and in so doing potentially  
achieves (2), although there are ample cases in which that is not so.  
Overcoming those failure cases and (3) are the real issue the table in  
RFC 3484 addresses.

Am I correct?

It seems to me that at least in part, this is a matter of making very  
broad assumptions about routing that may not be valid. It seems to me  
that there are two things we can do reliably. I have mentioned these  
to you before, in the v6ops context; let me bring them up again. They  
come down to - if you want the host to make statements about the  
network, I think it needs to know more than it currently knows about  
the network, either by measurement or by explicit communication.

I think the simplest solution to (2) is, frankly, to open connections  
at some rate (if I have N addresses and my peer has M, send a SYN-or- 
whatever on successive pairs in the cross-product every K milliseconds  
until I get a SYN-ACK on one of them, and then close all other  
sessions). The order of selection is determined according to the  
prefix length algorithm - the fastest responder is likely to be the  
most local domain, which is likely to be the one with a common prefix.  
In local scenarios, "open successive sessions" boils down to opening  
one session; in more remote scenarios, it will tend to select an  
address pair that (a) works and (b) has low RTT relative to the  
routing implied by other address pairs.

The simplest solution to (3), if my machine is in an administrative  
domain facing an ISP, is to have my DMZ router perform the BCP 38  
filter before the datagram reaches the ISP, and in the failure case  
reply with some form of ICMP message that says "routing took your  
datagram to an egress into the ISP with prefix <mumble>; select an  
address in prefix <mumble>". That will give the host the opportunity  
to select the correct address to traddle ingress filtering reliably.

Is there another requirement I'm missing? I don't think a table in the  
host that attempts to outthink the network is reliable or wise.

http://tools.ietf.org/html/draft-arifumi-6man-addr-select-conflict
   "Considerations of address selection policy conflicts", Arifumi
   Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, 24-Oct-09,
   <draft-arifumi-6man-addr-select-conflict-01.txt>

http://tools.ietf.org/html/draft-ietf-6man-addr-select-considerations
   "Considerations for IPv6 Address Selection Policy Changes", Tim  
Chown,
   19-Oct-09, <draft-ietf-6man-addr-select-considerations-00.txt>

http://tools.ietf.org/html/draft-ietf-6man-addr-select-sol
   "Solution approaches for address-selection problems", Arifumi  
Matsumoto,
   Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 1-Jul-09,
   <draft-ietf-6man-addr-select-sol-02.txt>