What is the largest Safe UDP Packet Size on the Internet

I've read a number of articles about UDP packet sizes but have been unable to come to a conclusion on whats correct.

A number of services restrict the largest UDP packet to 512 bytes (like dns)

Given the minimum [MTU][1] on the internet is 576 , and the size of the IPv4 header is 20 bytes, and the UDP header 8 bytes. This leaves 548 bytes available for user data

Would I be able to use packets up to the size of 548 without packet fragmentation? Or is there something the creators of DNS knew about, and that why they restricted it to 512 bytes.

Could I even go higher than 548 bytes safely?

[1]: http://en.wikipedia.org/wiki/Maximum_transmission_unit "Maximum Transmission Unit"

It is true that a typical IPv4 header is 20 bytes, and the UDP header is 8 bytes. However it is possible to include IP options which can increase the size of the IP header to as much as 60 bytes. In addition, sometimes it is necessary for intermediate nodes to encapsulate datagrams inside of another protocol such as [IPsec][1] (used for VPNs and the like) in order to route the packet to its destination. So if you do not know the [MTU][2] on your particular network path, it is best to leave a reasonable margin for other header information that you may not have anticipated. A 512-byte UDP payload is generally considered to do that, although even that does not leave quite enough space for a maximum size IP header.

[1]: http://en.wikipedia.org/wiki/IPsec "Internet Protocol Security" [2]: http://en.wikipedia.org/wiki/Maximum_transmission_unit "Maximum Transmission Unit"

The maximum safe UDP payload is 508 bytes. This is a packet size of 576 (the "minimum maximum reassembly buffer size"), minus the maximum 60-byte IP header and the 8-byte UDP header.

Any UDP payload this size or smaller is guaranteed to be deliverable over IP (though not guaranteed to be delivered). Anything larger is allowed to be outright dropped by any router for any reason. Except on an IPv6-only route, where the maximum payload is 1,212 bytes. As others have mentioned, additional protocol headers could be added in some circumstances. A more conservative value of around 300-400 bytes may be preferred instead.

The maximum possible UDP payload is 67 KB, split into 45 IP packets, adding an additional 900 bytes of overhead (IPv4, MTU 1500, minimal 20-byte IP headers).

Any UDP packet may be fragmented. But this isn't too important, because losing a fragment has the same effect as losing an unfragmented packet: the entire packet is dropped. With UDP, this is going to happen either way.

^{_{IP packets include a fragment offset field, which indicates the byte offset of the UDP fragment in relation to its UDP packet. This field is 13-bit, allowing 8,192 values, which are in 8-byte units. So the range of such offsets an IP packet can refer to is 0...65,528 bytes. Being an offset, we add 1,480 for the last UDP fragment to get 67,008. Minus the UDP header in the first fragment gives us a nice, round 67 KB.}}

Sources: RFC 791, RFC 1122, RFC 2460

The theoretical limit (on Windows) for the maximum size of a UDP packet is 65507 bytes. This is documented here:

> The correct maximum UDP message size is 65507, as determined by the following formula: 0xffff - (sizeof(IP Header) + sizeof(UDP Header)) = 65535-(20+8) = 65507

That being said, most protocols limit to a much smaller size - usually either 512 or occasionally 8192. You can often go higher than 548 safely if you are on a reliable network - but if you're broadcasting across the internet at large, the larger you go, the more likely you'll be to run into packet transmission problems and loss.

576 is the minimum maximum reassembly buffer size, i.e. each implementation must be able to reassemble packets of at least that size. See IETF RFC 1122 for details.

This article describes maximum transmission unit (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit. It states that IP hosts must be able to process 576 bytes for an IP packet. However, it notes the minumum is 68. RFC 791: "Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets."

Thus, safe packet size of 508 = 576 - 60 (IP header) - 8 (udp header) is reasonable.

As mentioned by user607811, fragmentation by other network layers must be reassembled. https://www.rfc-editor.org/rfc/rfc1122#page-56 3.3.2 Reassembly The IP layer MUST implement reassembly of IP datagrams. We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576

IPv4 minimum reassembly buffer size is 576, IPv6 has it at 1500. Subtract header sizes from here. See UNIX Network Programming by W. Richard Stevens :)

