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 _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
