RE: RFC 8200: The Devil's Paragraph

[Ron Bonica <[e-mail]>]

Jinmei,

If you like, we can work together on a short draft that updates The Devil's Paragraph.

The SPRING chairs have just announced that they will progress the Network Programming draft, regardless of objections. Our draft won't influence that decision, but it may avoid similar problems in the future.

                                                                                  Ron


Juniper Business Use Only

-----Original Message-----
From: 神明達哉 <[e-mail]> 
Sent: Friday, February 28, 2020 2:55 PM
To: Ron Bonica <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: Re: RFC 8200: The Devil's Paragraph

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