RE: [Technical Errata Reported] RFC6724 (6971)

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 11 May 2022 06:55 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1CBC15EB2F for <ipv6@ietfa.amsl.com>; Tue, 10 May 2022 23:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS_KL_yBl15r for <ipv6@ietfa.amsl.com>; Tue, 10 May 2022 23:55:14 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63CAC159525 for <ipv6@ietf.org>; Tue, 10 May 2022 23:55:13 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kylv41lKjz687G4; Wed, 11 May 2022 14:51:44 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 11 May 2022 08:55:09 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 11 May 2022 09:55:09 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Wed, 11 May 2022 09:55:09 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "dthaler@microsoft.com" <dthaler@microsoft.com>, "richdr@microsoft.com" <richdr@microsoft.com>, "arifumi@nttv6.net" <arifumi@nttv6.net>, "tjc@ecs.soton.ac.uk" <tjc@ecs.soton.ac.uk>, "ek.ietf@gmail.com" <ek.ietf@gmail.com>, "evyncke@cisco.com" <evyncke@cisco.com>, "bob.hinden@gmail.com" <bob.hinden@gmail.com>, "otroan@employees.org" <otroan@employees.org>, "furry13@gmail.com" <furry13@gmail.com>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: [Technical Errata Reported] RFC6724 (6971)
Thread-Topic: [Technical Errata Reported] RFC6724 (6971)
Thread-Index: AQHYZLpPEAsjauXmb0q7Hkk/2YG6Fq0ZO0UQ
Date: Wed, 11 May 2022 06:55:08 +0000
Message-ID: <d65f2f8b52f14b029c4c8a44584670b9@huawei.com>
References: <20220510220633.4F768133111@rfcpa.amsl.com>
In-Reply-To: <20220510220633.4F768133111@rfcpa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.199.163]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XmEOTuQz75Ss0Xhi0wQ6XG6bl4g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2022 06:55:18 -0000

If all bits of IPv4 address would be compared (rule 9 section 6)
Then DNS load balancing would not work for IPv4 - one IPv4 address would be always preferred, no round-robin.
I do not see how to tell the host about the IPv4 mask on the remote end, it is not delivered by DNS.

The error for this error was already so well known that come to the Wiki:
https://en.wikipedia.org/wiki/Round-robin_DNS
"Some resolvers attempt to re-order the list to give priority to numerically "closer" networks. This behaviour was standardized during the definition of IPv6, and has been blamed for defeating round-robin load-balancing."
Ed/
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of RFC Errata System
Sent: Wednesday, May 11, 2022 1:07 AM
To: dthaler@microsoft.com; richdr@microsoft.com; arifumi@nttv6.net; tjc@ecs.soton.ac.uk; ek.ietf@gmail.com; evyncke@cisco.com; bob.hinden@gmail.com; otroan@employees.org; furry13@gmail.com
Cc: ipv6@ietf.org; rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC6724 (6971)

The following errata report has been submitted for RFC6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6971

--------------------------------------
Type: Technical
Reported by: Brian Carpenter <brian.e.carpenter@gmail.com>

Section: 2.2

Original Text
-------------
We define the common prefix length CommonPrefixLen(S, D) of a source address S and a destination address D as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common, up to the length of S's prefix (i.e., the portion of the address not including the interface ID).  For example, CommonPrefixLen(fe80::1, fe80::2) is 64.

Corrected Text
--------------
We define the common prefix length CommonPrefixLen(S, D) of a source address S and a destination address D as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common, up to the length of S's prefix (i.e., for most IPv6 addresses, the portion of the address not including the interface ID).  For example, CommonPrefixLen(fe80::1, fe80::2) is 64. For two IPv4-mapped addresses in ::ffff:0:0/96, CommonPrefixLen() may be up to 128.

Notes
-----
1) Not all IPv6 address formats have a well-defined interface index.
2) In particular, the original text is inapplicable to IPv4-mapped addresses.
3) N.B.: In practice it seems that some implementations simply do a longest match up to /128 and that works fine.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6724 (draft-ietf-6man-rfc3484bis-06)
--------------------------------------
Title               : Default Address Selection for Internet Protocol Version 6 (IPv6)
Publication Date    : September 2012
Author(s)           : D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------