Re: RFC 8200: The Devil's Paragraph

[神明達哉 <[e-mail]>]

At Thu, 27 Feb 2020 22:52:20 +0000,
Ron Bonica <rbonica=[e-mail]> wrote:

> Looking more closely at "The Devil's Paragraph", it may have a few problems..  Currently, it says:
>
> "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 problem is that the rules for processing, insertion and deletion are different. It should say the following about extension header processing:
>
> "The Hop-by-Hop Options header can be processed by any node in packet's delivery path. The Destination Options header and Routing header can be processed by any node in a packets delivery path, so long as one of that node's addresses appears in the Destination Address field of the packet's IPv6 header. The Fragment Header, Authentication Header, and Encapsulating Security Payload header can only be processed by packet's ultimate destination."
>
> Regarding insertion and deletion, we should say one of the following:
>
> "Extension headers cannot be added to a packet after it has left the its source node and extension headers cannot be removed from a packet until it has arrived at its ultimate destination".

Yeah, we should have said something like this in RFC8200.  It's
regrettable that I couldn't catch it at that time, but on a nearly
fresh read of the text I now see the issue clearly.  The very original
RFC2460 text said "Destination Address field of the IPv6 header"
presumably intending to cover the case of "processing" a destination
options header or a routing header (like address swapping or
decrementing segments left) at an intermediate destination specified
in a routing header.  But, in the discussion that led to the new
"inserted, or deleted" text in RFC8200, we were probably too focused
on clarifying the meaning of "processed" and didn't pay enough
attention to the end effect of the resulting sentence with
"Destination Address...".

But our intent at that time was obviously "after its source node...and
until it has arrived at its ultimate destination" (otherwise the
debate shouldn't have been that hot).

I have no comment about where this clarification should be made.  An
erratum may be enough in that it should simply clarify the actual
intent, but if it triggers another heated discussion on the process
itself, it's probably not an efficient way of using our time.  But I
agree this should be clarified somewhere.

> We can debate whether we want to make a special exception for
> Routing headers where Segment Left is equal to 0.

In terms of clarifying the original intent, I'd say it's out of scope
since it opens up corner cases like having another routing header with
segment left > 0 follows this routing header.  Just saying "ultimate
destination" seems to be enough.

--
JINMEI, Tatuya