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

[Nick Hilliard <[e-mail]>]

Justin Iurman wrote on 25/04/2025 23:47:
> I appreciate the assertive tone of your response. I'm curious to hear 
> why you think it's out of scope for the IETF. And I'm not saying that 
> because I'm the author of the said paper.

it's because the ietf isn't a review channel for general papers and 
specifically because the topic of this email thread is the IETF AD 
review of draft-ietf-6man-eh-limits.

I'd be happy to discuss your article offline.

Nick

> About the conclusion: of course it's speculative. The reason is simple. 
> You can't conclude A or B (or whatever) and be 100% sure. For that, 
> you'd have to test and isolate every single node. Good luck with that. 
> What we discuss in the paper is a trend based on observations and 
> measurements.
> 
>> Some of the more eyebrow-raising quotes:
> 
> Some parts of this email are eyebrow-raising too ;-)
> 
>> "Important note: there is no intersection between the list of 
>> traversed ASes and the list of ASes that responded to the survey"
>>
>> "However, this could highlight some cases where old routers or bugs 
>> are the main cause of IPv6 EHs drops." Really?
> 
> Not sure what's the benefit of pasting some bits of the paper without 
> context.
> 
>> "Overall, routers from different vendors are expected to share the same 
>> kind of behavior with a default configuration, which therefore gives a 
>> trend and a big picture of what should be observed in the wild. 
>> Therefore, we assume our infrastructure being as representative as 
>> possible.". This assumption is both invalid and incorrect.
> 
> Are you saying we can't reasonably expect vendors to ship hardware that 
> is RFC-compliant regarding IPv6 (with vanilla configs)? Are you saying 
> they don't pass validation tests regarding IPv6?
> 
>> "As for the Juniper router, its results may not be entirely accurate, 
>> since we had to test a virtual image of the MX series with 
>> Containerlab [10] instead of physical hardware."
>>
>> "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])" - where reference [9] 
>> points to a document from 2006, i.e. around 19 years before the paper 
>> was published in March 2025. The authors need to provide more recent 
>> data because a single 19yo reference is a straw man argument.
> 
> Well, that's exactly the point of having such an old reference. We're 
> saying (very) old hardware had small buffer limits, but not recent one. 
> Having recent refs saying buffer limits are still that small is 
> impossible because they're not anymore, at least not that, 64-byte, small.
> 
>> "In order to determine the AS responsible for a drop, we chose to follow
>> this simple assumption: an AS will generally apply ingress filtering 
>> on IPv6 EHs [20]." - reference [20] points to RFC9098 which refers to 
>> iACLs.
>>
>> The lab test is obviously interesting, and it would be good to test a 
>> larger range of equipment. However, it does not model the real world 
>> in a meaningful fashion and given the limitations described in the 
>> text, the authors were not justified in arriving at the conclusions in 
>> section 8.
> 
> That's correct, and we're not pretending to model the real world. Not 
> sure someone can, actually. Again, we're discussing trends based on what 
> we saw. Good luck if you want to say for sure "it's because {your 
> opinion}".
> 
> Justin
> 
>> 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]/
>> --------------------------------------------------------------------