I've read some good answers here; however, there are some minor mistakes. Some have answered that the Message Length field in the UDP header is a max of 65535 (0xFFFF); this is technically true. Some have answered that the actual maximum is (65535 - IPHL - UDPHL = 65507). The mistake, is that the Message Length field in the UDP Header includes all payload (Layers 5-7), plus the length of the UDP Header (8 Bytes). What this means is that if the message length field is 200 Bytes (0x00C8), the payload is actually 192 Bytes (0x00C0).

What is hard and fast is that the maximum size of an IP datagram is 65535 Bytes. This number is arrived at the sum total of the L3 and L4 headers, plus the Layers 5-7 payload. IP Header + UDP Header + Layers 5-7 = 65535 (Max).

The most correct answer for what is the maximum size of a UDP datagam is 65515 Bytes (0xFFEB), as a UDP datagram includes the UDP header. The most correct answer for what is the maximum size of a UDP payload is 65507 Bytes, as a UDP Payload does not include the UDP header.

512 is your best bet. It's used elsewhere and is a nice even number (half of 1024).

Given that IPV6 has a size of 1500, I would assert that carriers would not provide separate paths for IPV4 and IPV6 (they are both IP with different types), forcing them to equipment for ipv4 that would be old, redundant, more costly to maintain and less reliable. It wouldn't make any sense. Besides, doing so might easily be considered providing preferential treatment for some traffic -- a no no under rules they probably don't care much about (unless they get caught).

So 1472 should be safe for external use (though that doesn't mean an app like DNS that doesn't know about EDNS will accept it), and if you are talking internal nets, you can more likely know your network layout in which case jumbo packet sizes apply for for non-fragmented packets so for 4096 - 4068 bytes, and for intel's cards with 9014 byte buffers, a package size of ... wait...8086 bytes, would be the max...coincidence? snicker

UPDATE

Various answers give maximum values allowed by 1 SW vendor or various answers assuming encapsulation. The user didn't ask for the lowest value possible (like "0" for a safe UDP size), but the largest safe packet size.

Encapsulation values for various layers can be included multiple times. Since once you've encapsulated a stream -- there is nothing prohibiting, say, a VPN layer below that and a complete duplication of encapsulation layers above that.

Since the question was about maximum safe values, I'm assuming that they are talking about the maximum safe value for a UDP packet that can be received. Since no UDP packet is guaranteed, if you receive a UDP packet, the largest safe size would be 1 packet over IPv4 or 1472 bytes.

Note -- if you are using IPv6, the maximum size would be 1452 bytes, as IPv6's header size is 40 bytes vs. IPv4's 20 byte size (and either way, one must still allow 8 bytes for the UDP header).

There isn't one.

I'm going to set aside entirely any 'UDP is best effort' reasoning, and just focus on 'maximum safe UDP packet size' taken as meaning 'small enough to absolutely avoid any fragmentation somewhere along the path'.

For important background:

> The only packet size you can rely to be transportable without fragmentation is 24 bytes for IPv4 and 56 bytes IPv6, as the smallest IP headers for a fragment are 20/48 bytes (v4/v6) and a fragment must have at least 4/8 bytes (v4/v6) payload data. Thus a transport system below IP layer that cannot transport at least packets of theses sizes, cannot be used to transport IP traffic [at all]. - Answer to 'how is the MTU 65507 in UDP...?'.

According to the answer above, this is because at that length, the IP fragmentation mechanism cannot operate - it could only generate a single fragment anyway.

> ... the IP standard requires every IP host to be able to receive IP packets with a total size of 576 bytes.... Note, however, the standard does not say 576 without fragmentation, so even a 576 byte IP packet might find itself fragmented between two hosts [somewhere along the path between source and destination].

So anything bigger than the smallest the internet protocol could possibly do, could in fact find itself fragmented due to being 'invisibly' temporarily encapsulated to just above the limit somewhere along the path, even if you chose the minimum UDP payload, which would be: 576 - 8 (for UDP header) - 20 (IPv4) or 40 (IPv6) = min of 528 (in case you are not sure whether v4 or v6 will be used).

A reason you might be trying to avoid fragmentation, is that it does increase the likelyhood that the packet will go missing in it's entirety. More packets, just due to the higher overhead, would mean greater likelyhood of failure, let alone that each packet (even a fragment) represents another 'chance' to be lost. Of course, if it happens to be handed on to some link that just drops it for being too big...

TCP implementations at OS level do things to try to pick the highest safe MTU within the TCP layer, including dealing with it dynamically changing sometimes, as parts of the path between source and destination can differ packet-by-packet.

