C. M. Heard wrote on 23/11/2018 16:20:
while promoting a **/_default deny_/** policy with respect to unknown
extension headers, experimental extension headers, and experimental
options. If every transit router followed that advice, it would be
impossible to transmit packets containing these things across the open
Internet. It is especially egregious to dispense that advice for
unknown extension headers, since that would severely impede deployment
of any new extension headers OR any new transport protocols in the open
Internet (as the document itself notes, unknown extension headers are
indistinguishable from unknown upper-layer protocol headers). This part
of the document's advice does nothing to improve the situation reported
in RFC 7872; if anything, it makes the situation worse. It certainly
will not make the Internet work better.
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. We can argue endlessly at the IETF about the pros and
cons of this from a protocol development and management point of view
but at the end of the day, transit operators have networks to run, and
there is a jarring disparity between data-plane forwarding speed and
control-plane processing capacity. If you expect one to bleed into the
other, something needs to give. This is often going to be
silicon-specific; what is slow-pathed on one platform may not be
slow-pathed on another, so generalised statements are difficult in this
situation.
Transit operators are going to make their own decisions about what to do
about packet filtering, and take any specific recommendation in an ID
like this with a grain of salt. In that respect, this document needs to
be seen as a store of information to help people make informed decisions
about what to do rather than being a prescriptive list.
Nick
