Re: [Technical Errata Reported] RFC6724 (6971)

[Brian E Carpenter <[e-mail]>]

On 12-May-22 09:12, David Farmer wrote:
> The effects of DNS round-robin need to be viewed from an overall perspective, not necessarily from the perspective of an individual host. The goal of DNS round-robin is to ensure that when there are multiple answers, that all hosts don't use the same order for the answers. It is ok for a host to reorder the answers, in fact, it is ok for an individual host to always use the same order of answers, as long as the answers don't end up in the same order for all hosts.
> 
> Nevertheless, the CommonPrefixLen() should be no longer than the SA subnet prefix length, which is typically 64 for most IPv6 subnets, and in the case of IPv4-mapped addresses in ::ffff:0:0/96 is typically between 112 
and 125, with 120 possibly being the most common, representing IPv4 subnet masks of 255.255.0.0 (/16), 255.255.255.248 (/29) and 255.255.255.0 (/24) respectively.
> 
> Finally, it is technically possible for the CommonPrefixLen() 
to be 128, but I think this should only occur IFF the SA and the DA are in fact the same address.

Exactly. If we were re-writing RFC6724, we might spell that out, but it is implied by the mention of matching at the length of the known prefix.

    Brian

> 
> Thanks
> 
> 
> On Wed, May 11, 2022 at 2:41 PM Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
> 
>     It is not errata.
>     Appendix B bullet 1 states that it was done on purpose. And the purpose has been explained:
>     "
>         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.
>     "
>     The decision to scrape again "DNS load balancing" is RFC 6724bis.
>     Ed/
>     -----Original Message-----
>     From: [e-mail] <mailto:[e-mail]> [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Philip Homburg
>     Sent: Wednesday, May 11, 2022 9:42 PM
>     To: [e-mail] <mailto:[e-mail]>
>     Cc: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>; RFC Errata System <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     Subject: Re: [Technical Errata Reported] RFC6724 (6971)
> 
>      > In my original
>      > comment, I have given the URL to the DNS load balancing explanation
>      > https://en.wikipedia.org/wiki/Round-robin_DNS <https://en.wikipedia.org/wiki/Round-robin_DNS>
> 
>     So your argument seems to be that by accident, RFC 6724 supports round-robin DNS for IPv4. And it needs to keep supporting round-robin DNS.
> 
>     The goal of this RFC is to sort addresses, in other words the goal is to break round-robin DNS in general.
> 
>     The fix in the erratum is to support sorting of addresses for IPv4 as well.
> 
>     But your argument seems to be that the whole RFC is wrong and that there should not have been any destination selection based on longest prefixes matches.
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
<https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> 
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>