What is the largest Safe UDP Packet Size on the Internet

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 (used for VPNs and the like) in order to route the packet to its destination. So if you do not know the MTU 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.

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.

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 :)

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

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.

There are different maximums for udp. In the End, it is your choice which limits you consider safe enough. Note: UDP in itself is not safe, therefore your packets could be lost at any moment.

Note: All of these have a range. How large it can actually be, depends on your IP Options. In general, you can calculate it like that: [upper maximum]-[length of IP-Options, in bytes]. All the ranges listed here exclude the UDP-Header(8 bytes)

Minimum Maximum Tranfer Limit(or something like that, i forgot the actual name and couldn't find it anywhere):512-552 bytes

This is probaly the safest size. The IPv4 protocol reqires all hops to transmit packets of this size, larger packets may be dropped by any host at any time.

Maximum Transfer Unit:1432-1472:

Packets of this size can be sent in a single ethernet frame without being fragmented. The loss of any fragment will result in the whole packet being useless. Therefore, when exceeding this limit, the chances of your packet becoming useless increase, due to fragmentation and potential loss of single fragments.

Absolute Limit: 65467-65507:

No Packet can exceed this limit, because at this limit, the IPv4 protocol reaches its full potential. you cannot send larger packets. This is because the IPv4 protocol reserves only 2 bytes(16 bit) for the total length. setting all these bits to 1, you get 65535. Subtracting the IP(20-60 bytes) and the UDP header(8 bytes), you get this limit. Packets of this size will result in at least 44 fragments. Keep in mind, the loss of any of these fragments will lead to the whole packet being useless.