Ever since I did sockets programming on a PDP/11, it's been the case that IP fragmentation will take care of the case where an IP datagram (such as a UDP datagram) is larger than the MTU for the segment allows.
Thus, I can send a UDP datagram of size 30 kB, and it might fragment to 20 segments of 1.5 kB on Ethernet, and then fragment each into three segments of <576 bytes later on for some particular wireless link, and as long as all the fragments make it to the other end, the UDP datagram makes it to the other end.
Then, I came across the documentation for the UDP socket in node.js, which claims that routers will drop datagrams that do not fit the MTU of the next segment. I thought this was only the case for datagrams with the "don't fragment" bit set in the header, but given that node.js is supposed to be a high quality product with some credibility in network circles, I'm wondering whether I missed something and many routers will now treat all datagrams as if they are "don't fragment?"
Here's the link: http://nodejs.org/api/dgram.html#dgram_socket_send_buf_offset_length_port_address_callback
Here's the quote:
generally sending a datagram greater than the (receiver) MTU
won't work (the packet gets silently dropped, without informing
the source that the data did not reach its intended recipient).
So, did I miss something, or does the node.js documentation need an update?
So, it turns out that the answer is a little more nuanced. Fragmentation is still a part of IPv4, and is largely supported by the Internet at large. IPv6 removes fragmentation, and instead defers to the application to do MTU discovery. Thus, the documentation note that made me question my assumptions is not so much "wrong," as it is "living in the future where somehow, most people have switched to IPv6."