More IP

Fragmentation, NAT, IPv6,

MPLS
Readings

IP format, fragmentation - 4.1.2

ICMP - 4.1.7
NAT - side bar, pp. 327-329
IPv6 - 4.3.5
MPLS - 4.5
IP Packet Format
0 4 8 16 19 31
Version HLen TOS Length
Ident Flags Offset
TTL Protocol Checksum
SourceAddr
DestinationAddr
Options (variable) Pad
(variable)
Data
IP Packet Format

4-bit version
IPv4 = 4, IPv6 = 6
4-bit header length
Counted in words, minimum of 5
8-bit type of service field (TOS)
Mostly unused
16-bit data length
Counted in bytes
IP Packet Format
Fragmentation support
16-bit packet ID
All fragments from the same packet have the same ID
3-bit flags
1-bit to mark last fragment
13-bit fragment offset into packet
Counted in 8-byte words
8-bit time-to-live field (TTL)
Hop count decremented at each router
Packet is discard if TTL = 0
IP Packet Format
8-bit protocol field
TCP = 6, UDP = 17
16-bit IP checksum on header
32-bit source IP address
32-bit destination IP address
Options
Variable size
Source-based routing
Record route
Padding
Fill to 32-bit boundaries
IP Packet Size

Problem
Different physical layers provide different
limits on frame length
Maximum transmission unit (MTU)
Source host does not know minimum
value
Especially along dynamic routes
MTUs

Ethernet - 1500 bytes

FDDI - 4500 bytes
802.11 - 2304 bytes
PPP - 512 bytes
IP Fragmentation and
Reassembly

Solution
When necessary, split IP packet into
acceptably sized packets prior to sending
over physical link
Questions
Where should reassembly occur?
What happens when a fragment is
damaged/lost?
IP Fragmentation and
Reassembly
Fragments are self-contained IP datagrams
Reassemble at destination to minimize
refragmentation
Drop all fragments in packet if one or more
fragments are lost
Avoid fragmentation at source host
Transport layer should send packets small
enough to fit into one MTU of local physical
network
Must consider IP header
Note: MTU in ATM is based on CS-PDU size
 IP Fragmentation and
Reassembly

Start of header
Ident = x 0 Offset 0
H1 R1 R2 R3 H2 Rest of header
1400 data bytes

ETH FDDI PPP ETH

Start of header
ETH IP (1400) Ident = x 1 Offset 0
Rest of header
FDDI IP (1400) 512 data bytes
PPP IP (512) Start of header
PPP IP (512) Ident = x 1 Offset 512
Rest of header
PPP IP (376) 512 data bytes

ETH IP (512) Start of header

Ident = x 0 Offset 1024
ETH IP (512) Rest of header
ETH IP (376) 376 data bytes
Internet Control Message
Protocol (ICMP)

IP companion protocol
Handles error and control messages

FTP HTTP NV TFTP

TCP UDP

IP ICMP

Ethernet FDDI ATM Modem

ICMP
Error Messages
Host unreachable
Reassembly failed
IP checksum failed
TTL exceeded (packet dropped)
Invalid header
Control Messages
Echo/ping request and reply
Echo/ping request and reply with timestamps
Route redirect
Traceroute and ICMP
Source sends series of UDP When ICMP message arrives,
segments to dest source calculates RTT
First has TTL =1 Traceroute does this 3 times
Second has TTL=2, etc. Stopping criterion
Unlikely port number UDP segment eventually
When nth datagram arrives arrives at destination host
to nth router: Destination returns ICMP host
Router discards datagram unreachable packet (type 3,
And sends to source an code 3)
ICMP message (type 11, When source gets this ICMP,
code 0)
stops.
Message includes name of
router& IP address
 NAT: Network Address Translation
rest of local network
Internet (e.g., home network)
10.0.0/24 10.0.0.1

10.0.0.4
10.0.0.2
138.76.29.7

10.0.0.3

All datagrams leaving local Datagrams with source or

network have same single source destination in this network
NAT IP address: 138.76.29.7, have 10.0.0/24 address for
different source port numbers source, destination (as usual)
 NAT: Network Address Translation
Motivation: local network uses just one IP address as far as outside
world is concerned:
range of addresses not needed from ISP: just one IP address for
all devices
can change addresses of devices in local network without notifying
outside world
can change ISP without changing addresses of devices in local
network
devices inside local net not explicitly addressable, visible by
outside world (a security plus).
 NAT: Network Address Translation
