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