IETF Logo Mail Archive

Re: [Technical Errata Reported] RFC6724 (6971)

Philip Homburg <pch-ipv6-ietf-8@u-1.phicoh.com> Wed, 11 May 2022 14:26 UTC

Return-Path: <pch-b28DE43C2@u-1.phicoh.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 7A007C19E84D for <ipv6@ietfa.amsl.com>; Wed, 11 May 2022 07:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 7QtSid2Da2Jk for <ipv6@ietfa.amsl.com>; Wed, 11 May 2022 07:26:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DD2C19E848 for <ipv6@ietf.org>; Wed, 11 May 2022 07:26:41 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1nonI1-0000N1C; Wed, 11 May 2022 16:26:09 +0200
Message-Id: <m1nonI1-0000N1C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>, 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)
From: Philip Homburg <pch-ipv6-ietf-8@u-1.phicoh.com>
Sender: pch-b28DE43C2@u-1.phicoh.com
References: <20220510220633.4F768133111@rfcpa.amsl.com> <d65f2f8b52f14b029c4c8a44584670b9@huawei.com> <m1nolHE-0000LLC@stereo.hq.phicoh.net> <232cf12db54348798afb7570e6df30e4@huawei.com>
In-reply-to: Your message of "Wed, 11 May 2022 12:58:45 +0000 ." <232cf12db54348798afb7570e6df30e4@huawei.com>
Date: Wed, 11 May 2022 16:26:03 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Q2t_zib4Ci9MYhsvek4ZewAbLBc>
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 14:26:44 -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? 

Just give an example where the proposed change gives the wrong result.
That is more productive than abstract assumptions about the length of a 
remote prefix.

v2.23.0 | Report a Bug | By Email