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: Fri, 3 Feb 2017 09:20:28 -0800

On Fri, Feb 3, 2017, at 1:37 AM, Brian E Carpenter wrote:
> In Section 4 ("IPv6 Extension Headers") the draft says:
>
>>    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.
>
> (FYI, the exception is the hop-by-hop extension header.)
>
> I do not dispute that this sentence reached WG consensus. However, I want
> to ask if it has IETF consensus. In my opinion, this sentence should read
>
>    With one exception, extension headers are not processed, inserted,
>    deleted or modified 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.
>
> I believe this was always the intended meaning of the word "processed"
> from the earliest design phase of IPv6, but some people have read this
> text as allowing insertion, deletion or modification of headers. IMHO
> it needs to be clarified.

I, too, am of the opinion that the WG consensus on this point was wrong.

>From the outset it has been fundamental to the IPv6 architecture that
an ICMPv6 message triggered by a particular packet will be sent back to
the source of that packet. If an intermediate node inserts an extension
header or makes an alteration in one that triggers an ICMPv6 error
message -- for example, Packet Too Big or Parameter Problem -- that
error message will be sent back to the source of the packet, not to
the node responsible for inserting the offending header or alteration.
That is fundamentally broken.

On that basis, I don't think that there is any doubt that Brian's
construction of the intent of RFC 2460 is the correct one, and
the language of RFC 2460bis should unambiguously reflect that.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 18 Feb 2017 15:15:10 -0800

On 2017-02-17 Joel M. Halpern wrote:
> I disagree with your interpretation of the bar the document must meet.
> I believe I have clearly stated my concern.
> I will leave that judgment to the relevant ADs and IESG when they
> review the last call results.

Thank you for saying this.  I am glad to see that someone who was not
involved in the WG discussion has chosen to speak out in support of
that position.

During the WG discussion, I said:

"If I were on the IESG and a spec came to me with a known ambiguity,
 I would vote to send it back to the WG with instructions to resubmit
 it after the ambiguity was fixed."

I would base that on the following language from RFC 2127, Section
3.1 (which replaces similar language in RFC 2026, Section 4.1.1):

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.

The relevant ADs and IESG may see this differently, but in my view,
language that has been shown to admit conflicting interpretations,
either by implementors or by authors of subsequent specifications,
constitutes a "known technical omission," and if that's not good
enough for PS, it's clearly not good enough for IS, either.

There is ample evidence in the record that the language in both 2460
and now in 2460bis has led to conflicting interpretations regarding
the admissibility of insertion of extension headers by any node other
than the one originating the packet.  The main discussion in 6man
focused on the segment routing header, where versions of
draft-previdi-6man-segment-routing-header up through 07 called for
insertion of that header by a border router, and according to
https://www.ietf.org/mail-archive/web/ipv6/current/msg20892.html and
https://www.ietf.org/mail-archive/web/ipv6/current/msg24145.html,
that behavior was actually implemented (for further evidence, see
also https://lwn.net/Articles/698841/).  That behavior was removed
in favor of encapsulation in the -08 version of the draft and also in
the version adopted by 6man (draft-ietf-6man-segment-routing-header),
but the older implementations apparently linger on.

The early SRH drafts, however, are not the only examples of conflicting
interpretations of the language in 2460. RFC 6621 Section 6.1.3 says:

   If a digest collision is detected at an SMF ingress point, the H-DPD
   option header is constructed with a randomly generated HAV.  An HAV
   is recalculated as needed to produce a non-colliding hash value prior
   to forwarding.  The multicast packet is then forwarded with the added
   IPv6 SMF_DPD option header.

By contrast, RFC 4782 (Quick Start) and RFC 6971 (Depth-First Forwarding)
were careful to specify that the HBH options defined therein were either
inserted by the source node or that encapsulation was used if inserted
by a non-originating node.

I couldn't find any discussion of 6621 or 6971 in the 6man archive.
I did see 4782 mentioned as problematic, but I didn't get that from
reading the RFC, which carefully discussed compatibility with AH.

On 2017-02-17, Ole Troan wrote:
> Do we agree that you can see this at two different angles?
>
> 1) Are there any interoperability issue or ambiguity in the protocol
>    specification of 2460 and how implementors of 2460 have interpreted
>    that?
>
> 2) Is 2460 "future-ambiguous", i.e it is unclear if 2460 permits a
>    future extension? Like ECMP, Header insertion NAT...

Question #1 is incomplete, as it fails to ask if there is an ambiguity
that has tripped up authors of specifications extending IPv6. That is
demonstrably the case. And it is equally clear from the discussion
on record that insertion of extension headers by intermediate nodes
breaks fundamental assumptions of IPv6 and causes some of the
core specifications to fail.

Question #2 is also incomplete, as it fails to acknowledge the
difference between extensions that break parts of the core
specifications and those that do not.

> I'm trying out the argument of declaring the whole question of
> ambiguity out of scope. To see if there is better consensus for
> that.

And I am hoping that the community and the IESG do not buy this.

Best regards,

Mike Heard