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

[Tom Herbert <[e-mail]>]

On Thu, Jun 10, 2021 at 3:20 PM Brian E Carpenter
<[e-mail]> wrote:
>
> On 11-Jun-21 03:07, Tom Herbert wrote:
> > On Thu, Jun 10, 2021 at 12:41 AM Fernando Gont
> > <fernando.gont=[e-mail]> wrote:
> ...
> <big snip>
> ...
> > If you are pursuing that path, you should also limite the overall IPv6
> > header chain length. That;s probably even more important than limiting
> > the number of EHs or number of HbH options.
> >
> >> Fernando,
> >
> >> That limit and other pertinent ones are defined in RFC8504 section 5.3
> >> and RFC8883. The limits in RFC8504 are specified for hosts, but it
> >> would be straightforward to apply them to routers  where the behavior
> >> when a limit is exceeded would be different-- end hosts should drop
> >> packets that exceed the limit, intermediate nodes should stop parsing
> >> and forward the packet. If a node decides to drop the packet then it
> >> can send an RFC8883 ICMP error to inform the sender what the exceeded
> >> limit was. Recommended defaults can be provided for limits; e.g. in
> >> RFC8504 the limit of HBH or DestOpts is eight meaning that receivers
> >> should support up to eight options and senders should be able to send
> >> up to eight options with reasonable confidence their packets won't be
> >> dropped. A similar default could be established for length of IP
> >> header chain (for hosts this isn't immediately necessary since hosts,
> >> unlike routers, usually don't have a concept of fixed sized parsing
> >> buffer holding headers, although with hardware acceleration that limit
> >> might be more applicable to set in the host).
>
> Which all, IMHO, shows that the Internet cannot ever be assumed to be
> transparent to extension headers of any kind; either we accept that
> extensions are confined to limited domains or we need a probing process
> before using them, to determine whether they can survive the trip.
>
> Not much has changed (and it's exactly the same for IPv4 options): unusable
> across the Internet.

Brian,

By that same logic, IPv6 itself is unusable across the Internet since
not all Internet paths support IPv6 :-). For that matter, probably any
protocol, with the possible exception of plain TCP/IPv4 without
options, is "unusable" if the definition of usable is that there is a
100% probability that packets of a protocol will reach their
destination.

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.

Tom

>
>    Brian