Networks Lecture 13

IP Datagram Format

+----------------------------------------------+
| vers | hdr len | TOS |     datagram len      |
+------+---------+-----+-----------------------+
|     identifier       | flags | frag offset   |
+--------+-------------+-----------------------+
|  TTL   |    proto    |    header checksum    |
+--------+-------------+-----------------------+
|             source address                   |
+----------------------------------------------+
|             dest. address                    |
+----------------------------------------------+
                  options....
+----------------------------------------------+
|                   data...                    |
vers
IP version - distinguishes IPv4 vs. IPv6.
hdr len
Number of 32 bit words in IP header. Usually 5. Only > 5 if there are IP options.
TOS
Type of service: 1=min delay, 2=max throughput, 3=max reliability, 4=min cost. Routers may interpret these values in order to provide different kinds of service to different flows.
datagram len
Length of the entire IP datagram, including both header and payload. Although the datagram length can usually by determined from the link layer frame, some link layer protocols do not preserve this information. Therefore, IP datagrams must be able to determine their own length.
identifier
Unique identifier of the datagram - used when the datagram is fragmented. All the fragments have the same identifier.
flags
The "more fragments" bit is set when additional fragments are part of the overall datagram.
frag offset
Used to reassemble fragments into a complete datagram.
TTL
Decremented by 1 every time the datagram is forwarded by a router. If it reaches 0, then the datagram is dropped. Prevents packets from lingering forever if there are routing loops.
proto
Specifies the protocol that the datagram's payload is part of. Could be UDP or TCP (transport layer), or could be a network-layer protocol such as ICMP.
header checksum
One's complement checksum of 16 bit words of the IP header only.
source address
The source IP address.
dest. address
The destination IP address.

IP Fragmentation

The size of the IP datagram may exceed the maximum transfer unit (MTU) imposed by the link layer. E.g., ethernet frames have an MTU of 1500 bytes. IP datagrams exceeding the MTU of the output link are fragmented by the router.

All fragments are routed just like any other network-layer packet. One subtlety is that the size of a fragment may exceed the link layer MTU, in which case it will need to be fragmented again.

Reassembly is done on end systems.

IPv4 Addressing

IP addresses are 32 bit values. They are often written as dotted quads where each component is an 8 bit value. E.g., "143.229.6.42". However, it is important to understand that the 8 bit boundaries have no special meaning.

How are IP addresses assigned to hosts? Every router must be capable of routing an IP datagram to any arbitrary destination host in the world. Without some kind of structure to organize "related" addresses, this would be unmanageable. We would potentially need 2^32 forwarding table entries at every router!

Subnets

A subnet is a network where

  1. All hosts in the subnet share the same address prefix
  2. every host in the subnet can communicate with every other host in the subnet without needing to forward datagrams through a router. (i.e., they are fully connected at the link level)
  3. hosts in the subnet can reach the rest of the network (internet) via a router or routers attached to the subnet

Because all of the hosts in the subnet share a common address prefix, routers in the larger network can forward packets towards all hosts in the subnet using a single forwarding table entry.

CIDR Addressing

CIDR = "Classless Inter-Domain Routing"

CIDR is a notation for writing address prefixes. For example

143.229.6/24

is the address prefix for the cs.vassar.edu domain. The /24 indicates that the prefix is 24 bits long.

In reality the cs.vassar.edu domain is organized as a single subnet. If we wanted to, we could further divide the cs.vassar.edu domain into four subnets by giving each smaller subnet a distinct address prefix. For example, the prefixes

143.229.6.192/26
143.229.6.128/26
143.229.2.64/26
143.229.2.0/26

divide the prefix 143.229.6/24 into four equally-sized subnets. It is clear how this is done by examining these prefixes in binary form:

Decimal Binary Length
143.229.6 10001111 11100101 00000110 24
143.229.6.192 10001111 11100101 00000110 11 26
143.229.6.128 10001111 11100101 00000110 10 26
143.229.6.64 10001111 11100101 00000110 01 26
143.229.6.0 10001111 11100101 00000110 00 26

