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

From: Karl Auer <[email-masked]>
Date: Tue, 24 Jul 2012 09:24:12 +1000

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-masked])
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

---

From: Karl Auer <[email-masked]>
Date: Sun, 29 Jul 2012 11:14:49 +1000

A few days ago, I asked about this draft as below. I haven't seen a
response, but the question still seems fair.

> I can see this for destination address selection, where you are
> working from a candidate set provided by a DNS server.
> 
> 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.
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 31 Jul 2012 08:30:17 +0900

Karl,

>> Am I missing something obvious here?

In my understanding, there is no use to look at the interface id part
also for source address selection as well as for destination address
selection.

DNS load balance issue is explicitly specified, because it is clear
problem that we see.

Thanks.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Tue, 31 Jul 2012 10:08:15 +1000

> DNS load balance issue is explicitly specified, because it is clear

Thanks, Arifumi, but I don't understand your point. You have not said
*why* "there is no use".

I do see the rationale for stopping the comparison at the prefix length
for *destination* address selection. I do not see the rationale for
doing so for *source* address selection.

Perhaps we need to distinguish between source address selection and
source address checking. I just made up that second term :-)

Source address selection is the process of choosing which source address
will be used in an outgoing packet.

Source address checking is the process, performed during destination
address selection, of looking to see which source address *would* be
selected if a given destination address were selected.

My question is about the first of these two, not the second. I don't see
how DNS load balancing affects the first.

Regards, K.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 31 Jul 2012 00:28:09 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Karl Auer
> Sent: Saturday, July 28, 2012 6:15 PM
> To: [email-masked]
> Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and
> CommonPrefixLen()
> 
> A few days ago, I asked about this draft as below. I haven't seen a response,

Probably because we've been in route to IETF.

> but the question still seems fair.
> 

True.   It is missing the implied tie breaker sentence that exists in
Destination address selection:
    Rule 10: Otherwise, leave the order unchanged.
    If DA preceded DB in the original list, prefer DA.  Otherwise prefer
    DB.

> > Am I missing something obvious here?

The bits in the interface identifier are not indicative of goodness or
appropriateness or whatever.   They can be random, or based on something
unrelated to appropriateness for a given destination or for destinations in
general.   So there's no benefit in having CommonPrefixLen() continue.
In the destination case, rule 10 preserves the original order, resulting in
DNS load balancing applying.   That is, the pre-sort order is the implied
tie breaker.

For source sorting, the same is true.   That is, you have a list of candidate
source addresses.   Whatever that order is, is the implied tie breaker.
So if the host has some default ordering, or chooses to round robin
them (as DNS does with dest addrs), or whatever else, then the 
implied Rule 9 (don't change the order) preserves that tie breaker,
which is better than using the interface identifier bits which don't
have any technical reason to use them.

I would be fine with making an editorial-only change to the doc to:
1) explicitly add Rule 9 which is already implied.
2) Update Appendix B with a sentence or two summarizing the change
   to source sorting.

Of course an implementation that does use the interface identifier bits
as RFC 3484 did is still compliant to 3484bis, since it can override rule
8 per the existing text, and of course it could order the candidate
source list by common prefix length, either of which would result in
the old behavior.   And since RFC 3484 already contained the same MAY
about overriding the new rule 8, there's no real "compliance" change
between the two, just a marginally different recommendation, based
on the WG agreement that the interface identifier bits aren't really
relevant to sorting.

-Dave

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

---

From: Karl Auer <[email-masked]>
Date: Tue, 31 Jul 2012 11:46:05 +1000

On Tue, 2012-07-31 at 00:28 +0000, Dave Thaler wrote:
> appropriateness or whatever.

Firstly, thanks for the extensive explanation.

I realise now that I was confusing two comparisons - the comparison of
an address with a prefix in the policy table and the comparison of two
addresses with each other.

Comparing an address with a prefix in the policy table must continue for
as many bits as are specified for the prefix in the policy table.

Is that understanding correct? If so, given the redefinition of
CommonPrefixLen(), do the definitions of Label() and Precedence() need
to make this point explicit?

> 1) explicitly add Rule 9 which is already implied.

Is it? In the fourth paragraph of Section 5, the draft says

     If the eight rules fail to choose a single address,
     the tie-breaker is implementation-specific.

I suppose one could say that since the draft does not specify an initial
ordering, the ordering is implementation-specific, so therefore the
tie-breaker is implementation specific :-) but that's not really the
point. If the draft wants the ordering to be the tie-breaker I think it
has to say so explicitly, as that would then exclude other tie-breaking
mechanisms.

It seems to me that the draft should be left as it is in this respect,
and thus allow an implementation to use the original ordering if it
wants to, but not demand it or expect it.

Regards, K.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 31 Jul 2012 22:40:03 +0000

> Sent: Monday, July 30, 2012 6:46 PM
> To: [email-masked]
> Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and
> CommonPrefixLen()
> 
> I realise now that I was confusing two comparisons - the comparison of an
> address with a prefix in the policy table and the comparison of two addresses
> with each other.
> 
> Comparing an address with a prefix in the policy table must continue for as
> many bits as are specified for the prefix in the policy table.
> 
> Is that understanding correct? 

That is correct.  The CommonPrefixLen(). algorithm is only relevant in the context of rules
that explicitly say so.   Prefix policy table lookups are not in that category

> If so, given the redefinition of
> CommonPrefixLen(), do the definitions of Label() and Precedence() need to
> make this point explicit?

My opinion: no, it already seems explicit enough to me.

>      the tie-breaker is implementation-specific.

True.   I forgot that, so no editorial change is needed, it's already explicit
as you point out.

> ordering, the ordering is implementation-specific, so therefore the tie-
> breaker is implementation specific :-) but that's not really the point. If the
> draft wants the ordering to be the tie-breaker I think it has to say so
> explicitly, as that would then exclude other tie-breaking mechanisms.
>
> It seems to me that the draft should be left as it is in this respect, and thus
> allow an implementation to use the original ordering if it wants to, but not
> demand it or expect it.

Agreed.

So the only editorial change we could consider is adding a sentence to
Appendix B noting the source rule was affected by the change as well.

-Dave