[IPv6]Re: Gorry Fairhurst's Discuss on draft-ietf-6man-eh-limits-19: (with DISCUSS and COMMENT)

[Tim Chown <[e-mail]>]

Hi,

On 25/04/2025, 23:27, "Justin Iurman" <[e-mail]> wrote:

Hi Tom,

On 4/25/25 20:28, Tom Herbert wrote:
> Nick,
>
>>From section 8 of that paper:
>
> "We also showed that IPv6 EHs drops are caused by some ASes, generally
> quite close to the packet source, due to policies"
>
> Technically that's true, but it's quite misleading as to what the real
> cause of drops is.
>
> There's no evidence that packets are being dropped because of an
> explicit policy to drop packets with Extension Headers (at least not
> HBH). For instance, there's no reason for a firewall to set a filter
> based on the length of Destination Options (only the end host
> processes them per RFC8200). But, we see a strong correlation between
> the length of Destination Options and drops. So explicit policies
> don't explain the drops.

Well, there is no evidence to the contrary either. Truth is, we can't
tell because it's case by case. For example, I've seen Hbh's or Dest's
of [8, 1024] bytes going through, and sometimes specific sizes not going
through, and so for the same path. This, combined to some verifications
on recent hardware tends to prove it's due to policies, not hardware.

On the other hand, we've tested old hardware and there is indeed a
buffer limit on some. One of them was dropping packets with Hbh or Dest
 >= 256 bytes, for example. So, I don't think hardware with a 64-byte
