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

["C. M. Heard" <[e-mail]>]

On 2017-02-18 Brian E Carpenter wrote:
> On 18/02/2017 07:00, Stewart Bryant wrote:
> > Ole
> >
> > Are you saying:
> >
> > A correct implementation of RFC2460 MUST NOT insert an EH at any point
> > along the path other than at the packet source.
> >
> Or
> >
> > A correct implementation of RFC2460 MAY insert an EH at any point along
> > the path.
>
> Ole doesn't, apparently, want to say either of those things.
>
> I want to say the first *as part of the promotion to Internet Standard*
> because it was the clear and documented intent of the authors and WG
> of RFC 1883, which became RFC 2460. (Documented in the ancient email I dug
> out a while back.) And it has been assumed by subsequent work such
> as PMTUD and IPsec/AH.

For the benefit of those who find it inconvenient to dig into the 6man WG
email archives, I've pasted the relevant part of that ancient email below.
See https://mailarchive.ietf.org/arch/msg/ipv6/poEU0yz7m2qpx3EACsszktrOlpk
for the full text of Brian's message.

-------- Forwarded Message --------
Subject: (IPng 609) changes to Last Call'ed specs
Date: Sun, 27 Aug 1995 20:59:26 PDT
From: Steve Deering <[e-mail]>
To: [e-mail]
CC: [e-mail]

At the request of our ADs, I prepared the following list of agreed-upon
changes and outstanding issues with the set of specs that underwent
IETF-wide Last Call in June and July.  Please let me know of any errors
or omissions.

Steve
[ … ]
===================================
The following suggestions in Charlie Lynn's formal response to the Last Call
were rejected at the Stockholm meeting:

  - Add a bit to the Routing Header indicating whether or not it was
    inserted into the packet en-route, i.e., by a node other than the
    packet's originator.

      reasons for rejection: insertion of extension headers en-route breaks
      PMTU-discovery and can result in ICMP error messages being sent to
      non-guilty parties.  The desired effect can be achieved, and those
      problems avoided, by using en-route encapsulation (with optional
      Routing Header) rather than header insertion.
[ … ]