IETF Logo Mail Archive

RE: [Technical Errata Reported] RFC6724 (6971)

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 11 May 2022 12:58 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 EDABEC180A7C for <ipv6@ietfa.amsl.com>; Wed, 11 May 2022 05:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 sPo2X64b8R17 for <ipv6@ietfa.amsl.com>; Wed, 11 May 2022 05:58:49 -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 C991CC15E6E6 for <ipv6@ietf.org>; Wed, 11 May 2022 05:58:49 -0700 (PDT)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kyvx36y1Bz67yMW; Wed, 11 May 2022 20:53:59 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Wed, 11 May 2022 14:58:46 +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 15:58:45 +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 15:58:45 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Philip Homburg <pch-ipv6-ietf-8@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: 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>
Subject: RE: [Technical Errata Reported] RFC6724 (6971)
Thread-Topic: [Technical Errata Reported] RFC6724 (6971)
Thread-Index: AQHYZLpPEAsjauXmb0q7Hkk/2YG6Fq0ZO0UQgABdlimAAAnGkA==
Date: Wed, 11 May 2022 12:58:45 +0000
Message-ID: <232cf12db54348798afb7570e6df30e4@huawei.com>
References: <20220510220633.4F768133111@rfcpa.amsl.com> <d65f2f8b52f14b029c4c8a44584670b9@huawei.com> <m1nolHE-0000LLC@stereo.hq.phicoh.net>
In-Reply-To: <m1nolHE-0000LLC@stereo.hq.phicoh.net>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.199.245]
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/6YJP-qpRWkw3wId43sxkuz6GcfM>
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 12:58:51 -0000

CommonPrefixLen(SA, D).
We know the IPv4 prefix for SA. We do not know for D.
Should we assume that prefix at the destination is always longer than the prefix at the source?
Where to stop bit comparison for DNS load balancing to work?
It is not discussed in the proposed change. Proposed change: "may be up to 128".
No, it should not be all 128bits (all 32bits of IPv4 address).
Ed/
-----Original Message-----
From: pch-b28DE43C2@u-1.phicoh.com [mailto:pch-b28DE43C2@u-1.phicoh.com] On Behalf Of Philip Homburg
Sent: Wednesday, May 11, 2022 3:17 PM
To: ipv6@ietf.org
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>; RFC Errata System <rfc-editor@rfc-editor.org>; 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
Subject: Re: [Technical Errata Reported] RFC6724 (6971)

In your letter dated Wed, 11 May 2022 06:55:08 +0000 you wrote:
>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 
>al ways 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.

It seems to me that in this RFC, the prefix length is taken from the local source candidate address. Obviously, any IPv4 stack knows the netmasks of it's own addresses.

But maybe you have a counter example where the proposed change causes the wrong result?

v2.23.0 | Report a Bug | By Email