Subject: Next steps on Extension Header Insertion

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Oct 2016 12:02:32 -0700

Hello,

The chairs believe the bis drafts for moving the IPv6 to Internet Standard are close to being done with one exception, text in rfc2460bis on Extension Header Insertion.  This topic has been discussed extensively on the list and in working group sessions.  Prior to declaring a consensus and advancing the documents to the IESG we would like some feedback from the working group.

The current text regarding header insertion in draft-ietf-6man-rfc2460bis-07.txt (and has been there since the -05) is:

  The insertion of Extension Headers by any node other than the source
  of the packet breaks PMTU-discovery and can result in ICMP error
  messages being sent to the source of the packet that did not insert
  the header.

  The current approach to allowing a header to be inserted 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].

Based on recent face to face and mailing list discussions, we think the text could be improved as follows:

  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 and 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 change in the first paragraph is more accurate as it notes there is more than one problem.  The change in the second paragraph makes it clear that encapsulation isn’t necessarily the only approach.

Our current take after reviewing the discussion in Berlin and on the mailing list we think there is consensus on the first paragraph as it accurately describes the issue with header insertion.  There is a much rougher consensus on the second paragraph, but don’t see it as the real issue which is the first paragraph.

While we both think that the intent of IPv6 was not to support header insertion we don’t see there being a consensus in the working group ban it outright as was proposed in the -01 draft:

  Extension headers must never be inserted by any node other than the
  source of the packet.  IP Encapsulation must be used to meet any
  requirement for inserting headers, for example, as defined in
  [RFC2473].

We think the choice before the working group at this point is to either do something like the proposed text, or to not say anything at all about this topic.  This would be no change from RFC2460.   We would like your feedback on these choices between now and 13 October.  We have created a survey so we can better gauge where the working group is.  We are hoping that by using the survey, we will get more responses then by email alone.

To summarize, we think there are three choices.

(A) Banning header insertion outright:

  Extension headers must never be inserted by any node other than the
  source of the packet.  IP Encapsulation must be used to meet any
  requirement for inserting headers, for example, as defined in
  [RFC2473].

(B) Describe the problems caused by header insertion:

  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 and 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]

(C) Not say anything at all about header insertion in rfc2460bis

  [No text in rfc2460bis about header insertion]

Note: If in case (B) or (C), it might be good to write a new draft that describes the issue in depth and makes recommendations.  We could then see if we can build a consensus around a draft like that, but it would be separate from the effort to move the IPv6 specifications to Internet Standard.

Please fill in the poll at

    https://www.surveymonkey.com/r/QG5QPVR

before November 4, 2016.  The poll allows you to express you preference for each choice, with 1 being the highest preference, and 3 being the lowest.  We will publish the results after the poll closes.

Thanks,
Bob & Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Oct 2016 08:20:45 +1300

This is just about a syntax issue and will not affect my response to the survey:

>   Two examples include breaking

That "and can" doesn't parse for me. I *think* you mean:

  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.

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Oct 2016 12:32:48 -0700

Brian,

> On Oct 27, 2016, at 12:20 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Yes, thanks.

Bob

---

From: Mark Smith <[email-masked]>
Date: Fri, 28 Oct 2016 07:21:37 +1100

>   that did not insert the header.

In this text I'd also like to see a mention of operational implications e.g.,

"It will also make troubleshooting harder, as construction of the
entire packet cannot now be reliably attributed to the host assigned
the source address in the packet."

Regards,
Mark.

> Regards
>    Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 27 Oct 2016 22:55:11 +0200

>  that did not insert the header.

Isn't that 3 examples. ;-)

Ole

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Oct 2016 09:50:20 -0700

At Thu, 27 Oct 2016 12:02:32 -0700,
Bob Hinden <[email-masked]> wrote:

> before November 4, 2016.  The poll allows you to express you
> preference for each choice, with 1 being the highest preference, and
> 3 being the lowest.  We will publish the results after the poll
> closes.

Does this mean our choices are now limited to these three?  What if,
for example, the choice from A-C that is closest to my preferred text
is X, but I also have a pretty strong concern about the currently
presented text of X?

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Oct 2016 10:14:33 -0700

Jinmei-san,

> On Oct 28, 2016, at 9:50 AM, 神明達哉 <[email-masked]> wrote:
> 

The chairs are attempting to get a better view of the direction that the w.g. would like to go.  It’s not about adopting the exact text in each choice, that would happen later.

Hope this answers your question.

Bob

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Oct 2016 10:29:41 -0700

At Fri, 28 Oct 2016 10:14:33 -0700,

> Hope this answers your question.

Yes, it does, thanks.  I've submitted my preferences to the poll.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Oct 2016 09:55:12 -0700

> On Oct 27, 2016, at 12:02 PM, Bob Hinden <[email-masked]> wrote:
> 

One thing it doesn’t allow is offering alternative text. To me, the big issue with header inserting (second question) is neither of the two cases you mention, as they are examples of possible failures. The big issue is that when the packet is changed in flight, failures can happen as a result that the end user cannot predict or diagnose - it has issues with the end to end argument. If someone changed the packet in flight, it would be incumbent on them to ensure that such failures did not happen, or that the user was aware to not use certain technologies that it would break. 

With that comment, I have made my response to the poll.