Bug #1651
closed
udp4 packet has DF flag set
Added by Junxiao Shi almost 10 years ago.
Updated almost 10 years ago.
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
Is this flag set even when packet size is larger than MTU size?
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.
- Assignee set to Davide Pesavento
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?
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?
As decided in 20140619 conference call, Davide should submit the patch only if it's "not complicated" and it is platform-independent.
Check on OSX 10.9. No flags are set when < 1500 byte UDP datagram is sent out.
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.
- Status changed from New to In Progress
- Status changed from In Progress to Code review
- % Done changed from 0 to 90
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.
- % Done changed from 90 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by