> On 3. Feb 2024, at 16:27, Dan McDonald <[email protected]> wrote: > > 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.
random_get_bytes() and random_get_pseudo_bytes(). rgds, toomas > > 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-M9100d40ffba9a9e67ed75d02 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
