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

[Justin Iurman <[e-mail]>]

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.

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