buffer limit (like we used to have 10 or 20 years ago) is still relevant
nowadays. If you really want to go that way (and we've already discussed
that in Santa Clara last year during Netdev), I'd ACK this draft with a
bigger (minimum) "limit" (btw, I don't like this term, +1 to Tim).

> The most plausible explanation is that packets are being dropped
> because the presence of Extension Headers is pushing the L4 headers
> too deep in the packet for the device's capabilities (section 8.1,

Agree with that, not saying it's incorrect. However, again, I'm not sure
it's more plausible than my explanation above. All valid causes.
Besides, the pattern you see around some sizes (64 in your case) may not
be what you think it is. There are other explanations as well, all
valid, but we don't know until we can isolate and test those specific
nodes. It's probably a bit premature to ship a 64-byte "limit" based on
what we know.

Hi Justin, just to say (a) a very nice paper, well done and 9B0 the paragraph above sums up exactly what I was trying to express previously.

I guess it’s down to the ADs now, I don’t think there’s much more to be said.

Tim


Justin

> RFC9098). It is very common for intermediate nodes to filter packets
> based on L4 headers, i.e. NAT, firewalls, etc., so if a firewall
> cannot access the L4 header then the default policy may be to drop the
> packet. For instance, a firewall may only allow UDP and TCP packet
> through, if a packet is received with 256 bytes of Extension Headers
> and the device parsing buffer is only 128 bytes then the packet will
> be dropped since the node cannot identify the IP protocol and the
> default policy is likely to drop. This cannot be fixed by just
> configuration, the parsing buffer is a limited physical resource in
> many router designs. We can, however, extrapolate from the data that a
> parsing buffer size of at least 128 bytes has good support on the
> Internet.
>
> So, yes, technically many drops are due to policy, but it's only an
> indirect consequence of using Extension Headers.
>
> Tom
>
>>
>> Nick
>>
>> And even that most
>>> drops are caused by a smaller number of ASNs, close to the point of
>>> ingress to the ASN, for the ASNs tested in Table 4.
>>>
>>> To be fair, the paper does talk of “old” routers, e.g.:
>>>
>>> “For example, Ouellette [42] reports a router running a default
>>> configura[1]tion with hardware limit (i.e., with a limited parsing
>>> buffer size for the headers), which seems to drop a packet as soon as
>>> the total size of IPv6 EHs reaches something between 160 and 192 bytes.
>>> This kind of limit exists in old routers, where the parsing buffer size
>>> is quite small (usually 256 bytes max, sometimes even smaller, e.g., 64
>>> or 128 bytes, for older routers [9]).”
>>>
>>> But we must not set limits now based on yesterday’s hardware.
>>>
>>> So when you say "don't ossify it so low" it's a bit of an irony to me.
>>> The Internet is currently ossified at zero, and we're trying to move the
>>> needle to something greater than zero. The draft is trying to provide
>>> reasonable and practical guidance. And yes, the draft is giving the
>>> minimum limits of support for routers, at least for those that require
>>> access to L4 headers. There is sufficient data that the minimum limits
>>> proposed in the draft are supportable and could gain nearly ubiquitous
>>> support across the Internet. OTOH, we could mandate some arbitrarily
>>> high level of support, but good luck getting ubiquitous support in
>>> deployment.
>>>
>>> It's not ossified at zero.  There is a problem, but please don’t be
>>> overly dramatic.
>>>
>>> The above paper suggests most drops are down to policy, not hardware
>>> limitations. We should look at more evidence like that.  Which is why
>>> I’d strongly advise the ADs to return this draft to 6man while that
>>> evidence is gathered, and the less controversial part – the protection
>>> of nodes from attacks – is advanced with the rest removed for potential
>>> resubmission in a new draft.
>>>
>>>
>>>
>>>      > I’d like to discuss whether the I-D could be constrained to avoid this, and
>>>      > allow the minimum size to evolve.
>>>
>>>      Do you have suggestions on how to approach this?
>>>
>>> Isn't that the point of a BCP, to revisit manifest constants as
>>> technology evolves (IMO this draft should be a BCP).
>>>
>>> If it’s proven BCP.  You’re just handwaving a “solution” without the
>>> evidence to back it up. We need more data like the above.
>>>
>>>      I’d like to see the draft only cover what’s in 7.3 of RFC8504
>>>      section 5.3, on limits for processing to protect nodes against DoS
>>>      and other attacks.  This would put the draft in the same area as
>>>      draft-ietf-6man-deprecate-router-alert. The RFC then covering other
>>>      processing would remain RFC 9673 (on top of RFC 8200).  RFC 8504-bis
>>>      could then point to that work and remove its ‘interim’ text of 5.3
>>>      that I’ve personally considered a placeholder for this draft.
>>>
>>> DoS isn't the problem, nodes on the Internet are dropping packets just
>>> because they contain extension headers. In lieu of practical guidance,
>>> routers have taken it upon themselves to define ad hoc level of support
>>> which has resulted in making EH essentially unusable on the Internet. I
>>> believe the draft is useful to set some minimal requirements so the EH
>>> becomes at least a possibility to use.
>>>
>>> The “routers” (router vendors I assume you mean) haven’t defined an
>>> ad-hoc level of support.  The paper suggests otherwise. If you believe
>>> they have, have you pointers to the evidence?
>>>
>>> But DoS could be a problem, and is one we should give guidance on
>>> protecting against, just as we do with actions like we have taken on
>>> router alerts. That was the point of section 5.3 of RFC8504. This draft
>>> should be the expansion of that and stay away from setting arbitrary,
>>> and very low, EH length limits.
>>>
>>> OTOH, if there's a better way than setting minimal requirements and
>>> level of support to make EH usable I'm all ears, but to date no one has
>>> yet proposed anything specific AFAICT.
>>>
>>> Minimal requirements for who?  The vendors, or the operators?
>>>
>>> We need more data like that presented in the above paper.  Until then,
>>> we should only publish this draft as one that sets limits to enable the
>>> protection of nodes as per 5.3 of RFC8504, so we can then remove that
>>> section from 8504-bis and point at this RFC-to-be from there.
>>>
>>> Then a new draft needs to be discussed about handling of EHs by length.
>>> Which seems to be more a policy issue than hardware one.  We already
>>> have RFC 9673.
>>>
>>> And the new draft should not have the word “limits” in its title if we
>>> want to encourage a minimum level of conformance, particularly with
>>> policy.  Which also suggests that the new draft might be better homed in
>>> v6ops.
>>>
>>> Tim
>>>
>>> Tom
>>>
>>>      Tim
>>>
>>>
>>>
>>>      Nick
>>>
>>>      --------------------------------------------------------------------
>>>      IETF IPv6 working group mailing list
>>>      [e-mail] <mailto:[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]/
> --------------------------------------------------------------------