This preview shows page 1. Sign up to view the full content.
Unformatted text preview: w how the datagram was fragmented, For this
reason alone, fragmentation is often avoided. [Kent and Mogul 1987] provide arguments for
Using UDP it is easy to generate IP fragmentation. (We'll see later that TCP tries to avoid
fragmentation and that it is nearly impossible for an application to force TCP to send segments
large enough to require fragmentation.) We can use our sock program and increase the size of
the datagram until fragmentation occurs. On an Ethernet the maximum amount of data in a
frame is 1500 bytes (Figure 2.1), which leaves 1472 bytes for our data, assuming 20 bytes for
the IP header and 8 bytes for the UDP header. We'll run our sock program, with data sizes of
1471, 1472, 1473, and 1474 bytes. We expect the last two to cause fragmentation:
discard file:///D|/Documents%20and%20Settings/bigini/Docu...homenet2run/tcpip/tcp-ip-illustrated/udp_user.htm (7 of 29) [12/09/2001 14.46.58] Chapter 11. UDP: User Datagram Protocol Figure 11.7 shows the corresponding tcpdump output.
0.0003) bsdi-1112 > svr4.discard: udp 1471
bsdi.lll4 > svr4.discard: udp 1472
bsdi.lll6 > svr4.discard: udp 1473 (frag
bsdi > svr4: (frag 26304:l@1480)
bsdi.1118 > svr4.discard: udp 1474 (frag
bsdi > svr4: (frag 26313:2@1480) Figure 11.7 Watching fragmentation of UDP datagrams.
The first two UDP datagrams (lines 1 and 2) fit into Ethernet frames, and are not fragmented.
But the length of the IP datagram corresponding to the write of 1473 bytes is 1501, which must
be fragmented (lines 3 and 4). Similarly the datagram generated by the write of 1474 bytes is
1502, and is also fragmented (lines 5 and 6).
When the IP datagram is fragmented, tcpdump prints ad...
View Full Document
- Spring '12