On 8/9/19 00:32, Ole Troan wrote: > Fernando, > >>> The takeaway I attempted to highlight is that there is in fact >>> agreement between 6man and spring on how to proceed, and we are >>> proceeding as agreed to work on the relevant documents. >> >> I don't really know what the agreement is, other than the implicit >> agreement that if you're considering violating an IPv6 standard, >> you should come to 6man and do a Std Track document that updates >> the relevant standard... > > if there ever is a corner case were header insertion can be done > safely, and the issues it creates mitigated, then that should > certainly not result in an update to the general rule in 8200.
1) As noted in the discussion, there's nothing that you can do with EH-insertion that you cannot do with encap/decap. I don't see enough motivation for an update of this sort -- other than "we want to save 40 bytes". In any case, I repeat what many others have already said: It's on us to find problems on EH-insertion for it to not move forward. There should first be a strong argument made in favor of it. 2) You cannot "mitigate" the implications of EH-insertion at the protocol level (attribution of error messages, MTU issues...). The only possible mitigations are operational, and those quite often fail. 3) While RFC8200 does not employ RFC2119 language (chair's call, not mine), the statement in RFC8200 is pretty much a MUST. You do need to update RFC8200. A reader of RFC8200 should now that there are scenarios in which EH insertion is indeed allowed. Otherwise you end up with two specs (IPv6 and SRv6) that contradict with each other. 4) I expect that, as co-chair, you'd agree with me that allowing EH insertion in IPv6 is a major modification/addition. According to our charter, we don't seem allowed to do that: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. I'm quite surprised that a few years ago many of you guys wanted to essentially freeze most work on IPv6, and now you're so open to such a major and fundamental change. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring