Hi, Tom, On Thu, 2021-04-08 at 08:00 -0700, Tom Herbert wrote: > On Thu, Apr 8, 2021 at 7:33 AM Timothy J. Salo <salo@xxxxxxxxxxx> > wrote: > > On 4/8/2021 9:21 AM, Tom Herbert wrote: > > > [...] > > > Sure, tell me, as a host stack developer, what at reasonable > > > minimum > > > length is for an IP header chain and I'll fix the packets I'm > > > sending > > > so that the operators don't need to be bothered with this. > > > > No one really knows. > > That presumes there is no data, and that it is impossible to get the > data. I don't believe that is true. For instance, RFC7872 does show > that between 80-90% of eight byte Destination Options make it through > the Internet. That's a pretty high percentage, so that suggests that > a > minimal recommendation for EH length could be at least eight. You seem to keep misinterpreting things: 1) This document does not make recommendations. If you want recommendations, please do submit a draft. (I will note that RFC7112 at the time wanted to restrict the IPv6 header chain to 1280 bytes, and even *that* didn't fly. -- SO, good luck with that project....) 2) As noted by many, many times, the effect of e.g. EH length on processing describes on so many factors (vendor, model, deployment, etc.) that trying to come up with a "minimal recommendation" is simply guesswork. 3) There's no reason to believe that packets that are currently let through do not or could not cause issues. 4) And no, I don't think that you can expect an operator to make a survey of every single device they use, and try to find out what's the ipv6 header chain length that wouldn't screw the network, and work hard to support it. As noted before, you're going to have a hard time explaining your CEO or manager why you've decided to unnecessarily accept risk that you do not need to accept. JUst as a data point, this was posted yesterday: https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html > > > Moreover, there is no reason to believe that the > > value won't change in the future. Furthermore, this is well beyond > > the > > control of the IETF: it is driven by decisions made by router > > vendors > > and ISPs. > > > The ADs can correct me if I'm wrong, but I believe it is within the > scope of IETF to make recommendations and suggest best practices > concerning the use of standard protocols and those recommendations > can and should take operational data into account. Indeed. But this document is not a recommendation, and was never meant to. Isn't the Disclaimer clear enough on this point? Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
