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
Version
8
16
19
Length
HLen TOS
Ident
Flags
Offset
TTL
Protocol
Checksum
SourceAddr
DestinationAddr
Pad
Options (variable)
(variable)
Data
31
IP Packet Format

4-bit version


4-bit header length


Counted in words, minimum of 5
8-bit type of service field (TOS)


IPv4 = 4, IPv6 = 6
Mostly unused
16-bit data length

Counted in bytes
IP Packet Format

Fragmentation support

16-bit packet ID


3-bit flags


1-bit to mark last fragment
13-bit fragment offset into packet


All fragments from the same packet have the same ID
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





16-bit IP checksum on header
32-bit source IP address
32-bit destination IP address
Options




TCP = 6, UDP = 17
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
H1
R1
ETH
R2
FDDI
R3
PPP
H2
ETH
ETH IP (1400)
FDDI IP (1400)
PPP IP (512)
PPP IP (512)
PPP IP (376)
ETH IP (512)
ETH IP (512)
ETH IP (376)
Start of header
Ident = x
0
Rest of header
1400 data bytes
Start of header
Ident = x
1
Rest of header
512 data bytes
Offset 0
Offset 0
Start of header
Ident = x
1 Offset 512
Rest of header
512 data bytes
Start of header
Ident = x
0 Offset 1024
Rest of header
376 data bytes
Internet Control Message
Protocol (ICMP)

IP companion protocol

Handles error and control messages
FTP
HTTP
NV
TCP
UDP
IP
Ethernet
TFTP
FDDI
ICMP
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
segments to dest




First has TTL =1
Second has TTL=2, etc.
Unlikely port number
When nth datagram arrives
to nth router:



Router discards datagram
And sends to source an
ICMP message (type 11,
code 0)
Message includes name of
router& IP address
When ICMP message arrives,
source calculates RTT
 Traceroute does this 3 times
Stopping criterion
 UDP segment eventually
arrives at destination host
 Destination returns ICMP “host
unreachable” packet (type 3,
code 3)
 When source gets this ICMP,
stops.

NAT: Network Address Translation
rest of
Internet
local network
(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
network have same single source
NAT IP address: 138.76.29.7,
different source port numbers
Datagrams with source or
destination in this network
have 10.0.0/24 address for
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
2: NAT router
changes datagram
source addr from
10.0.0.1, 3345 to
138.76.29.7, 5001,
updates table
2
NAT translation table
WAN side addr
LAN side addr
1: host 10.0.0.1
sends datagram to
128.119.40.186, 80
138.76.29.7, 5001 10.0.0.1, 3345
……
……
S: 10.0.0.1, 3345
D: 128.119.40.186, 80
10.0.0.1
S: 138.76.29.7, 5001
D: 128.119.40.186, 80
138.76.29.7
S: 128.119.40.186, 80
D: 138.76.29.7, 5001
3: Reply arrives
dest. address:
138.76.29.7, 5001
3
1
10.0.0.4
S: 128.119.40.186, 80
D: 10.0.0.1, 3345
10.0.0.2
4
10.0.0.3
4: NAT router
changes datagram
dest addr from
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


Set of contiguous 0’s can be elided


5CFA:0002::CF07:1234:5678:FFCD
Address assignment


3
010
5CFA:0002:0000:0000:CF07:1234:5678:FFCD
Provider-based
geographic
m
Region ID
n
Provider ID
o
Subscriber ID
p
Subnet
125-m-n-o-p
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
version
hdr len
16
TOS
length
ident
TTL
31
flags
protocol
offset
checksum
source address
destination address
options (variable)
pad (variable)
IPv6 Packet Format
0
version
8
priority
16
31
flow label
payload length
next header
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)
hop limit
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
version
8
priority
16
31
flow label
payload length
next header
source address 4 words
destination address 4 words
options (variable number, usually fixed length)
hop limit
IPv6 Packet Format

Version


Priority and Flow Label



Header not included
Next Header




Support service guarantees
Allow “fair” bandwidth allocation
Payload Length


6
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


Routing


Sender identification
Encrypted security payload


IP fragmentation info
Authentication


Full/partial route to follow
Fragmentation


Miscellaneous information for routers
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
length
next header
type
value
Jumbogram option (packet longer than 65,535
bytes)
Payload length in main header set to 0
0
8
next header
16
0
31
194
Payload length in bytes
0
IPv6 Extension Headers
0
8
next header
16
0
31
# of addresses
next address
strict/loose routing bitmap
1 – 24 addresses

Routing extension




Up to 24 “anycast” addresses target AS’s/providers
Next address tracks current target
Strict routing requires direct link
Loose routing allows intermediate nodes
IPv6 Extension Headers
0
8
next header
16
reserved
31
offset
reserved
ident

Fragmentation extension

Similar to IPv4 fragmentation



13-bit offset
Last fragment mark (M)
Larger fragment identification field
M
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



16 byte



More overhead
Good for foreseeable future
20 byte



Might run out in a few decades
Less header overhead
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


Application layer




A standard service
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
Logical view:
E
F
IPv6
IPv6
IPv6
A
B
E
F
IPv6
IPv6
IPv6
IPv6
A
B
IPv6
Physical view:
tunnel
IPv4
IPv4
Tunneling
Logical view:
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
Physical view:
Flow: X
Src: A
Dest: F
data
A-to-B:
IPv6
E
F
IPv6
IPv6
D
E
F
IPv4
IPv6
IPv6
tunnel
Src:B
Dest: E
Src:B
Dest: E
Flow: X
Src: A
Dest: F
Flow: X
Src: A
Dest: F
data
data
B-to-C:
IPv6 inside
IPv4
B-to-C:
IPv6 inside
IPv4
Flow: X
Src: A
Dest: F
data
E-to-F:
IPv6
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
IP keeps
header IP
remainder
of link-layer frame
header still
 but IPMPLS
datagram
address!
header

label
20
Exp S TTL
3
1
5
MPLS capable routers


a.k.a. label-switched router
forwards packets to outgoing interface based
only on label value (don’t inspect IP address)


signaling protocol needed to set up forwarding




MPLS forwarding table distinct from IP forwarding
tables
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
label
out
label dest
10
12
8
out
interface
A
D
A
0
0
1
in
label
out
label dest
out
interface
10
6
A
1
12
9
D
0
R6
0
0
D
1
1
R3
R4
R5
0
0
R2
in
label
8
out
label dest
6
A
out
interface
0
in
label
6
outR1
label dest
-
A
A
out
interface
0