Bug #1651
closed
udp4 packet has DF flag set
100%
Description
Environment: Ubuntu 12.04 64-bit, OpenVZ kernel 2.6.32
Steps to reproduce:
- create a udp4 tunnel
- tcpdump on NIC used by this udp4 tunnel
- cause an Interest to be sent via the tunnel
Expected: "Don't Fragment" flag is unset on the udp4 packet
Actual: "Don't Fragment" flag is set on the udp4 packet
NFD does not plan to have fragmentation on udp4 tunnels, and needs to rely on IP fragmentation.
With "Don't Fragment" flag set, IP fragmentation is disabled.
Files
Updated by Alex Afanasyev almost 10 years ago
Is this flag set even when packet size is larger than MTU size?
Updated by Junxiao Shi almost 10 years ago
The tested system has 1500-octet MTU.
UDP packet for a 1572-octet NDN packet is fragmented, and has no DF flag.
UDP packet for a 1470-octet NDN packet has DF flag set.
However, universally supported MTU for IPv4 is 576.
Even if all backbones support 1500-octet MTU, most datagram-based VPN would decrease MTU to around 1396.
Updated by Davide Pesavento almost 10 years ago
Isn't this behavior part of the path MTU discovery that Linux does by default for TCP and UDP?
I don't think this actually created any problems in your particular test case, otherwise the send call would have returned EMSGSIZE and you should have noticed that in the logs.
In any case, since we cannot do sender-side datagram fragmentation in nfd (unless we use ndnlp for udp too), we are unable to properly respond to ICMP "datagram too big" messages, for instance by reducing the datagram size. Therefore we should probably disable PMTU discovery on the udp socket.
Does the same happen on mac?
Updated by Davide Pesavento almost 10 years ago
Any comments on my previous comment? Other ideas? If not, do you want me to submit a patch to disable PMTU discovery for udp4 faces?
Updated by Junxiao Shi almost 10 years ago
As decided in 20140619 conference call, Davide should submit the patch only if it's "not complicated" and it is platform-independent.
Updated by Alex Afanasyev almost 10 years ago
- File osx10-9.pcap osx10-9.pcap added
Check on OSX 10.9. No flags are set when < 1500 byte UDP datagram is sent out.
Updated by Davide Pesavento almost 10 years ago
Alex Afanasyev wrote:
Check on OSX 10.9. No flags are set when < 1500 byte UDP datagram is sent out.
Ok, then we can conclude that this behavior is Linux-specific. Consequently, I'm going to assume that the "platform-independent" requirement (comment #6) no longer applies.
Updated by Davide Pesavento almost 10 years ago
- Status changed from New to In Progress
Updated by Davide Pesavento almost 10 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 90
Updated by Alex Afanasyev almost 10 years ago
Checked how fragmentation works for IPv6. On my machine UDP datagrams more than 1232 bytes is getting fragmented. In any case, this would universally work for all paths, since IPv6 spec requires 1280 as minimum MTU.
root@benz:/home/cawka# tcpdump -vv -ni tun0 host 1::1
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
20:18:42.451461 IP6 (hlim 64, next-header UDP (17) payload length: 1240) 2607:f010:3f9::1.6363 > 1::1.6363: [udp sum ok] UDP, length 1232
...
20:18:45.292617 IP6 (hlim 64, next-header Fragment (44) payload length: 1240) 2607:f010:3f9::1 > 1::1: frag (0x94bcca39:0|1232) 6363 > 6363: UDP, length 1233
20:18:45.292628 IP6 (hlim 64, next-header Fragment (44) payload length: 17) 2607:f010:3f9::1 > 1::1: frag (0x94bcca39:1232|9)
This behavior is consistent with and without the patch in the code review.
Updated by Alex Afanasyev almost 10 years ago
- Status changed from Code review to Closed