Re: [Errata Rejected] RFC8200 (6003)

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

I don't have a strong opinion on how this errata should be handled,
but I'd like to make a remark on one specific point:

At Sun, 10 May 2020 11:41:12 -0700 (PDT),
RFC Errata System <[e-mail]> wrote:

>  --VERIFIER NOTES-- 
> Section 3 clearly highlights for the reader when the IPv6 Destination Address in the header might differ from the IPv6 address of the ultimate destination.
> 
> As such, all references in the document to "Destination Address" lacking further qualifying text should be read bearing this in mind.  The text in section 4 is no exception.  The key text has remained unchanged since RFC 1883.

Does "the key text" mean the definition of "Destination Address" in
Section 3?

      Destination Address 128-bit address of the intended recipient of
                          the packet (possibly not the ultimate
                          recipient, if a Routing header is present).
                          See [RFC4291] and Section 4.4.

then that's true.  And, I agree that the text in question in Section 4
intentionally uses the term "Destination Address" precisely in this
sense until RFC2460:

   With one exception, extension headers are not examined or 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.

This "Destination Address" *must* include an intermediate destination
specified in a routing header, since there can be an extension header
(other than hop-by-hop options headers) before a routing header, and
such a routing header would have to be "examined" or "processed" at
each destination specified in that routing header.

Now, RFC8200 changes this text in a non-trivial way, and in that sense
"a key text" has changed, which is in fact the point of the "error":

   Extension headers (except for the Hop-by-Hop Options header) are not
   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.

The phrase "inserted, or deleted" was added as a result of the
discussion regarding whether "examined or processed" includes
insertion or deletion.  If it doesn't, it means that an arbitrary node
in a packet's delivery path (whether or not the nodes' address can
appear in the Destination Address field of the IPv6 packet due to a
routing header) can insert or delete an extension header.  In
particular, such an arbitrary node can insert a routing header into a
packet even if that node itself doesn't appear in the Destination
Address field.  That would be particularly convenient for the
"insertion/deletion" mode of SRv6, and that interpretation ("examined
or processed" does NOT include insertion or deletion) were mainly
supported by those developing the SRv6 protocol.  Other people opposed
that interpretation and argued that "examined or processed" should
include insertion or deletion, since otherwise it would break some
existing standard protocols such as PMTUD or AH and make error
handling less robust (the same argument we're still seeing today).

So far I hope I simply explained the past fact without mixing my own
opinions.  Now this is what I would interpret the new text (which also
matched my memory on how I interpreted it at that time): with this
background history in mind, the intent of the new text should simply
be an attempt to clarify "examined or processed" includes "inserted or
deleted" for any intermediate node in a packet's delivery path.

Unfortunately the resulting text overlooked its implication with the
definition of "Destination Address", that is, accidentally making a
loophole for intermediate nodes specified in a routing header.  But if
the loophole had had been noticed at that time, it wouldn't have been
accepted by those who opposed allowing insertion/deletion, since its
adverse effects such as breaking PMTUD would be almost fully intact.
And the loophole wouldn't have made much sense for the SRv6 developers
either, since it would still prevent an fully arbitrary insertion.

So I believe most people involved in that discussion interpreted the
text as I did, regardless of their position on intermediate
insertion/deletion.  Of course, this interpretation wouldn't be
favorable for those who wanted arbitrary insertion/deletion.  The
"deal" in my memory is that while rfc2460bis (now RFC8200) explicitly
made it more restrictive than RFC2460, 6man and spring WGs would
collaborate on followup work on how we can loosen the condition.  (I
wish I had a more direct reference to this conclusion at that time,
but I couldn't easily find it so I'm writing this largely based on my
own memory and it's quite possible that it's not entirely accurate).

And that's why I believe that this is essentially a simple "bug fix"
of the RFC text and that it's more productive to fix the bug quickly
and focus on the "followup work".  In that sense I sort of agree that
it can be fixed as an erratum.  But I also admit that "purely
literally" the current RFC8200 text could read as if it made the
loophole intentionally, and so I understand the argument that it's not
suitable for errata.  And, in any case, I don't think it's productive
to spend too much time on whether errata are the suitable place for
this fix.  If that level of point is somehow debatable, I'd rather
suggest focusing on draft-bonica-6man-ext-hdr-update (I'd suggest the
same thing even if I don't happen to be a coauthor of the draft).

--
JINMEI, Tatuya