RE: [Errata Rejected] RFC8200 (6003)

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Jinmei,

Please see my comments in line below marked with [xjr]:

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.
[xjr] "Destination address field of the IPv6 header" even have further qualifying text to the "Destination address", so the Section 4 of RFC8200 is even more clear and solid.

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.  
[xjr] No. the text of Section 4 doesn't mean this. Note the "the node identified in the Destination Address field of the IPv6 header." ---- the further qualifying text to the "Destination address".

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).
[xjr]That may not an encouragement of "insertion" on such nodes, but that I think is a solid consideration in RFC2460bis (see the following of rfc2460bis):
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-08
And after that, the rfc2460bis -09 is almost the same as the -00 revision, with "insertion/deletion" added:
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-00
Later, the rev-11 change the "With one exception" to "except for the Hop-by-Hop Options header":
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-11
[xjr] So finally the main ambiguity fixed by RFC8200 was the "With one exception" changing to "except for the Hop-by-Hop Options header".

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.
[xjr] From the history of 2460bis, I did see the concerns about the impact of "insertion" (before rev-09 of 2460bis), but I did not see the concerns about the impact of "deletion".

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.
[xjr] the resulting text overlooked its implication with the definition of "Destination Address" ---- I didn't see this. 
[xjr] Adding the "insertion/deletion" in RFC8200 doesn't change much the RFC2460 text. 
[xjr] The "insertion/deletion" is still in careful discussion when a proposal is passing the 6man review.

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).
[xjr] I didn't found the intension of rfc2460bis to make it more restrictive, maybe one can check the changelog of rfc2460bis for learning.
[xjr] I didn't think either it necessary to make it more restrictive.

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).
[xjr] As a core protocol, the RFC8200 should not restrict the possible development of EH that it couldn't foresee. Instead, the development of EH should be left in case-by-case consideration under this core protocol of 8200.
[xjr] I would consider such development as a motivation of IPv6, as stated in RFC8200 -- Improved Support for Extensions and Options.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of JINMEI Tatuya / ÉñÃ÷ß_ÔÕ
Sent: Tuesday, May 12, 2020 9:57 AM
To: RFC Errata System <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Errata Rejected] RFC8200 (6003)