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

[Justin Iurman <[e-mail]>]

On 12/23/25 23:12, Tom Herbert wrote:
> On Tue, Dec 23, 2025 at 1:58 PM Justin Iurman <[e-mail]> wrote:
>>
>> Sebastian,
>>
>> On 12/23/25 22:41, Sebastian Moeller wrote:
>>> Justin,
>>>
>>>> On 23. Dec 2025, at 22:33, Justin Iurman <[e-mail]> wrote:
>>>>
>>>> Tom,
>>>>
>>>> On 12/23/25 22:21, Tom Herbert wrote:
>>>>> On Tue, Dec 23, 2025 at 1:05 PM Justin Iurman <[e-mail]> wrote:
>>>>>>
>>>>>> Tom,
>>>>>>
>>>>>> On 12/23/25 21:55, Tom Herbert wrote:
>>>>>>> On Tue, Dec 23, 2025 at 12:31 PM Justin Iurman <[e-mail]> wrote:
>>>>>>>>
>>>>>>>> Bob,
>>>>>>>>
>>>>>>>> I don't think it does, but I may be wrong. Could you point me to the
>>>>>>>> text you have in mind?
>>>>>>>>
>>>>>>>> This draft enforces the number of occurrences of all Extension Headers,
>>>>>>>> not the number of options inside a Hop-by-Hop or Destination Options
>>>>>>>> header nor the processing of Hbh/options. Which is, IMHO, different from
>>>>>>>> RFC 9673. The idea came after a discussion with Tom on the mailing list
>>>>>>>> (regarding draft-ietf-6man-eh-limits), and his concern about DoS attacks
>>>>>>>> on hosts, mainly for the Destination Options header which could appear
>>>>>>>> many times (i.e., at least more than two). I believe this draft solves
>>>>>>>> that concern and at the same time avoids the need to publish
>>>>>>>> draft-ietf-6man-eh-limits, which by the way may also require changes in
>>>>>>>> rfc8504-bis Section 5.3 (e.g., maybe a smaller limit on the number of
>>>>>>>> options, current is 8). Other concerns about the size of EHs and/or
>>>>>>>> options in draft-ietf-6man-eh-limits don't need to be addressed IMHO, as
>>>>>>>> already discussed and explained previously on the mailing list. Overall,
>>>>>>>> I see this draft + rfc8504-bis + RFC 9673 as an acceptable solution,
>>>>>>>> compared to draft-ietf-6man-eh-limits.
>>>>>>>
>>>>>>> Justin,
>>>>>>>
>>>>>>> This was already addressed in eh-limits draft:
>>>>>>>
>>>>>>> "
>>>>>>> A host or intermediate MAY enforce the recommended extension
>>>>>>> header ordering and number of occurrences of extension headers
>>>>>>> described in Section 4.1 of [RFC8200].  Per the ordering
>>>>>>> recommendations, each extension header can occur at most once in a
>>>>>>> packet with the exception of Destination Options header which can
>>>>>>> occur twice.  The recommended extension header ordering per
>>>>>>> [RFC8200] is:
>>>>>>>
>>>>>>>          -  IPv6 header
>>>>>>>          -  Hop-by-Hop Options header
>>>>>>>          -  Destination Options header
>>>>>>>          -  Routing header
>>>>>>>          -  Fragment header
>>>>>>>          -  Authentication header
>>>>>>>          -  Encapsulating Security Payload header
>>>>>>>          -  Destination Options header
>>>>>>>          -  Upper-Layer header
>>>>>>>
>>>>>>>     If a host or intermediate node enforces extension header ordering
>>>>>>>     and a packet is received with extension headers out of order or
>>>>>>>     the number of occurrences of an extension header is greater than
>>>>>>>     one, or two for the Destination Options header, then the receiving
>>>>>>>     node MUST discard the packet and MAY send an ICMP Parameter
>>>>>>>     Problem message with code 0 (Erroneous Header Field Encountered)
>>>>>>>     [RFC4443] to the packet's source address.
>>>>>>> "
>>>>>>>
>>>>>>> Also, this draft is only for one tiny part of the problem and I don't
>>>>>>> believe it is really addressing the core issue which is the high drop
>>>>>>> rates of packets with extension headers.
>>>>>>
>>>>>> Correct. However, we already discussed why draft-ietf-6man-eh-limits was
>>>>>> trying to do too much by specifying limits on the size of EHs and Hbh/Do
>>>>>> options (feedback from WG members and the IESG). And since you did not
>>>>>> want to remove these problematic parts in the draft, I see this draft as
>>>>>> a good trade-off and the only way forward.
>>>>> Justin,
>>>>> I don't see how this is a good trade-off nor the only way forward for
>>>>> solving the undepoyability of extension headers. IMO, if we're not
>>>>> going to address the real issues with extension headers then the best
>>>>> way forward is to deprecate them.
>>>>
>>>> Right, I'll do it again and repeat what was already discussed. Why is it a good trade-off? Because it mitigates DoS attacks, especially for Hbh and DO (which was one of the concerns in draft-ietf-6man-eh-limits). Because rfc8504-bis can specify new limits on the number of Hbh/DO options (although the current default of 8 could reasonably remain, thanks to this draft). Because RFC 9673 already handles the processing of Hbh and its options. And, above all, because what you're trying to solve cannot be solved the way you did. Specifying limits on the size of EHs and options would be useless (at best) or dangerous. Why? Well, if you look at the reasons of such drops, there are two: (i) policies applied by operators, and (ii) hardware limitation. For the first one, you can't do much except trying to educate people. For the second one, specifying "limits" won't solve anything. There are proofs that recent hardware do not have such low limitation (i.e., small parsing buffers). The solution is therefore to not have a solution, i.e., situation will improve over time (old hardware will be replaced at some point).
>>>
>>> That IMHO is more wishful thinking, and less robust engineering: if operators have no desire of actually parsing deep into packets due to their policies, what makes you believe that the (I assume non-exhaustive) examples you saw in recent router hardware to allow deeper parsing will actually be predictive of the capabilities of all modern hardware to come? Now, maybe there are reasons that hardware vendors need/want these deeper inspection capabilities even if their customer,ers do not seem to care; do you know of any such motivations that might allow a robust prediction that deeper buffers are here to stay?
>>
>> This is indeed wishful thinking, but not entirely. It was observed that
>> operators tend to apply policies on Hbh and Frag (and RHs too
>> sometimes), but not really on DO or other EHs where pure hardware
>> limitation is the root cause in that case. What's already heavily
>> filtered by operators is going to be hard to save. Regarding your
>> question(s), I believe SRv6 is a good example of why you would want to
>> be able to parse deep (e.g., an old 64-byte parsing buffer is probably
>> not what you want in most cases here). That (i.e., market pressure on
>> vendors regarding SRv6 capabilities), combined with evolving hardware
>> capabilities, leads me to foresee the sun behind the clouds in the long
>> term.
> 
> Justin,

