[IPv6]Re: Gorry Fairhurst's Discuss on draft-ietf-6man-eh-limits-19: (with DISCUSS and COMMENT)

[Tom Herbert <[e-mail]>]

z

On Wed, Apr 16, 2025 at 5:58 AM Gorry Fairhurst via Datatracker
<[e-mail]> wrote:
>
> Gorry Fairhurst has entered the following ballot position for
> draft-ietf-6man-eh-limits-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-eh-limits/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. I support the editor in measures
> to facilitate more widespread support for extension headers. I recognise there
> are design limits in current host stacks, and I understand the recommendations
> originate from the current design in Linux. If documenting these limits
> encourages better support for EH, this is good.
>
> To help ensure a clear understanding of my ballot position, this is the third
> time I have reviewed this draft -- each in different roles, and each based on a
> complete read of this I-D. First, as an early reviewer for TSV-ART I raised
> substantial concerns when I-D -16 targeted PS. Second, as a IETF-LC reviewer of
> I-D -18, again for TSV-ART - but this time only focussed on transport (then
> targeting INFO). Each time I recorded major issues one concerning the way in
> which RFC2119 requirements were introduced, and also had comments. I thank the
> author for the improvements and updates of the I-D after each round of review.
> I now review this as an AD, with a different set of criteria.
>
> I am balloting this as DISCUSS because I remain deeply concerned about the
> potential to restricting the ability for innocation in use of EH by transport
> endpoints. I plan to revise this position after discussion, and have not yet
> decided whether to ballot Abstain or ballot No Objection.
>
> Please find below several blocking DISCUSS points:
>
> DISCUSS 1) This I-D has been submitted to target publication as Information. As
> such, I do not expect this to update RFC 8504, and this is the basis for the
> current review. However, there are still places in the text that could be
> interpreted as an update. I’d like to discuss if this draft could be re-worded,
> particularly to avoid chnaging lower case text to derive new RFC-2119
> requirements.

Hi Gorry,

I believe removing RFC2119 verbiage would water down the draft to the
point of being insignificant. As you know, this draft started as PS
and then BCP and then Informational. In retrospect, I think it should
have been BCP and it should have been an update to RFC8504.

>
> DISCUSS 2) I do not yet see the underlying evidence supporting introducing
> limits for intermediate nodes. I can see how intermediate nodes could be built
> using host stacks, but I'd like to clarify can intermediate nodes also built
> from other designs?  I’m asking because I’d like to discuss how to add clarity
> on whether the set of limits are derived from constraints in deployed routers
> (and intermediate nodes) - or observed for end-to-end paths.

We're not introducing limits for intermediate nodes, we're
acknowledging their existence in deployment. The data is clear on this
and RFC9098 describes the operational implications that lead to
routers dropping packets with extension headers (it's not hosts doing
the dropping). The data shows a strong correlation between extension
header size and drop rates, the longer the extension header chain the
greater the drop rate. This is the effect of the common parsing buffer
design in routers where the L4 headers are pushed too deep in the
packet to be read(RFC9098 Section 8.1). RFC9673 doesn't help here
because it's not just HBH Options that are the problem, the data shows
that packets with long Destination Options are also more likely to be
dropped. So the parsing buffer size is a real limit in routers
currently deployed, the goal of the draft is to provide an expectation
on what the minimum size should be-- in lieu of IETF providing any
guidance, router vendors will continue to define their own ad hoc
limits which in some cases is 0.

>
> DISCUSS 3) The idea of a minimum level of required support is clearer to me
> when related to endpoints/hosts. Once this is expressed also as a router limit
> for routers or intermediaries, I suggest that future extensibility is impacted.
> I suggest vendor designs are likely ossified to whatever limit is specified.
> I’d like to discuss whether the I-D could be constrained to avoid this, and
> allow the minimum size to evolve.

I can't rectify this viewpoint with reality. The Internet is fully
built out and as you know drop rates of packets with Extension Headers
are high to the point where they're unusable, The problem is in
routers, and it's not like router vendors have been planning all along
to fix extension headers. Packet drops have been happening for thirty
years and without taking action probably will go on for another thirty
years.

Neither do I understand the concerns about how this draft could stunt
innovation. Right now the current state of deployment prohibits _any_
innovation with respect to extension headers. No serious host
application is going to try to use extension headers today. That's
what we need to fix. Some might argue that extension headers are a
lost cause and their use should only be relegated to limited domains.
That very well might be what ends up happening anyway, but if it does
then IMO the Internet as a whole just took a major loss as being built
on an extensible L3 protocol. Opportunities for innovation in that
space would be lost forever.

I'll also point out that the most successful transport protocol of all
time, TCP, is limited to a paltry forty bytes of options. That has
hardly stunted innovation in TCP, and to the contrary I believe it's
facilitated ubiquity. It's an academic argument to say we need
protocols with unlimited flexibility, but it's a pragmatic argument to
say we need protocols with reasonably limited flexibility for feasible
deployment

Thanks,
Tom


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This provides some non-blocking COMMENT points (replies would be appreciated to
> help me understand):
>
> 1) The discussion on QUIC (RFC 9000) is not helpful, please remove. The RFC
> states:
>
> “This requirement to support a UDP payload of 1200 bytes limits the space
> available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if
> the path only supports the IPv6 minimum MTU of 1280 bytes. This affects Initial
> packets and path validation.”
>
> I recall that google telemetry showed a significant number of end-to-end paths
> had limited traversal for UDP datagrams dependent on size. The decision to set
> the default QUIC maximum packet size was based on the desire to enable
> deployability to most (but not all) access networks. Even so, the majority of
> networks were able to support much larger packets than the minimum packet size,
> so the majority of networks were not constrained in the way that this I-D seems
> to suggest, especially since this applies ONLY to Initial packets and path
> validation.
>
> 2) Please consider whether the product of the Happy WG could provide an
> alternative solution to the problem of heterogenous support for EH over
> different paths.
>
>
>