Closed toreanderson closed 9 years ago
Oh wow.
It's pretty surprising. Not only did I miss that paragraph from the RFC in the other issue, but I even forgot that we actually had already noticed that and casually coded it some time ago in branch ipv6_db.
(in case you're considering downloading that commit: that code underwent some testing but hasn't been reviewed. Approach with caution)
(BTW: There's a typo there. The flag is called "--genFH", not "--buildFH".)
Cool, you guys really rock! :-)
I tested the branch. It's not quite ready yet, I think. If --genFH
is disabled, and Jool receives an IPv4 packet is received that is too large to fit in the --minMTU6
value, the result is two fragmented IPv6 packets (no way around that, right), but there's no Fragment header included, which results in bogus packets:
Demonstrated below with --minMTU6 1500
, tcpdump taken directly on Jool node:
12:06:07.662302 IP (tos 0x0, ttl 63, id 50800, offset 0, flags [none], proto UDP (17), length 1481)
87.238.39.42.12345 > 185.47.42.1.4444: UDP, length 1453
12:06:07.662358 IP6 (hlim 62, next-header UDP (17) payload length: 1456) 64:ff9b::57ee:272a.12288 > 2001:db8::1.4441: [bad udp cksum 0xdaaf -> 0x429f!] UDP, length 1453
12:06:07.662371 IP6 (hlim 62, next-header UDP (17) payload length: 13) 64:ff9b::57ee:272a.12288 > 2001:db8::1.5888: [bad udp cksum 0xdaaf -> 0x9eab!] UDP, length 1453
If I however drop the IPv4 packet size to 1480 I get a well-formed non-[atomic-]fragmented 1500 byte large IPv6 packet:
12:11:07.582394 IP (tos 0x0, ttl 63, id 38976, offset 0, flags [none], proto UDP (17), length 1480)
87.238.39.42.12345 > 185.47.42.1.4444: UDP, length 1452
12:11:07.582493 IP6 (hlim 62, next-header UDP (17) payload length: 1460) 64:ff9b::57ee:272a.12345 > 2001:db8::1.4444: [udp sum ok] UDP, length 1452
Also, with 1481 bytes IPv4 packet and --genFH ON
I get well-formed IPv6 fragments:
12:11:50.925460 IP (tos 0x0, ttl 63, id 214, offset 0, flags [none], proto UDP (17), length 1481)
87.238.39.42.12345 > 185.47.42.1.4444: UDP, length 1453
12:11:50.925516 IP6 (hlim 62, next-header Fragment (44) payload length: 1456) 64:ff9b::57ee:272a > 2001:db8::1: frag (0x000000d6:0|1448) 12345 > 4444: UDP, length 1453
12:11:50.925531 IP6 (hlim 62, next-header Fragment (44) payload length: 21) 64:ff9b::57ee:272a > 2001:db8::1: frag (0x000000d6:1448|13)
Jool is true to the spec in that it will generate atomic fragments whenever it receives an IPv4 packet with DF=0 (assuming the resulting packet does not exceed the value of ''--minMTU6'', in which case it will necessarily be split into real fragments).
However, RFC 6145 allows the translator to provide a function to disable this behaviour. Quoting from section 4 «Translating from IPv4 to IPv6»:
It would be nice if Jool had such an option, because operationally speaking, it is best to avoid fragments whenever possible.
Also note that if draft-gont-6man-deprecate-atomfrag-generation passes, RFC 6145 would be updated to make this behaviour the default.
There's some background discussion in the final comments on issue #118.