[IPv6]Re: rfc8504bis

[Brian E Carpenter <[e-mail]>]

Tom,

I'll focus on your conclusion:

>  IMO, setting
> the default limit to zero for destination and HBH options would be
> entirely reasonable. In the datacenter where extension headers can be
> useful, configuring higher limits is easy enough.

To be clear, we're talking (in section 5.3) about end-hosts, not nodes
in general. The text already allows a host to "place limits on the number
and sizes of extension headers and options it is willing to process."
However, I'm not comfortable with setting a default, because whatever we
pick will be wrong. A default of zero would definitely promote ossificaton.

Regards/Ngā mihi
    Brian Carpenter

On 23-Jul-26 06:27, Tom Herbert wrote:
> On Tue, Jul 21, 2026 at 2:01 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> We might as well say that anything that isn't forbidden is allowed, which has always been the case on the Internet anyway. It's better to say nothing than to attempt any such global statements. I think the current text is fine.
> 
> Brian,
> 
> Note that RFC8200 does not allow for packets to be dropped because
> they contain extension headers:
> 
> "Extension headers (except for the Hop-by-Hop Options header) are not
> processed, inserted, or deleted by any node along a packet's delivery
> path, until the packet reaches the node (or each of the set of nodes,
> in the case of multicast) identified in the Destination Address field
> of the IPv6 header."
> 
> We know that packets are commonly dropped because they contain
> extensions; therefore, intermediate nodes are somehow processing them
> contrary to RFC8200. This isn't because nodes are concerned with the
> extension headers themselves, it's because EH pushes the transport
> header too deep in the packet, preventing the node from processing it,
> which is necessary for filtering. So I claim that Internet routers
> doing this are indeed out of compliance with the standard, and the
> practical effect is that sending extension headers over the Internet
> is a nonstarter.
> 
> Regarding section 5.3 of RFC8504, if I were to suggest any changes I
> would recommend much tighter limits. For the vast majority of hosts on
> the Internet extension headers serve no purpose, and processing them
> wastes compute cycles and presents an obvious DoS vector. IMO, setting
> the default limit to zero for destination and HBH options would be
> entirely reasonable. In the datacenter where extension headers can be
> useful, configuring higher limits is easy enough.
> 
> Tom
> 
>>
>>
>> Regards/Ngā mihi
>>      Brian Carpenter
>>
>> On 22-Jul-26 03:08, Tim Chown wrote:
>>> Well, we’re talking about end/receiving host protection here.
>>>
>>> Note the text that’s being commented on in 8504 has been that way since at least 2019.
>>>
>>> Tim
>>>
>>> On 21/07/2026, 16:32, "Tom Herbert" <tom=[e-mail]> wrote:
>>>
>>>
>>>
>>> On Tue, Jul 21, 2026 at 7:04 AM Tim Chown <Tim.Chown=[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>      So “be conservative in what you do, be liberal in what you discard from others”? 😉
>>>
>>>
>>> That seems to be reality on the Internet  with regards to extension headers.
>>>
>>> Tom
>>>
>>>
>>>      On 21/07/2026, 15:55, "Tom Herbert" <tom=[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>>      On Tue, Jul 21, 2026 at 12:41 AM Bonica, Ron <ronald.bonica=[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>          Tom,
>>>
>>>          To the contrary, I think the draft should say:
>>>
>>>          "A host MAY discard any incoming packet, according to its local policy".
>>>
>>>
>>>      Ron,
>>>
>>>      Then why not just say "Any node MAY discard any incoming packet, according to its local policy"? That would immediately bring all hosts and routers on the Internet into protocol compliance :-)
>>>
>>>
>>>          All rules subsumed by that rule should be deleted because they are redundant.
>>>
>>>
>>>      Yep, problem solved!
>>>
>>>      Tom
>>>
>>>
>>>                                                                                          Ron
>>>          ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>          *From:* Tom Herbert <tom=[e-mail] <mailto:[e-mail]>>
>>>          *Sent:* Tuesday, July 21, 2026 2:52 AM
>>>          *To:* Bonica, Ron <[e-mail] <mailto:[e-mail]>>
>>>          *Cc:* 6man <[e-mail] <mailto:[e-mail]>>
>>>          *Subject:* Re: [IPv6]rfc8504bis
>>>
>>>
>>>          On Mon, Jul 20, 2026, 8:41 AM Bonica, Ron <ronald.bonica=[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>              Folks,
>>>
>>>              RFC8504bis says:
>>>
>>>              "A host MAY disallow unknown options in destination options or hop-by-hop options. This SHOULD be configurable where the default is to accept unknown options and process them per [RFC8200]. If a packet with unknown options is received and the host is configured to disallow them, then the packet SHOULD be silently discarded."
>>>
>>>              At first glance, this appears to be a violation of 8200. However, this rule applies to hosts only and a host can discard any packets that violate its policy.
>>>
>>>              I recommend replacing the word "disallow" with "discard" amplifying the fact that this rule applies to host only, and not routers.
>>>
>>>
>>>          Hi Ron,
>>>
>>>          I don't see why this change is necessary. It's clear from the requirement and the section title that the requirement and the others in the section are only applicable to hosts.
>>>
>>>          Of course, in the real world routers do drop various packets with extension headers at their leisure which directly violates RFC8200. However, I don't think router vendors would bother to twist RFC8504 to somehow legitimize that.
>>>
>>>          Tom
>>>
>>>
>>>                                                                                            Ron
>>>
>>>
>>>              --------------------------------------------------------------------
>>>              IETF IPv6 working group mailing list
>>>              [e-mail] <mailto:[e-mail]>
>>>              List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ <https://urldefense.com/v3/__https://mailman3.ietf.org/mailman3/lists/[e-mail]/__;!!NpxR!g_SqChRPD1Tfqk48g2-yZjhq8YlqSXYlJBhCzIxhD5Daj815syyewN3Rpvv8Oo11acSyoUvpgBdDBfSQoiEu1we7fVewDOs3$>
>>>              --------------------------------------------------------------------
>>>
>>>
>>> --------------------------------------------------------------------
>>> 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]/
>> --------------------------------------------------------------------