Re: END SID Without SRH

[Mark Smith <[e-mail]>]

On Wed., 12 Jun. 2019, 17:29 Ole Troan, <[e-mail]> wrote:

> > Per RFC 8200's definition of host and router, the packet has arrived at
> the destination host, so the TCP segment should be handed up to the TCP
> layer for processing, and if there is no matching TCP port, a TCP reset is
> sent back to the source.
> >
> > I don't think any other processing would be compliant with RFC 8200, and
> operationally it would be very confusing - the value in the packet's
> destination address field isn't being used by a device holding that address
> as a destination address.
>
> Traditionally an address identifies an interface (or set of interfaces).
> But we use addresses in many different ways. Ranging from NAT64 IPv6
> prefixes that represent the IPv4 Internet to IPv6 addresses being used to
> represent data blocks in a video.
> In userland networking one could imagine an IPv6 address representing an
> individual TCP application.
>

Certainly. The way anycast is commonly used is an example. Multicast is too
because groups in many cases represent applications or services rather than
just the destination nodes.

The thing is that in all (compliant) cases, the destination address
identifies the point where forwarding, using the IPv6 fixed header, towards
the DA address stops, and next layer up processing starts.

So in Ron's example (packet with an END SID DA, no extension headers at
all, NH of TCP), if the next header in the packet is a TCP header when it
arrives at the DA that is the END SID, then TCP processing is what happens
to the packet next.

If SR is saying it doesn't, then SR is describing processing rules that
don't comply with RFC 8200, because SR would be ignoring the value in the
packet's Next Header field.


> My understanding (which might be flawed, mind you) is that the SID is an
> "forwarding instruction" or represents a service. It is not the address of
> an interface point of attachment.


I'd generally describe these types of addresses as routeable service or
function addresses.

They're not unicast addresses because it is valid to have multiple devices
in a network have them.

They're not (normally) multicast addresses, because packets aren't intended
to be duplicated at various junctions within the network.

I think they're anycast addresses or very close to anycast addresses.
Identify a service, function or application layer protocol within the
address, valid to exist on one or more nodes in the network, but only to be
delivered to one of them.

Regards,
Mark.


>
> Ole