Internet Packets and Encapsulation

Hardware networks send packets of data having a specified format.
The software Internet is no different. It needs virtual packets.
1. Packets have a header of specified form, which is overhead, and a payload.
  
  Header Payload
2. Payload is 1 to 64k bytes in length, more practical than hardware.
3. Current practice is to avoid payloads more than a K or two.
IP4 Header format:

Version
H. Len
Service
Total Length

Identification
Flags
Fragment Offset

TTL
Type
Header Checksum

Source IP4 Address

Destination IP4 Address

Options, if any

0
8
16
24
31
1. Version: The IP version, 4.
2. H. Len: The header length, in words. Needed since the options field can vary in size.
3. Service: A routing priority whose use has evolved. We'll ignore it for now.
4. Total Length: Length of the whole packet, in bytes.
5. Identification, Flags and Fragment offset. These are used with fragmentation, which is discussed later. When sending a packet, the Identification field is a random number that changes with each packet sent, and the others are zero.
6. TTL = Time To Live. A packet is dropped after being routed this many times. This prevents a routing loop from keeping packets on the net forever. (A routing loop should not occur, but we don't want to make things worse if it does.)
7. Type: The type of data in the payload. This tells the receiver how to process the arriving data.
8. Header Checksum: Just that. Packets with a bad header checksum are dropped.
9. Source and destination addresses. The 32-bit IP4 addresses where the packet came from and is going to.
10. Options. Not often used. If options are present, the section is padded to a multiple of 32 bits.
IP6 header.
1. IP4 uses the same header for all packets, which can cause some waste. IP6 uses a more flexible format:
  
  Base Header Extension 1 . . . Extension N
2. The base header appears on all packets, and extensions (if any) allow additional data. (Not likely to get away with none.)
3. IP6 base header:
  
  Version
  Traffic Class
  Flow Label
  
  Payload Length
  Next Header
  Hop Limit
  
  Source IP6 Address
  (4 rows)
  
  Destination IP6 Address
  (4 rows)
  
  0
  8
  16
  24
  31
  1. Version: The IP version, 6.
  2. Traffic class: Similar to IP4 service.
  3. Flow label: Identifies packets as belonging together. For instance, all the packets in a connection might have the same flow label. Has a number of advantages for routing, and IP4 hasn't got one.
  4. Payload length: Just that, in bytes.
  5. Next header: Tells what comes after, either an extension header type or a payload type.
  6. Hop Limit: Same as IP4 TTL.
  7. The source and destination addresses, which are 128 bits each, so they cover four lines in the diagram.
4. Extension headers.
  1. Full implementations must support (though not always use) the following headers:
    1. Hop-by-Hop Options
    2. Routing
    3. Fragment
    4. Destination Options
    5. Authentication Encapsulating
    6. Security Payload
  2. Hop-by-hop, if present must come first. It is the only one read by routers along the way. Others are processed only by the recipient.
Encapsulation.
1. Since IP is a software protocol, there are IP hardware packets.
2. IP packets are carried as the payload of an underlying hardware.
  
  IP Header
  IP Payload
  
  Frame Header
  Frame Payload (IP datagram)
3. If the underlying network is Ethernet, the frame header Frame Type field is hex 0800, for Internet.
4. When the IP Datagram travels through the Internet, it must pass from one hardware net to another.
5. When flies through a router, it changes planes.
Fragmentation.
1. Each hardware limits its packet size, called a maximum Transmission Unit (MTU).
2. For instance, and Ethernet frame carries 46-1500 bytes of payload.
3. An IP datagram can have up to 64k, which doesn't fit too well.
4. In that case, the datagram must be fragmented into smaller messages.
5. IP4 Fragmentation Each fragment carries a copy of the original header, with changes.
  1. The fragment offset field is set to the position in the original payload of the first byte in the fragment. Units of eight bytes.
  2. The fragment flag (in the flags field) is set to 1, on all fragments but the last.
  3. The identification is not changed, so all the fragments have the same id, which is is different from other packets.
6. A datagram is a fragment if either its fragment bit is set, or its fragment offset is nonzero. The one without the flag set is the last one.
7. Any router will fragment any IP4 datagram that won't fit on the outbound net.
8. The datagram is reconstructed at the final destination.
  1. When the first fragment of a datagram arrives, the receiver starts a timer.
  2. It adds each additional fragment as it arrives.
  3. If the timer expires before they all arrive, the datagram is discarded.
9. There is also a do-not-fragment flag. If set by the sender, the datagram is discarded if it ever needs to fragmented.
Fragmentation in IP4 versus IP6.
1. In IP4, each datagram has space for the fragment information (identifier, flag and offset). In IP6, the fragment extension header is added to fragments, and it holds the id and offset.
2. The presence of the fragment header serves as the fragment flag.
3. The unfragmentable part is the base header, plus any extension that must be read by routers. It is copied to each fragment.
4. In IP4, datagrams are fragmented by routers as needed, but in IP6, a datagram must be fragmented by the sender. Routers do not do so.
5. How does IP6 know to fragment?
  1. To know if a datagram must be fragmented, the sender must know the smallest MTU of any network along the path. This is known as the path MTU.
  2. This can be discovered by sending packets of various sizes, and seeing which get through.
  3. Routers will usually send an ICMP error message (covered later) when it must drop a packet for size, so the sender can tell which ones make it.
  4. This formalizes a practice used in IP4, where TCP senders will find the path MTU to avoid the inefficiency of fragmentation. The MTU can be found in IP4 by sending packets with don't fragment sent.