IP details

• IP processing
• IP fragmentation
• ICMP
• IPv6

Some properties of IP

• connectionless: routing is based only on the destination address
• TTL field keeps small routing mistakes from bringing down the network
• unreliable:
  • no packet sequence numbers,
  • no acknowledgements,
  • no error checking on the data
• possible errors:
  • loss
  • duplication
  • out-of-order delivery
  • corruption

IP Encapsulation

• when sending a datagram, IP must:
  • select the next hop and find out its hardware address
  • encapsulate the IP header and data as the payload of a hardware frame
  • the hardware header must identify this frame as an IP packet
• a router removes the old hardware header, processes the IP header (including checking the checksum), looks up in the routing table, and sends the datagram to the next hop
• problem: different networks may have different Maximum Transmission Units (MTUs) -- eg 1500 for Ethernet, 1024 for SLIP
• a maximum-sized IP packet over Ethernet cannot directly be sent over SLIP
• the original sender does not know the path MTU, the smallest MTU over the entire path -- especially since the path may vary over time

IP Fragmentation -- concepts

• if IP must send a datagram of size n, the IP header is h bytes long (typically h = 20), and the MTU is M < n + h, then IP must fragment the datagram:
  • the payload is split up into n / (MTU - h) different units, each no larger that M - h bytes
  • each unit is encapsulated into its own IP packet and sent separately
  • the IP header encodes information (in the packet ID, fragment offset, and flags fields) marking this as part of a larger packet
• the fragments are always reassembled by the end system, never by a router
• if any fragment is lost, the receiver must discard the entire datagram

IP Fragmentation -- details

• each packet carries a 16-bit packet ID field which must be different for packets sent at similar times by the same sender to the same destination (the field can be generated by a counter, or could carry a timestamp, or any other algorithm which yields different values for different packets)
• all fragments of a packet carry the same packet ID: if a fragment is re-fragmented, the smaller fragments still carry the same packet ID
• each fragment also carries a fragment offset: the position of the fragment payload in the original datagram.
• the fragment offset must be a multiple of 8, and the lowest 3 bits are not sent (since the field is 13 bits, and must encode an offset of up to 2¹⁶)
• the size of the original datagram is known when we receive the specially-marked last fragment

IP Fragmentation -- Bits and Bytes

• the fragment offset field holds the most significant 13 bits of the actual fragment offset
• two flag bits are used:
  • DF: don't fragment, if the packet would need to be fragmented, drop it instead (and send an ICMP error message)
  • MF: more fragments, true (1) if there are more fragments, false (0) if this is the last fragment
• most of the fragmented header fields are the same, except for fragment offset, flags, total length, and of course TTL and checksum
• some options go in the first fragment only, some in all, so header sizes might differ

Datagram Reassembly

• RFC 815
• goal: space and time efficient algorithm
• problems: don't know the datagram size until we receive the last fragment and since datagrams may arrive out of order, how do we know when we are done?
• answer: keep a list of holes. Initially, the list has one hole from 0 to 2¹⁶
• as datagrams arrive, shrink, split, or delete holes from the list
• when the last datagram arrives, as marked by MF=0, we can tell the total (reassembled) packet size n, so we can get rid of the hole from n to 2¹⁶-1
• once the hole list is empty, the datagram is complete
• the hole list can be kept in the buffer space allocated to the (soon-to-be-filled) holes, lessening the need for dynamic memory allocation

IP Fragmentation -- In-class Exercise

• work individually
• fragment the IP packet with: version 4, header length 20 bytes, TOS 0, total length 31, packet ID 0x90ab, DF = 0, MF = 0, fragment offset 0x100, TTL 17, protocol 17, checksum (correct), source 128.171.10.1, destination 128.171.10.2, data 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b.
• the MTU of the network you are sending on is 28 bytes
• write down all the bytes of all the packets you send (you don't need to compute the checksum)

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 and echo reply, ping
• send an ICMP error packet whenever we drop a (non ICMP error) packet
• ICMP: RFC 792

ICMP Echo

• Echo packet (type 8) or Echo Reply (type 0)
• ICMP 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)

Other ICMP Types

• [3] Destination Unreachable (because network, host, or protocol unreachable, or because prohibited...)
• [11] Time Exceeded: in transit (TTL = 0), or during reassembly (missing fragment)
• [5] Redirect: use this other router for this destination (not very secure)
• [9] Router advertisement
• [10] Router solicitation
• [4] Source Quench
• [12] Parameter Problem

Problems with IPv4

• address space too small (32 bits).
• insufficient structure in addresses.
• no support for real-time.
• no support for security.
• no support for auto-configuration.
• no support for mobile hosts.

IPv6

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6

• Header Length is missing
• Type of Service is now Traffic Class, and most of it (6 of 8 bits) is now dedicated to "differentiated services", DiffServ
• Fragmentation (Id, flags, fragment offset) is in an extension header
• TTL is now Hop Limit
• Protocol is now Next Header (and substitutes for header length)
• Checksum is gone (and now required in higher-layer protocol)
• Options are in extension headers.

IPv6 Extension Headers

• Hop-by-Hop/Jumbo Payload (up to 2³² bytes/packet)
• Routing
• Fragmentation (source only)
• Destination Options
• Security/Authentication

IPv6 Address Classes

• Supersets of other standard addresses (NSAP/02,03, IPX/04,05)
• Provider-based addresses (20-3F)
• v4-compatible addresses (::00:1.2.3.4) -- so a tunnel endpoint can have corresponding IPv4 and IPv6 addresses
• v4-mapped addresses (::FFFF:1.2.3.4) -- an address of a node that is strictly IPv4, represented as an IPv6 address
• Link local use addresses (FE80::0)
• Site local use addresses
• Multicast (FF00::0)
• Loopback (0:0:0:0:0:0:0:1)

IPv6 Autoconfiguration

• RFC 2462
• each interface usually has a unique number
• if the number has fewer than 118 bits, it can be prefixed by FE8 (10 bits) to form a unique link-local address
• however, the host is required to perform duplicate-address detection, by broadcasting a mesage (a Neighbor Solicitation ICMP message) requesting whether anyone else is using that number
• note that a link-local address is not routable
• if there is a router on the network, the router will send Router Advertisement messages periodically
• the host can also send Router Solicitation messages
• Router Advertisements carry Prefix information that can be used to form a Site Local address or a global address
• the prefix length must be 128 - the length of the interface identifier

IPv6 Flow Labels

• special services (quality of service, real-time) may be requested for a specific flow
• all packets in a flow should have the same flow label, source and destination address, and hop-by-hop extension headers or routing headers
• flow labels must be random so any subset of bits can be used for hashing
• many possible flows between any two hosts
• packets not in a flow have flow label zero
• routers may use flows for soft state