Re: Thoughts on address selection

[Brian E Carpenter <[e-mail]>]

Fred,

Another approach to problem 3 is to extract REAP from SHIM6
and figure out how to use it to enhance address selection
in practice.

   Brian

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