On 2/2/24 22:54, Toomas Soome via illumos-discuss wrote:
On 3. Feb 2024, at 07:50, 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.
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.
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.
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.
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
- Bill
is the flowadm(8) related there?
Not really. The flows that flowadm(8) administers are larger-scale
aggregates, while the flows labeled by the IPv6 flow label are fine
grained (each TCP connection is two flows, with one in each direction).
If you're doing link aggregation or equal-cost multipathing, you need
some way to distribute these microflows across links or next-hops such
that all packets in each microflow take the same path but different
microflows can take different paths.
With ipv4, routers and switches have to parse quite a bit of the packet
header to find the L4 header to extract port numbers for a flow hash;
with v6, the 20-bit flow label is at a fixed location at the top of the
L3 header, and much easier to find either in silicon or software.
- Bill
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Tf37a59e0bc93f2a7-Mcebce0ff361943707f18f6c0
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
