Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Tom Herbert <[e-mail]>]

On Sat, Feb 20, 2021 at 12:10 PM Nick Hilliard <[e-mail]> wrote:
>
> Hi Tom,
>
> Tom Herbert wrote on 20/02/2021 15:32:
> > This is reflected in the statement: "If an IPv6 header chain is
> > sufficiently long that it exceeds the packet look-up capacity of the
> > router, the router might be unable to determine how the packet should
> > be handled, and thus could resort to dropping the packet." It's not to
> > me clear what "sufficiently long" means;
>
> Is this just an issue of dialect?  The term "If an IPv6 header chain is
> sufficiently long that..." just means "If an IPv6 header chain is long
> enough that..."
>
> > in particular, such a
> > statement isn't helpful to the host stack developer trying to figure
> > out if the packets they're creating will be properly forwarded.
>
> That's something that should be addressed in a future ID.  Right now
> we're concentrating on documenting the problem.
>
Nick,

Maybe so, but without further details I believe the way the problem is
being documented is ambiguous and unenlightening. Besides, there has
already been work in this area that really could be cited here. For
instance, in RFC8883 the different ICMP errors reflect several
different ways and provide a lot more detail as to why nodes might
drop packets because headers are "too long". That RFC lists the
priority of ICMP errors as:

 1.  Existing ICMP errors defined in [RFC4443].
 2.  "Unrecognized Next Header type encountered by intermediate node"
 3.  "Extension header too big"
 4.  "Option too big" for length or number of consecutive padding
options exceeding a limit.
 5.  "Option too big" for the length of an option exceeding a limit.
 6.  "Too many options in an extension header"
 7.  "Extension header chain too long" headers exceeding a limit.
 8.  "Too many extension headers"
 9.  "Headers too long"

Numbers 3-8 represent reasons why nodes might drop a packet with
extension headers. Number 9 encompasses those cases where a node
parses beyond the IPv6 headers chains (for instance a node that parses
into GRE encapsulation).

Give that these classes are documented, then the obvious question is
what are the common limits that should work. RFC8504 does this for
some of the limits that are more apropos to the host; hopefully, an
outcome of this draft will define some practical limits for routers
and set some expectations about what should work.

Tom

> Nick