Internetworking

Lecture 2: Basic routing, ARP, and

Basic Routing
basic IP

Literature: Delivery, Forwarding, and Routing

Forouzan, TCP/IP Protocol Suite: Ch 6 - 8 of IP packets

lecture_2 lecture_2

Connection-oriented vs Connectionless Direct vs Indirect delivery

Connection-Oriented Services Direct delivery
The network layer establishes a connection between a source and a The final destination is connected to the same A
destination physical network as the sender.
Packets are sent along the connection. IP destination address and local interface has
The decision about the route is made once at connection same netmask indirect delivery
establishment Map IP address to physical address: ARP R1

Routers/switches in connection-oriented networks are stateful Indirect delivery indirect delivery

Connectionless Services From router to router, last delivery is direct R2

The network layer treats each packet independently Destination address and routing table: Routing indirect delivery
Route lookup for each packet (routing table) A B R3
IP is connectionless direct delivery direct delivery
IP routers are stateless
direct delivery

B
lecture_2 lecture_2 R

Next-hop Routing Routing Table Search - Classful

How do you hold information about route from A to all other hosts?
Determine class from destination address
A R1 R2 R3 B
Store table of host/network address and nexthop in every node
Search within class
Routing table often divided into buckets
N1, - N1, - N1, R1 N1, R2 N1, R3
N2, R1 N2, R2 N2, R4 N2, R2 N2, R3
N3, R1 N3, R2 N3, R4 N3, R2 N3, R3 Class A bucket
N4, R1 N4, R2 N4, R3 N4, - N4, -
A B
R1 R2 R3 destination
destination IP
IP address
address
Class B bucket
N1 N4
R4 Class C bucket
N2 N3

C D E F
lecture_2 lecture_2

1
 Routing Table Search - Classless Routing Tables
Longest prefix first The basic idea with IP addressing (and CIDR) is to aggregate
addresses
Conceptually: divide table in 32 buckets - one for each netmask
length and match destination with longest prefixes first more specific networks (with longer prefixes)
less specific networks (with shorter prefixes)
SW algorithms: tree, binary trees, tries (different data structures)
More aggregation leads to smaller routing tables
HW support: TCAMs Content Addressable Memory
The ideal situation is to have domains publishing (exporting) only a
Masklen small set of prefixes
0 Effective address assignment policy
Netid
1 Some mechanisms lead to increased fragmentation
Netid
# of available addresses decreasing distribution of long prefixes (/24)
...

31 Multihoming - sites having several subnetworks from different providers

