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