Subject: Proposed rfc2460bis extension header insertion text

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Nov 2016 10:15:09 -0800

Here is the proposed extension header insertion text for rfc2460bis.

   The insertion of Extension Headers by any node other than the source
   of the packet causes serious problems.  Two examples include breaking
   the integrity checks provided by the Authentication Header Integrity
   [RFC4302], and breaking Path MTU Discovery which can result in ICMP
   error messages being sent to the source of the packet that did not
   insert the header.

   One approach to avoid these problems is to encapsulate the packet
   using another IPv6 header and including the additional extension
   header after the first IPv6 header, for example, as defined in
   [RFC2473]

The only change from what was in the survey was the editorial change suggested by Brian Carpenter.

The text is open for improvement as long as it keeps it within the consensus in the w.g.  That is, that it only describes the problems with header insertion.

The goal is to publish a new draft when the ID repository reopens.

Thanks,
Bob & Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Nov 2016 07:49:52 +1100

> The only change from what was in the survey was the editorial change
suggested by Brian Carpenter.

I'm happy enough with that.

Regards,
Mark.

> The text is open for improvement as long as it keeps it within the
consensus in the w.g.  That is, that it only describes the problems with
header insertion.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Nov 2016 09:19:11 -0800

At Wed, 9 Nov 2016 10:15:09 -0800,

>    header after the first IPv6 header, for example, as defined in
[...]
> consensus in the w.g.  That is, that it only describes the problems
> with header insertion.

I'd now like to exercise the right I reserved at the time of poll and
propose "improved" text.  To me, the above text has some fundamental
issue that it's as ambiguous as the original RFC2460 regarding whether
the protocol allows the insertion or deletion.

Among the three options in the poll, the only option that addressed
this point was the "outright ban", but that one seemed too strong and
I didn't see any realistic possibility for it to be adopted anyway,
given the history of this discussion.  I was okay about softening the
tone by mainly just describing the problems of insertion, so that was
the closest to my preference.  But, unless the ambiguity issue is
resolved it can't actually be my choice.  I still didn't raise that
point at the time of poll because if we start tweaking the choices we
couldn't have even agreed on the options and just got stuck like
previous discussions; I wanted to give the attempt of polling a chance
to see if we can make a progress from that.  So, I'd now like to
request some flexibility about the meaning of "within the consensus".

With this excuse, this is my proposed text.  It's based on the
currently proposed text and mainly *only* describes the problems, but
it also tries to clarify the ambiguity.

  In the original design of IPv6 extension headers at the time
  [RFC2460], extension headers are not supposed to be inserted (or
  deleted) by any node other than the source of the packet.  In fact,
  the insertion of Extension Headers by an intermediate node causes
  serious problems.  Two examples include breaking the integrity
  checks provided by the Authentication Header Integrity [RFC4302],
  and breaking Path MTU Discovery which can result in ICMP error
  messages being sent to the source of the packet that did not insert
  the header.

  Some recently developed attempts have sought to loosen the
  restriction and allow the insertion and removal of extension headers
  at intermediate nodes under some particular set of conditions.  A
  future update to the protocol may allow such flexible behavior.
  Until the conditions that can safely allow it are figured out,
  however, it is prudent for newer protocols to assume the originally
  intended restrictions.

  One safe approach to avoid these problems is to encapsulate the
  packet using another IPv6 header and including the additional
  extension header after the first IPv6 header, for example, as
  defined in [RFC2473].

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 08:23:53 +1300

Hi,

I generally support Jinmei's proposal. However:

>  A future update to the protocol may allow such flexible behavior.

That goes too far; it is a case of allowing the camel to push its nose
inside the tent. I would simply delete that sentence.

> Until the conditions that can safely allow it are figured out,

s/Until/Unless/

(Considering how the WG responded when we drafted text allowing
the flow label to be modified in a similar way, I am very pessimistic
about such conditions ever reaching consensus.)

Regards
   Brian