Re: END SID Without SRH

[Ole Troan <[e-mail]>]

Mark,

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

Take my example of user-land networking, where I give my BGP application an IPv6 address.
That packet is forwarded to the application itself (let's assume it has a TCP library implementation). 
It doesn't really make any sense to give that packet to the host's TCP stack. It wouldn't know what to do with it.
I _think_ the same thing applies with SIDs.

Best regards,
Ole

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