Re: END SID Without SRH

On Wed, Jun 12, 2019 at 2:08 AM Ole Troan <otroan@employees.org> wrote:
>
> 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.
>
Ole,

A host can always drop packets it receives and still claim
correctness. The problem here is the new ICMP message that can be sent
in response to a plain IPv6 packet. The ICMP error is segment routing
specific, however it can be sent to hosts that do not support segment
routing. The error is at best confusing to those hosts as well as any
legacy network monitoring that captures ICMP errors.

An alternative is to either just drop the packet without sending the
error, or maybe send an existing error-- possibly Parameter Problem
for Unrecognized Nexthdr, or Destination Unreachable with code 1 or 4.

One nit, a request for a new ICMP Parameter Problem code should be
mentioned in the IANA considerations section.

Tom

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------