Doug Barton wrote: > >>... > >> I agree with Randy, providing guidance on this topic will be very > >> helpful, and BCP is the right category. > >> > >> As for what the number should be, if 256 is in the 80th percentile or > >> higher of Warren's survey, that should be fine. A few vendors who are > >> examining less than that now may be encouraged to increase up to 256 > >> knowing that they have a reasonable upper bound to shoot for, as > > opposed > >> to an arbitrarily large number that varies from implementation to > >> implementation. > > > > I would like to check with current hardware designers that 256 is a > > good number for them, as opposed to 240, say. > > Others (more knowledgeable than I) had already made that point, but for > the record, yes, we should check with the hardware folks on this. >
While guidance is useful to establish a consistent-behavior baseline across vendors and deployments, care must be taken to avoid the trap of precluding innovation and evolution. Well-meaning limits based on current hardware capabilities will become doctrine over time, and changing values to allow something new will become virtually impossible, as the utility of the new thing without a significant deployment base will never outdo the inertia of established practice. Particularly when there is a perception that the established practice has some 'security' value. I have no issue with requiring L4 in the first fragment, though what constitutes a fragment needs to change. It is long past time that 1500B packets should have been removed as a limiting factor, and if/when we ever do get to something larger, restricting header chains to 256B will look absurd. BCP -> YES Hard byte count -> NO (make that hell no) Focus on the real operational requirement (firewall functionality), then make sure that the constraint automatically tracks evolution in firewall functionality. Getting there leads to L4 in the first fragment, and anything else leads to artificial constraints that will need to be redone, if that is even possible. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
