Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1280 bytes. The path between our system and your network has an MTU of 1480 bytes. The bottleneck is at IP address 2001:470:0:6e::2. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1472 bytes. The path between our system and your network has an MTU of 1480 bytes. The bottleneck is at IP address 2001:470:0:69::2. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1472 bytes. The path between our system and your network has an MTU of 1450 bytes. The bottleneck is at IP address 2001:1900:5:1::229. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
Your host, NAT, or firewall acts as a DNS server or proxy. Requests sent to this server are eventually processed by 216.66.80.90.
This is probably a bug in your NAT's firmware, and represents a minor security vulnerability.
IPv6 Path MTU (?): Warning
Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1480 bytes. The path between our system and your network has an MTU of 1480 bytes. The bottleneck is at IP address 2001:470:20::2. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
109.551 test-42| Message: mtu 1488 64
109.552 test-42| UDP socket at 2001:470:67:22f:224:2cff:feaa:6383:46451
109.732 test-42| Got datagram of 29 bytes.
109.732 test-42| Responsive failure
109.732 test-42| Response is bad 1488 2001:470:20::2 1480
109.732 test-42| Works: 1476
109.732 test-42| Fails: 1488
109.732 test-42| At: 1482
109.732 test-42| Message: mtu 1482 64
109.733 test-42| UDP socket at 2001:470:67:22f:224:2cff:feaa:6383:45177
109.903 test-42| Got datagram of 29 bytes.
109.903 test-42| Responsive failure
109.904 test-42| Response is bad 1482 2001:470:20::2 1480
109.904 test-42| Works: 1476
109.904 test-42| Fails: 1482
109.904 test-42| At: 1479
109.904 test-42| Message: mtu 1479 64
109.905 test-42| UDP socket at 2001:470:67:22f:224:2cff:feaa:6383:56287
110.004 test-42| Got datagram of 1024 bytes.
110.005 test-42| Success
110.005 test-42| Works: 1479
110.005 test-42| Fails: 1482
110.005 test-42| At: 1480
110.005 test-42| Message: mtu 1480 64
110.005 test-42| UDP socket at 2001:470:67:22f:224:2cff:feaa:6383:35993
110.103 test-42| Got datagram of 1024 bytes.
110.103 test-42| Success
110.103 test-42| Works: 1480
110.103 test-42| Fails: 1482
110.103 test-42| At: 1481
110.103 test-42| Message: mtu 1481 64
110.104 test-42| UDP socket at 2001:470:67:22f:224:2cff:feaa:6383:36066
110.276 test-42| Got datagram of 29 bytes.
110.277 test-42| Responsive failure
110.277 test-42| Response is bad 1481 2001:470:20::2 1480
110.277 test-42| Final MTU is 1480
Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1480 bytes. The path between our system and your network has an MTU of 1480 bytes. The bottleneck is at IP address 2001:470:0:5d::2. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
So yeah, its "bad" because it's limited to 1480?
163.903 main|
163.903 main| Running test 42: checkMTUV6
163.903 main| ----------------------------
163.913 test-42| Testing the ability to send a large UDP packet (2000 bytes) over IPv6
163.913 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.913 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53348
163.914 test-42| Got exception java.net.SocketException: Message too long on UDP test
163.914 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.914 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53349
163.966 test-42| Got exception java.net.PortUnreachableException: ICMP Port Unreachable on UDP test
163.966 test-42| Can't send UDP fragments
163.966 test-42| Testing the ability to receive a large UDP packet (2000 bytes) over IPv6
163.966 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.966 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53350
164.023 test-42| Got exception java.net.PortUnreachableException: ICMP Port Unreachable on UDP test
164.023 test-42| Can't receive UDP fragments
164.023 test-42| Attempting to send a packet with
164.023 test-42| fragmentation of 2009 bytes
164.023 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
165.024 test-42| No data received.
165.024 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
166.025 test-42| No data received.
166.025 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
167.025 test-42| No data received.
167.025 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
168.026 test-42| No data received.
168.027 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
169.028 test-42| No data received.
169.028 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
170.028 test-42| No data received.
170.029 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
171.029 test-42| No data received.
171.029 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
172.030 test-42| No data received.
172.030 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
173.032 test-42| No data received.
173.032 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
174.033 test-42| No data received.
174.033 test-42| No reply back
174.033 test-42| Now looking for the receive MTU. Trying 1500 first
174.033 test-42| MSG: mtu 1500 64
174.033 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53352
174.095 test-42| Got datagram of 31 bytes.
174.095 test-42| Response is bad 1500 2001:470:0:90::2 1480
174.095 test-42| Path MTU is <1500B
174.095 test-42| Beginning binary search to find the path MTU
174.095 test-42| Works: 0
174.095 test-42| Fails: 1500
174.095 test-42| At: 750
174.095 test-42| Message: mtu 750 64
174.095 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53353
174.148 test-42| Got datagram of 702 bytes.
174.148 test-42| Success
174.148 test-42| Works: 750
174.148 test-42| Fails: 1500
174.148 test-42| At: 1125
174.148 test-42| Message: mtu 1125 64
174.148 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53354
174.203 test-42| Got datagram of 1024 bytes.
174.203 test-42| Success
174.203 test-42| Works: 1125
174.203 test-42| Fails: 1500
174.203 test-42| At: 1312
174.203 test-42| Message: mtu 1312 64
174.203 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53355
174.252 test-42| Got datagram of 1024 bytes.
174.252 test-42| Success
174.252 test-42| Works: 1312
174.252 test-42| Fails: 1500
174.252 test-42| At: 1406
174.252 test-42| Message: mtu 1406 64
174.253 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53356
174.301 test-42| Got datagram of 1024 bytes.
174.301 test-42| Success
174.301 test-42| Works: 1406
174.301 test-42| Fails: 1500
174.301 test-42| At: 1453
174.301 test-42| Message: mtu 1453 64
174.302 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53357
174.353 test-42| Got datagram of 1024 bytes.
174.354 test-42| Success
174.354 test-42| Works: 1453
174.354 test-42| Fails: 1500
174.354 test-42| At: 1476
174.354 test-42| Message: mtu 1476 64
174.354 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53358
174.408 test-42| Got datagram of 1024 bytes.
174.408 test-42| Success
174.408 test-42| Works: 1476
174.408 test-42| Fails: 1500
174.408 test-42| At: 1488
174.408 test-42| Message: mtu 1488 64
174.408 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53359
174.468 test-42| Got datagram of 31 bytes.
174.468 test-42| Responsive failure
174.468 test-42| Response is bad 1488 2001:470:0:90::2 1480
174.468 test-42| Works: 1476
174.468 test-42| Fails: 1488
174.468 test-42| At: 1482
174.468 test-42| Message: mtu 1482 64
174.469 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53360
174.528 test-42| Got datagram of 31 bytes.
174.528 test-42| Responsive failure
174.529 test-42| Response is bad 1482 2001:470:0:90::2 1480
174.529 test-42| Works: 1476
174.529 test-42| Fails: 1482
174.529 test-42| At: 1479
174.529 test-42| Message: mtu 1479 64
174.529 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53361
174.580 test-42| Got datagram of 1024 bytes.
174.580 test-42| Success
174.580 test-42| Works: 1479
174.580 test-42| Fails: 1482
174.580 test-42| At: 1480
174.580 test-42| Message: mtu 1480 64
174.580 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53362
174.628 test-42| Got datagram of 1024 bytes.
174.628 test-42| Success
174.628 test-42| Works: 1480
174.628 test-42| Fails: 1482
174.628 test-42| At: 1481
174.628 test-42| Message: mtu 1481 64
174.629 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53363
174.689 test-42| Got datagram of 31 bytes.
174.689 test-42| Responsive failure
174.689 test-42| Response is bad 1481 2001:470:0:90::2 1480
174.689 test-42| Final MTU is 1480
230 174.728043 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 838 Source port: 53349 Destination port: eye2eye
231 174.731075 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 TCP 86 sentinelsrm > 57537 [ACK] Seq=43 Ack=2 Win=5712 Len=0 TSval=87108372 TSecr=1298810232
232 174.779641 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 ICMPv6 1294 Destination Unreachable (Port unreachable)
233 174.780117 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 78 Source port: 53350 Destination port: eye2eye
234 174.836455 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 ICMPv6 126 Destination Unreachable (Port unreachable)
235 174.837125 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x451f2d01)
236 174.837131 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
241 175.838153 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x22a0eb7a)
242 175.838159 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
243 176.838659 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x39ec621f)
244 176.838665 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
245 177.839024 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x24e7bdfe)
246 177.839031 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
249 178.259659 2001:470:e07d:1:c62c:3ff:fe2c:78e0 2001:470:e07d:1::1 ICMPv6 149 Destination Unreachable (Port unreachable)
253 178.261531 2001:470:e07d:1:c62c:3ff:fe2c:78e0 2001:470:e07d:1::1 ICMPv6 149 Destination Unreachable (Port unreachable)
254 178.261558 2001:470:e07d:1:c62c:3ff:fe2c:78e0 2001:470:e07d:1::1 ICMPv6 149 Destination Unreachable (Port unreachable)
255 178.261569 2001:470:e07d:1:c62c:3ff:fe2c:78e0 2001:470:e07d:1::1 ICMPv6 149 Destination Unreachable (Port unreachable)
257 178.261591 2001:470:e07d:1:c62c:3ff:fe2c:78e0 2001:470:e07d:1::1 ICMPv6 149 Destination Unreachable (Port unreachable)
258 178.840290 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x29ffd029)
259 178.840296 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
260 179.841590 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x3d394354)
261 179.841596 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
264 180.842345 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x77c2fbc1)
265 180.842362 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
266 181.842854 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x2fa68044)
267 181.842860 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
268 182.844119 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x3a598b70)
269 182.844126 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
272 183.845585 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x61c80d48)
273 183.845592 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
274 184.846852 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53352 Destination port: bcs-lmserver
275 184.908422 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53352
276 184.909101 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 72 Source port: 53353 Destination port: bcs-lmserver
277 184.961213 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 764 Source port: bcs-lmserver Destination port: 53353
278 184.961756 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53354 Destination port: bcs-lmserver
279 185.016423 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1139 Source port: bcs-lmserver Destination port: 53354
280 185.016967 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53355 Destination port: bcs-lmserver
281 185.065661 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1326 Source port: bcs-lmserver Destination port: 53355
282 185.066323 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53356 Destination port: bcs-lmserver
283 185.114773 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1420 Source port: bcs-lmserver Destination port: 53356
284 185.115388 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53357 Destination port: bcs-lmserver
285 185.167136 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1467 Source port: bcs-lmserver Destination port: 53357
286 185.167749 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53358 Destination port: bcs-lmserver
287 185.221257 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1490 Source port: bcs-lmserver Destination port: 53358
288 185.221967 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53359 Destination port: bcs-lmserver
289 185.281867 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53359
290 185.282656 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53360 Destination port: bcs-lmserver
291 185.342016 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53360
292 185.342637 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53361 Destination port: bcs-lmserver
293 185.393482 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1493 Source port: bcs-lmserver Destination port: 53361
294 185.393965 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53362 Destination port: bcs-lmserver
295 185.441881 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1494 Source port: bcs-lmserver Destination port: 53362
296 185.442379 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53363 Destination port: bcs-lmserver
163.913 test-42| Testing the ability to send a large UDP packet (2000 bytes) over IPv6
163.913 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.913 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53348
163.914 test-42| Got exception java.net.SocketException: Message too long on UDP test
163.914 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.914 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53349
163.966 test-42| Got exception java.net.PortUnreachableException: ICMP Port Unreachable on UDP test
163.966 test-42| Can't send UDP fragments
163.966 test-42| Testing the ability to receive a large UDP packet (2000 bytes) over IPv6
163.966 test-42| Sending UDP request to ipv6-node.u14369.n3.netalyzr.icsi.berkeley.edu on port 1948
163.966 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53350
164.023 test-42| Got exception java.net.PortUnreachableException: ICMP Port Unreachable on UDP test
164.023 test-42| Can't receive UDP fragments
226 174.727246 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1510 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x36cd5178)
227 174.727256 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 622 IPv6 fragment (nxt=UDP (0x11) off=1448 id=0x36cd5178)
228 174.727648 2001:470:e07d:1::1 2001:470:e07d:1:a833:b6aa:c711:ffa1 ICMPv6 1294 Packet Too Big
229 174.728036 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x1bd690be)
230 174.728043 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 838 Source port: 53349 Destination port: eye2eye
232 174.779641 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 ICMPv6 1294 Destination Unreachable (Port unreachable)
233 174.780117 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 78 Source port: 53350 Destination port: eye2eye
234 174.836455 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 ICMPv6 126 Destination Unreachable (Port unreachable)
235 174.837125 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x451f2d01)
236 174.837131 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
241 175.838153 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x22a0eb7a)
242 175.838159 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
243 176.838659 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x39ec621f)
244 176.838665 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
245 177.839024 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x24e7bdfe)
246 177.839031 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
164.023 test-42| Attempting to send a packet with
164.023 test-42| fragmentation of 2009 bytes
164.023 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
165.024 test-42| No data received.
165.024 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
166.025 test-42| No data received.
166.025 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
167.025 test-42| No data received.
167.025 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
168.026 test-42| No data received.
168.027 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
169.028 test-42| No data received.
169.028 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
170.028 test-42| No data received.
170.029 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
171.029 test-42| No data received.
171.029 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
172.030 test-42| No data received.
172.030 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
173.032 test-42| No data received.
173.032 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53351
174.033 test-42| No data received.
174.033 test-42| No reply back
235 174.837125 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x451f2d01)
236 174.837131 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
241 175.838153 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x22a0eb7a)
242 175.838159 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
243 176.838659 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x39ec621f)
244 176.838665 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
245 177.839024 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x24e7bdfe)
246 177.839031 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
258 178.840290 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x29ffd029)
259 178.840296 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
260 179.841590 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x3d394354)
261 179.841596 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
264 180.842345 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x77c2fbc1)
265 180.842362 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
266 181.842854 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x2fa68044)
267 181.842860 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
268 182.844119 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x3a598b70)
269 182.844126 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
272 183.845585 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 IPv6 1294 IPv6 fragment (nxt=UDP (0x11) off=0 id=0x61c80d48)
273 183.845592 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 847 Source port: 53351 Destination port: bcs-lmserver
174.033 test-42| Now looking for the receive MTU. Trying 1500 first
174.033 test-42| MSG: mtu 1500 64
174.033 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53352
174.095 test-42| Got datagram of 31 bytes.
174.095 test-42| Response is bad 1500 2001:470:0:90::2 1480
174.095 test-42| Path MTU is <1500B
174.095 test-42| Beginning binary search to find the path MTU
174.095 test-42| Works: 0
174.095 test-42| Fails: 1500
174.095 test-42| At: 750
174.095 test-42| Message: mtu 750 64
174.095 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53353
174.148 test-42| Got datagram of 702 bytes.
174.148 test-42| Success
174.148 test-42| Works: 750
174.148 test-42| Fails: 1500
174.148 test-42| At: 1125
174.148 test-42| Message: mtu 1125 64
174.148 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53354
174.203 test-42| Got datagram of 1024 bytes.
174.203 test-42| Success
174.203 test-42| Works: 1125
174.203 test-42| Fails: 1500
174.203 test-42| At: 1312
174.203 test-42| Message: mtu 1312 64
174.203 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53355
174.252 test-42| Got datagram of 1024 bytes.
174.252 test-42| Success
174.252 test-42| Works: 1312
174.252 test-42| Fails: 1500
174.252 test-42| At: 1406
174.252 test-42| Message: mtu 1406 64
174.253 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53356
174.301 test-42| Got datagram of 1024 bytes.
174.301 test-42| Success
174.301 test-42| Works: 1406
174.301 test-42| Fails: 1500
174.301 test-42| At: 1453
174.301 test-42| Message: mtu 1453 64
174.302 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53357
174.353 test-42| Got datagram of 1024 bytes.
174.354 test-42| Success
174.354 test-42| Works: 1453
174.354 test-42| Fails: 1500
174.354 test-42| At: 1476
174.354 test-42| Message: mtu 1476 64
174.354 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53358
174.408 test-42| Got datagram of 1024 bytes.
174.408 test-42| Success
174.408 test-42| Works: 1476
174.408 test-42| Fails: 1500
174.408 test-42| At: 1488
174.408 test-42| Message: mtu 1488 64
174.408 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53359
174.468 test-42| Got datagram of 31 bytes.
174.468 test-42| Responsive failure
174.468 test-42| Response is bad 1488 2001:470:0:90::2 1480
174.468 test-42| Works: 1476
174.468 test-42| Fails: 1488
174.468 test-42| At: 1482
174.468 test-42| Message: mtu 1482 64
174.469 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53360
174.528 test-42| Got datagram of 31 bytes.
174.528 test-42| Responsive failure
174.529 test-42| Response is bad 1482 2001:470:0:90::2 1480
174.529 test-42| Works: 1476
174.529 test-42| Fails: 1482
174.529 test-42| At: 1479
174.529 test-42| Message: mtu 1479 64
174.529 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53361
174.580 test-42| Got datagram of 1024 bytes.
174.580 test-42| Success
174.580 test-42| Works: 1479
174.580 test-42| Fails: 1482
174.580 test-42| At: 1480
174.580 test-42| Message: mtu 1480 64
174.580 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53362
174.628 test-42| Got datagram of 1024 bytes.
174.628 test-42| Success
174.628 test-42| Works: 1480
174.628 test-42| Fails: 1482
174.628 test-42| At: 1481
174.628 test-42| Message: mtu 1481 64
174.629 test-42| UDP socket at 2001:470:e07d:1:a833:b6aa:c711:ffa1%0:53363
174.689 test-42| Got datagram of 31 bytes.
174.689 test-42| Responsive failure
174.689 test-42| Response is bad 1481 2001:470:0:90::2 1480
174.689 test-42| Final MTU is 1480
274 184.846852 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53352 Destination port: bcs-lmserver
275 184.908422 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53352
276 184.909101 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 72 Source port: 53353 Destination port: bcs-lmserver
277 184.961213 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 764 Source port: bcs-lmserver Destination port: 53353
278 184.961756 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53354 Destination port: bcs-lmserver
279 185.016423 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1139 Source port: bcs-lmserver Destination port: 53354
280 185.016967 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53355 Destination port: bcs-lmserver
281 185.065661 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1326 Source port: bcs-lmserver Destination port: 53355
282 185.066323 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53356 Destination port: bcs-lmserver
283 185.114773 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1420 Source port: bcs-lmserver Destination port: 53356
284 185.115388 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53357 Destination port: bcs-lmserver
285 185.167136 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1467 Source port: bcs-lmserver Destination port: 53357
286 185.167749 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53358 Destination port: bcs-lmserver
287 185.221257 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1490 Source port: bcs-lmserver Destination port: 53358
288 185.221967 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53359 Destination port: bcs-lmserver
289 185.281867 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53359
290 185.282656 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53360 Destination port: bcs-lmserver
291 185.342016 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53360
292 185.342637 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53361 Destination port: bcs-lmserver
293 185.393482 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1493 Source port: bcs-lmserver Destination port: 53361
294 185.393965 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53362 Destination port: bcs-lmserver
295 185.441881 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 1494 Source port: bcs-lmserver Destination port: 53362
296 185.442379 2001:470:e07d:1:a833:b6aa:c711:ffa1 2607:f740:b::f93 UDP 73 Source port: 53363 Destination port: bcs-lmserver
297 185.502727 2607:f740:b::f93 2001:470:e07d:1:a833:b6aa:c711:ffa1 UDP 93 Source port: bcs-lmserver Destination port: 53363
Your system can not send or receive fragmented traffic over IPv6.
The path between your network and our system supports an MTU of at least 1280 bytes. The path between our system and your network has an MTU of 1480 bytes. The bottleneck is at IP address 2001:470:0:90::2. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.
11:48:57.223794 IP6 (flowlabel 0xd1a2a, hlim 64, next-header UDP (17) payload length: 1440) ussenterprise.ufp.org.63767 > 2001:470:e07d:1:21d:7dff:fea3:66ae.8010: [udp sum ok] UDP, length 1432
11:48:57.234794 IP6 (flowlabel 0xd1a2a, hlim 64, next-header UDP (17) payload length: 1440) ussenterprise.ufp.org.63767 > 2001:470:e07d:1:21d:7dff:fea3:66ae.8010: [udp sum ok] UDP, length 1432
11:48:57.244795 IP6 (flowlabel 0xd1a2a, hlim 64, next-header UDP (17) payload length: 1440) ussenterprise.ufp.org.63767 > 2001:470:e07d:1:21d:7dff:fea3:66ae.8010: [udp sum ok] UDP, length 1432
11:48:57.255795 IP6 (flowlabel 0xd1a2a, hlim 64, next-header UDP (17) payload length: 1440) ussenterprise.ufp.org.63767 > 2001:470:e07d:1:21d:7dff:fea3:66ae.8010: [udp sum ok] UDP, length 1432
11:49:39.392331 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 1440) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xc142ccd0:0|1432) 59968 > 8010: UDP, length 1433
11:49:39.392334 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 17) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xc142ccd0:1432|9)
11:49:39.643317 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 1440) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xc7f16651:0|1432) 59968 > 8010: UDP, length 1433
11:49:39.643320 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 17) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xc7f16651:1432|9)
11:49:39.894314 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 1440) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xf6422ca8:0|1432) 59968 > 8010: UDP, length 1433
11:49:39.894316 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 17) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xf6422ca8:1432|9)
11:49:40.145311 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 1440) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xee742ee6:0|1432) 59968 > 8010: UDP, length 1433
11:49:40.145314 IP6 (flowlabel 0xe004b, hlim 64, next-header Fragment (44) payload length: 17) ussenterprise.ufp.org > 2001:470:e07d:1:21d:7dff:fea3:66ae: frag (0xee742ee6:1432|9)
11:52:23.052771 IP6 (flowlabel 0x644bd, hlim 56, next-header UDP (17) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae.64362 > ussenterprise.ufp.org.8010: [udp sum ok] UDP, length 1232
11:52:23.060641 IP6 (flowlabel 0x644bd, hlim 56, next-header UDP (17) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae.64362 > ussenterprise.ufp.org.8010: [udp sum ok] UDP, length 1232
11:52:23.070635 IP6 (flowlabel 0x644bd, hlim 56, next-header UDP (17) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae.64362 > ussenterprise.ufp.org.8010: [udp sum ok] UDP, length 1232
11:52:23.082502 IP6 (flowlabel 0x644bd, hlim 56, next-header UDP (17) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae.64362 > ussenterprise.ufp.org.8010: [udp sum ok] UDP, length 1232
11:52:23.089872 IP6 (flowlabel 0x644bd, hlim 56, next-header UDP (17) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae.64362 > ussenterprise.ufp.org.8010: [udp sum ok] UDP, length 1232
11:52:52.782560 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xe48c9858:0|1232) 44552 > 8010: UDP, length 1233
11:52:52.786058 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 17) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xe48c9858:1232|9)
11:52:52.792804 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xf29e788f:0|1232) 44552 > 8010: UDP, length 1233
11:52:52.797676 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 17) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xf29e788f:1232|9)
11:52:52.807295 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xa93258d6:0|1232) 44552 > 8010: UDP, length 1233
11:52:52.807298 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 17) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xa93258d6:1232|9)
11:52:52.812541 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 1240) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xfd13fade:0|1232) 44552 > 8010: UDP, length 1233
11:52:52.815789 IP6 (flowlabel 0x0e4cc, hlim 56, next-header Fragment (44) payload length: 17) 2001:470:e07d:1:21d:7dff:fea3:66ae > ussenterprise.ufp.org: frag (0xfd13fade:1232|9)
It does appear that I cannot receive any IPv6 fragments over my tunnel/routerWhile running some unrelated test I noticed that I was receiving fragmented IPv6 packets over the tunnel from HE. I was using the test on http://test-ipv6.com/, and it was sending packets that were too large to make it through the tunnel. PMTU discovery did work as intended, though the server behaved in a way that surprised me a bit. The TCP segment that had triggered the ICMP response was fragmented and I received a fragmented TCP packet through the tunnel. I would have expected TCP to split the data into smaller segments, but that was not what happened. Later TCP traffic did however use smaller segments.
Options would likely be 1480, 1472, and 1280, unless anyone can think of any other useful common values.Is it a lot easier to implement a fixed set of values than it is to implement an input field where any value from 1280 to 1480 could be entered?
Is there still any reason to think this is not a flaw in netalyzer?
Options would likely be 1480, 1472, and 1280, unless anyone can think of any other useful common values.Is it a lot easier to implement a fixed set of values than it is to implement an input field where any value from 1280 to 1480 could be entered?
I also know we'd find several MTUs of 1337 if it were free-form.You'd probably need to round it down to a multiple of 8. But "mtu-=mtu%8" isn't hard to implement :-)
It's about the same either way, but there are a few sweet spots that are the most useful. So it's really a choice between: leaving it completely open-ended, and people really have to know why they may need to change it in order to change it to a useful value; giving the most useful values; or do both, and hope it doesn't confuse and/or break people. I also know we'd find several MTUs of 1337 if it were free-form. ;-)
if you wan to score bonus points, create a small tool/applet that tests the IPv4 path between the tunnel endpoint and the tunnel broker server to determine the largest IPv4 packet that can pass without fragmentation, and then make a recommendation to the user.As far as I could tell that already happenes. It just happenes behind the scenes without you even noticing. But I'd need somebody to doublecheck to be sure I'm interpreting my observations correctly.
He is talking about recommending a MTU.I just did the same test over again, and what I saw was that if the IPv6 in IPv4 packet from the tunnel server to the user results in an ICMP message indicating that the IPv4 packet needs fragmentation, then the tunnel server will use that information to lower the IPv6 MTU of the tunnel temporarily. I don't know for how long the tunnel server keeps the lower MTU on the tunnel.
I don't know for how long the tunnel server keeps the lower MTU on the tunnel.I just tried to time it. After the tunnel server received the ICMP message it lowered the MTU of the tunnel for 150 seconds. After those had passed it increased the MTU back to the default value.
If you are on a network that is letting you get jumbo frame capabilities on WAN, then you are on a network that should already be providing you native IPv6 IMO.
The iperf test with udp 1433 is not valid as pmtu detection wil not work for iperf as you choose 1433 as message size. That wil not fit into the 1432 (1480) bytes tunnel. UDP does not allow segmentation and because you told iperf to use 1433 it will stay on 1433 bytes.
Al tests I did showed that PMTU is working correcty with he's tunnelbroker ipv6 connections. It must be that the netalyzr test is incorrect. Hopefully they will respond also to this thread.
I don't think you're right on the packet size issue. I can send 1600 byte packets between two 1500 byte hosts on clean IPv6 connections. If your theory was correct that wouldn't work as well.Fragmentation is permitted on the sending host regardless of which upper layer protocol is used. As long as there is no later hop with a smaller MTU than the first hop, it should work just fine.
I think the Apple Time Capsule is dropping all IPv6 fragments inbound on the tunnel as a security policy. I have opened a bug with apple to that effect, and will report back where that goes if they get back to me.I saw the problem without any Apple equipment. I'm pretty sure whatever the problem is, does not lie on my end of the tunnel.
I don't know exactly what is supposed to happen for UDP. Having the stack on the sending host buffer the UDP packet and retransmit in case of a fragmentation needed message doesn't sound like what you would expect from UDP. And pushing the requirement of dealing with fragmentation to the application layer isn't good either. Failing to implement either of those approaches will just lead to the application layer having to deal with a lost packet, which it is supposed to be capable of anyway. But always having a timeout for the very first packet isn't a great solution.
I believe best current operational practice for DNS over IPv6 is to send only 1280 byte UDP frames.Then again, I don't think it is completely agreed upon how to get past the 512 byte limit that DNS was designed with.
Ok, MTU adjustment is live.
Currently supporting three options: 1480, 1472 and 1280.
I have an MTU of 1380, do these settings have any meaning for me?How did you manage to figure out your MTU without knowing what it means? If your actual MTU is 1380, then the best choice from the list of options is 1280. I assume 1480 is still the default. If you stick with the default, then a small number of packets will get dropped on the way from the Internet to your computer.
I have an MTU of 1380, do these settings have any meaning for me?How did you manage to figure out your MTU without knowing what it means? If your actual MTU is 1380, then the best choice from the list of options is 1280. I assume 1480 is still the default. If you stick with the default, then a small number of packets will get dropped on the way from the Internet to your computer.
1280: Minimum IPv6 MTU per the RFCs.
1480: Standard MTU for an IPv6 encapsulated packet over IPv4 ethernet.
1472: Similar to 1480, except encapsulated as PPPoE under IPv4.
That's what they mean and how they're derived.
What I'm trying to ascertain is, what they mean to me with an MTU of 1380.If your exact value is not on the list, you want to use the largest one among those that are less than your actual MTU. So first you eliminate 1472 and 1480 because those are larger than 1380. Then you take the largest among those that remain.
What I'm trying to ascertain is, what they mean to me with an MTU of 1380.If your exact value is not on the list, you want to use the largest one among those that are less than your actual MTU. So first you eliminate 1472 and 1480 because those are larger than 1380. Then you take the largest among those that remain.
If you aren't finding that you experience MTU issues with how the MTU is configured on HE's side, then no, you don't need to touch a thing.Correct. As I indicated earlier, HE had auto detection of the MTU already before the new option was introduced. The possible values were limited to the range 1280-1480 bytes. As long as PMTU was working on the IPv4 connection from the tunnel server to your router, you shouldn't experience a problem. The autodetection would cause a single packet drop once every few minutes.
Correct. As I indicated earlier, HE had auto detection of the MTU already before the new option was introduced
There is no MTU auto-detection; never has been.There most certainly is. I don't know for how long it existed. I learned about the existence of that feature about three weeks ago.
ping6 -n -s 1424 2001:470:28:940::1I got the tunnel server to report an MTU of 1464 bytes. That is not one of the configurable choices, but I was able to get the tunnel server to use that MTU by making use of the auto detection.
PING 2001:470:28:940::1(2001:470:28:940::1) 1424 data bytes
From 2001:470:0:11e::2 icmp_seq=1 Packet too big: mtu=1464
From 2001:470:28:940:1c82:31b3:813c:2e14 icmp_seq=2 Destination unreachable: No route
From 2001:470:28:940:1c82:31b3:813c:2e14 icmp_seq=3 Destination unreachable: No route
They did not dynamically change to some other number on the interface.The tunnel server on 216.66.80.90 does change the MTU of my tunnel dynamically. I have looked at the traffic with tcpdump, and there is no doubt that tunnel server is dynamically changing the MTU.
You are talking packets, not interfaces.In the end all that matters to the users, is what packets the tunnel server is sending. What terminology is used on the tunnel server is not important. In my example the tunnel server was using an MTU of 1464 for processing the network traffic.
Firmware version 7.6.3 has been released officially, please retest.
Your tunnel's MTU is 1480 which is maximum for using this tunnel service.Thanks very much.
200ms slower rendering an image in a browser? Spotify tuned their system to start playing music within 285 seconds from pressing play because that is just above 250ms which is when the human brain processes sound as instantaneous (cool NPR story from years ago). I'd say an extra 200ms to render something will not be noticed.
Spotify tuned their system to start playing music within 285 seconds from pressing playI assume you meant 285 ms.
because that is just above 250ms which is when the human brain processes sound as instantaneous (cool NPR story from years ago).When working on a sound processing project at university, we got some advice from a professional sound technician, who told us the threshold is 20ms.
I'd say an extra 200ms to render something will not be noticed.My former colleagues would ridicule you for making such a statement. There we were working with deadlines around 200ms to complete the rendering of a webpage, including the time it took to download all resources needed to render the page.
I assume you meant 285 ms.oops, I did, lemme go fix that
When working on a sound processing project at university, we got some advice from a professional sound technician, who told us the threshold is 20ms.Neat, I find that using VLC lets you tweak with the audio delay and have definitely noticed some weirdness on a few videos out there but its almost always around something absurd like 400-700ms off which is way way more obvious generally.
When I am watching a DVD I can clearly feel something is wrong, if the sound is offset by 100ms. But I can't always pinpoint the direction in which the sound is off.
My former colleagues would ridicule you for making such a statement. There we were working with deadlines around 200ms to complete the rendering of a webpage, including the time it took to download all resources needed to render the page.Also probably depends on age of the user as well :) A younger person firing on all neurons should be noticing it, but as we get older and more addled, everything will probably feels like it takes forever!
200ms may not be enough to consciously notice that there was a delay. But subconsciously the users will notice the difference, and it will change their perception of the overall quality of the service.
I do want to point out one thing I found which is a bit of a surprise to me. It turns out most (all?) of the Linux kernels output UDP fragments in _reverse_ order. That is, say you had a 3500 byte packet to transmit which would become 1500 byte segment #1, 1500 byte segment #2, and 500 byte segment #3. They will go out on the wire 3, then 2, then 1.It's easier to reassemble packets that way. The last fragment is the only one, which can tell you how large the reassembled packet is going to be. So until you have received the last fragment, you cannot allocate memory for reassembly, and you'll have to keep packets separate.
At least with a couple of popular NAT implementations we tested that do in fact reassemble fragments this causes them to be dropped. Segment #1 must be received first to create a state table entry for the rest of the packets.Fragmentation is known to be problematic. NAT is known to be problematic. Combining the two makes it even worse. What you are describing is not the only problem.
However, as a programmer I also get that having a NAT box store random fragments in the hopes the rest of the bits come in later is both a bit of a programming challenge and a potential DDOS vector.That's something implementers of NAT devices have to deal with, if they don't want to be shipping a broken product. You can set aside a few MB of memory for storing fragments that cannot yet be forwarded due to the first fragment not having been seen yet. And a FIFO strategy would be sensible for discarding packets once memory is full, and in fact fragments must be discarded once they are a few minutes old, even if there isn't any memory pressure.
if there is any work around.My best recommendation is to avoid NAT and avoid fragmentation.
I do want to point out one thing I found which is a bit of a surprise to me. It turns out most (all?) of the Linux kernels output UDP fragments in _reverse_ order. That is, say you had a 3500 byte packet to transmit which would become 1500 byte segment #1, 1500 byte segment #2, and 500 byte segment #3. They will go out on the wire 3, then 2, then 1.It's easier to reassemble packets that way. The last fragment is the only one, which can tell you how large the reassembled packet is going to be. So until you have received the last fragment, you cannot allocate memory for reassembly, and you'll have to keep packets separate.
As the packets are being reassembled, you need to keep track of which bytes of the final packet have been received, and which have not. Keeping track of that is much easier if you receive them in order. And since you need to start with the last, that order has to be reverse order. From that perspective, it makes a lot of sense to send fragments in reverse order.
Your statement makes no sense to me.I assumed you knew how fragmentation works. My bad.
More importantly, from a security perspective when received in reverse order the receiving host must store all fragments received in memory to see if a header comes in that matches. This enables a trivial DDOS, send fragments to the host and it will run out of memory!This is a well-known issue, which you have to keep in mind when implementing an IP stack. Just limit the amount of memory used for reassembly and use a FIFO strategy to discard fragments when memory need to be used for a newly arrived fragment.
If packet #1 is received first it's header can be matched against ACL's, including dynamic state entries, and allowed or discarded. Subsequent fragments can then be saved or discarded upon reception based on if they match an initial packet that has already passed the security checks.Ordering was optimized for the receiver not the firewall. Additionally with IPv6 you can't always apply ACL's based on any one fragment. IPv6 packets can be constructed in a way, where even figuring out the port number being used requires all the fragments.
I believe from both a programming perspective and a security perspective things are significantly easier if the fragmented frames arrive in order, rather than any out of order sequence, including the reversed sequence Linux uses.I think your idea about what is easier would change, if you tried to implement fragment reassembly. As for the security implications, it is a mistake to consider what ordering is easiest to deal with. Your security needs to work regardless of which order an attacker sends packets in.
basically I inserted an ethernet switch between the Time Capsule and my cable modem so that I could capture both sides.That's not supposed to be possible to do with a switch. I keep an old hub around just in case I need to do that sort of debugging.
EndHost:~ bicknell$ dig +norecurse +bufsize=2048 txt txtpadding-1800.netalyzr.icsi.berkeley.edu @ipv6-node.netalyzr.icsi.berkeley.eduThat ID mismatch is a symptom of a quite mysterious bug on their side. Notice how the incorrect ID being received is always 25185. That packet is not DNS at all. What it contains is ASCII data. I captured one of those and found this 31 character string in the packet "bad 1496 2001:470:0:69::2 1480 ".
;; Warning: ID mismatch: expected ID 28893, got 25185
;; Warning: query response not set
; <<>> DiG 9.8.3-P1 <<>> +norecurse +bufsize=2048 txt txtpadding-1800.netalyzr.icsi.berkeley.edu @ipv6-node.netalyzr.icsi.berkeley.edu
;; global options: +cmd
;; connection timed out; no servers could be reached
The ID mismatch is the first interesting thing, but it's not actually the problem.
The bad news is that they are not making it past my Time Capsule.Then the Time Capsule is at fault. And netalyzr is correct to report that you have a fragmentation problem.
I'm working with the Netalyzr folks to see if there is anything we can do to get the fragments in order to see if that makes a differenceI can hack together a DNS server sending replies in various orders, if you need to test that.
I believe from both a programming perspective and a security perspective things are significantly easier if the fragmented frames arrive in order, rather than any out of order sequence, including the reversed sequence Linux uses.I think your idea about what is easier would change, if you tried to implement fragment reassembly. As for the security implications, it is a mistake to consider what ordering is easiest to deal with. Your security needs to work regardless of which order an attacker sends packets in.
That's not supposed to be possible to do with a switch. I keep an old hub around just in case I need to do that sort of debugging.
That ID mismatch is a symptom of a quite mysterious bug on their side. Notice how the incorrect ID being received is always 25185. That packet is not DNS at all. What it contains is ASCII data. I captured one of those and found this 31 character string in the packet "bad 1496 2001:470:0:69::2 1480 ".
The good news here is that TunnelBroker is off the hook, the fragments are making it down my tunnel. :D
The bad news is that they are not making it past my Time Capsule. I'm working with the Netalyzr folks to see if there is anything we can do to get the fragments in order to see if that makes a difference before going back to update my bug report with Apple. I suspect though that many firewalls will block all fragments (very bad), and that many will block the fragments received out of order (somewhat bad). If people can replicate this test with different hardware it would be appreciated.
It emits fragments in order. The code to both send and receive them is quite clean, in my opinion.Sending in order is a bit simpler than sending in reverse order. Code for receiving needs to be prepared to receive fragments in any order. So for simplicity of the code, sending in order is preferable.
It doesn't occur every time for me, perhaps for 1 in 10 queries.It depends on the PMTU information being cached on the sender. If the cache has no PMTU information for your IP the first fragment will be 1500 bytes. That fragment is bounced by the tunnel server. At that point your IP address will be put in the cache with a PMTU of 1480 bytes. But rather than retransmitting the packet on receipt of the ICMPv6 error, it sends an invalid response.
The FreeBSD/BIND combo I used emitted 1280 byte maximum length UDP.That actually sounds like a very sensible default behaviour. I think more systems should do that.
The result is still one packet and one fragment, just of slightly different sizes.I assume you mean one UDP packet fragmented in two IPv6 fragments.
I also pointed out to the Netalyzr folks it would be very cool if they could devise a test to send the fragments both in order and out of order, and see if it makes any difference. While it doesn't in this case, I suspect with some firewalls and NAT implementations it will.It's quite likely, it will make a difference in some cases.
So, I've now shown fragments don't make it past the Time Capsule regardless of packet order.I have a few more ideas for you to try.
The good news here is that TunnelBroker is off the hook, the fragments are making it down my tunnel. :D
The bad news is that they are not making it past my Time Capsule. I'm working with the Netalyzr folks to see if there is anything we can do to get the fragments in order to see if that makes a difference before going back to update my bug report with Apple. I suspect though that many firewalls will block all fragments (very bad), and that many will block the fragments received out of order (somewhat bad). If people can replicate this test with different hardware it would be appreciated.
I configured one of my DNS servers on a FreeBSD box to generate an 1800 byte TXT records, and reran the tests to my own server. I observed a few interesting details:
1) The FreeBSD/BIND combo I used emitted 1280 byte maximum length UDP. I'm not immediately sure if this is a FreeBSD-ism, or BIND-ism. The result is still one packet and one fragment, just of slightly different sizes.
2) The packets are emitted in order, and received down the tunnel in order.
3) Neither of the two response packets makes it past the Time Capsule.
So, I've now shown fragments don't make it past the Time Capsule regardless of packet order. I raised the severity of my bug report with Apple, documented all of this with them, and poked a couple of people over there I know in an attempt to nudge it to slightly higher priority.
I also pointed out to the Netalyzr folks it would be very cool if they could devise a test to send the fragments both in order and out of order, and see if it makes any difference. While it doesn't in this case, I suspect with some firewalls and NAT implementations it will.