We know that UDP has a max segment size (65,507 bytes) due to size limit of a single IP packet, but IP also has a fragment/recombine feature, so why doesn't network layer use this feature to tackle oversize UDP segment? That is, when a UDP segment whose size is greater than one IP packet is handed to network layer, IP can first fragment it, using multiple IP packets to route them, and at the destination host, these fragments can be combined together to form the original UDP segment. This way, network layer can handle arbitrary large UDP segment, and transport layer doesn't need to worry UDP segment size, so why isn't this used in practice?
IP fragmentation happens at a lower level than UDP and it's basically to ensure IP datagrams (not UDP datagrams: I'll call the IP ones "packets" below even though the RFC confusingly calls them datagrams) can get from source to destination even when there's a point in the middle that cannot handle the original size of the IP packet.
The limitation on UDP is not IP, it's the UDP header, which has a 16-bit value for the length:
Octet
+-------------+
0 | Source port |
1 | |
+-------------+
2 | Destination |
3 | port |
+-------------+
4 | Length |
5 | |
+-------------+
6 | Checksum |
7 | |
+-------------+
In other words, if you send a 60K UDP datagram from a system that allows 61K IP packets, it will go of okay.
If it encounters a network segment that only allows 31K IP packets, IP will fragment it and recombine it later.
That's happening at the lower level. Even once the UDP datagram is recombined, it has the same length limitation due to the 16-bit length field in its header.