Re: END SID Without SRH

[Mark Smith <[e-mail]>]

On Fri, 14 Jun 2019 at 02:45, David Farmer <[e-mail]> wrote:
>
>

<snip>

>> >
>>
>> Thanks.   I don’t see any issue here, the document is appropriately scoped.
>
>
> It might be nice if there was a clear simple statement someplace to the effect, "IPv6 addresses that are used for SIDs SHOULD NOT also be used and a regular IPv6 destination."
>

What'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:

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