Re: [Technical Errata Reported] RFC8028 (6035)

Fred Baker <fredbaker.ietf@gmail.com> Wed, 01 April 2020 17:13 UTC

Return-Path: <fredbaker.ietf@gmail.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 7B8FF3A13CF for <ipv6@ietfa.amsl.com>; Wed, 1 Apr 2020 10:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2V9MRpivGUj for <ipv6@ietfa.amsl.com>; Wed, 1 Apr 2020 10:13:50 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6343A13CD for <ipv6@ietf.org>; Wed, 1 Apr 2020 10:13:50 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id z14so4916663wmf.0 for <ipv6@ietf.org>; Wed, 01 Apr 2020 10:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OP2cmy4seKjsauKRwX70fGjaz5yCAdZ7pK2waKQeLl0=; b=vKVl4QPWaRjSIzZn4nkmv6xH2JhsFIhaLO5j4ZQZDVzoMNgM9WijwN55toJgL7YUku D73fR1FVvFABPctqj8DRHeleOLLbB7x7ld81p7dy1Kh8k7FBJm2694HQ+eWnugrCUSBv 3+S/ksdxMRyqDVJ+XXtzDuprDJe2YStoh/11vLI/nQAwIXbbiw50v38zehxMrenlWtkt REHX4jH4PEUviwLI/r/7TbCTZAGtmRsmdwP1ZwX+ghmITrCUnQrfbmBj4Pgj+ccnzkHb iI/Rc2txWRBN+qzImTDIJMEyCydO9AVGlHKUJDMP+ezbEipUaaTSNb1aYw+8f4eUhrWp c1Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OP2cmy4seKjsauKRwX70fGjaz5yCAdZ7pK2waKQeLl0=; b=iQVhpRK88J2FcnhgJwrFEYjQgmLFvHAPIiT26MUYI/nYm0ag9NhOWfYNxlhwLy3gtt 798eBokLuQgAibO0CumJrKVU8fefAdC8XVHTPh5MyFvIVVYZVyCS3AIUfQfbPZmL7NyX Sj29M2N6xp8fC3MSxw8hyVXBUifmfb6SD/CNSo01LpgTEQR85DTNQUrSWDbGFbOt62+C kRkzLinfOkLH7qj+OGxVjCV+o6hHl8j4detciP1wEaQZsg1eEpSeNlkoNorvWK0WiTdm nJ2T2iE6QRwenWFjV9Gu3SJ/UcdSG/1xMVelozVouqxyNNinzSyzBBi7mUbUiO9X0vaI q+jQ==
X-Gm-Message-State: AGi0PuYZ3jCqyoP0HIS4vwHywa4jQ8BGkRm5MN8McQhO/QJ87qEQQbbP OxxsWmxZMrnQOkfQuVRryEY=
X-Google-Smtp-Source: APiQypKZpMg4q76FLW8Gm142N/cR86M1FVMyYHmWrL/8zoX7c2tw+jkexyPq+Gk2Hujwd7sDpghu+A==
X-Received: by 2002:a1c:6189:: with SMTP id v131mr5323017wmb.69.1585761228768; Wed, 01 Apr 2020 10:13:48 -0700 (PDT)
Received: from ?IPv6:2600:8802:5900:13c4::101d? ([2600:8802:5900:13c4::101d]) by smtp.gmail.com with ESMTPSA id i8sm3996961wrb.41.2020.04.01.10.13.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 10:13:47 -0700 (PDT)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <14E28D7E-CCD3-45D4-B963-FC7544770A9B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CB240158-442B-4F01-B42F-21D1798FA258"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [Technical Errata Reported] RFC8028 (6035)
Date: Wed, 01 Apr 2020 10:13:38 -0700
In-Reply-To: <20200401022511.6AADAF40738@rfc-editor.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, ek.ietf@gmail.com, evyncke@cisco.com, Bob Hinden <bob.hinden@gmail.com>, otroan@employees.org, fgont@si6networks.com, ipv6@ietf.org
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20200401022511.6AADAF40738@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GHIYJ28IGpYXbHc-pyys4cihTbs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Apr 2020 17:13:54 -0000

It would be interesting to see whether this happens in practice; at the moment it sounds somewhat theoretical. But I don't have a problem adding a sentence or two if and when RFC 8028 is updated if it's a real issue.

> On Mar 31, 2020, at 7:25 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8028,
> "First-Hop Router Selection by Hosts in a Multi-Prefix Network".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6035
> 
> --------------------------------------
> Type: Technical
> Reported by: Fernando Gont <fgont@si6networks.com>
> 
> Section: 3.1
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> In the context of this document, it is clear that the prefix information becomes more associated with the sending router, than with the link as a whole. As such, the PIO lifetimes should be interpreted to indicate the view of the router sending the Router Advertisement, as opposed to absolute information about a prefix.
> 
> For example, if two routers (say, router A and Router B), advertise the prefix 2001:db8::/64 as:
> 
> * Router A:
> A=1, L=1, PIO: 2001:db8::/64, Valid Lifetime=0, Preferred Lifetime=0
> 
> * Router B:
> A=1, L=1, PIO: 2001:db8::/64, Valid Lifetime=X, Preferred Lifetime=Z
> 
> then, addresses should be configured/maintained with a Valid Lifetime of X, and a Preferred Lifetime of Z. Furthermore, the prefix should be considered on-link with a Valid Lifetime of X. And Router A should be employed as the preferred next hop for packets sourced from the prefix 2001:db8::/64, since it advertises the prefix with a non-zero Valid Lifetime and non-zero Preferred Lifetime (as opposed to Router B).
> 
> As long as one router on the local subnet considers a prefix to be Valid (and possibly Preferred), the prefix should be considered Valid (and Preferred, if applicable). Similarly, as long as one router on the local subnet considers the prefix to be on-link and/or usable for auto-configuration, the prefix should be considered as such.
> 
> 
> Notes
> -----
> This is not a bug in RFC8028, but rather a clarification on what's likely a desired behavior. As such, and if considered appropriate, this errata is meant to be "held for document update".
> 
> i would like to thank Fred Baker and Brian Carpenter for taking the time to answer my questions on RF8028.
> 
> 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.
> 
> --------------------------------------
> RFC8028 (draft-ietf-6man-multi-homed-host-10)
> --------------------------------------
> Title               : First-Hop Router Selection by Hosts in a Multi-Prefix Network
> Publication Date    : November 2016
> Author(s)           : F. Baker, B. Carpenter
> Category            : PROPOSED STANDARD
> Source              : IPv6 Maintenance
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG