Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Joe Touch <> Tue, 07 February 2017 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88C0F1295B0; Tue, 7 Feb 2017 11:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sk8-2nGlNhnn; Tue, 7 Feb 2017 11:08:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F910120725; Tue, 7 Feb 2017 11:08:43 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v17J7eaG003111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:07:42 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To:, "tom p." <>
References: <> <> <> <> <00af01d27e11$fe539500$> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 7 Feb 2017 11:07:42 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CDF5BCBCF48D19481D6FACD2"
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc:,, "Stefano Previdi \(sprevidi\)" <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Feb 2017 19:08:44 -0000

Hi, all,

Can anyone give those of us not tracking 672 messages a brief summary?

IMO, without diving into that thread deeply, I agree with the new
proposed text below from Brian:

>    With one exception, extension headers are not processed, inserted,
>    deleted or modified 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.
In fact, I'd go further to say that that non-HBH EHs should not even be
*viewed* or used as context by intermediate nodes.

And any limits on what can be done with HBH EHs should be stated
explicitly. I'd be glad if at least the EH lengths didn't change.


On 2/3/2017 10:22 AM, wrote:
>> are we re-spinning the debate on a WG-agreed text ?
>> <tp>
>> Yes, and I am sure that that is exactly what is intended.
> Then let's encourage people outside of 6man, with other points of view, and other arguments to come forward.
> A re-run of the discussions already had in 6man with the same arguments and the same participants doesn't seem useful.
> For a brief (sic) overview take a look at 672 messages already on the topic: