Subject: Removal of destination options that precede a routing header

From: James Guichard <[email-masked]>
Date: Tue, 26 May 2020 13:41:18 +0000

Dear 6man,

I am trying to determine how destination options that precede a routing header are supposed to be removed. RFC8200 is very unclear on this point although the text infers what will happen without saying so specifically (at least I don't see any text).

For destination options after a routing header the process seems clear if not actually stated. RFC8200 has this to say in section 4.1:

      note 3: for options to be processed only by the final destination
              of the packet.

Note 3 is for destination options after a routing header. As such the destination option is processed after the routing header and therefore the router is able to determine from the SRH that it is the final destination as segments left = 0. Presumably an implementation would at this point remove the routing header and the destination options and send the packet on its merry way.

For destination options preceding a routing header RFC8200 has this to say in section 4.1:

note 1: for options to be processed by the first destination that
              appears in the IPv6 Destination Address field plus
              subsequent destinations listed in the Routing header.

I can infer from the above that the destination option gets processed by each node in the routing header because the DA of the IPv6 packet at each hop is taken from the routing header so the router processes the destination option because it is addressed to it. At some point the packet is addressed to the last node in the routing header; upon receipt of a packet at that node the destination option is processed and then the routing header - the routing header is presumably now removed as segments left = 0 *but* the destination option was already processed and so the packet is sent on its merry way but this time *with the destination option that precedes the routing header*. If this is the case, then you have just leaked information contained within the destination option outside of the limited domain e.g. this almost certainly happens at a PE router.

I would appreciate clarification on this.

Thanks!

Jim

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 16:23:25 +0200

Hi,

> Note 3 is for destination options after a routing header. As such the destination option is processed after the routing header and therefore the router is able to determine from the SRH that it is…

The header aren't removed. When there are no segments left the destination address is that of the final destination, which will get the full packet as sent by the sender with all the headers intact.

Cheers,
Sander

---

From: Jim Guichard <[email-masked]>
Date: Tue, 26 May 2020 10:27:40 -0400

I’m not so sure about that as the original packet is encapsulated in an
outer IPv6 header.

On Tue, May 26, 2020 at 10:24 AM Sander Steffann <[email-masked]> wrote:

> Hi,
>
> > Note 3 is for destination options after a routing header. As such the
> destination option is processed after the routing header and therefore the
> router is able to determine from the SRH that it is the final destination
> as segments left = 0. Presumably an implementation would at this point
> remove the routing header and the destination options and send the packet
> on its merry way.
>
> The header aren't removed. When there are no segments left the destination
> address is that of the final destination, which will get the full packet as
> sent by the sender with all the headers intact.
>
> Cheers,
> Sander
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 16:34:21 +0200

Hi,

> I’m not so sure about that as the original packet is encapsulated in an outer IPv6 header.

Ah, an extra layer :)

In that case the final destination is the tunnel endpoint and wouldn't just remove the destination options and routing headers, but would remove the whole encapsulation. So the DOH before the RH would be processed by every router along the tunnel/RH path, the DOH after the RH would be processed by the final router on the tunnel/RH path, at which the whole encapsulation would be removed.

Cheers,
Sander

---

From: James Guichard <[email-masked]>
Date: Tue, 26 May 2020 15:20:15 +0000

Hi Sander,

Thank you for the clarification. 

Dare I say It as I don’t want to start another long and exhausting email thread 😉 but it is kind of interesting as knowing this helps to clarify that when RFC 8200 is talking about the node identified in the destination address field of the IPv6 header then said node is able to process, delete and insert extension headers according to the text; in order to process DOH before a RH then that node must be the router as identified in the DA of the incoming packet and not the ultimate destination as previously argued in another thread. 

Jim
-----Original Message-----
From: Sander Steffann <[email-masked]> 
Sent: Tuesday, May 26, 2020 10:34 AM
To: Jim Guichard <[email-masked]>
Cc: 6man <[email-masked]>; James Guichard <[email-masked]>
Subject: Re: Removal of destination options that precede a routing header

Hi,

Ah, an extra layer :)

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 18:04:07 +0200

Hi,

> Dare I say It as I don’t want to start another long and exhausting email thread 😉 but it is kind of interesting as knowing this helps to clarify that when RFC 8200 is talking about the node identif…

I do interpret the text in a different way, but I agree that the current text can be interpreted like you describe as well. I'm not sure that was the intention, but that is what it is, and second guessing intention afterwards is rather pointless, so… :)

I do think that header insertion/deletion between the source and final destination can be harmful, but let's resolve that by looking forward to what we actually want. Looking back at 8200 and disagreeing on what it says isn't very productive. We already know we disagree. Let's provide better guidance to future protocol designers.

Cheers,
Sander