Re: [Technical Errata Reported] RFC8200 (5933)
Fernando Gont <fgont@si6networks.com> Wed, 11 December 2019 03:33 UTC
Return-Path: <fgont@si6networks.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 999C5120833 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 19:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 llBlpJlxwsOo for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 19:33:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8B1120044 for <ipv6@ietf.org>; Tue, 10 Dec 2019 19:33:13 -0800 (PST)
Received: from [192.168.1.7] (unknown [181.113.152.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 40BD18648D; Wed, 11 Dec 2019 04:33:10 +0100 (CET)
Subject: Re: [Technical Errata Reported] RFC8200 (5933)
To: RFC Errata System <rfc-editor@rfc-editor.org>, bob.hinden@gmail.com, suresh@kaloom.com, evyncke@cisco.com, otroan@employees.org
Cc: ipv6@ietf.org
References: <20191211032724.46F77F406F3@rfc-editor.org>
From: Fernando Gont <fgont@si6networks.com>
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <68a2fde6-55ca-f806-8421-481623f7a558@si6networks.com>
Date: Tue, 10 Dec 2019 22:32:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <20191211032724.46F77F406F3@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik>
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, 11 Dec 2019 03:33:18 -0000
Folks, I gave the relevant text yet another look and, besides the possible clarification regarding the "intermmediate destinations", I've found a bug in the corresponding text. Namely, the text in RFC8200 rules out the processing of a Destination Options header along the packet delivery's path *by the nodes listed in a Routing Header*. That's of course an error -- otherwise there's no point in including a Destination Options header that precedes a routing header. The errata I've submitted clarifies the first item, and fixes the second. Thanks, Fernando On 10/12/19 22:27, RFC Errata System wrote: > The following errata report has been submitted for RFC8200, > "Internet Protocol, Version 6 (IPv6) Specification". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5933 > > -------------------------------------- > Type: Technical > Reported by: Fernando Gont <fgont@si6networks.com> > > Section: 4 > > Original Text > ------------- > Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header. > > The Hop-by-Hop Options header is not inserted or deleted, but may be > examined or processed by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. The Hop-by-Hop Options header, when present, must > immediately follow the IPv6 header. Its presence is indicated by the > value zero in the Next Header field of the IPv6 header. > > > Corrected Text > -------------- > Extension headers (except for the Hop-by-Hop Options header, or a > Destination Options header preceding a Routing header) are not processed, > inserted, or deleted by any node along a packet's delivery path, until the > packet reaches the final destination node (or each of the set of final > destination nodes, in the case of multicast). > > For packets that do not include a Routing Header, the final destination > node is identified by the Destination Address field of the IPv6 header. > For packets that include a Routing Header, the final destination node is > identified by the Destination Address field of the IPv6 header only when > the Segments Left field of the Routing Header is 0. > > The Hop-by-Hop Options header is not inserted or deleted, but may be > examined or processed by any node along a packet's delivery path, > until the packet reaches the final destination node (or each of the set of > final destination nodes, in the case of multicast). The Hop-by-Hop Options > header, when present, must immediately follow the IPv6 header. Its > presence is indicated by the value zero in the Next Header field of the > IPv6 header. > > A Destination Options header preceding a Routing Header is not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the destination node (or each of the set > of destination nodes, in the case of multicast) identified by the > Destination Address field of the IPv6 header. This means that a > Destination Options header preceding a Routing Header will be > processed by the first destination of the packet (specified by the > Destination Address field of the IPv6 header at the origin node) and by > each node listed in the Routing Header. > > Notes > ----- > This errata clarifies two different issues: > > * It clarifies that nodes other than the final destination do not insert o remove extension headers. > > * It clarifies that the Destination Options header preceding a routing header *is* processed along the > packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header. > > 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. > > -------------------------------------- > RFC8200 (draft-ietf-6man-rfc2460bis-13) > -------------------------------------- > Title : Internet Protocol, Version 6 (IPv6) Specification > Publication Date : July 2017 > Author(s) : S. Deering, R. Hinden > Category : INTERNET 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 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [Technical Errata Reported] RFC8200 (5933) RFC Errata System
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Tom Herbert
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- RE: [Technical Errata Reported] RFC8200 (5933) Ron Bonica
- Re: [Technical Errata Reported] RFC8200 (5933) Loa Andersson
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu