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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56C83129464; Sat, 4 Feb 2017 00:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zonjCVekCSzr; Sat, 4 Feb 2017 00:32:39 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 96AE7129451; Sat, 4 Feb 2017 00:32:39 -0800 (PST)
Received: from ([]) by with ESMTP; 04 Feb 2017 08:32:39 +0000
Received: from (localhost []) by (Postfix) with ESMTP id BF074D788D; Sat, 4 Feb 2017 00:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=3iZcSrtPjtq/NhMnB39Oe4WcN7M=; b= M7jx0EOgq3/5CaOVdQw0syCtbJOJYk2xFy/FYFq18JpcMNr2cuVqNhp3S2lRIPb8 o97tDnrr4QTih07t8IzodyezmWMxfL3CXNs4syAw9nrxSUPaM6cC+D2bZyj4Ad8a /UPCqSkSVqtmr3Hgh615n6fbZ+HycKxzQ3ejRsNDfYU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=eWnjXwam4DPu/yyanzpdeUD AUUnDiPVgNCiMRCOYsjFJd5eCcRcwdSpmtHVm/mA4wJ1A2kxONNcyN3nTVeISuQn Q4TeeTIOy8v2j5l/hx2VdM2/bv+qzVRFFrleZjQ33D6F6B2JzI46KWURI6PkgYmO VNd/O8/Zx5sE5davtj78=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 61E03D788B; Sat, 4 Feb 2017 00:32:38 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 25D3A83DE987; Sat, 4 Feb 2017 09:32:38 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_7551FFB2-5870-4FE9-A24F-602551AEAF8B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Sat, 4 Feb 2017 09:32:37 +0100
In-Reply-To: <>
To: Pete Resnick <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <>
X-Mailer: Apple Mail (2.3259)
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 08:32:41 -0000

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.
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.

The chairs tried various approaches to find a consensus without luck. The approach finally chosen was a poll between the three options. And the (rough) consensus was based on the data from the poll.

Excerpt from the shepherds writeup:

A working group last call for moving this and the other two documents to Internet Standard was started on 30 May 2016. Reviews were also requested. Issues found during the last call and reviews were entered into the 6MAN ticket system. These are now closed. The biggest issue raised was how to handle the issue of Extension Header insertion in this document. After many discussion on the mailing list and face to face meeting, there wasn’t a clear consensus. The chairs conducted an online survey that provided three choices: Ban header insertion, describe the problems with header insertion, or say nothing. The result of the survey was to describe the solution. The results and methodology used to evaluate the results can be seen at: This was discussed at the 6MAN session at IETF97 and on the mailing list after the meeting. The chairs believe there is a consensus to go forward with the text that is in draft-ietf-6man-rfc2460bis-08.

The summary given to the working group calling for the poll:

Best regards,
Ole, 6man co-chair