Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

[Tom Herbert <[e-mail]>]

On Thu, Oct 19, 2017 at 5:20 PM, Brian E Carpenter <
[e-mail]> wrote:

> On 20/10/2017 10:23, Toerless Eckert wrote:
> > On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote:
> >>> Instead of punting them because of presence of
> >>> RSVP-router-alert option. And of course you can blame IP multicast:
> every router
> >>> started to punt router-alert because of MLD (and of course us
> multicast folks
> >>> missed the chance to fix this in MLDv2 because it only tried to
> duplicate IGMPv3),
> >>> but no RFC told developers to punt because of router-alert + value in
> the router alert.
> >>> AFAIK, the same applies to hop-by-hop option in general. Alas, even
> rfc7045 did not discuss
> >>> this issue.
> >>>
> >>> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow
> down packets
> >>> because of the presence of this mechanism, but only because of
> presence of
> >>> (mechanism,value) where value is intended to be supported by device.
> If the device
> >>> can not do this, then it MUST IGNORE this mechanism and forward
> packets with the mechanism
> >>> as if the option was not present.
> >>
> >> That's pretty much what RFC7045/RC8200 say, except that they
> >> say it as a warning.
> >
> > It does not analyze the fact that the existing hop-by-hop option (and
> options
> > carried via it like router alert) are burned because existing router
> imple entations
> > punt packets with hop-by-hop options even though they do ultimately not
> > need to process the packets (hop by hop option they don't do or
> router-alert
> > protocol they don't do).
>
> We discussed that before agreeing on the words in 7045, which were +-
> adopted
> in 8200.
>
> > And IMHO the existing hop-by-hop option is burned because the
> architecture
> > RFCs did not well enough express in MUST statements that you must never
> > speed down packets because of hop-by-hop/router-alert unless you really
> know
> > you will support/do-something with that option. And that you achieve
> this eg.:
> > by filtering/punting based on option/protocol. And that you can NOT do
> anything else.
>
> The protocol design really shouldn't talk about implementation choices
> in routers and the fact that FPGA people hate the IPv6 extension header
> design like the plague, which has led to broken implementations. In 1994
> there weren't any 'fast path' router designs, iirc, and the design simply
> didn't consider this problem to be a problem. So the assumption was that
> the forwarder CPU would pass on the whole header, and would only branch
> off the main code path if it saw a HbH header. I know we're 20 years
> later, but logically that hasn't changed. The problem is that many vendors
> didn't implement it; they sacrificed correctness for speed.
>
> > This is also the root cause why in our analysis a hacky extraction by
> > eg: STUN signature inside UDP is a lot safer for existing networks than
> relying
> > on any hop-by-hop option. Badly standardized, badly implemented.
>
> We agree on badly implemented ;-). IPv4 Options are badly implemented, too.
>
> >> As Ole said - within a domain where hop-by-hop option X is
> >> supported, you can reasonably expect that all routers process X.
> >
> > Ask an enterprise operator with 10 different router models from 3
> vendors ;-)
>
> If they want to use X they need to buy routers that support X.
>
> Or at least buy routers that ignore X instead of unilaterally dropping
packets that contain X (be liberal in what you receive!).