Brian E Carpenter wrote on 03/10/2021 05:13:
Does that harm the Internet, even if it leaks? It might disappoint the sender, as any sender of a bogus packet is disappointed, but apart from that, who is damaged?
in the smaller sense, limited domain leakage will happen and if the destination addresses of packets are routinely changed, then this provides the opportunity for potentially serious data leakage. It would be a good idea to note this in the security section of the draft.
It would be a mistake, I think, to dismiss this as a configuration issue and then claim that the ietf is not in the business of telling people not to make mistakes. It's more a case of an existing failsafe mechanism being removed entirely. This is a poor idea from both an engineering design point of view and in multiple senses from the point of view of the principle of least astonishment.
In the bigger scheme of things, it's becoming difficult to reconcile whether srv6 is strictly compatible with ipv6. It's understandable to want to declare the existence of a limited domain, throw everything in there, apply a different set of rules and claim that it's all ok, but there is now a wedge firmly jammed in between rfc8200 and srv6, which is being prised open further by drafts like this which introduce more, and more substantial semantic incompatibilities.
Rather than concentrating on this draft, it would be a better idea for the ietf to ask where does this path lead that we are going down.
There's no issue developing a protocol like SRv6 at the ietf, but if drafts of this sort are progressed as-is, it looks likely that that at a certain point, the differences between SRv6 and rfc8200 will be large enough that it's going to cause pain points for them to share a common code point of 6 in the IANA IP version number registry. This would be in noone's benefit.
Nick _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
