Re: RFC 3484 Section 6 Rule 9

Hi all,

2008/6/2 marcelo bagnulo braun <marcelo@it.uc3m.es>:
...
> 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf