Re: END SID Without SRH

[Ole Troan <[e-mail]>]

Mark,

[snip]

> pWhat's a "regular IPv6 destination"?
> 
> It would need to be explicitly defined now, because it has been implicit.
> 
> It's one thing to encode function or service destinations in IPv6
> addresses. That's is done and supported in IPv6 with anycast and
> multicast.
> 
> When the packet arrives at that function or service destination
> encoded in an anycast or multicast address, it is processed as per the
> instructions encoded in the chain of EH and upper layer headers in the
> packet. For example, even though the use of TCP with multicast doesn't
> make sense, once the multicast packet holding the TCP segment has
> arrived at a node with the multicast address, the node is to hand the
> TCP segment to the TCP module.
> 
> It's quite a different thing to encode packet processing in the
> destination address that contradicts or ignores the instructions
> encoded in the chain of EH and upper layer headers. I think this might
> be a more significant change to the IPv6 packet processing model and
> operation than we realise.
> 
> RFC 8200 is very clear and explicit on multiple occasions about
> following the processing encoded in the EH chain and upper layer
> headers when the packet arrives at the destination device that holds
> the matching DA:

I think that' a way too literal interpretation of 8200.

Especially in the context of routers.
A remote node cannot expect that any combination of the local nodes's destination address and header chain will be processed.
A router will not process your protocol 89 packet on any DA. In the VPP MAP-E implementation, the BR address is a "service address", and will drop anything that isn't protocol 4 (as well as any packet with extension header).

Best regards,
Ole







> 
> 4.  IPv6 Extension Headers
> 
> ...
> 
> "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." (For context for the next two quotes.)
> 
> ...
> 
> "At the destination node, normal demultiplexing on the Next Header
>   field of the IPv6 header invokes the module to process the first
>   extension header, or the upper-layer header if no extension header is
>   present.  The contents and semantics of each extension header
>   determine whether or not to proceed to the next header. ***Therefore,
>   extension headers must be processed strictly in the order they appear
>   in the packet***; a receiver must not, for example, scan through a
>   packet looking for a particular kind of extension header and process
>   that header prior to processing all preceding ones."
> 
> ...
> 
> 4.1.  Extension Header Order
> 
> ...
> 
>  "IPv6 nodes must accept and attempt to process extension headers in
>   any order and occurring any number of times in the same packet,
>   except for the Hop-by-Hop Options header, which is restricted to
>   appear immediately after an IPv6 header only.  Nonetheless, it is
>   strongly advised that sources of IPv6 packets adhere to the above
>   recommended order until and unless subsequent specifications revise
>   that recommendation."
> 
> ...
> 
> Regards,
> Mark.
> 
> 
> 
>> Thanks
>> --
>> ===============================================
>> David Farmer               Email:[e-mail]
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------