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

Fernando Gont <> Sat, 04 February 2017 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27AE31294F8; Sat, 4 Feb 2017 01:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QOjeQbid17Vz; Sat, 4 Feb 2017 01:10:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 240E31293DF; Sat, 4 Feb 2017 01:10:26 -0800 (PST)
Received: from [IPv6:2001:1291:200:42e::2] ( [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5459083656; Sat, 4 Feb 2017 10:10:20 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To:, Pete Resnick <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sat, 4 Feb 2017 06:04:46 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,, Stefano Previdi <>,
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: Sat, 04 Feb 2017 09:10:28 -0000

On 02/04/2017 05:32 AM, wrote:
> Thank you Pete! You are of course right.
> Let me try to provide some background of the issue.
> The contentious text is the following paragraph from 2460:
> With one exception, extension headers are not 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.
> Essentially the question is: - Does the IPv6 architecture permit
> insertion of extension headers and/or header options by a node along
> the packet's delivery path?
> This question came up triggered by discussions around some recent
> proposals: - draft-ietf-conex-destopt, - RFC4782 (does header
> deletion) - draft-ietf-6man-segment-routing-header -
> draft-brockners-inband-oam-transport
> The IP architecture (IPv4 and IPv6) supports _modifying_ IP options
> in flight, but it is unclear if it could permit changing the IP
> datagram's size. 

The only case that can be made for that is that the spec doesn't say
"insertion of EHs is forbidden" -- but then, if you were to have to
write a spec explicitly noting everything that is forbidden, you
wouldn't be able to achive that in your lifetime.

Everyone has agreed (including the authors of RFC2460) that EH insertion
has never been allowed.

> Increasing a packets size in flight would break
> PMTUD (RFC1981), AH, and might results in other ICMP error messages
> being sent to an unsuspecting source.
> There were three main positions argued in the working group.
> 1) Ban header insertion outright. 2) Describe the problems with
> header insertion. 3) No changes to RFC2460 text.
> Permitting header insertion in the sense of specifying how header
> insertion could possibly work is of course outside the scope of
> advancing RFC2460.

Explicitly allowing EH insertion would most likely be out of scope, too:
It completely changes a very basic aspect of IPv6.

FWIW, I think that publishing a spec with what some have considered to
be ambiguous text (subsequently leading to 600+ messages on the very
group that specifies the protocol) would be a lousy job on our side.
Either explicitly ban extension header insertion, or explicitly allow it.

Whether EH insertion is allowed (or not) seems to me like a very basic
question that the protocol spec should be able to answer -- particularly
since we're moving it to Standard.

Given that the question has been "raised", it deserves an answer in the
spec. Otherwise, when asked "Are intermediate systems allowed to mangle
with IPv6 packets as they please?", I guess we'd have to answer "We
don't know... but neither did the group that wrote the spec".

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492