[IPv6]Re: Fwd: New Version Notification for draft-iurman-6man-eh-occurrences-00.txt

[Sebastian Moeller <[e-mail]>]

Hi Justin,


> On 28. Dec 2025, at 13:01, Justin Iurman <[e-mail]> wrote:
> 
> On 12/24/25 17:28, Tom Herbert wrote:
>> On Wed, Dec 24, 2025 at 2:19 AM Justin Iurman <[e-mail]> wrote:
>>> 
>>> On 12/24/25 01:07, Tom Herbert wrote:
>>>> On Tue, Dec 23, 2025 at 3:58 PM Justin Iurman <[e-mail]> wrote:
>>>>> 
>>>>> On 12/24/25 00:48, Tom Herbert wrote:
>>>>>> On Tue, Dec 23, 2025, 3:28 PM Justin Iurman <[e-mail]> wrote:
>>>>>>> 
>>>>>>> On 12/24/25 00:15, Tom Herbert wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, Dec 23, 2025, 3:06 PM Justin Iurman <[e-mail]
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>> 
>>>>>>>>       On 12/24/25 00:00, Tom Herbert wrote:
>>>>>>>>        >
>>>>>>>>        >
>>>>>>>>        > On Tue, Dec 23, 2025, 2:54 PM Justin Iurman
>>>>>>>>       <[e-mail] <mailto:[e-mail]>
>>>>>>>>        > <mailto:[e-mail]
>>>>>>>>       <mailto:[e-mail]>>> wrote:
>>>>>>>>        >
>>>>>>>>        >     Hi Nick,
>>>>>>>>        >
>>>>>>>>        >     On 12/23/25 23:29, Nick Hilliard wrote:
>>>>>>>>        >      > Hi Justin,
>>>>>>>>        >      >
>>>>>>>>        >      > Justin Iurman wrote on 23/12/2025 21:10:
>>>>>>>>        >      >> The change proposed in the draft not only enforces the
>>>>>>>>       rule for
>>>>>>>>        >      >> senders, but is also allows receivers to discard packets with
>>>>>>>>        >      >> extension headers exceeding their number of occurrences.
>>>>>>>>       Right now,
>>>>>>>>        >      >> RFC 8200 assumes that a receiving node should process EHs
>>>>>>>>        >     regardless
>>>>>>>>        >      >> of the number of occurrences.
>>>>>>>>        >      >
>>>>>>>>        >      > yes, but this misses the point.
>>>>>>>>        >      >
>>>>>>>>        >      > Your draft allows a receiving node to drop multiple
>>>>>>>>       occurrences
>>>>>>>>        >     of the
>>>>>>>>        >      > same type (nb: at the cost of maintaining a count or index
>>>>>>>>       for each
>>>>>>>>        >      > type, which is a significant state overhead when handling
>>>>>>>>       packet
>>>>>>>>        >      > forwarding), but the point is that in order to do this, the
>>>>>>>>        >     receiving -
>>>>>>>>        >      > or intermediate node - needs to parse the entire header
>>>>>>>>       chain to
>>>>>>>>        >     find
>>>>>>>>        >      > out which EHs to drop. The requirement to parse
>>>>>>>>       excessively long EH
>>>>>>>>        >      > chains is the root cause of the problems identified in
>>>>>>>>       rfc9098.
>>>>>>>>        >      >
>>>>>>>>        >      > You can't address the problems in rfc9098 by setting rules of
>>>>>>>>        >     engagement
>>>>>>>>        >      > at the sending side. You can only deal with them on
>>>>>>>>       receiving /
>>>>>>>>        >      > intermediate nodes by putting an upper bound on the "overall
>>>>>>>>        >     quantity"
>>>>>>>>        >      > of EHs in the packet.
>>>>>>>>        >      >
>>>>>>>>        >      > I'm using the vague term "overall quantity" because some
>>>>>>>>       hardware
>>>>>>>>        >     craps
>>>>>>>>        >      > out on parsing due to fixed buffer lengths and other hardware
>>>>>>>>        >     craps out
>>>>>>>>        >      > after a specific number of headers.  So any draft aimed at
>>>>>>>>        >     addressing
>>>>>>>>        >      > this problem needs to acknowledge both situations when
>>>>>>>>       specifying
>>>>>>>>        >     what
>>>>>>>>        >      > limits a receiving or intermediate node should implement
>>>>>>>>       in order to
>>>>>>>>        >      > protect itself against ddos threat incidents.
>>>>>>>>        >
>>>>>>>>        >     Oh, got it, thanks! Would something like this address what you
>>>>>>>>        >     described
>>>>>>>>        >     above?
>>>>>>>>        >
>>>>>>>>        >     OLD:
>>>>>>>>        >         IPv6 nodes MAY discard a packet exceeding the number of
>>>>>>>>        >     occurrences of
>>>>>>>>        >         extension headers.
>>>>>>>>        >
>>>>>>>>        >     NEW:
>>>>>>>>        >         IPv6 nodes MAY discard a packet exceeding the number of
>>>>>>>>       occurrences
>>>>>>>>        >     of
>>>>>>>>        >         extension headers, provided that they can safely parse
>>>>>>>>       the header
>>>>>>>>        >         chain without exceeding their processing or hardware
>>>>>>>>       limitations.
>>>>>>>>        >
>>>>>>>>        >
>>>>>>>>        > If they can't safely parse the header chain, what action is taken?
>>>>>>>> 
>>>>>>>>       None, hence "MAY". This would lead to a drop anyway, since that's the
>>>>>>>>       current behavior of hardware with limitations. But I expect end-
>>>>>>>>       hosts to
>>>>>>>>       implement it.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Justin,
>>>>>>> 
>>>>>>> Tom,
>>>>>>> 
>>>>>>>> What RFC gives the requirements and procedures of a router that drops
>>>>>>>> packets because a hardware limitation was exceeded? That was the point
>>>>>>>> of eh-limits draft I believe
>>>>>>> 
>>>>>>> I'm not questioning the point of eh-limits, I'm more concerned (and I'm
>>>>>>> not the only one) with the proposed solution. Also, correct me if I'm
>>>>>>> wrong but, eh-limits specifies a 64-byte limit which at the end of the
>>>>>>> day only "documents" the current (worst) state. I don't see how it helps
>>>>>>> to improve the situation (how about support for more than 64 bytes of EHs?).
>>>>>> 
>>>>>> The problem we have right now is being able to use EH of _any_ length
>>>>>> greater than zero. At least a requirement to support 64 bytes would
>>>>>> move the ossification point from zero to something greater than zero.
>>>>>> If you want to send 1000 bytes of EH on the Internet it's never going
>>>>>> to happen (notwithstanding the fact that there's no use case for
>>>>>> sending 1000 bytes of EH other than DoS).
>>>>> 
>>>>> Tom,
>>>>> 
>>>>> If you ended up with 64 bytes, it's because it seems to be the low
>>>>> limit, not zero. Also, you could theoretically send 1000 bytes of DO by
>>>>> using ESP if you really want to (which would go through the "public"
>>>>> Internet). Not a chance with a Hbh, though. So, there are workarounds
>>>>> while the situation regarding hardware limitation improves. And recent
>>>>> measurements/observations tend to suggest we're right to think it will
>>>>> improve in the long term.
>>>> 
>>>> What are these recent measurements you're referring to?
>>> 
>>> Tom,
>>> 
>>> We tested Cisco/Nokia/Huawei/Juniper routers, some recent and some
>>> not-so-recent-but-not-that-old. We tried multiple combinations of EHs,
>>> with filtering (to force a lookup) and without. None of them showed such
>>> limitations, i.e., mtu-sized packets with EHs were going through without
>>> problem.
>>> 
>>> There is also draft-ouellette-v6ops-eh-router-forwarding. Kyle found a
>>> router with such limitations, and it was a very very old piece of
>>> (legacy) hardware according to him (no more details for privacy
>>> reasons). However, the said router could handle up to 176 bytes of EHs
>>> (HBH or DO, in this case), which is more than the 128-byte parsing
>>> buffers you announced. Other routers that were tested did not show such
>>> limitations.
>>> 
>>> I can already hear the arguments again: "these are limited
>>> measurements", "it's not representative", you name it. While this is
>>> true (it's difficult to get access to such routers, and even if you do,
>>> you can't possibly test them all), I think we can no longer ignore the
>>> fact that this trend of larger parsing buffers is very real.
>>> 
>> Hi Justin,
> 
> Hi Tom,
> 
>> They're not just limited arguments, they're lab results. The only
>> thing that's relevant is what's happening in real deployment. The data
> 
> And I agree with that, no question. I just think it'd be foolish to not even consider it. After all, it's also our job to anticipate the future.

[SM] Well, predictions are hard, especially those about the future...

> 
>> from real deployment says that Extension headers are commonly dropped,
>> and the data also shows strong correlation between drop rate and
>> length of extension headers. In eh-limits we deduced that a reasonable
>> minimal level of support is 64 bytes of EH based on the data. The
>> number was not pulled out of a hat as some seem to think, it's based
>> on an analysis from deployment data.
> 
> I don't think anyone said that. The problem is the decision to limit the size of EHs in general, not the number 64 in particular (although it is small enough to limit future deployments).

[SM] This IMHO is the same maximalist position that got us into the current mess*. ATM, EHs do not reliably pass the internet, period. I am all for trying to convince the industry and providers to "give" us 64 byte of EH space, and then it is up to us to make something useful out of that to convince the same stakeholders to increase the "allowance".

*) Well, that and ignoring the "use it, or loose it" maxim, had we made all EHs an mandatory load bearing part of IPv6 nobody could afford to ignore them, but we did not, and there we are.


