RE: Thoughts on address selection

Fred, 

For your icmp see 3.4 in:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-fwrh-02.txt

Tony


> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Fred Baker
> Sent: Tuesday, November 10, 2009 10:43 AM
> To: draft-arifumi-6man-addr-select-conflict@tools.ietf.org; draft-ietf-
> 6man-addr-select-considerations@tools.ietf.org; draft-ietf-6man-addr-
> select-sol@tools.ietf.org
> Cc: IETF IPv6 Mailing List
> Subject: Thoughts on address selection
> 
> 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
> --------------------------------------------------------------------