For UDP, this whole problem becomes yours also: And it's not so simple as just 'use the largest that will certainly not fragment'.

RFC2460 section 5 has this to say (about minimum MTU for IPv6). > IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

Therefore fragmentation can also happen at beneath the IP level, where a particular link between two hosts along the path decides to fragment it, then may shove the fragments down parallel pipes... to have them reassembled into one packet at the other end of that one link.

If there is an out-of-ordering of those fragments, that reording mechanism might reassemble the packet incorrectly, without even realizing that it reordered part of it.

Of course, if the hardware was sticking to the IP specification, it should be able to notice that the packets got out of order by inspecting the fragment offset part of the IP header, but most link protocols just reassemble the fragments in the order received, without worrying about out-of-order packet reception.

Now if that 'lower level' interconnect is itself used as a network... such as within the core of a large switch, for instance, then it might be possible that under heavy loads and many parallel paths, such fragments might get out of order before reassembly.

This is super evil, but probably does happen sometimes, leading to the occasional still-delivered and yet badly-mangled packet, which still passes a simple xor-based checksum test... Which happens to be what the IP checksum is.

TCP just sets 'do not fragment' and deals with it, but UDP leaves that bit clear... so if you're using UDP, you should also assume it possible that your stream of bytes might sometimes get reordered even within packets... and so you should verify your data using a checksum method that will catch reordering.

Most links will do 1500 MTU anyway, but link layer have different minimum and maximum datagram sizes:

• Ethernet: 64 to 1500 (or higher with higher MTU capability)
• ATM: 53 bytes / datagram only
• Frame Relay: 46 to 4470 bytes (ref: IP fragmentation is broken

Unfortunately, the UDP header itself is 8 bytes... so this means, that the only size UDP payload that could certainly avoid fragmentation... is zero! (and will only fit in the smallest possible IPv6 packet anyway).

The best / reasonable course is probably to use 512 for your UDP datagrams and do your own checks for data getting out of order within a datagram, as well as dealing packets arriving out of order. (I.E, don't rely at all on IP to drop broken packets for you).

I fear i incur upset reactions but nevertheless, to clarify for me if i'm wrong or those seeing this question and being interested in an answer:

my understanding of https://www.rfc-editor.org/rfc/rfc1122 whose status is "an official specification" and as such is the reference for the terminology used in this question and which is neither superseded by another RFC nor has errata contradicting the following:

theoretically, ie. based on the written spec., UDP like given by https://www.rfc-editor.org/rfc/rfc1122#section-4 has no "packet size". Thus the answer could be "indefinite"

In practice, which is what this questions likely seeked (and which could be updated for current tech in action), this might be different and I don't know.

I apologize if i caused upsetting. https://www.rfc-editor.org/rfc/rfc1122#page-8 The "Internet Protocol Suite" and "Architectural Assumptions" don't make clear to me the "assumption" i was on, based on what I heard, that the layers are separate. Ie. the layer UDP is in does not have to concern itself with the layer IP is in (and the IP layer does have things like Reassembly, EMTU_R, Fragmentation and MMS_R (https://www.rfc-editor.org/rfc/rfc1122#page-56))

UDP is not "safe", so the question is not great - however -

• if you are on a Mac the max size you can send by default is 9216 bytes.
• if you are on Linux (CentOS/RedHat) or Windows 7 the max is 65507 bytes.

If you send 9217 or more (mac) or 65508+ (linux/windows), the socket send function returns with an error.

The above answers discussing fragmentation and MTU and so on are off topic - that all takes place at a lower level, is "invisible" to you, and does not affect "safety" on typical connections to a significant degree.

To answer the actual question meaning though - do not use UDP - use raw sockets so you get better control of everything; since you're writing a game, you need to delve into the flags to get priority into your traffic anyhow, so you may as well get rid of UDP issues at the same time.

UDP is an unreliable protocol when used by its self. But it is actually not that unreliable. Sure, if you used it for banking software it is unreliable, but if you used it for online gaming or video/audio streaming, it is pretty reliable.

If you are interested in the raw data, go here https://www.openmymind.net/How-Unreliable-Is-UDP/, and check out the statistics gathered by Karl Seguin.

TLDR: UDP has an average reliability of 98.64%, where as TCP has 100%.

If the 1.36% likelihood of a packet being dropped is a worry, then use TCP, else use UDP.