On Mon, Nov 26, 2018 at 04:21:06AM -0300, Fernando Gont wrote: > Christian. > > On 25/11/18 17:40, Christian Huitema wrote: > [.....] > > > Nick made that point, probably unintentionally, when he wrote that > > "transit operators would generally take the view that any data-plane > > packet which needs to be put through a slow path will be rate limited up > > to 100% loss". Last I checked, data plane processing is implemented in > > specialized components that are designed for speed. I am quite concerned > > that filtering recommendations made by the IETF will end up deeply > > embedded in the hardware of at least some routers, and that changing > > them in the future would be quite hard. That's pretty much the recipe > > for ossification. > > PLease take a look at the advice: it essentially argues "pass everything > that has been stadardizez and that will not cause you pain". And, again, How is this better than "pass everything that will not cause you pain"? Why should the transit care if something is standardized or just an experiment running over the internet? > this is in line with RFC7045. Compare that with what we have in the > real world (RFC7872), and you'll probably agree that if folks were to > implement this advice, it would be a *huge* improvement -- at the time > of this writing you cannot even use ipsec reliably on the Internet(!). One can agree that folks implementing this advice would be an improvement over the current state of affairs, without agreeing that the IETF should advocate against using our protocols as they were designed. > > > > The IPv6 header contains a > > "payload type" field, that may legitimately contain any of the payload > > types defined in the IANA registry of protocol numbers > > (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). > > Some of those payload types are flagged as IPv6 extension header types > > and listed in the corresponding registry > > (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing > > EH without discussing the other payload types seems bizarre. Do the > > reasons for blocking for the experimental payload type 253 also apply > > to, for example, the UDP Lite payload type? What about discussing ESP > > and not discussing L2TP or MANET? > > This document discusses EHs. THe considerations for filtering on upper > payloads are rather different, and normally depend on the upper protocol > details. (e.g. TCP ports). Perhaps I am confused, but IIUC this document discusses values placed in the IPv6 "Next Header" field, some of which are EHs and some of which are not. Values not recognized to the processing entity may be EHs or may be "next protocol"s, and if the value is not recognized there is no way to know which is the case. Ergo, filtering out unknown values that might be EHs is also filtering out unknown next-protocols, which seems really bad for the future flexibility of the internet. -Ben
