[9front] [PATCH] ipv6 flow label support

[9front] [PATCH] ipv6 flow label support

[Arne Meyer]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hello,

this patch implements ipv6 flow labels. The labels are generated by hashing the 5-tuple (src,dst,proto,srcport,dstport) with the fnv-1a hash function (http://www.isthe.com/chongo/tech/comp/fnv/index.html). Flow labels are implemented for tcp, udp and esp.

Greetings,
Arne

[-- Attachment #2: flowlabel.patch --]
[-- Type: application/octet-stream, Size: 3509 bytes --]

diff 970d3b7eb7dc56aa84924dd68c4c39fd1df5d1f5 uncommitted
--- a/sys/src/9/ip/esp.c
+++ b/sys/src/9/ip/esp.c
@@ -339,6 +339,7 @@
 	Esptail *et;
 	Userhdr *uh;
 	Versdep vers;
+	uint hash;
 
 	getverslens(convipvers(c), &vers);
 	bp = qget(c->wq);
@@ -414,6 +415,11 @@
 
 		hnputl(eh6->espspi, ecb->spi);
 		hnputl(eh6->espseq, ++ecb->seq);
+
+		hash = flowhash(eh6->src, eh6->dst, IP_ESPPROTO, eh->spi, eh->spi+2);
+		eh6->vcf[1] = hash>>16;
+		eh6->vcf[2] = hash>>8;
+		eh6->vcf[3] = hash;
 	}
 
 	/* compute secure hash */
--- a/sys/src/9/ip/ipaux.c
+++ b/sys/src/9/ip/ipaux.c
@@ -578,3 +578,38 @@
 		csum = (csum & 0xFFFF) + v;
 	hnputs(pcsum, csum^0xFFFF);
 }
+
+#define FNV_INIT	0x811c9dc5
+#define FNV_PRIME	0x01000193
+
+static uint fnv(uchar *v, int l, uint h)
+{
+	int i;
+
+	for(i = 0; i < l; i++){
+		h ^= (uint) v[i];
+		h *= FNV_PRIME;
+	}
+
+	return h;
+}
+
+/*
+ * Compute ipv6 flowhash withe the fnv-1a hash function
+ */
+uint flowhash6(uchar *s, uchar *d, uchar p, uchar *sp, uchar *dp)
+{
+	uint h;
+
+	h = FNV_INIT;
+
+	h = fnv(s, IPaddrlen, h);
+	h = fnv(d, IPaddrlen, h);
+	h = fnv(&p, 1, h);
+	h = fnv(sp, 2, h);
+	h = fnv(dp, 2, h);
+
+	h = (h >> 20) ^ (h & 0x0fffff);
+
+	return h;
+}
\ No newline at end of file
--- a/sys/src/9/ip/ipv6.c
+++ b/sys/src/9/ip/ipv6.c
@@ -97,7 +97,7 @@
 	} else {
 		eh->vcf[0] = IP_VER6;
 		eh->vcf[0] |= tos >> 4;
-		eh->vcf[1]  = tos << 4;
+		eh->vcf[1] |= tos << 4;
 	}
 	eh->ttl = ttl;
 
--- a/sys/src/9/ip/ipv6.h
+++ b/sys/src/9/ip/ipv6.h
@@ -164,6 +164,7 @@
 extern int v6aNpreflen;
 extern int v6aLpreflen;
 
+uint flowhash6(uchar *, uchar *, uchar, uchar *, uchar *);
 void ipv62smcast(uchar *, uchar *);
 void icmpns6(Fs *f, uchar* src, int suni, uchar* targ, int tuni, uchar* mac, int maclen);
 void icmpna6(Fs *f, uchar* src, uchar* dst, uchar* targ, uchar* mac, int maclen, uchar flags);
--- a/sys/src/9/ip/tcp.c
+++ b/sys/src/9/ip/tcp.c
@@ -6,6 +6,7 @@
 #include	"../port/error.h"
 
 #include	"ip.h"
