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