Re: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

[Fernando Gont <[e-mail]>]

On Thu, 2021-06-10 at 15:47 -0700, Tom Herbert wrote:
[....]
> It seems like this is an exercise of making protocols ever more
> usable-- either by fallbacks (e.g. Happy Eyeballs) as you mentioned,
> but also by clarifications to the protocol requirements to elicit
> practical implementation. For instance, RFC8200 allowing nodes to
> completely ignore HBH options instead of requiring every single node
> in the path to process was a big step in the right direction.
> Specifying a reasonable default limit for the number of options that
> should be processed or length of the IPv6 header chain that is
> supported would be another step. Note these things won't get us to
> 100% support, but they could increase reachability and hence increase
> utility of the protocols.

If the feature cannot be relied upon, a fallback mechnism needs to be
implemented. Now, as a protocol designer, why would I even bother
implementing functionality with an unreliable mechanism, particularly
when I could simply rely on something else?


OTOH, if I know that you have a fallback mechanism to take care of
situations where packets with EHs are dropped, why should I allow you
EH packets in my network in the first place?


-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531