Implementation: NAT router must:
outgoing datagrams: replace (source IP address, port #)
of every outgoing datagram to (NAT IP address, new
port #)
. . . remote clients/servers will respond using (NAT IP
address, new port #) as destination addr.
remember (in NAT translation table) every (source IP
address, port #) to (NAT IP address, new port #)
translation pair
incoming datagrams: replace (NAT IP address, new port
#) in dest fields of every incoming datagram with
corresponding (source IP address, port #) stored in NAT
table
 NAT: Network Address Translation
NAT translation table
2: NAT router 1: host 10.0.0.1
WAN side addr LAN side addr
changes datagram sends datagram to
138.76.29.7, 5001 10.0.0.1, 3345 128.119.40.186, 80
source addr from

10.0.0.1, 3345 to
138.76.29.7, 5001, S: 10.0.0.1, 3345
updates table D: 128.119.40.186, 80
10.0.0.1
1
S: 138.76.29.7, 5001
2 D: 128.119.40.186, 80 10.0.0.4
10.0.0.2
138.76.29.7 S: 128.119.40.186, 80
D: 10.0.0.1, 3345 4
S: 128.119.40.186, 80
D: 138.76.29.7, 5001 3 10.0.0.3
4: NAT router
3: Reply arrives changes datagram
dest. address: dest addr from
138.76.29.7, 5001 138.76.29.7, 5001 to 10.0.0.1, 3345
NAT: Network Address Translation

16-bit port-number field:

60K simultaneous connections with a single LAN-side
address!
NAT is controversial:
routers should only process up to layer 3
violates end-to-end argument
NAT possibility must be taken into account by app designers,
eg, P2P applications
address shortage should instead be solved by IPv6
IPv6

History
Next generation IP (AKA IPng)
Intended to extend address space and routing
limitations of IPv4
Requires header change
Attempted to include everything new in one change
IETF moderated
Based on Simple Internet Protocol Plus (SIPP)
IPv6
Wish list
128-bit addresses
Multicast traffic
Mobility
Real-time traffic/quality of service guarantees
Authentication and security
Autoconfiguration for local IP addresses
End-to-end fragmentation
Protocol extensions
Smooth transition!
Note
Many of these functionalities have been retrofit into IPv4
IPv6 Addresses
128-bit
3.4 x 1038 addresses (as compared to 4 x 109)
Classless addressing/routing (similar to CIDR)
Address notation
String of eight 16-bit hex values separated by colons
5CFA:0002:0000:0000:CF07:1234:5678:FFCD
Set of contiguous 0s can be elided
5CFA:0002::CF07:1234:5678:FFCD
Address assignment
Provider-based
geographic

3 m n o p 125-m-n-o-p
010 Region ID Provider ID Subscriber ID Subnet Host
IPv6
Prefix Address type
0000 0000 Reserved (includes transition addresses)
0000 0001 ISO NSAP (Network Service Point) Allocation
0000 010 Novell IPX allocation
010 Provider-based unicast
100 Geographic multicast
1111 1110 10 Link local address
1111 1110 11 Site local address
1111 1111 Multicast address
Other unassigned
IPv4 Packet Format
20 Byte minimum
Mandatory fields are not always used
e.g. fragmentation
Options are an unordered list of (name, value) pairs
0 8 16 31
version hdr len TOS length
ident flags offset
TTL protocol checksum
source address
destination address
options (variable) pad (variable)
IPv6 Packet Format

0 8 16 31
version priority flow label
payload length next header hop limit
source address word 1
source address word 2
source address word 3
source address word 4
destination address word 1
destination address word 2
destination address word 3
destination address word 4
options (variable number, usually fixed length)
IPv6 Packet Format
40 Byte minimum
Mandatory fields (almost) always used
Strict order on options reduces processing time
No need to parse irrelevant options

0 8 16 31
version priority flow label
payload length next header hop limit
source address 4 words
destination address 4 words
options (variable number, usually fixed length)
IPv6 Packet Format
Version
6
Priority and Flow Label
Support service guarantees
Allow fair bandwidth allocation
Payload Length
Header not included
Next Header
Combines options and protocol
Linked list of options
Ends with higher-level protocol header (e.g. TCP)
Hop Limit
TTL renamed to match usage
IPv6 Extension Headers
Must appear in order
Hop-by-hop options
Miscellaneous information for routers
Routing
Full/partial route to follow
Fragmentation
IP fragmentation info
Authentication
Sender identification
Encrypted security payload
Information about contents
Destination options
Information for destination
IPv6 Extension Headers

Hop-by-Hop extension
Length is in bytes beyond mandatory 8
0 8 16 31
next header length type
value

Jumbogram option (packet longer than 65,535

bytes)
Payload length in main header set to 0
0 8 16 31
next header 0 194 0
Payload length in bytes
IPv6 Extension Headers

0 8 16 31
next header 0 # of addresses next address
strict/loose routing bitmap

1 24 addresses

Routing extension
Up to 24 anycast addresses target ASs/providers
Next address tracks current target
Strict routing requires direct link
Loose routing allows intermediate nodes
IPv6 Extension Headers

0 8 16 31
next header reserved offset reserved M
ident

Fragmentation extension
Similar to IPv4 fragmentation
13-bit offset
Last fragment mark (M)
Larger fragment identification field
IPv6 Extension Headers
Authentication extension
Designed to be very flexible
Includes
Security parameters index (SPI)
Authentication data
Encryption Extension
Called encapsulating security payload (ESP)
Includes an SPI
All headers and data after ESP are encrypted
IPv6 Design Controversies
Address length
8 byte
Might run out in a few decades
Less header overhead
16 byte
More overhead
Good for foreseeable future
20 byte
Even more overhead
Compatible with OSI
Variable length
IPv6 Design Controversies
Hop limit
65,535
32 hop paths are common now
In a decade, we may see much longer paths
255
Objective is to limit lost packet lifetime
Good network design makes long paths unlikely
Source to backbone
Across backbone
Backbone to destination
IPv6 Design Controversies
Greater than 64KB data
Good for supercomputer/high bandwidth
applications
Too much overhead to fragment large data
packets
64 KB data
More compatible with low-bandwidth lines
1 MB packet ties up a 1.5MBps line for more
than 5 seconds
Inconveniences interactive users
IPv6 Design Controversies

Keep checksum
Removing checksum from IP is
analogous to removing brakes from a car
Light and faster
Unprepared for the unexpected
Remove checksum
Typically duplicated in data link and
transport layers
Very expensive in IPv4
IPv6 Design Controversies
Mobile hosts
Direct or indirect connectivity
Reconnect directly using canonical address
Use home and foreign agents to forward traffic
Mobility introduces asymmetry
Base station signal is strong, heard by mobile units
Mobile unit signal is weak and susceptible to interference,
may not be heard by base station
IPv6 Design Controversies
Security
Where?
Network layer
A standard service
Application layer
No viable standard
Application susceptible to errors in network
implementation
Expensive to turn on and off
How?
Political import/export issues
Cryptographic strength issues
 Transition From IPv4 To IPv6
Not all routers can be upgraded
simultaneous
no flag days
How will the network operate with mixed IPv4
and IPv6 routers?
Tunneling: IPv6 carried as payload in IPv4
datagram among IPv4 routers
 Tunneling

A B tunnel E F
Logical view:
IPv6 IPv6 IPv6 IPv6

A B E F
Physical view:
IPv6 IPv6 IPv4 IPv4 IPv6 IPv6
 Tunneling
A B tunnel E F
Logical view:
IPv6 IPv6 IPv6 IPv6

A B C D E F
Physical view:
IPv6 IPv6 IPv4 IPv4 IPv6 IPv6

Flow: X Src:B Src:B Flow: X

Src: A Dest: E Dest: E Src: A
Dest: F Dest: F
Flow: X Flow: X
Src: A Src: A
data Dest: F Dest: F data

data data

A-to-B: E-to-F:
B-to-C: B-to-C:
IPv6 IPv6
IPv6 inside IPv6 inside
IPv4 IPv4
 Multiprotocol label switching (MPLS)

initial goal: speed up IP forwarding by using

fixed length label (instead of IP address) to
do forwarding
borrowing ideas from Virtual Circuit (VC)
approach
PPP or Ethernet
but IPMPLS
datagram
header still
IP keeps
header IP address!
remainder of link-layer frame
header

label Exp S TTL

20 3 1 5
 MPLS capable routers
a.k.a. label-switched router
forwards packets to outgoing interface based
only on label value (dont inspect IP address)
MPLS forwarding table distinct from IP forwarding
tables
signaling protocol needed to set up forwarding
RSVP-TE
forwarding possible along paths that IP alone would
not allow (e.g., source-specific routing) !!
use MPLS for traffic engineering
must co-exist with IP-only routers
MPLS forwarding tables
in out out
label label dest interface
10 A 0 in out out
12 D 0 label label dest interface

8 A 1 10 6 A 1
12 9 D 0

R6
0 0
D
1 1
R4 R3
R5
0 0
A
R2 in outR1 out
label label dest interface
in out out
label label dest interface 6 - A 0
8 6 A 0