Re: I-D Action: draft-bonica-6man-ext-hdr-update-01.txt

Brian E Carpenter <> Mon, 09 March 2020 04:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0B363A1055 for <>; Sun, 8 Mar 2020 21:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HsHAX70e3kfE for <>; Sun, 8 Mar 2020 21:17:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CED133A1052 for <>; Sun, 8 Mar 2020 21:17:52 -0700 (PDT)
Received: by with SMTP id ca13so1594054pjb.2 for <>; Sun, 08 Mar 2020 21:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fScfNipn7f8M1RMQX3nld4alHGr9/fqb7XLseMLSfOQ=; b=rBSv9DzgsItzD6EmTJVGDjkU4zjWBHOk/Lr591UzFgBqf70Iy1y17Rx9CO2Wk7gvQR VgQf0P9kUeva9p8Waw8zlBomtAUqr8d+kf4D5owju+8299/MVHqpXVbEfAfRC3Xc+qV0 qbQs7asyCl42JkGdTWdilRll6Q2qyhV45WjusNmCraadmRH+Wi4Zphtk6KPeueEysu2/ JtTU+KmNLfCBmNh6b0smQ+l9vuuCKn3Nok3NBPH7Cl4u1efy7uSJ3K5Fmb/D7glCe7Bg 5ObZoQG0Q/o/bgVxS9QP4Rj04d9uLFOJFVqP1Lg/PyoRSEQeyXen5nO2nCrmkX3tuJLr gyEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fScfNipn7f8M1RMQX3nld4alHGr9/fqb7XLseMLSfOQ=; b=cfu4YU6YQOi1pjfo4lUs+7VFo0PpbdZgyseEShnUSzpS+JEhkeS9upjlxD//kBItZp fU/mTMShWuIi7U0DSyEkuNhO+GPoZyMz5LRtt7BMJP4oNH8/6lhdq2YGtNUf0ZYischA ctUfz8Q88XfDJ1nqDrUtay6HBz6ysxE29mGwPM/lrr7HM4SAr9XRusLRncpW1LEhAkuE Mlh+DitDJmLLY/HNgBAiO5yLMGHQ2m7RvGvnJZPmTzyKgxk7lutt9O7dQZB4q4jX1uEO PSjq66IYRO5xUqkO4hiHGXjccZ6d1T+KT7599rv8gsKzHmtc/AaPl3Rz4kVHBA0IQS3D 6Scw==
X-Gm-Message-State: ANhLgQ1N3WhJwS7xiu+cRyBruBPoKvKmjcEQJcs3GUkMxttFg0kEPI8D Kn2vHhre/CFndy2nWdXPdeM=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuid6kf5QgdVp7xbolDWbAfnToj7Ua/ulxgN2Fs?= =?utf-8?q?0J2fZz5svm/SBE7MR/CV6giWWbH9wbxwIg=3D=3D?=
X-Received: by 2002:a17:90a:858c:: with SMTP id m12mr16279490pjn.127.1583727472031; Sun, 08 Mar 2020 21:17:52 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id t126sm9379195pfd.54.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2020 21:17:51 -0700 (PDT)
Subject: Re: I-D Action: draft-bonica-6man-ext-hdr-update-01.txt
To: 6man <>, Ron Bonica <>
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Mon, 9 Mar 2020 17:17:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2020 04:17:55 -0000


I'm going to nit-pick the crucial text in the draft, without taking a position
on whether it should go forward. I think it's essential to get the text right
before we take any sort of decision.

> 2.  Terminology
>    The following terms are used in this document:
>    o  Source node - An IPv6 source node accepts data from an upper-layer
>       protocol, encapsulates it in an IPv6 header, and sends the
>       resulting IPv6 packet to a destination node.

Actually it doesn't encapsulate, it simply prepends the IPv6 header.
>    o  Destination node - An IPv6 destination node receives an IPv6
>       packet and delivers its payload to an upper-layer protocol.

If that's what we now mean by "Destination node", we probably need to add
a note that the Destination address might not be the address of the
Destination node (as stated at
>    o  Delivery path - A packet's delivery path is a series of nodes that
>       a packet traverses on route to its destination.  The delivery path
>       includes the destination node.
>    o  Segment - A segment is a series of links and nodes in a packet's
>       delivery path.  The IPv6 Routing header steers packets from
>       segment to segment along the delivery path.  If a packet contains
>       a Routing header, its delivery path can contain multiple segments.
>       If a packet does not contain a Routing header, its delivery path
>       contains only one segment.

Are we sure that statement applies to all past, present and future types
of routing header? If so, it should be "An IPv6 Routing header steers...".
>    o  Segment egress node - A segment egress node terminates a segment.
>       When a packet arrives at a segment egress node, its IPv6
>       Destination Address identifies a resource that belongs to the
>       node.  All destination nodes are also segment egress nodes.

That's a significant change. According to RFC 4291, an IPv6 address
is assigned to an interface; nothing to do with "resources". If you
want an IPv6 address to identify a resource rather than act as a 
locator, that's an update to 4291, IMHO.

> 3.  Updates To RFC 8200
...> 3.2.  Updated Text
>    Source nodes can send packets that include extension headers.
>    Extension headers are not inserted by subsequent nodes along a
>    packet's delivery path.
>    The Hop-by-Hop Options header can be processed by any node in a
>    packet's delivery path.

I have long been disturbed by the word "process". Any node can read
the value of any extension header (unless encrypted). Firewalls do it
and might drop packets as a result. So "process" can't mean "read".
Maybe it means "modify"? But of course options can only be modified
in specified ways (and cannot be changed in length).

>    ... The following headers can be processed by
>    any segment egress node, including the destination node:
>    o  Destination Options header.

Same comment.

>    o  Routing header.

Same comment, but it should add that the spec of any type of
routing header must specify precisely what modifications are
allowed, and the length of the header must not increase.
>    The following headers can be processed by the destination node only:
>    o  The Fragment header.
>    o  The Authentication header.
>    o  The Encapsulating Security Payload header.

Do we really need to say that? Once the packet enters the destination node
there's no issue.
>    Except for the following fields, extension headers are not modified
>    by nodes along a packet's delivery path:

See, "processed" only means anything if something is modified.

>    o  The Segments Left field in the Routing header.
>    o  Type-specific data in the Routing header.

Are we sure that is enough for all future routing header types? (Actually,
there's already a spec for which that rule is probably insufficient:
draft-lc-6man-generalized-srh, which adds a "C-SID left" field to the
routing header.)
>    o  Option Data in the Destination Options header.
>    Extension headers are not 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).

Again, once the packet is inside the destination node, there's nothing to say.

Finally, do we need some comment about AH? Should we require specs to state
either that they are incompatible with AH, or to state exactly which fields
are mutable for AH purposes?

   Brian Carpenter

On 07-Mar-20 13:47, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : Inserting, Processing And Deleting IPv6 Extension Headers
>         Author          : Ron Bonica
> 	Filename        : draft-bonica-6man-ext-hdr-update-01.txt
> 	Pages           : 5
> 	Date            : 2020-03-06
> Abstract:
>    This document provides guidance regarding the processing, insertion
>    and deletion of IPv6 extension headers.  It updates RFC 8200.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or