Re: END SID Without SRH

[Mark Smith <[e-mail]>]

Oops, not quite complete email.

On Fri, 14 Jun 2019 at 09:36, Mark Smith <[e-mail]> wrote:
>
> On Thu, 13 Jun 2019 at 17:25, Darren Dukes (ddukes) <[e-mail]> wrote:
> >
> > Mark.
> >
> > You remember your SIDs in your SR domain come from a SID block you created, S/s (see section 5.1) and this destination address falls within that space.
> >
>
> Humans really aren't all that good at remembering numbers. We even
> make errors when
>

copying numbers from a from one place to another, seconds apart. Typos
in IP addresses has been a very common cause of faults in my
experience, and they're fundamentally human memory failures.

We also forget we haven't completed an email when we push 'send' it
the next day!


> If IPv6 addresses are going to have special meaning and unconventional
> RFC 8200 processing, they should come from a special purpose address
> space - not one that is from within any of the the existing unicast
> address spaces.
>
> That would make it possible for if tools like Wireshark could have
> know of a well known SID prefix so that they can identify and mark SR
> packets. It reduces the operator's mental load while troubleshooting.
> (Having
>
> There are a lot of defined reserved IPv6 and IPv4 prefixes, for uses
> that are more obscure than I'd think SR is intended to be e.g.
> 198.18.0.0/15 for Benchmarking, or 2001::/32 TEREDO.
>
>
> I still think mandating the SRH in all to be SR processed packets is
> better, even with a common well-known IANA assigned SID specific IPv6
> prefix. It is explicit, rather than implicit in the packet's IPv6
> addresses, and leverages existing mechanisms to deal with received
> packet errors (i.e., ICMPv6 Parameter Problem,
>

Code 0 - Erroneous header field encountered or more specific Code 2 -
Unrecognized IPv6 option encountered.


>
> > You notice the destination sending an ICMP parameter problem error with a code that says “SR Upper-layer Header Error”.
> >
>
> What if the device receiving the packet isn't SR capable or aware? It
> will try to pass the packet to up to the TCP stack and process it. If
> it generates a TCP RESET, it'll send the TCP RESET back to the SR
> aware node than sent the packet in the first place.
>
> Would that receiving SR node know what to do with a TCP RESET (or a
> UDP triggered ICMPv6 Destination Unreachable Port Unreachable?) from
> what is supposed to be an SR node?
>
> I don't see any advice to only use ULA address space for SIDs
> (assuming an IANA reserved prefix isn't chose), so with SIDs that fall
> from within the GUA unicast address space, the likelihood of packets
> leaking to non-SR aware nodes increases.
>
> Regards,
> Mark.
>
<snip>