Reminder, poll on header insertion closes soon

[Bob Hinden <[e-mail]>]

If you haven’t yet, please fill in the poll, it closes on November 4, 2016.

Thanks,
Bob


> On Oct 27, 2016, at 12:02 PM, Bob Hinden <[e-mail]> wrote:
> 
> 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
> 
> 
> 
>