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

From: "C. M. Heard" <[email-masked]>
Date: Sun, 19 Feb 2017 09:33:40 -0800

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 <[email-masked]>
To: [email-masked]
CC: [email-masked]

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.
[ … ]

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 19 Feb 2017 13:50:42 -0800

On 2017-02-18 Philip Homburg wrote:
> So the only purpose of a stronger text against inserting extension headers
> would be to prevent IETF working groups from publishing RFCs that use
> that technique.

That is not the only purpose -- some of us, at least, would like to believe
that stronger text will help to discourage practices that can have
demonstrably harmful effects -- but it is definitely an important purpose.

> Then the question becomes, why would we need to pre-emptively constrain
> ourselves?

To prevent IETF working groups from publishing RFCs that are inconsistent
with  existing standards track specifications and cause them not to work, or
more precisely, to prevent them from doing so without proper consideration
of negative side effects and how to deal with them (which may include
explicitly updating or obsoleting existing specifications).

//cmh

---

From: heasley <[email-masked]>
Date: Tue, 21 Feb 2017 18:08:39 +0000

> demonstrably harmful effects -- but it is definitely an important purpose.

Stronger text is also amunition for operators and users to push vendors to
fix bugs (no matter the proto in question).  we prefer the text to be
precise.  if it breaks ptmud and ptmud is essentially mandatory ....

[ps thanks for digging in the ml archive]