Re: [Int-area] [EXTERNAL] Re: MCP Hint Option

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 <ek.ietf@gmail.com>
Sent: Saturday, May 28, 2022 12:41 AM
To: Robinson, Herbie <Herbie.Robinson@stratus.com>
Cc: int-area@ietf.org
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 <Herbie.Robinson@stratus.com<mailto:Herbie.Robinson@stratus.com>> 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
Int-area@ietf.org<mailto:Int-area@ietf.org>
https://www.ietf.org/mailman/listinfo/int-area<https://www.ietf.org/mailman/listinfo/int-area>