s what happens if an IP header checksum error is detected by IP.)
This UDP checksum is an end-to-end checksum. It is calculated by the sender, and then verified by the receiver. It is designed to catch any modification of the UDP header or data anywhere between the sender and receiver.
Checksums should always be enabled. To check if a receiver has checksum enabled, use
tcpdump after sending a single UDP datagram with
There is no communication between the sender and receiver before the first datagram is sent (unlike TCP). Also, there are no acknowledgments by the receiver when the data is received (unlike TCP).
The physical network layer normally imposes an upper limit on the size of the frame that can be transmitted. Whenever the IP layer receives an IP datagram to send, it determines which local interface the datagram is being sent on (routing), and queries that interface to obtain its MTU. IP compares the MTU with the datagram size and performs fragmentation, if necessary. Fragmentation can take place either at the original sending host or at an intermediate router.
When an IP datagram is fragmented, it is not reassembled until it reaches its final destination.
If one fragment is lost the entire datagram must be retransmitted. IP itself has no timeout and retransmission is the responsibility of the higher layers. (TCP performs timeout and retransmission, UDP doesn't).
Also note the terminology: an IP datagram is the unit of end-to-end transmission at the IP layer (before fragmentation and after reassembly), and a packet is the unit of data passed between the IP layer and the link layer. a packet can be a complete IP datagram or a fragment of an IP datagram.
ICMP unreachable error (fragmentation required): another variation of the ICMP unreachable error occurs when a router receives a datagram that requires fragmentation, but the don't fragment (df) flag is turned on in the IP header.
Theoretically, the maximum size of an IP datagram is 65535 bytes, imposed by the 16-bit total length field in the IP header. With an IP header of 20 bytes and a UDP header of 8 bytes, this leaves a maximum of 65507 bytes of user data in a UDP datagram. most implementations, however, provide less than this maximum.
UDP programming interfaces allow the application to specify the maximum number of bytes to return each time. What happens if the received datagram exceeds the size the application is prepared to deal with? Unfortunately this depends on the implementation. The traditional Berkeley version of the sockets API truncates the datagram, discarding any excess data.
Chapter 12: Broadcasting and Multicasting
Broadcasting and multicasting only apply to UDP, where it makes sense for an application to send a single message to multiple recipients. TCP is a connection-oriented protocol that implies a connection between two hosts (specified by IP addresses) and one process on each host (specified by port numbers).
There are times, however, when a host wants to send a frame to every other host on the cable called a broadcast. We saw this with ARP and RARP. Multicasting fits between unicasting and broadcasting: the frame should be delivered to a set of hosts that belong to a multicast group.
The limited broadcast address is 255.255.255.255.
What routers and hosts do with broadcasting depends on the type of broadcast address, the application, the TCP/IP implementation, and possible configuration switches.
IP multicasting provides to services to applications: delivery to multiple destinations (with TCP these applications would deliver a separate copy to each destination); and solicitation of servers by clients.
Multicast group addresses are a separate class of IP address. A multicast group address is the combination of the high-order 4 bits of 1110 and the multicast group ID. These are normally written as dotted-decimal numbers and are in the range 18.104.22.168 through 22.214.171.124.
The set of hosts listening to a particular IP multicast address is called a host group. A host group can span multiple networks. Membership in a host group is dynamic