+#include	"ipv6.h"
 
 enum
 {
@@ -1025,6 +1026,7 @@
 	ushort csum;
 	ushort hdrlen, optpad = 0;
 	uchar *opt;
+	uint hash;
 
 	hdrlen = TCP6_HDRSIZE;
 	if(tcph->flags & SYN){
@@ -1090,7 +1092,11 @@
 
 	/* move from pseudo header back to normal ip header */
 	memset(h->vcf, 0, 4);
+	hash = flowhash6(h->tcpsrc, h->tcpdst, IP_TCPPROTO, h->tcpsport, h->tcpdport);
 	h->vcf[0] = IP_VER6;
+	h->vcf[1] = hash>>16;
+	h->vcf[2] = hash>>8;
+	h->vcf[3] = hash;
 	hnputs(h->ploadlen, hdrlen+dlen);
 	h->proto = ph->proto;
 
--- a/sys/src/9/ip/udp.c
+++ b/sys/src/9/ip/udp.c
@@ -193,6 +193,7 @@
 	int version;
 	Routehint *rh;
 	ushort csum;
+	uint hash;
 
 	upriv = c->p->priv;
 	f = c->p->f;
@@ -313,7 +314,11 @@
 			csum = 0xffff;	/* -0 */
 		hnputs(uh6->udpcksum, csum);
 		memset(uh6, 0, 8);
+		hash = flowhash6(uh6->udpsrc, uh6->udpdst, IP_UDPPROTO, uh6->udpsport, uh6->udpdport);
 		uh6->viclfl[0] = IP_VER6;
+		uh6->viclfl[1] = hash>>16;
+		uh6->viclfl[2] = hash>>8;
+		uh6->viclfl[3] = hash;
 		hnputs(uh6->len, ptcllen);
 		uh6->nextheader = IP_UDPPROTO;
 		ipoput6(f, bp, nil, c->ttl, c->tos, rh);
--- a/sys/src/cmd/ip/snoopy/ip6.c
+++ b/sys/src/cmd/ip/snoopy/ip6.c
@@ -279,8 +279,8 @@
 	if(len < m->pe - m->ps)
 		m->pe = m->ps + len;
 
-	m->p = seprint(m->p, m->e, "s=%I d=%I ttl=%3d pr=%d ln=%d",
-		h->src, h->dst, h->ttl, h->proto, NetS(h->length));
+	m->p = seprint(m->p, m->e, "s=%I d=%I ttl=%3d pr=%d fl=%ux ln=%d",
+		h->src, h->dst, h->ttl, h->proto, Net3(h->vcf+1) & 0x0fffff, NetS(h->length));
 	v6hdr_seprint(m);
 	return 0;
 }

Re: [9front] [PATCH] ipv6 flow label support

[cinap_lenrek]

hey man,

this looks pretty wild and i cant wrap my head around
why the hell would the *SENDER* put the hash instead
of the receiveriver calculating it...

currently, the user can set the tos field for its
connection using a ctl message... that should
go into the flow label field so its up to the user
making the connection.

is here any RFC suggesting the flowlabel should be
a hash that could easilly be calculated by the
receiver on the existing ip header fields?

i really need more context to convince me that this
is the right thing todo.

a rfc would do.

--
cinap

Re: [9front] [PATCH] ipv6 flow label support

[cinap_lenrek]

rfc6437?

--
cinap

Re: [9front] [PATCH] ipv6 flow label support

[Arne Meyer]

Jep,

section 3 says; and i quote "source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow." i chose the fnv hash because it's supposed to have a uniform distribution of hash values that satisfies the RFC.

> cinap_lenrek@felloff.net hat am 25.11.2023 21:51 CET geschrieben:
> 
>  
> rfc6437?
> 
> --
> cinap

Re: [9front] [PATCH] ipv6 flow label support

[cinap_lenrek]

ok, just read the rfc...

i suppose we should probably calculate the flowhash when
we establish the connection and know the 5-tuple
instead of doing that hash for every single packet
being sent out.

special case is udp, which can work in headers mode.

--
cinap

Re: [9front] [PATCH] ipv6 flow label support

[Arne Meyer]

yes we could calculate the flow hash when we start the connection, but the RFC refers to stateless methods for calculating the flow label. FNV is a cheap hash function, i think the performance impact is negligible.
I agree about udp header mode, I can update the patch.

> cinap_lenrek@felloff.net hat am 25.11.2023 22:05 CET geschrieben:
> 
>  
> ok, just read the rfc...
> 
> i suppose we should probably calculate the flowhash when
> we establish the connection and know the 5-tuple
> instead of doing that hash for every single packet
> being sent out.
> 
> special case is udp, which can work in headers mode.
> 
> --
> cinap

Re: [9front] [PATCH] ipv6 flow label support

[cinap_lenrek]

the more i learn about the ipv6 flow-label the more
of a rabbit hole it becomes.

so it seems that some load-banalcer people actually dont
use the flowlabel anymore because of middle boxes
filling in random flowlabels across the same tcp
session, breaking the whole scheme. [1]

then linux implements crazy flow-label changes during
tcp retransmission timeouts to work around broken
paths in load balancers to switch to a different path. [2]

more concerning is the use for flow labels to generate
a unique per device id independent of the protocols
and ip addresses used as windows and linux haved used
keyed hash functions that have been shown to be reversible
as the 5-tuple hash input is known by an observer
and you can extract the static key used for the hashing
and use that to identify the device across differnet
ip addresses and protocols. [3]

[1] https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
[2] https://datatracker.ietf.org/meeting/111/materials/slides-111-rtgwg-sessb-3-selfhealing-network-01
[3] https://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=9152759&ref=

arne, is here any particular REASON why we should
not just put ZERO in the flow-label field and pretend
flow-labels dont exist?

this thing seems to have cause enougth damage to
the ipv6 internet.

--
cinap

Re: [9front] [PATCH] ipv6 flow label support

[Arne Meyer]

After I did some more research I have to agree with you.
Flow labels seem to be badly broken, my patch should not go in and we should probably ignore the whole mess.
This sucks :(

> cinap_lenrek@felloff.net hat am 26.11.2023 14:28 CET geschrieben:
> 
> arne, is here any particular REASON why we should
> not just put ZERO in the flow-label field and pretend
> flow-labels dont exist?
> 
> this thing seems to have cause enougth damage to
> the ipv6 internet.
> 
> --
> cinap

Re: [9front] [PATCH] ipv6 flow label support

[ori]

Quoth Arne Meyer <meyer.arne83@netcologne.de>:
> i think the performance impact is negligible.

please measure, we can send a lot of packets.