question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()

[Karl Auer <[e-mail]>]

I don't fully understand this change (from section Appendix B):

1.  Changed the definition of CommonPrefixLen() to only compare bits
       up to the source address's prefix length.  The previous
       definition used the entire source address, rather than only its
       prefix. As a result, when a source and destination addresses
       had the same prefix, common bits in the interface ID would
       previously result in overriding DNS load balancing [RFC1794] by
       forcing the destination address with the most bits in common to
       be always chosen.  The updated definition allows DNS load
       balancing to continue to be used as a tie breaker.

I can see this for destination address selection, where you are working
from a candidate set provided by a DNS server.

But I don't see it for source address selection. If you have multiple
source address candidates in the same prefix, they will "fall through"
Rule 8 and the implementation then has to make a choice anyway, and that
choice doesn't seem able to be related to DNS load balancing.

That is, the design rationale for the new CommonPrefixLen() doesn't seem
to apply to source address selection, which leads me to think that for
source address selection, CommonPrefixLen() should not stop at the
source address prefix length.

Am I missing something obvious here?

Regards, K.
 
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([e-mail])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687