Re: [Technical Errata Reported] RFC6724 (6971)

[David Farmer <[e-mail]>]

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.

Thanks


On Wed, May 11, 2022 at 2:41 PM Vasilenko Eduard <vasilenko.eduard=
[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]]
> On Behalf Of Philip Homburg
> Sent: Wednesday, May 11, 2022 9:42 PM
> To: [e-mail]
> Cc: Vasilenko Eduard <[e-mail]>; RFC Errata System <
> [e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [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
>
> 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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
===============================================
David Farmer               Email:[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
===============================================