Re: END SID Without SRH

[Tom Herbert <[e-mail]>]

On Fri, Jun 14, 2019 at 3:19 AM Mark Smith <[e-mail]> wrote:
>
> Hi Ole,
>
> On Fri, 14 Jun 2019 at 16:52, Ole Troan <[e-mail]> wrote:
> >
> > Mark,
> >
> > [snip]
> >
> > > pWhat's a "regular IPv6 destination"?
> > >
>
> <snip>
>
> > > 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.
> >
>
> I think it is the "right amount" of literal when you use RFC 8200's
> definitions of 'router' and 'host'.
>
> > Especially in the context of routers.
>
> Router as a device, or a router as a function?
>
> RFC 8200 definitions of a router and a host seem to me to be entirely
> functional.
>
>  router       a node that forwards IPv6 packets not explicitly
>                 addressed to itself.
>
> host         any node that is not a router.
>
>
> A typical router as a device implements the RFC 8200 router function
> in its forwarding plane, and the RFC 8200 host function in its control
> plane.
>
> > A remote node cannot expect that any combination of the local nodes's destination address and header chain will be processed.
>
> I agree.
>
> I think it is clear what is supposed to happen when a packet is
> received that can't be processed according to the EH / transport layer
> header chain:
>
> - the packet gets dropped
>
> - a (possibly rate limited) ICMPv6 error message is sent back to the
> source stating the drop cause
>
> There isn't supposed to be "the packet is still processed rather than
> dropped, and differently to how the packet's sender specified it to be
> processed."
>
> > A router will not process your protocol 89 packet on any DA.
>
> Agree.
>
> First thing that needs to match is the DA of the packet against the
> router (device (RFC 8200 router & host))'s local addresses or the
> device's processes' multicast addresses.
>
> Once that match occurs, then the packet gets handed up the local stack
> to the OSPF process, if it exists. If it doesn't, "Parameter Problem,
> Unrecognized Next Header type encountered".

Mark,

As understand it, a host with SID addresses only recognize IP in IP
encapsulation and no other upper layer protocols, so other protocols
are unrecognized. If such a host drops packets with unrecognized next
header, e.g. TCP, and sends "Parameter Problem, Unrecognized Next
Header type encountered" that is compliant with RFC8200.

Whether this is desirable behavior is arguable. For instance, I'd
expect the first thing that a user might do when they are see packets
with a segment list failing to be delivered is start pinging addresses
in the segment list. Getting an ICMP error instead of just an ICMP
Echo Reply from a destination doesn't seem particularly helpful to me.

Tom

>
> This is IPv6 host processing (because of packet arriving at device
> holding the matching DA) where the host doesn't support the protocol
> in the packet.
>
> >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).
> >
>
> And that is and would be the expected behaviour. It doesn't understand
> it so it drops it and may send an ICMPv6 error message.
>
> The ambiguity and I think non-compliance with RFC 8200 is when
> dropping isn't occurring, and how to process the packet is singularly
> encoded in the DA address. This is instead of following what is
> explicitly encoded in the following EHs and transport layer headers.
> This is contrary to IPv6 host processing of DA match -> EH processing
> -> Transport layer -> Application Layer packet processing.
>
> (I started down this path a few years ago by thinking about the
> scenario of buying a router (device) from a router vendor, and then
> running it as a BGP route reflector or server that isn't ever in the
> packet forwarding path. Is it still a "router", or is it now a host?
> Per RFC 8200, not a router, only a host, even if it still looks like a
> router (device) with a router vendor's logo on it).
>
> Best regards,
> Mark.
>
> > 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
> > > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------