> 
>> As for " the fact that this trend of larger parsing buffers is very
>> real". Until we have data from deployment that shows an improvement
>> it's not real and it's not a fact. And even if the trend were real how
> 
> The opposite is also true. How could you quantify the number of hardware with limitation? Suppose it's <1% of the entire fleet, would you still specify these limits? Because we don't really know. It only takes one on a path to screw things up. If you have such hardware in a Tier-1 AS, then you could incriminate the entire Internet. Would this reflect reality? No.

[SM] Respectfully, as an internet user pondering the question whether or not to use an EH, I could not care less about the number of affected devices I am more concerned about the number of affected paths and especially whether my desired path is affected... I guess I would want to have path-EH-capability-discovery...

> 
>> would that turn into quantifiable requirements? If I'm a programmer
>> who is considering the use of extension headers in an Internet
>> application what is your guidance to me?  Can I safely send 1000 bytes
>> of EH? 256 bytes? 64 bytes? or maybe I shouldn't use them at all.
>> Please give _quantified_ and _actionable_ guidance. If the best IETF
>> can offer is "we're hoping that someday all the problems will be fixed
>> by hardware someday" then I think that is a disservice to our users.
> 
> I thought you said there were no use cases or users anyway. Honestly, what would you use as a user on the public Internet nowadays?

