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

[Gorry Fairhurst <[e-mail]>]

On 24/04/2025 10:23, Tim Chown wrote:
>
> Hi,
>
> On 23/04/2025, 23:22, "Nick Hilliard" <[e-mail]> wrote:
>
> Gorry,
>
> Gorry Fairhurst via Datatracker wrote on 16/04/2025 13:58:
> > 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.
>
> Can you point out the specific sections of text that you're concerned 
> about?
>
> As a general comment, I'd be supportive of seeing this ID published as a
> BCP. Hopefully that boat hasn't sailed.
>
> I hope that boat hasn’t even anchored at the dock to get ready to 
> sail. I object to the draft being advanced for reasons stated 
> previously. If there is consensus however then Informational is the 
> very most it should be. Perhaps Experimental.
>
I reviewed this as targeting Informational: that is what was requested 
to the IESG.

So, first to clarify: I would not be concerned about Verbatim citations 
(in quotes) of text from another RFC.

So, I am questionin text that refers to something in another 
standards-track RFC where it is written without an RFC2119 keyword, and 
where it is written in this I-D using an RFC2119 keyword.

>
>
> > 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.
>
> The draft is about specifying a set of minimum supported standards for
> EHs, rather than introducing limits.
>
> But those minimums will be interpreted as limits.  It’s even in the title!
>
>
>
> Intermediate nodes are normally built from designs which aren't host
> stacks. E.g. an ASIC-based forwarding platform might use linux, but
> that's only for the control plane of the device. The forwarding plane
> (and hence the forwarding limitations) would relate largely to the
> ASIC's capabilities, not to a host stack.
>

> > 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'm not sure that the ossification argument stands up to scrutiny.
>
> 1. there's plenty of types of routing kit which will support long EH
> chains (mid-to higher end kit, and anything which supports SRv6).
> Specifying a minimum will have no impact on this kit because it's not
> appropriate for the use case for this style of kit.
>
> So end to end long EH chains do work in the wild, for well-provisioned 
> networks?
>
>
>
> 2. at the other end of the market where there's currently poor support
> for EHs, specifying a minimum supported standard will only make a
> difference for the better.
>
> It must be possible to identify specific equipment and its 
> capabilities. Has anyone done this and produced a list?  This would 
> support evidence of current implementation/vendor practice.  Versus 
> evidence of policy-based filtering, typically within end sites, which 
> is a different matter.
>
>
>
> 3. we've been running ipv6 for 30 years at this point, and EHs are still
> unusable. It's reasonable to associate this with the fact that there are
> there are no explicit minimum standards for supporting EHs (other than
> fragmentation).
>
> This isn’t the only factor, and if we must have minimums, don’t ossify 
> it so low.
>
>
>
> > I’d like to discuss whether the I-D could be constrained to avoid 
> this, and
> > allow the minimum size to evolve.
>
> Do you have suggestions on how to approach this?
>
> I’d like to see the draft only cover what’s in 7.3 of RFC8504 section 
> 5.3, on limits for processing to protect nodes against DoS and other 
> attacks.  This would put the draft in the same area as 
> draft-ietf-6man-deprecate-router-alert. The RFC then covering other 
> processing would remain RFC 9673 (on top of RFC 8200).  RFC 8504-bis 
> could then point to that work and remove its ‘interim’ text of 5.3 
> that I’ve personally considered a placeholder for this draft.
>
> Tim
>
>
>
> Nick
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------
>
To clarify my DISCUSS-2, this relates specifically to the Intermediate 
Node and Router limits, sections 4 and 5.

I do recognise the challenge in finding support for EH at datacenters or 
from virtualised platfroms (been there, seen what can happen). To 
discuss this, I'd first like to know whether modern routers and other 
network equipment already can support sizes that are larger than these 
limits.

Gorry