On Tue, Aug 28, 2018 at 06:02:19PM -0700, Tom Herbert wrote:
> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options
> https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions
Thanks
> "NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the Hop-by-Hop
> Options header if explicitly configured to do so."
The industry does not fix these type of issues in old running code just
because someone else wants to deploy new code in new boxes somewhere
else along the path. That broken code will kill deployments for
a decade until it expires. Besides: Anybody who continues to just
evolve code from an old code basis is also unlikely to read, understand
and fix this piece in the evolution to rfc8200 too.
And there is not even a MUST in that text. And it does not talk about
granularity of inspection. Guess what triggered the first wave of bad
implementations killing onpath services: IPv4 router alert that
was punting ANY IPv4 router alert. Instead of at least only per-IPv4
protocol field in the router-alert.
Sorry. Will never fly in real deployment across Internet paths
if its based on this lame text in rfc8200. I stand by my suggestion.
There is also no consideration at all to rethink even expressing
the granularity of deciding whether or not to inspect.
> That allowance should be sufficient to resolve most of the the
> Hop-by-Hop being dropped problem. All that is being asked of
> middleboxes is that they ignore HBH instead of dropping the packet if
> they don't want to deal with them. That should not be difficult to
> implement. Hopefully, it's just a matter of evangelization and time to
> improve the situation.
Good luck. Where can i buy short sell options for anything
done on the existing hop-by-hop code point ?
Cheers
Toerless
> > See above: short of something that extreme, we should focus
> > on doing the right thing for new code but build it in
> > such a way that it is not blocked by bad existing old onpath code.
> >
> Agreed.
>
> Tom
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