[SM] I keep repeating this, I want better congestion/min capacity signalling, and ECN clearly dies not cut it, especially after burning one code-point on L4S.

> 
> Hbh? It's heavily filtered by policies already, and you can't expect people to waste cycles for you without prior agreement (which, in my books, sounds like a limited domain). Don't get me wrong, I'd love to have Hbh on the public Internet for some use cases, but operators decided otherwise and we can't blame them. When vendors choose to follow RFC9673 and make Hbh processing optional/configurable (vs. punting), things might improve, although that ship has sailed IMO.
> 
> Frag? It's heavily filtered too, and people don't rely on it.
> 
> RH? Nope, limited domains.
> 
> Except for the Destination Options Header (and ESP, of course), I can't think of another that would make more sense on the public Internet.
> 
>> In lieu of getting reasonable guidance, I think it's perfectly
>> reasonable for operating systems to disable extension headers by
>> default. The irony isn't lost that the naysayers who complained that
>> 64 bytes would lead to protocol ossification may have inadvertently
>> forced extension headers to be permanently ossified at zero.
> 
> As written above, I don't think we should say "Extension Headers" when in reality we're talking more about the Destination Options Header in this context. Regardless, it's not ossified at zero (none of them).

[SM] That heavily depends on one's definition of ossification. I am convinced that "ossification ", like "starvation" is following the "I recognise it, when I see it" kind of definition. Which is okay, I guess, but not helpful for a discussion or standardisation.

Regards
	Sebastian

> 
> Justin
> 
>> Tom
>>> Justin
>>> 
>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Also, only hosts should be allowed to drop packets because of the number
>>>>>>>> of occurrences being exceeded, routers should not do that. Technically,
>>>>>>>> routers are only supposed to look at HBH. The reason they look beyond
>>>>>>>> that is to find L4 header, but their ability to find that is more a
>>>>>>>> function of header chain length, not number of EHs or number of options.
>>>>>>> 
>>>>>>> We're in violent agreement here, isn't it clear in the draft?
>>>>>> 
>>>>>>   From the draft: "IPv6 nodes MAY discard a packet exceeding the number
>>>>>> of occurrences of extension headers."
>>>>>> 
>>>>>> Per RFC8200, IPv6 nodes include hosts and routers, so the text would
>>>>>> allow routers to drop packets because limits on # of occurrences being
>>>>>> exceeded.
>>>>>> 
>>>>>> Also, if nodes drop packets then sending an ICMP error to that effect
>>>>>> should be a MAY (see eh-limits)
>>>>> 
>>>>> Agree.
>>>>> 
>>>>> Justin
>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Justin
>>>>>>> 
>>>>>>>> Tom
>>>>>>>> 
>>>>>>>> 
>>>>>>>>        >
>>>>>>>>        >     Justin
>>>>>>>>        >
>>>>>>>>        >      > Nick
>>>>>>>>        >
>>>>>>>>        >
>>>>>>>>         --------------------------------------------------------------------
>>>>>>>>        >     IETF IPv6 working group mailing list
>>>>>>>>        > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>>>>>>       <mailto:[e-mail]>>
>>>>>>>>        >     List Info: https://mailman3.ietf.org/mailman3/lists/
>>>>>>>>       [e-mail]/ <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>
>>>>>>>>        >     <https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>>>>>>>>       <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>>
>>>>>>>>        >
>>>>>>>>         --------------------------------------------------------------------
>>>>>>>>        >
>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------