RE: RFC 8200: The Devil's Paragraph

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

Juniper Business Use Only

-----Original Message-----
From: Mark Smith <markzzzsmith@gmail.com> 
Sent: Friday, February 28, 2020 8:31 PM
To: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>
Cc: Ron Bonica <rbonica@juniper.net>; 6man WG <ipv6@ietf.org>
Subject: Re: RFC 8200: The Devil's Paragraph

On Sat, 29 Feb 2020 at 07:44, Manfredi (US), Albert E <albert.e.manfredi@boeing.com> wrote:
>
> Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
>
> > "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.

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
> ipv6@ietf.org
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!UfGZliRyo0nsRSEHcIvoN3rZGF6BYm5GpuPHjoeROAwByKWRzXDGC
> _wPPtcHcd0E$
> --------------------------------------------------------------------