Hi all, 2008/6/2 marcelo bagnulo braun <marcelo@xxxxxxxxxx>: ... > so, are you suggesting to keep rule 8 of source address selection > (longest prefix match) and remove rule 9 of destiantion address > selection (longest prefix match)? > > btw, an analysis of some multihomed scenarios and the impact of longest > prefix match can be found at > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-06.txt. > > From the draft, it is possible to see that it helps, but not that much > and it is probably worth having better support. But i am not sure we > should simply remvoe it with an errata. IMHO, we should actually solve > this problem and provide a solution for multiprefixed sites I'm one of the authors of the above mentioned draft. This draft shows the problematic cases with the default address selection rules defined in RFC 3484. Some of them are resulted from the longest matching rule. So, I don't feel comfortable to see the above sentence telling that this draft supports the longest matching rule. IMHO, the longest matching rule should be deleted from IPv4 and IPv6 in order to preserve the DNS Round-Robin mechanism. Or, at least, this rule should be configurable and should be off by default. Now that the DNS RR is widely used and IPv6 hierarchical address allocation is spoiled, we don't have a reasonable excuse for keeping the rule 9. DNS RR cannot be implemented without the universal address selection behavior. However, local optimization of traffic engineering owing to dst and src address selection can be implemented locally, for example, by manipulating the address selection policy table. The automization of this manipulation process is the motivation for our proposal: http://www.watersprings.org/pub/id/draft-fujisaki-dhc-addr-select-opt-05.txt which is currently expired, though. I have another expired draft: http://www.watersprings.org/pub/id/draft-arifumi-ipv6-rfc3484-revise-00.txt I'll include this issue of rule 9 in this draft and post it to 6man sooner. Kindest regards, Arifumi Matsumoto _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf