On Feb 3, 2024, at 1:50 AM, Bill Sommerfeld via illumos-discuss <[email protected]> wrote: > > On 2/2/24 21:41, Dan McDonald wrote: >>> On Feb 2, 2024, at 11:07 PM, Jesus Cea <[email protected]> wrote: >>> >>> I am using IPv6 and I noticed that by default SmartOS uses a flow label of >>> 0 (no flow label) in its IPv6 datagrams. I wonder how could I enable the >>> use of flow labels in order to be more compatible with for example, load >>> balancers (that hash (origin ip, destination ip, flowlabel) to route to a >>> backend server). For example, as described in >>> https://datatracker.ietf.org/doc/rfc7098/ >> If you are using pre-compiled software, that could be a useful RFE to have 0 >> == random if a IP netstack parameter is set. (I'm curious how BSD and Linux >> do this?) > > linux randomizes by default; this is explicitly encouraged by RFC6437 > (https://www.rfc-editor.org/rfc/rfc6437) and its successors.
So implicit 0 ==> random, huh? Nice! > It's IMHO not really reasonable to expect applications to do this, and the > TCP accept/listen API doesn't give servers a good place to inject a flow > label for the server->client direction. I figured getsockname() would report that, but I could be wrong. > So we should do this by default; for TCP it's easy (set at connection > establishment time to a uniformly distributed value between 1 and 2^20-1). > Appendix A of RFC6437 has a recommended hash function for this but anything > sufficiently random should work. We do have an in-kernel randomness api, hell even gethrtime() low or middle-low bits might work? Just grab a uint32_t's worth and mask. For UDP, we can do the same if we call connect() on the endpoint... if we don't do connect-send-disconnect on sendto/sendmsg like BSD does (I can't remember off the top of my head). > For IPsec, you want to use 20 bits of the SPI. You might think that in > tunnel mode you could use the inner flow label of the encapsulated packet, > but that would spread your SA traffic across multiple paths and blow up your > receiver's replay detection windows. Naturally. Tunnel mode SAs more often than not cover multiple inner flows so BOOM. > Another trick TCP can play with flow labels that I'm aware of: in networks > with significant multipathing it's been found useful to reroll the flow label > dice after loss or congestion - this juggles long-lived flows across > different paths and reduces overall congestion. A paper on this worth > reading: https://dl.acm.org/doi/10.1145/3544216.3544226 Again... Nice! Thanks for the education, Dan ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tf37a59e0bc93f2a7-Mb95443797ce6b9ffc6bae29a Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
