Re: END SID Without SRH

[Mark Smith <[e-mail]>]

On Fri, 14 Jun 2019 at 21:06, Ole Troan <[e-mail]> wrote:
>
> Mark,
>
> > 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.
>
> OK, then I don't understand.
> Would you mind spoon feeding me. How is SRH processing different?
>

Because in Ron's original example packet, there was not SRH i.e. a
vanilla IPv6 packet, no SRH, no other EH's, and a directly following
TCP header and payload.

So the packet's DA SR semantics encoded a packet processing meaning
that was contradicting what the packet's IPv6's header following TCP
header said to do.

I'm not against the idea of an IPv6 DA encoding some function or
service meaning or semantics.

It is when the DA is encoding processing on a packet that is contrary
to what the rest of the packet says to the do that I think would cause
a lot of problems. (I've had some bad experiences with people placing
semantic meaning on values that they shouldn't have - 0.0.0.0 is still
a valid although deprecated broadcast address, not a "we can switch on
debugging for our layer 2 device IP address" -
http://lists.ausnog.net/pipermail/ausnog/2017-July/039402.html - (if
they wanted to have a magic address for debugging, they should have
chosen a magic layer 2 address within their own address space for
that)).

Best regards,
Mark.

> Best regards,
> Ole