Tom,

> SRv6 is restricted to limited domains. All the edge routers and core
> routers on the Internet won't see SRv6 so I don't see that as a
> motivation to allow deep parsing in those devices. Also, increasing

But you still need hardware with expected capabilities to deploy SRv6 in 
limited domains, or anything else similar.

> the size of the parsing buffer in a device is expensive, and I don't
> see anyone doing that without some sort of motivation.  The data shows
> that 128 byte parsing buffers are commonly deployed, I don't see
> there's going to be a rush to increase that any time soon.

That's not true. The data only shows that there are still some hardware 
out there with limitation. You cannot say they are commonly deployed: 
you only need one on a path to screw things up, but it doesn't mean all 
nodes on the same path have the same kind of limitation. We could even 
say the opposite, as measurements tend to show that recent hardware have 
not such limitation anymore (either through way bigger parsing buffers, 
or packet recirculation).

Justin

> Tom
> 
>>
>> Justin
>>
>>> Regards
>>>        Sebastian
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Justin
>>>>
>>>>> Tom
>>>>>>
>>>>>> Justin
>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>>
>>>>>>>> Justin
>>>>>>>>
>>>>>>>> On 12/23/25 20:57, Bob Hinden wrote:
>>>>>>>>> Justin,
>>>>>>>>>
>>>>>>>>> I suggest you take a look at RFC 9673 "IPv6 Hop-by-Hop Options Processing Procedures”.   I believe it covers this topic for hop-by-hop options.
>>>>>>>>>
>>>>>>>>> Bob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Dec 23, 2025, at 11:26 AM, Justin Iurman <[e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> Happy holidays!
>>>>>>>>>>
>>>>>>>>>> This new draft aims to mitigate the risk of DoS attacks due to an abusive use of IPv6 Extension Headers. This problem is related to non-normative language combined with ambiguous wording in RFC 8200. This is one of the concerns raised in draft-ietf-6man-eh-limits. Feedback welcome!
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Justin
>>>>>>>>>>
>>>>>>>>>> -------- Forwarded Message --------
>>>>>>>>>> Subject: New Version Notification for draft-iurman-6man-eh-occurrences-00.txt
>>>>>>>>>> Date: Tue, 23 Dec 2025 11:14:36 -0800
>>>>>>>>>> From: [e-mail]
>>>>>>>>>> To: Justin Iurman <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> A new version of Internet-Draft draft-iurman-6man-eh-occurrences-00.txt has
>>>>>>>>>> been successfully submitted by Justin Iurman and posted to the
>>>>>>>>>> IETF repository.
>>>>>>>>>>
>>>>>>>>>> Name:     draft-iurman-6man-eh-occurrences
>>>>>>>>>> Revision: 00
>>>>>>>>>> Title:    Mitigating DoS attacks in IPv6 by clarifying the number of occurrences of Extension Headers
>>>>>>>>>> Date:     2025-12-23
>>>>>>>>>> Group:    Individual Submission
>>>>>>>>>> Pages:    5
>>>>>>>>>> URL: https://www.ietf.org/archive/id/draft-iurman-6man-eh-occurrences-00.txt
>>>>>>>>>> Status:   https://datatracker.ietf.org/doc/draft-iurman-6man-eh-occurrences/
>>>>>>>>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-iurman-6man-eh-occurrences
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Abstract:
>>>>>>>>>>
>>>>>>>>>>       This document updates RFC 8200 by specifying normative requirements
>>>>>>>>>>       on the number of occurrences of IPv6 Extension Headers.  Operational
>>>>>>>>>>       experience has demonstrated that permitting multiple occurrences of
>>>>>>>>>>       the same Extension Header can create parsing ambiguity, increase
>>>>>>>>>>       attack surface, and complicate packet processing in general.  This is
>>>>>>>>>>       especially true for both the Hop-by-Hop Options Header and the
>>>>>>>>>>       Destination Options Header, which can contain a number of options.
>>>>>>>>>>       This document restricts IPv6 packets to carry at most one instance of
>>>>>>>>>>       each Extension Header, with the exception of the Destination Options
>>>>>>>>>>       Header, which is permitted to appear twice as specified in RFC 8200.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> List Info: 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]/
>>>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>>>> --------------------------------------------------------------------
>>>
>>