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

[Tim Chown <[e-mail]>]

Hi,

On 16/04/2025, 13:58, "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.

The history of the text in 7.3 of RFC 8504 about EH processing is that it was added with Tom’s input to give guidance on protecting nodes from excessive EH options - see https://www.rfc-editor.org/rfc/rfc8504#section-5.3. We realised as the draft of 8504 was nearing completion that we could add useful guidance to follow what was said in 7.2. It was easier to get it agreed and in there than produce a new draft, at the time.

We are now beginning an 8504-bis, and as one of the authors I would have hoped that this EH draft was a more detailed and (with more time available) thought through set of recommendations to protect nodes, and that on publication is could be cited in Section 7.3 (or whatever that becomes) of 8504-bis and there would be no need for specific text in 8504-bis.

The problem now is that this draft has gone way beyond the protection of nodes onto something for more restrictive, as Gorry says below for the other DISCUSSes.  I can see that 8504-bis can very usefully refer to RFC 9673 but I fear for what this draft may become and the implications of citing it in 8504-bis if it goes significantly beyond node protection.

Tim


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.

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.


----------------------------------------------------------------------
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.



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------