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