Forwarding decisions are always made by matching a destination address to the longest possible prefix.

Hierarchical Routing

Using CIDR addressing gives us a nice way to achieve hierarchical addressing, where forwarding decisions in the network-at-large can be made using a relatively small number of routing table entries. Here is how this might be accomplished.

ISPs are allocated large contiguous blocks of address space, where the block can be described using a single, short address prefix. The ISP then allocates chunks of this contiguous address space to its customers, in much the same way that we divided the cs.vassar.edu address prefix into smaller chunks in the example above.

Anywhere in the internet (except inside the ISP's network), routers need only a single forwarding table entry to reach any host in any customer network. The reason that this is possible is because the original block of address space that the customer networks were allocated from can all be described by a common (short) address prefix.

Things may not work out quite this nicely in practice. Customers can switch ISPs, taking their IP address prefix with them. Now, in order to route datagrams towards the customer's new ISP, a new more specific forwarding table entry will be needed. This is fragmentation of the original address block. Another reason fragmentation can occur is if some customer networks are served by multiple ISPs.

The problem of fragmentation means that larger forwarding tables may be necessary. However, fragmentation does not cause datagrams to be mis-routed. As long as a customer's new ISP advertises a route whose prefix is longer---more specific---than the original prefix covering the prefix for the original address block, datagrams will still reach the hosts in the customer network.

ARP and DHCP

ARP

One detail we have glossed over is how datagrams are sent and delivered between hosts connected to the same subnet. Most local area networks are based on link-layer technologies that require a link-layer address to be specified in order for a link layer frame to be efficiently delivered to its destination. For example, in an ethernet LANs, link-layer frames are addressed by specifying an ethernet address. As far as the network (IP) layer is concerned, the network-level address (IP address) is sufficient to get a network datagram to its destination. So, how do we turn an IP address into a link-layer address?

Note that for broadcast networks like ethernet, each host could simply send each transmitted frame to the broadcast address, which is a special link-layer address indicating delivery to all nodes attached to the LAN. However, this is inefficient, especially when link-layer switches are used.

The task of mapping IP address to link-layer addresses is the responsibility of the protocol ARP protocol. ARP = Address Resolution Protocol.

How ARP works:

Each node maintains an ARP cache containing a map of recently resolved IP addresses and their corresponding link-layer addresses.

ARP messages are carried directly in link-layer frames: they are not encapsulated in IP datagrams.

Many TCP/IP implementations perform gratuitous ARP queries when they enable their network interface. A gratuitous query is one where a node asks for the link layer address of its own IP address. This serves two purposes:

DHCP

Another detail we are missing is how nodes obtain their own IP address. One way is for the network administrator to manually configure each node. This is not a good solution for large networks.

The DHCP protocol is a way that nodes can automatically learn their IP address. One machine on a LAN serves as the DHCP server. The DHCP protocol works as follows:

  1. When a node needs to get an IP address (usually when it boots up), it sends a DHCP request encapsulated in a UDP segment sent to the IP broadcast address, 255.255.255.255. (The IP broadcast address is automatically translated into the link-layer broadcast address, ensuring that all nodes on the LAN hear the DHCP request.)
  2. A server process running on the DHCP server machine determines an IP address for the node (possibly by checking the node's link-layer address). It puts an entry in its ARP cache (associating the node's IP address with its link-layer address) and then sends a DHCP response in a UDP datagram addressed to the node's new IP address.
  3. The client receives its reply, and now knows its IP address

One subtlety occurs in step 1: the node trying to learn its IP address must send a UDP segment. What source IP address should appear in the IP datagram encapsulating the UDP segment, when the node does not know its own IP address? The answer is that a special IP address, 0.0.0.0, is used as the source address.

In addition to configuring IP addresses, DHCP can be used for other important configuration information such as