On Mon, Dec 2, 2024 at 9:05 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote: > > On 01/12/2024 21:36, Tom Herbert wrote: > > But my bigger issue with this review is the repeated insinuation that > this draft would somehow ossify IPv6 or impede evolution of IPv6 or > transports. I believe this characterization is wholly unfounded, > unfair, and incorrect. Please comment on this. And if you do want to > argue that *this* draft somehow impedes IPv6 or Transport layer > evolution then please give specific examples; as I mentioned just > expecting everyone to support unlimited extensibility isn't feasible > (and note that I gave an example of the cost of unlimited > extensibility in a DoS attack). > > Tom > > Personally, I do like the principle of setting some minimum expectations to increase deployability of extension headers. > > I see some feedback on my use of the word "ossify": by which I mean the possibility that this I-D could cause header formats to become fixed and then unable to change the format. > > For me, fixing minimum values at endpoints is likely to be changeable in future, but deploying limits in a network device less so, and much less so where exceeding these result in packet discard, this included the new proposal for limits for “intermediate nodes”. There are other comments. Gorry, The draft in NO WAY recommends that routers drop packets that exceed limits-- this requirements are very clear: "If a limit is exceeded, routers SHOULD still forward the packet and SHOULD NOT drop packets because a limit is exceeded. And for every applicable limit you'll find boilerplate text "It is NOT RECOMMENDED that a router discards the packet because the limit is exceeded, however if it does then..." This draft isn't even introducing the concept that routers can drop packets for non-conformant reasons, that is a pre-existing condition. The high drop rates of extension headers on the Internet is because routers or intermediate nodes dropping packets , end hosts! Now we could say that routers MUST NOT drop packets if a limit is exceeded, but IMO that would be futile-- vendors aren't going to line up to enthusiastically fix the problem on the basis that IETF decided it's a MUST. What we can do however, is advise the router vendors that they really shouldn't drop packets, but if they really feel they need to then we can at least give them guidance on the best way to do that with minimal adverse impact-- that is exactly what this draft aims to do. > > Please don’t assume as a reviewer whether I would love or hate to see the final publication of this document. The review notes things seen as needing attention and things needed to be stated clearly and consistently beyond doubt, so choice of wording in the I-D matters. I’d be happy to look again at a new revision, if you plan one. I believe that requirements on routers about dropping packets when limits are exceeded are about as clear as I can make them. If you think that is not the case then please suggest alternate text. Tom > > Best wishes, > > Gorry > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
