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