On Fri, Nov 22, 2024 at 11:57 AM John Levine via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: John Levine > Review result: Ready with Nits > > For someone not steeped in IPv6 lore, reading this draft feels like arriving > during Act Three of a five-act opera. The plot so far, I believe, is that IPv6 > allows long chains of extension headers which can cause processing problems > that have led some routers to disallow them altogether. Also, large headers in > fixed size fast path memory can keep routers from seeing application and port > numbers that some rules use. Hence this document proposes limits on header size > and ordering that we hope everyone can live with. Hi John, Thanks for thoughtful review! I especially like how you compare IPv6 to five-act opera! :-) > > The motivation is clear enough, the limits are explained in an understandable > way, and as far as I can tell they are all reasonable. > > I understand that the proposed status of this draft was recently changed from > BCP to Informational on the sensible basis that there isn't enough practice yet > to know what is best. Nonetheless it still contains RFC 2119 requirements > language, which seems overly prescriptive for a document that describes what is > so far a best guess. I think that all the upper case words can be turned into > lower case and still make sense, while not offering a premature promise that if > you do what they say, everyone will accept your traffic. We hope they do, but > that will presumably be revealed in Act Four. I'll make some points in reply. First, there is precedent for using normative language in an Informational I-D like this. RFC6434 was an Informational draft that set similar operational requirements as the eh-limits draft, that RFC was obsoleted by RFC8504 which is a BCP. I think the eh-limits should follow the same progression. Second, almost all the requirements in the draft are MAY (the use and enforcement of limits should be optional). The exception is in Section 5 where there are three MUSTs pertaining to router requirements. These set basic requirements that routers must be prepared to forward packets that contain extension headers of some expected length. The problem this addresses is that some routers require access to the transport layer and if it's too deep in a packet they may arbitrarily drop the packet (even in the case they don't actually process the extension headers). We set this minimal size of extension headers to be 64 bytes, which is actually quite generous compared to RFC8200 which doesn't have any provisions for routers to drop packets like this. Tom . -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