32 Current routing tables (# of entries) is ~150000 (~60% are /24 prefixes)

lecture_2 destination
destination IP
IP address
address lecture_2

Routing Table Common Fields IP Router Model

Routing
Information
Mask Network Next-hop Interface Flags Reference Use IP RIB Base
Address Address count Control Routing
Plane
........ .............. ............... .............. ......... ................ ......
Forwarding
IP Information
Forwarding FIB Base
Data
Mask netmask applied for the entry [255.255.255.0] Plane
Network address destination network [192.168.15.0] Ethernet
Interface
FDDI
Interface
Next-hop address next router [130.237.15.1] Router
Interface outgoing interface [eth0]
Flags status/info [U(p), G(ateway), H(ost-specific)...] A Router can be partitioned into a dataplane and a controlplane
The dataplane is fast and special purpose handles packet
Reference count # of users using this route forwarding in real-time
Use # of packets transmitted for this destination The control plane is general purpose handles routing in the
background
lecture_2 lecture_2

IP Forwarding
A router switches packets between network interfaces
Extracts header information from the incoming datagram
Destination IP address
Makes a lookup in the forwarding information base by making a match
against networks
Next-Hop IP address,
ARP
Outgoing interface,...
Modifies datagram header
Mapping between logical IP addresses and
Sends on outgoing interface
physical addresses
But a router performs much more than IPv4 lookup
Access lists, filtering
Traffic management
Other protocols: Bridging, MPLS, IPv6, ...

lecture_2 lecture_2

2
 Logical and Physical Addresses Communicating with a next-hop
Name: bsdi
bsdi sun
sun svr4
svr4
Name: bsdi
bsdi sun
sun svr4
svr4

MAC addr: 0:0:c0:6f:2d:40 8:0:20:3:f6:42 0:0:c0:c2:9b:26

IP addr: 140.252.13.35 140.252.13.33 140.252.13.34
MAC addr: 0:0:c0:6f:2d:40 8:0:20:3:f6:42 0:0:c0:c2:9b:26
IP addr: 140.252.13.35 140.252.13.33 140.252.13.34
Problem: bsdi wants to send an IP packet to svr4
No routers between sender and receiver directly connected host
A hosts network interface card (NIC) has: Getting the IP address of svr4
a hardcoded, physical MAC address Static configuration
e.g., 48-bit Ethernet address DNS: Name Address (Later lectures)
a configured, logical IP address Getting the MAC address of svr4
a configured name Static configuration
Dynamic Address Resolution - ARP

lecture_2 lecture_2

ARP - Address Resolution Protocol ARP Example

bsdi intends to send an IP datagram to svr4 (140.252.13.34)
Problem: we are to send a packet to an interface on a 1. Send an ARP request on broadcast to all stations:
directly attached network - we know the IP-address of the who has 140.252.13.34?
destination but not the MAC address. 2. svr4 identifies it as its own address and sends an ARP reply on unicast
back to bsdi
Idea: Broadcast a request - On which MAC address can I have 140.252.13.34 and its mac address is 0:0:c0:c2:9b:26
IP-address X be reached?. 3. bsdi sends the datagram to svr4 using the resolved mac address
ARP request 4. Note that sun and svr4 can update their ARP caches with bsdi!
The host/router with the destination replies with its MAC
address
bsdi sun svr4
ARP reply
This is the basic functionality of ARP 3 1 2

lecture_2 lecture_2

ARP Packet ARP Optimizations

Two length fields
ARP cache
Hardware (Ethernet address length: 6)
Protocol (IP address length: 4)
Resolved addresses are saved in a cache.

Sender Ethernet and IP address Works because of correlations in use of addresses

Target Ethernet and IP address Limits ARP traffic
ARP is encapsulated directly into a data link frame (e.g., Ethernet) Entries in the ARP cache times out
hardware size Network is snooped
hw prot hw prot sender sender target target Since the senders Internet-to-Physical address binding is in every
type type len len op Ethernet addr IP addr Ethernet addr IP addr
ARP broadcast; (all) receivers update their caches before
2 2 1 1 2 6 4 6 4
processing an ARP packet
protocol size

lecture_2 lecture_2

3
 ARP Timeouts Indirect/Direct Delivery and ARP
If there is no reply to an ARP request A sends an IP packet to B through router R
The machine is down or not responding Ethernet links to connect A and B to R
Request was lost, therefore retry (but not too often)
Eventually give up (When?) IP A IP R IP B

ARP cache timeouts

MAC a MAC r1 MAC r2 MAC b
completed entry in 20 minutes (BSD Unix)
incomplete entry in 3 minutes (BSD Unix)
IP Header Src: A, Dst: B Src: A, Dst: B

Ethernet Header Src: a, Dst: r1 Src: r2, Dst: b

Indirect delivery Direct delivery

lecture_2 lecture_2

Proxy ARP (RFC 826) Gratuitous ARP

Proxy ARP - someone Host sends an ARP request of its own address
responds to ARP requests on Generally done at boot time to inform other machines of its address
someone elses behalf (possibly a new address) - they get a chance to update their cache entries
gemini immediately
Allows sub-networks to be arp request for
140.252.1.129 Lets hosts check to see if there is another machine claiming the same
hidden address duplicate IP address sent from Ethernet address a:b:c:d:e:f

arp reply
Example: sun is hidden behind 140.252.1.183
As noted before, hosts have paid the price by servicing the broadcast,
netb: Netb responds on behalf netb so they can cache this information - this is one of the ways the proxy
of sun. ARP server could know the mapping
slip
140.252.1.129
Note that faking that you are another machine can be used to provide
sun failover for servers

lecture_2 lecture_2

RARP: Reverse Address Resolution

Protocol (RFC 903)
How to get your own IP address, when all you know is your link address
Necessary if you dont have a disk or other stable storage
RARP request - broadcast to every host on the network
(i.e., EtherDST=0xFFFFFF), TYPE=0x8035
RARP server: I know that address! and sends an RARP reply
Source host - receives the RARP reply, and now knows its own IP addr
RARP packet has exactly the same format as ARP packet
BOOTP/DHCP is a more powerful alternative to RARP
RARP Server
Someone has to know the mappings - quite often this is in
the file /etc/ethers
Since this information is generally in a file, RARP servers
are generally implemented as user processes
Unlike ARP responses which are generally part of the
TCP/IP implementation (often part of the kernel)
How does the process get the packets - since they arent IP
and wont come across a socket?
PCAP Packet Capture (used by Tcpdump/Ethereal)
BPF Berkeley Packet Filter (older)
RARP requests are sent as hardware level broadcasts -
therefore are not forwarded across routers

lecture_2 lecture_2

4
 Issues in IP
Following the end2end argument, only the absolutely
necessary functionality is in IP
Best Effort Service: Unreliable and Connectionless
Application or Transport layer handles reliability
IP How to deliver datagrams over multiple links (hops) in an
internetwork?
Addressing
Basic functionality and the IP packet header
Best-effort delivery service
Forwarding of packets from one link to another
Error handling

lecture_2 lecture_2

IPv4 Header RFC 791 The Version Field

Version
HLEN Header Length
Version 3 (IEN 21)
Type of Service Stems from when TCP was being split into one component handling
Total Length
hop-by-hop communication (IP) and one component handling end-
to-end communication (TCP). IEN 21 1 February 1978.
Header + Payload

Fragmentation Version 4 (RFC 791)

ID, Flags, Offset IPv4
TTL Time To Live
Version 5 (RFC 1190)
Limits lifetime

Protocol ST-II - Multimedia streaming protocol

Higher level protocol Version 6 (RFC 2460)
Header checksum
IPv6
IP Addresses
Source, Destination The McGraw-Hill Companies, Inc., 2000
Options
lecture_2 lecture_2

The Length Fields The Type of Service Field

Header Length (4 bits) Type of Service (ToS): 8 bits
Size of IPv4 header including options. Intended as a field for specifying Quality of Service on a
Expressed in number of 32-bit words (4-byte words) per-packet basis.
Min is 5 words (=20 bytes) Few applications set the TOS field.
Max is 15 words (=60 bytes) limited size limited use Unless an added cost/policy check/ associated with usage of a
precedence level - it is very likely going to be abused.
Total Length (16 bits) Long history of experimental use
Total length of datagram including header. RFC 791 original
If datagram is fragmented: length of fragment. RFC 1122, 1349, 1455 modified the meaning of the ToS field
Expressed in bytes. Current proposal: RFC 2474
Max: 65535 bytes. (This is IPs length limit) Differentiated Services
Many systems only accept 8K bytes. Early Congestion Notification (ECN): RFC 2481, 3168

lecture_2 lecture_2

5
 The ToS Byte Original proposal DSField Current Proposal
Bit 0 Bit 7
Bit 0 Bit 7 DSCP ECN
Precedence TOS
Differentiated Services (DiffServ) proposes to use 6 of these bits to
provide 64 priority levels - calling it the Differentiated Service (DS) field
Original Proposal RFC 791 RFC 2474
Bits 0-6: Differentiated Services CodePoint (DSCP)
Bits 0-2: Precedence
The DSCP is set when entering an area and determines the QoS
Defines priority e.g., when packets must be dropped handling of the IP datagram in the routers within that area
Scheduling
Bits 3-5: TOS
Shaping
Bit 3: 0 = Normal Delay, 1 = Low Delay Queue Dropping
Bit 4: 0 = Normal Throughput, 1 = High Throughput Explicit Congestion Avoidance (ECN)
Bit 5: 0 = Normal Reliability, 1 = High Reliability. ECN Capable Transport (ECT)
Congestion Experienced (CE)
lecture_2 lecture_2

Fragmentation MTU Fragmentation contd

Physical networks maximum frame size
MTU Maximum Transfer Unit.
A host or router transmitting datagram larger than MTU of
link must divide it into smaller pieces - fragments.
Both hosts and router may fragment
But only destination host reassemble!
The McGraw-Hill Companies, Inc., 2000
Each fragment routed separately as independent datagram

If the IP datagram is larger than the MTU of the link layer, it In effect, only datagram service (e.g. UDP)
must be divided into several pieces to fit the MTU this is TCP uses 576 byte MTU or path MTU discovery
called fragmentation 3 fields of the IP header concerns fragmentation

lecture_2 lecture_2

The Fragmentation Fields Fragmentation Example Offset

Identification: 16 bits
ID + src IP addr uniquely identifies each datagram sent by a host
The ID is copied to all fragments of a datagram upon fragmentation
Flags: 3 bits
RF (Reserved Fragment) for future use (set to 0)
DF (Dont Fragment).
Set to 1 if datagram should not be fragmented.
If set and fragmentation needed, datagram will be discarded and an error
message will be returned to the sender
MF (More Fragments)
Set to 1 for all fragments, except the last.
Fragmentation Offset: 13 bits
8-byte units: (ipip_frag << 3)
The McGraw-Hill Companies, Inc., 2000
Shows relative position of a fragment with respect to the whole datagram

lecture_2 lecture_2

6
 Fragmentation Example Detailed The TTL field
MTU = 1500 bytes
TTL - Time To Live: 8 bits
IPv4 hdr UDP hdr Limit the lifetime of a datagram - avoid infinite loops
id=0, DF=0 Data
A router receiving a TTL>1 decrements the TTL and
20 bytes 8 bytes 1473 bytes forwards it
A TTL <= 1 shall not be forwarded
ICMP time exceeded is returned to the sender (later slide)

IPv4 hdr Recommended value is 64

IPv4 hdr UDP hdr id=n, DF=0 Data
Data
id=n, DF=0 MF=0, Should really be called Hop Limit (as in IPv6)
MF=1, off=0 off=185
Historically: Every router holding a datagram for more than 1 second
20 bytes 8 bytes 1472 bytes 20 bytes 1 byte
should decrement the TTL by the number of seconds.
Offset = 185 185x8 = 1480 bytes

lecture_2 lecture_2

The Protocol Field Header Checksum

Ensures integrity of header fields
Hop-by-hop (not end-to-end)
The header fields must be correct for proper and safe processing.
Demultiplexing to decimal keyword protocol The payload is not covered.
higher layers Internet Control Message Other checksums
1 ICMP
Assigned by IANA 4 IP IP in IP (encapsulation) Link-level CRC. IP assumes a strong L2 checksum/CRC. Hop-by-hop.
Internet Assigned 6 TCP Transmission Control L4 checksums, eg TCP/ICMP/UDP checksums cover payload. End-to-end.
Numbers Authority
17 UDP User Datagram Internet Checksum Algorithm, RFC 1071
A subset (out of 134) IPv6 in IPv4
41 IPv6 Treat header as sequence of 16-bit integers.
assigned
46 RSVP Reservation Protocol Add them together
Take the ones complement of the result.

lecture_2 lecture_2

Summary
Basic Routing
Connectionless, next-hop routing
Routing tables: RIBs and FIBs
Longest prefix match
Address resolution
ARP
RARP
IP Internet Protocol
Basic functionality
Header fields

lecture_2