Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

[[e-mail]]

Guys,

Please hold your horses. The AD has made the call. I don't think we need to have a poll on that.

Cheers,
Ole

> On 15 Mar 2017, at 03:47, Suresh Krishnan <[e-mail]> wrote:
> 
> Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.  The only argument made against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change.
> 
> OLD (from -08):
> 
> 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, rather than the node that inserted 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]
> 
> With one exception, extension headers are not processed by any node
> along a packet's delivery path, until the packet reaches the node (or
> each of the set of nodes, in the case of multicast) identified in the
> Destination Address field of the IPv6 header...
> 
> NEW:
> 
> With one exception, extension headers are not examined, processed,
> inserted, or deleted by any node along a packet's delivery path,
> until the packet reaches the node (or each of the set of nodes, in
> the case of multicast) identified in the Destination Address field of
> the IPv6 header...
> 
> Please feel free to comment either privately or on list if you have any concerns with this resolution going forward.
> 
> Regards
> Suresh
> 
> P.S.: There were also other editorial issues that were raised during last call and they should be addressed in the next version of the draft--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------