[spring] Re: [IPv6]C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

[Sander Steffann <[e-mail]>]

Hi Andrew,

> As I have repeatedly stated in spring and will state so again here.  In certain circumstances the use of C-SID breaks the checksums as relates to transit nodes.   RFC8200 lays out specific processing rules for upper-layer checksums, and expressly deals with scenarios where there is a routing header (Section 8.1.). RFC8200 in section 8.1. also provides for specific cases for UDP traffic that is encapsulated.
> 
> As the compression draft notes – there are systems that may be in the transit line that will fail to compute the checksums in the absence of a routing header.  This is in my view a violation of RFC8200. Now, there has been some discussion about if “middleware” boxes are bad etc – but that’s entirely beside the point, the fact is that the draft changes the data plane in such a way as to make it incompatible with existing deployments.  This brings this clearly into the domain of 6man (since the spring charter stated, explicitly, that modification to existing data planes that make them incompatible with existing deployments should be avoided)
> 
> I do not want to a start a debate about if what operators have deployed – either because they wished to deploy or were forced to deploy by regulation – is a good thing – operators are free to run their networks as they see fit.  However, when changing the ipv6 data plane to the point where a new draft makes said data plane incompatible with existent deployments, at the very least said draft should update the original draft (and in fact I would go further and argue that when changing something as fundamental as the upper-layer checksum, there should be an 8200bis to allow for this).
> 
> For far too long we have seen srv6 work violating underlying standards that are the domain of 6man – yet we still insist on claiming that srv6 is ipv6.  This has led to several issues, including the publication of a draft like draft-krishnam-6man-sids to clarify things, and a draft in spring to address significant security considerations with regards to srv6 etc.  The time has come to say, we cannot keep violating the base ipv6 standards unless we update the original standards – because every time this is allowed to happen, we drift further from the base standard and introduce the possibility of further calamity for operators.   As such – I do not believe that this document should be allowed to proceed in the absence of an update to RFC8200 and preferably a BIS document.  Breaking the checksum is simply not acceptable without the base standard explicitly dealing with the case in question (as RFC8200 does for other use cases)

I agree. Even though SRv6 is supposed to be used in a controlled environment, as we have tested some time ago it can work over the open internet. And coming from the ISP side: I don’t want to be the one who gets shouted at when SRv6 breaks in the future. Everything that claims to be IPv6 *MUST* comply with the relevant IPv6 RFCs.

Cheers,
Sander