1) Application programming interface limitations. Generally sockets have a buffer size of 8K, but both provide APIs to set the buffer size (SetSockOpt). In general, it is best to send UDP no more than 512 bytes, which basically guarantees no packet loss (because most networks and hosts have MTUs greater than 512).
2) TCP/IP kernel limitations. There may be implementation features that prevent IP lengths up to 65535.
Since IP is capable of sending or receiving datagrams of a specific length does not mean that the receiving application can read data of that length. Therefore, the UDP programming interface allows applications to specify a maximum number of bytes to be returned at a time. What happens if the length of a received datagram is greater than the application can handle? The typical Berkeley version of the socket API truncates the datagram and discards any excess data; the socket API under SVR4 (including Solaris 2.x) does not truncate the datagram. Excess data is returned in later reads. It also does not notify the application of multiple read operations from a single UDP datagram; the TLI API does not discard data. Instead, it returns a flag indicating that more data is available, and later read operations by the application return the rest of the datagram.
UDP does not fragment; fragmentation is something the IP layer does, and fragment reorganization is the responsibility of the IP layer.
If you send data using UDP, it is best not to have too much data, and you should avoid splitting packets between the IP layer and the link layer to prevent loss of fragmentation, which can result in loss of the entire UDP packet.