[Technical Errata Reported] RFC8028 (6035)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 01 April 2020 02:25 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 EF4143A1048 for <ipv6@ietfa.amsl.com>; Tue, 31 Mar 2020 19:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kjlqDeltFJzd for <ipv6@ietfa.amsl.com>; Tue, 31 Mar 2020 19:25:15 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBC13A1045 for <ipv6@ietf.org>; Tue, 31 Mar 2020 19:25:15 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 6AADAF40738; Tue, 31 Mar 2020 19:25:11 -0700 (PDT)
To: fredbaker.ietf@gmail.com, brian.e.carpenter@gmail.com, ek.ietf@gmail.com, evyncke@cisco.com, bob.hinden@gmail.com, otroan@employees.org
Subject: [Technical Errata Reported] RFC8028 (6035)
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200401022511.6AADAF40738@rfc-editor.org>
Date: Tue, 31 Mar 2020 19:25:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GRk0E38bKEYWbbuUVArJ9bYu0G8>
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 02:25:18 -0000

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