[IPv6]Re: Call for adoption: draft-iurman-6man-eh-occurrences-02 (Ends 2026-05-17)

[Tom Herbert <[e-mail]>]

On Thu, Apr 23, 2026 at 10:23 AM Justin Iurman <[e-mail]> wrote:
>
> Hi Tom,
>
> On 4/23/26 12:57, tom petch wrote:
> > From: Justin Iurman <[e-mail]>
> > Sent: 22 April 2026 15:54
> >
> > Hi Tom,
> >
> > As Tom (the other one :D) mentioned, ICMPv6 errors are the indication.
> > The draft says: "[...] MAY send an ICMP Parameter Problem message
> > [...]". Yes, it is only a "MAY", but "SHOULD" or "MUST" would probably
> > be too strong here. OTOH, RFC8200 recommends (although without normative
> > language) to respect the specified ordering and number of occurrences. I
> > don't have data to support what I'm about to say, but, I'm pretty sure
> > there is no legitimate packet out there with out-of-order or
> > more-than-allowed Extension Headers. Such packets should be flagged as
> > suspicious, and dropping them seems reasonable anyway.
> >
> > <tp>
> > It is the 'MAY' that catches my attention and drives me to respond.  I find that too vague for an update to IPv6.  By now we should be nailing IPv6 down much tighter IMHO.
>
> [JI] We'll have plenty of time to discuss s/MAY/SHOULD (or are you
> thinking MUST?) after the adoption.

Actually, looking at RFC8883 the ICMP errors for reporting packet
drops by routers are a SHOULD to send. Probably, it makes sense to use
SHOULD here as well.

>
> > And as I said in my other post. if there is no such legitimate packet out there, then is it worth the effort of creating an RFC which updates the existing IPv6 ones?  IMHO, no; if it is worth doing, then we should do it more thoroughly.

It depends on what you mean by "legitimate". If someone launches a DOS
attack on a host by packing 700 Destination  Option headers into
single MTU sized packet is that a legitimate packet? :-)

Tom

>
> [JI] IMHO, hosts need to be allowed to protect themselves against
> abusive use of EHs. Right now, it's too permissive, as RFC8200 expects
> them to process pretty much anything. Not having such legitimate packet
> out there (theoretically) does not mean that malicious ones do not exist.
>
> Justin
>
> > Cheers,
> > Justin
> >
> > On 4/22/26 13:26, tom petch wrote:
> >> So packets may vanish into a black hole without any warning and with no indication what is going on.
> >>
> >> It sounds like an idea that needs more thinking through.  How can I tell that this is why my packets are vanishing and what I should do about it?  You really need something somewhere to tell users about these boxes which have a built-in black hole that you cannot detect (like most black holes).
> >>
> >> Tom Petch
> >>
> >> ________________________________________
> >> From: Jen Linkova via Datatracker <[e-mail]>
> >> Sent: 22 April 2026 08:32
> >>
> >> This message starts a 6man WG Call for Adoption of:
> >> draft-iurman-6man-eh-occurrences-02
> >>
> >> This Working Group Call for Adoption ends on 2026-05-17
> >>
> >> Abstract:
> >>      Operational experience has demonstrated that permitting multiple
> >>      occurrences of the same IPv6 Extension Header can create parsing
> >>      ambiguity, complicate packet processing, and increase potential
> >>      security risks.  Although RFC 8200 recommends that senders follow a
> >>      specific order of appearance and limit the occurrences of Extension
> >>      Headers, receivers cannot assume that these recommendations have been
> >>      followed.  This document updates RFC 8200 by allowing an IPv6
> >>      destination node, namely a host (i.e., the final destination of an
> >>      IPv6 packet) or an intermediate destination node addressed by an
> >>      entry in a Routing header list other than the final one, to enforce
> >>      strict ordering and limits on the occurrence of Extension Headers.
> >>
> >> Please reply to this message and indicate whether or not you support adoption
> >> of this Internet-Draft by the 6man WG. Comments to explain your preference
> >> are greatly appreciated. Please reply to all recipients of this message and
> >> include this message in your response.
> >>
> >> Authors, and WG participants in general, are reminded of the Intellectual
> >> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
> >> Appropriate IPR disclosures required for full conformance with the provisions
> >> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> >> Sanctions available for application to violators of IETF IPR Policy can be
> >> found at [3].
> >>
> >> Thank you.
> >> [1] https://datatracker.ietf.org/doc/bcp78/
> >> [2] https://datatracker.ietf.org/doc/bcp79/
> >> [3] https://datatracker.ietf.org/doc/rfc6701/
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-iurman-6man-eh-occurrences/
> >>
> >> There is also an HTMLized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-iurman-6man-eh-occurrences-02
> >>
> >> A diff from the previous version is available at:
> >> https://author-tools.ietf.org/iddiff?url2=draft-iurman-6man-eh-occurrences-02
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> >> --------------------------------------------------------------------
> >
>