>As far as I know, but I'm trying to stay away from the actual proposals and ar >gue this generally, no-one is proposing to update the RFC8200 header insertion > text. >What people are proposing are for specific domains. And given that, I believe >people need to argue the technical merits of those specific proposals. >As opposed to throwing the "law book" around.
Maybe I missed it somewhere, but why is it so hard to publish an RFC that updates RFC 8200? Is this a process failure that we cannot update an Internet Standard? One thing is that firewalls and other middle boxes routinely violate RFC 8200 by looking beyond the IPv6 header. It is bad to have specs that do not reflect reality. I'm not aware of wide spread middle boxs that modify IPv6 packets, though there is some amount of NAT66. In general, inserting new EHs is bad for the various reasons brought up in the past. However, SR is a special case. And there is no reason we can't make an exception for a specific situation. However, somebody reading the IPv6 specs should not have an unexpected surprise of reading RFC 8200 and then later finding that some nodes violate it due to a completely unrelated RFC. It is not that much work to add a section that officially updates RFC 8200. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
