It didn’t agree with my understanding, either… Until I did a careful re-read
and found section 4.5, page 17, second paragraph:
“The Per-Fragment headers must consist of the IPv6 header plus any
extension headers that must be processed by nodes en route to the
destination, that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present,
else no extension headers.”
I would be really surprised if there is any implementation out there that
tosses datagrams that put just a destination options header before a fragment
header, but the standard would appear to say they can…
I found more related to this topic in RFC-3542, section 9.2, page 40:
The set preceding
a Routing header are specified with the cmsg_level member set to
IPPROTO_IPV6 and the cmsg_type member set to IPV6_RTHDRDSTOPTS. Any
setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently
ignored when sending packets unless a Routing header is also
specified.
Of course, this is referring to what is specified by the API, and doesn’t
exactly say the kernel can’t insert just a destination options header; however,
it does point out that numerous authors have been assuming there can’t be per
fragment destination options without a routing header.
Unfortunately, I think that if one wants the MCPHINT option to be useable for
defragmentation, one needs to include the null routing header. Unless…
This gives me an idea. What if the IPv6 MCPHINT was conveyed in a routing
header with a new routing type and zero for segments left? I cringe a little
bit, but it is a sort of routing.
From: Erik Kline <[email protected]>
Sent: Saturday, May 28, 2022 12:41 AM
To: Robinson, Herbie <[email protected]>
Cc: [email protected]
Subject: [EXTERNAL] Re: [Int-area] MCP Hint Option
[EXTERNAL SENDER: This email originated from outside of Stratus Technologies.
Do not click links or open attachments unless you recognize the sender and know
the content is safe.]
________________________________
Herbie,
Out of curiosity, can you explain more about what this sentence means:
"""
Note that RFC8200 [RFC8200] requires that per fragment destination
headers to be followed by a routing header.
"""
The way I read this sentence doesn't exactly agree with my understanding of
8200.
Thanks,
-ek
On Thu, May 26, 2022 at 6:47 PM Robinson, Herbie
<[email protected]<mailto:[email protected]>> wrote:
I would like to propose a small (8 page) RFC for the working group to take up.
This is small option that can drastically improve multi-core IPSec performance
in some situations.
draft-robinson-intarea-mcphint-00 - Multiple Core Performance Hint Option
(ietf.org)<https://datatracker.ietf.org/doc/draft-robinson-intarea-mcphint>
I have prototyped it and the prototype achieved a better than a 3x performance
increase on the first test case I tried (haven’t had time to do any more
testing).
There are some issues at the end of the document that I would definitely like
some feedback on.
Thanks for taking a look.
Also, I should mention that Stratus has applied for a patent. Management has
told me that it will be available free of charge. The online patent disclosure
should get filled in when management gets back from vacation (some time next
month).
_______________________________________________
Int-area mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area<https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
