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

[Tom Herbert <[e-mail]>]

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.

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]/
> >> --------------------------------------------------------------------
>