Subject: RFC 8200: The Devil's Paragraph

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 22:52:20 +0000

Folks,

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".

We can debate whether we want to make a special exception for Routing headers where Segment Left is equal to 0. But the current text is too permissive. For example, it allow the penultimate segment endpoint to insert destination options. When it does so, the destination node falsely assumes that the source node originated the destination option.

                                                                                                                 Ron

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Feb 2020 15:08:37 +1300

Ron,

Rather than getting involved in the errata/appeal discussion, I'll comment here.

On 28-Feb-20 11:52, Ron Bonica wrote:
> Folks,
> 
> 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
>    of the IPv6 header.”
> “The Hop-by-Hop Options header can be processed by any node in packet’s delivery path. 

The word "process" itself is troublesome, and I believe I said this at some point in the 2460bis discussion. I'd rather see it broken into two parts
  "read and interpreted"
  "modified (without changing the data length)"
with separate rules for each.

That said, putting the rule for the HbH header first rather than making it an exception seems much clearer.

> 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.”
>  
> “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”.
> 
> We can debate whether we want to make a special exception for Routing headers where Segment Left is equal to 0. But the current text is too permissive. For example, it allow the penultimate segment endpoint to insert destination options. 

I don't understand how it does that. But then it was always clear to me (as to Fernando) that "destination" meant "ultimate destination".

> When it does so, the destination node falsely assumes that the source node originated the destination option.

That's right, and it's an unverifiable assumption.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 23:38:58 -0300

> with separate rules for each.

The problem is, that as anything that's produced by humans, if you want, 
you will probably always find something that could have been said better.

When it comes to this discussion, it has always bee clear to everyone 
that IPv6 does not support header insertion/removal along the delivery path.

In fact, even with RFC2460, it was only the proponents of RFC2460 that 
said there was ambiguity, and that's why we tried to add more text and 
polish the existing one.

One would expect that if in good faith/will, you try to understand the 
intent, and if not clear, you go to the source (i.e., the folks that 
worked on the spec (ideally the authors, and possibly folks that 
participated in the process).

But in this case, it has been totally the opposite: the proponents have 
tried to lecture 6man about their own interpretation of the standard, 
and when faced with the response, essentially they did their best to 
intentially leave as much ambiguity in the spec as possible, to prepare 
the playground we are seeing. -- remember 6man shipped rfc2460bis with 
no clarification on the topic, and only incororated it as a result of 
IETF LC.

So we're now operating in a mode of having to craft text knowing that 
folks will willingly try to read from it what they want to read.

Similarly, I have submitted an errata (which fixes other issues with the 
EH-processing text).. but still pretending that the intent of RFC8200 is 
not clear.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Feb 2020 11:54:47 -0800

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

> Looking more closely at "The Devil's Paragraph", it may have a few problems..  Currently, it says:
>

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

---

From: Ron Bonica <[email-masked]>
Date: Fri, 28 Feb 2020 20:01:38 +0000

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

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

> "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

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 28 Feb 2020 20:43:45 +0000

> "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".

Which is the way I always interpreted the paragraph. The word "processed" I guess causes problems, although I'm not sure if they are real, or just people trying to get away with something.

For what it's worth, in this case where the "penultimate node" must do something strange, before the packet can be delivered to its intended destination, my own approach has always been to address the packet TO THE PENULTIMATE NODE, and then that router knows what to do with it. This violates nothing. Given that the "penultimate node" has to be specifically configured for this job anyway, it doesn't seem like such an approach limits flexibility or anything else. (Unless I missed something critically imnportant in the long thread.)

Bert

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Feb 2020 14:09:39 -0800

At Fri, 28 Feb 2020 20:01:38 +0000,

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

I'm happy to help (if you need it; I wouldn't insist I should be
involved in it).  Will send an offlist message to Ron separately.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Feb 2020 12:30:42 +1100

On Sat, 29 Feb 2020 at 07:44, Manfredi (US), Albert E
<[email-masked]> wrote:
> For what it's worth, in this case where the "penultimate node" must do something strange, before the packet can be delivered to its intended destination, my own approach has always been to address the packet TO THE PENULTIMATE NODE, and then that router knows what to do with it.

Yes.

I'm wondering what the value is of leaving the outer IPv6 tunnel
header there is after the SRHectomy.

If the outer IPv6 tunnel header (with a DA of the "penultimate node")
and the SRH and every other EH for the "penultimate node" were
processed and removed at that node, leaving the original inner IPv6
packet to be then sent on, we'd have an operation as old as the hills
known as "decapsulation".

> This violates nothing. Given that the "penultimate node" has to be specifically configured for this job anyway, it doesn't seem like such an approach limits flexibility or anything else. (Unless I missed something critically imnportant in the long thread.)
>
> Bert
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Sun, 1 Mar 2020 00:27:05 +0000

Mark,

The low order bits of the Destination Address in the outer IPv6 header represent an instruction. That instruction determines:

- which payload types will be processed and which will be dropped. For example, END.DT6 passes IPv6 payloads but drops IPv4
- how the payload will be processed after de-encapsulation. For example, END.DT6 can determine which IPv6 Virtual Routing and Forwarding table will be used to forward the packet.

This isn't entirely in keeping with RFC 4291, but at this point, what's one more variation from the IPv6 architecture.

                                                                 Ron

-----Original Message-----
From: Mark Smith <[email-masked]> 
Sent: Friday, February 28, 2020 8:31 PM
To: Manfredi (US), Albert E <[email-masked]>
Cc: Ron Bonica <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: RFC 8200: The Devil's Paragraph

Yes.

I'm wondering what the value is of leaving the outer IPv6 tunnel header there is after the SRHectomy.

If the outer IPv6 tunnel header (with a DA of the "penultimate node") and the SRH and every other EH for the "penultimate node" were processed and removed at that node, leaving the original inner IPv6 packet to be then sent on, we'd have an operation as old as the hills known as "decapsulation".

> This violates nothing. Given that the "penultimate node" has to be 
> specifically configured for this job anyway, it doesn't seem like such 
> an approach limits flexibility or anything else. (Unless I missed 
> something critically imnportant in the long thread.)
>
> Bert
>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!UfGZliRyo0nsRSEHcIvoN3rZGF6BYm5GpuPHjoeROAwByKWRzXDGC
> _wPPtcHcd0E$