NICMx / Jool

SIIT and NAT64 for Linux
GNU General Public License v2.0
320 stars 66 forks source link

Option to disable atomic fragments #120

Closed toreanderson closed 9 years ago

toreanderson commented 9 years ago

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»:

   When the IPv4 sender does not set the DF bit, the translator SHOULD
   always include an IPv6 Fragment Header to indicate that the sender
   allows fragmentation.  The translator MAY provide a configuration
   function that allows the translator not to include the Fragment
   Header for the non-fragmented IPv6 packets.

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.

ydahhrk commented 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".)

toreanderson commented 9 years ago

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)
ydahhrk commented 9 years ago

http://jool.mx/usr-flags-atomic.html#genfh