ARP, IP details

address resolution
ARP header
ARP request-reply
IP header
Alignment and Endianness
IP processing
IP fragmentation

Address Resolution

address resolution is the process of finding a hardware address given a protocol (IP) address
on Ethernet, for example, NICs will filter out packets that don't have their hardware address
on ATM, the data will have to be sent on a connection -- if the connection exists I need to figure out which VPI/VCI to use, otherwise I will need an ATM hardware address
how to resolve?
- table lookup (ARP table)
- computation (same addresses)
- message exchange -- ask someone else

Address Resolution: Table Lookup

fixed-size protocol address, fixed-size hardware address (for a given network)
could omit the network number from the table
sequential search may be OK
direct indexing (host number is index into table) may be OK
but who builds the table?

Address Resolution: Message Exchange

the information is available in the network
why not use the network to create the lookup table?
because we don't know who to send the request to
broadcast request, addressed host can reply -- every Ethernet NIC accepts broadcast frames
request from one or more servers, server(s) do table lookup -- hardware address of server must be configured in

Address Resolution: Computation

if the hardware address can be assigned, then we can assign the IP address and the hardware addresses to match
if the host part of the IP address is as long as the hardware address (same number of bits), simply assign the host number as the hardware address
if the hardware address is longer (more bits) than the host number, can assign an arbitrary hardware address prefix
if the hardware address is shorter (fewer bits) than the host number, can use any computation that won't cause collisions -- e.g. modulo n if host numbers are in the range of m to m+n - 1. If the hardware address has b bits, then 2^b > n -- why?

ARP packet

request (op 1) is sent to broadcast address, reply (op 2) to sender hardware address
only 28 bytes, padding needed to get to 46
hardware and protocol lengths (hl, pl) make ARP flexible enough for lots of protocols (e.g. IPv6)

ARP processing

when I have a packet to send on an ethernet to a directly-connected next-hop H
I build an ARP packet with protocol 0x800, op 0x1 (request), my hardware and IP addresses, target hardware address 0xffffffffffff, and target IP address H
I send this to the broadcast address with ethtype 0x806,
receivers discard it if not for them
H remembers my IP to hardware translation, and builds an ARP with protocol 0x800, op 0x2 (reply), H's hardware and IP addresses, my hardware address and IP addresses
if I don't get a reply, I retransmit

IP datagram

an IP datagram consists of a header followed by the payload (data)
an IP header is normally 20 bytes, but may have additional optional headers, up to a maximum of 60 bytes (always a multiple of 4 bytes)
the data can be arbitrary, but has a maximum length of 2¹⁶ - 1 - 20 bytes: 20 bytes is the minimum IP packet header length, and 2¹⁶ - 1 is the maximum length of the packet + header
overhead of sending header is less (per byte) for larger packets, but the same per packet
32-bit source and destination addresses in the IP header are IP addresses
IP is designed to be handled in software

IP header

from RFC 791

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| HLen  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP header fields

all fields are big-endian
version number must be first field (so we can evolve)
Type of Service is defined but not widely used
Total Length is needed for protocols that may pad the packet (e.g. ethernet) and to check for errors
header length used for options
TTL/Time To Live (really a "maximum hop count") kills packet in case of routing errors
protocols: 1 (ICMP), 6 (TCP), 17 (UDP)

IP Header fields

all fields are aligned on their own size
header checksum (RFC 1071, http://www.ietf.org/rfc/rfc1071.txt) only protects header
source address might be useful for responding, but not used in "normal" processing
packet ID and fragmentation fields (discussed next lecture) allow us to send packets larger than the underlying network's MTU
minimum MTU for carrying IP is 576 bytes

Endianness

32-bit number int x = 0x87654321 takes four bytes
integer pointer: int * ip = &x
character pointer: int * cp = (char *) &x
which byte is returned by *cp? The answer is either the byte 0x87 (big endian) or the byte 21 (little endian)
neither solution is "better" (Gulliver's travels): sun uses big-endian, intel uses little-endian
Internet uses big-endian

Alignment

32-bit number int x = 0x87654321 takes four bytes
integer pointer: int * p = &x
the bit value of p is int i = (int) p is i even? a multiple of four? the answer depends on the architecture
an 8-bit computer has no need for alignment
a 32-bit memory bus only needs one cycle to transfer an aligned 32-bit word, two cycles if the word is unaligned/misaligned
RISC processors give bus error if misaligned
C tries to align all its data, but allows arbitrary casting

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

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)