A few days ago, I asked about this draft as below. I haven't seen a response, but the question still seems fair.
> 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 --------------------------------------------------------------------
