1

I'm doing some UDP bandwidth tests using iperf (https://iperf.fr/) over IPv6. I have very bad results when using a Linux UDP client with the following command line:

iperf -u -V -c fe80::5910:d4ff:fe31:5b10%usb0 -b 100m

Investigating the issue with Wireshark I have seen there is some fragmentation while the client is sending data. To be more precise, I see UDP client outgoing packets with size 1510 bytes and 92 bytes, alternating. For example, the UDP packets that I see have the following pattern (in size): 1510, 92, 1510, 92, 1510, 92,...,1510, 92,...

Reading iperf2 documentation I read the following for option (-l) :

The length of buffers to read or write. iPerf works by writing an array of len bytes a number of times. Default is 8 KB for TCP, 1470 bytes for UDP. Note for UDP, this is the datagram size and needs to be lowered when using IPv6 addressing to 1450 or less to avoid fragmentation. See also the -n and -t options.

I have tried to do the same bandwidth test by replacing the Linux iperf UDP client command line with the following:

iperf -u -V -c fe80::5910:d4ff:fe31:5b10%usb0 -b 100m -l1450

and I see good results. Looking at the Wireshark capture I see no fragmentation anymore.

Doing the same test over IPv4 I don't need to change the default UDP datagram size (I don't need to use '-l' option) to get good results.

So my conclusion is that fragmentation (over IPv6) is responsible for poor bandwidth performances.

Anyway, I'm wondering what really happens when setting UDP datagram size to 1450 over IPv6. Why do I have fragmentation over IPv6 and not over IPv4 with default value for UDP datagram size? Moreover, why do I have no fragmentation when reducing the UDP datagram size to 1450?

Thank you.

Salvatore
  • 1,145
  • 3
  • 21
  • 42

2 Answers2

5

The base IPv4 header is 20 bytes, the base IPv6 header is 40 bytes and the UDP header is 8 bytes.

With IPv4 the total packet size is 1470+8+20=1498, which is less than the default ethernet MTU of 1500.

With IPv6 the total packet size is 1470+8+40=1518, which is more than 1500 and has to be fragmented.

Now let's look into your observations. You see packets of size 1510 and 92. Those include the ethernet header, which is 14 bytes. Your IPv6 packets are therefore 1496 and 78 bytes. The contents of the big packet are: IPv6 header (40 bytes), a fragmentation header (8), the UDP header (8) and 1440 bytes of data. The smaller packet contains the IPv6 header (40), a fragmentation header (8) and the remaining 30 bytes of data.

Sander Steffann
  • 9,509
  • 35
  • 40
3

The most common MTU for Ethernet is 1500, not including ethernet frame headers. This means you can send 1500 bytes in one packet over the wire, including IP headers. IPv6 headers are larger than IPv4 headers for several reasons, with the most important being that IPv6 addresses are larger than IPv4. So when you run with the default value over IPv6 your packet size goes over the MTU size and the packet needs to be split into two; a procedure known as fragmentation.

Emil Vikström
  • 90,431
  • 16
  • 141
  • 175
  • 1
    So, if I understood well, keeping the MTU fixed at 1500, we have less space for UDP payload because of greater size of IPv6 header. As a result the default UDP datagram doesn't fit the Ethernet frame together with Ethernet and IPv6 headers and the packet must be fragmented. – Salvatore Sep 25 '15 at 08:38
  • 1
    Yes! Although the ethernet MTU does [not include ethernet headers](https://en.wikipedia.org/wiki/Ethernet_frame#Ethernet_II). So you can usually send a 1500 bytes *payload* (the payload in ethernet context being the IP packet including IP headers) in each ethernet frame. – Emil Vikström Sep 25 '15 at 08:44