Re: END SID Without SRH

[Mark Smith <[e-mail]>]

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

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