Re: Thoughts on address selection

[Arifumi Matsumoto <[e-mail]>]

Fred,

On 2009/11/10, at 10:42, Fred Baker wrote:

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

3) is not the only case that the policy table is designed for.
And, that's the thing the DT are working on.

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

What we are working on is not to make the host's decision better,
but provide a method for a network administrator to propagate
his policy to the client.


>
> 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>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------