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

[Tom Herbert <[e-mail]>]

On Thu, Jun 10, 2021 at 4:06 PM Fernando Gont <[e-mail]> wrote:
>
> 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?
>
Because fallbacks offer degraded service not equivalent service. For
instance your question could be restated as: given that IPv4 is the
fallback for IPv6, why should you allow IPv6 packets in your network
in the first place?

Tom

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