IP routing

ICMP
fragmentation and reassembly

Internet Control Message Protocol (ICMP)

Internet is complex
how do we find out what is going wrong?
send a packet "there and back": ICMP echo, ping
send an ICMP error packet whenever we drop a (non ICMP error) packet
ICMP: RFC 792

ICMP headers

error message:

Destination Unreachable Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

information packets:

Echo or Echo Reply Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

ICMP Echo

Echo packet (type 8) or Echo Reply (type 0)
checksum covers entire packet
identifier (typically process ID on sender machine)
sequence number (typically 1, 2, 3...)
arbitrary data follows (could be large)
for ping, data typically holds binary date and time (2 32-bit words, 8 bytes)
timestamp message is similar

Other ICMP Types

type = 3: Destination Unreachable (network, host, protocol, prohibited...)
type = 11: Time Exceeded (in transit, during reassembly)
type = 5: Redirect: use this other router for this destination
type = 9: Router advertisement
type = 10: Router solicitation
type = 4: Source Quench
type = 12: Parameter Problem

Fragmentation and Reassembly

Different interfaces have different MTUs (Maximum Transmission Unit):
- 1006 bytes for SLIP
- 1500 bytes for Ethernet
- 4096 bytes for FDDI
- 65527 bytes for ATM AAL-5
minimum MTU for carrying IP: 576 bytes
if a host or a router must send an IP packet bigger than the MTU, the packet is fragmented and each fragment is sent separately
each fragment is a valid IP packet
fragments are reassembled only by the destination host, never by routers
in-class question: when would a host have to send a packet larger than the MTU?

Fragmentation Variables

packet ID is the same for different fragments of the same packet, but different for different packets
fragment offset is 1/8 the position of the first byte in the fragment (e.g. if the position is 1200, the fragment offset is 150 = 1200/8)
more fragments bit (MF) is 0 if this is the last fragment, 1 otherwise
don't fragment bit (DF) is 0 if you may fragment this packet, 1 otherwise

Fragmentation Algorithm

packet of total length L, header length h, to be sent on interface with MTU M < L
if DF is set, discard the packet
select n lengths L₁ ... L_n such that:
- L - h = sum_{1 <= i <= n} (L_i - h)
- L_i <= M for 1 <= i <= n
- (L_i - h) mod 8 = 0 for 1 <= i < n
send each fragment as an IP packet. All header fields are the same as for the original, except:
- total length is L_i + h
- fragment offset is (sum_{1 <= j < i} (L_j - h)) / 8
- MF is 1 except for the last fragment

Reassembly Constraints

packet length is unknown until we get a fragment with MF=0
fragments may be out of order
packets may be as small as one byte
prefer not to use dynamically-allocated memory
packet ID, protocol number, and source and destination address must match for all the fragments of one packet
must keep time-to-live timer for each packet, discard a packet if TTL expires and the packet is incomplete

Reassembly Algorithm

RFC 815, http://www.ietf.org/rfc/rfc815.txt
single, maximum size buffer needed per packet (no dynamic memory allocation needed)
information about missing fragments (linked list of ``holes'') kept in the buffer itself
A "hole" is a part of the complete packet that we haven't received yet
Logically, before receiving the first fragment we have a single hole, from 0 to oo (16-bit numbers)
may have to delete holes or split one hole to create two new ones
packet payloads are placed into the buffer according to their fragment offset
once the last hole is deleted, the packet is reassembled

Reassembly Steps

a hole describes byte positions first and last (inclusive), and the same for a fragment
when receiving a packet frag, loop over each hole hole:
1. if frag.first > hole.last, ignore this hole
2. if frag.last < hole.first, ignore this hole
3. delete hole
4. if frag.first > hole.first, create a new hole descriptor with newhole.first = hole.first and newhole.last = frag.first - 1
5. if frag.last < hole.last and frag.MF = 1, create a/another new hole descriptor with newhole.first = frag.last + 1 and newhole.last = hole.last

In-class exercise

I have the following holes (given as offset of first byte, offset of last byte): (0, 79), (120, 143), (160, oo)
insert fragment 104, 111, MF=1 into this list
insert fragment 160, 162, MF=0 into this list
insert fragment 0, 79, MF=1 into this list
insert fragment 80, 119, MF=1 into this list