Transcript network

Internet Protocol
ECS 152B
Ref: slides by J. Kurose and K. Ross
Encapsulation
User
process
Overview
HTTP
User
process
TCP
SNMP
UDP
application
message
transport
segment
ICMP
IP
IGMP
ARP
Hardware
interface
RARP
network
datagram
link
frame
Demultiplexing
Network layer functions
• transport packet
from sending to
receiving hosts
• network layer
protocols in every
host, router
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Functions
• path determination: route taken by packets
from source to dest. Routing algorithms
• forwarding: move packets from router’s
input to appropriate router output
• call setup: some network architectures
require router call setup along path before
data flows (not Internet)
Network service model
Q: What service model for
transporting packets from
sender to receiver?
• guaranteed bandwidth?
• preservation of inter-packet
timing (no jitter)?
• loss-free delivery?
• in-order delivery?
• congestion feedback to
sender?
The most important
abstraction provided
by network layer:
? ?
?
virtual circuit
or
datagram?
Virtual circuits
“source-to-dest path behaves much like
telephone circuit”
• call setup, teardown for each call before data can flow
• each packet carries VC identifier (not destination host
ID)
• every router on source-dest path maintains “state” for
each passing connection
• link, router resources (bandwidth, buffers) may be
allocated to VC
– to get circuit-like perf.
Virtual circuits: signaling protocols
• used to setup, maintain teardown VC
• used in ATM, frame-relay, X.25
• not used in today’s Internet
application
transport 5. Data flow begins
network 4. Call connected
data link 1. Initiate call
physical
6. Receive data application
3. Accept call
2. incoming call
transport
network
data link
physical
Datagram networks: the Internet model
• no call setup at network layer
• routers: no state about end-to-end
connections
– no network-level concept of “connection”
• packets forwarded using destination host
address
application
– packets between same source-dest pair mayapplication
take
transport
different paths
transport
network
network
data link 1. Send data
2. Receive data
data link
physical
physical
Network layer service models:
Network
Architecture
Internet
Service
Model
Guarantees ?
Congestion
Bandwidth Loss Order Timing feedback
best effort none
ATM
CBR
ATM
VBR
ATM
ABR
ATM
UBR
constant
rate
guaranteed
rate
guaranteed
minimum
none
no
no
no
yes
yes
yes
yes
yes
yes
no
yes
no
no (inferred
via loss)
no
congestion
no
congestion
yes
no
yes
no
no
• Internet model being extended: Intserv, Diffserv
VC vs. Datagram
• VC
– Guaranteed service
– Complexity
• Datagram
– Simple
– Best effort
Datagram or VC network: why?
Internet
ATM
• data exchange among
• evolved from telephony
computers
• human conversation:
– “elastic” service, no strict
– strict timing, reliability
timing req.
requirements
• “smart” end systems
(computers)
– need for guaranteed
– can adapt, perform control,
service
error recovery
• “dumb” end systems
– simple inside network,
– telephones
complexity at “edge”
– complexity inside
• many link types
network
– different characteristics
– uniform service difficult
• application at the end system,
easy to define new services
Internet Protocol
• Functionality:
– Determine how to route packets from source to
destination
– Hide the details of the physical network
– Unreliable, connectionless, datagram delivery
• To be studied:
–
–
–
–
Addressing
Routing
ARP
ICMP and IGMP
Encapsulation
source
destination
original message
Application
Application
Transport
Transport
Network
Network
Link
Link
IP header
IP protocol version
number
header length
(bytes)
“type” of data
max number
remaining hops
(decremented at
each router)
upper layer protocol
to deliver payload to
20 bytes overhead
32 bits
head. type of
length
ver
len service
fragment
16-bit identifier flgs
offset
upper
time to
Internet
layer
live
checksum
total datagram
length (bytes)
for
fragmentation/
reassembly
32 bit source IP address
32 bit destination IP address
Options (if any)
data
(variable length,
typically a TCP
or UDP segment)
E.g. timestamp,
record route
taken, specify
list of routers
to visit.
IP Header
•
•
•
•
•
•
•
Version: 4
Header length: 4 bits, max 15x4=60 bytes
TOS: 0 for normal service,
Total length: 16 bits, max 65535 bytes
TTL: 32/64, decrease by one in each hop
Protocol field: TCP,UCP,ICMP,IGMP,etc.
Checksum: header only
IP Address
Class-based address:
class
7 bits
A
0 network
B
C
D
1.0.0.0 to
127.255.255.255
host
14 bits
10
network
128.0.0.0 to
191.255.255.255
host
21 bits
110
network
host
28 bits
1110
multicast address
32 bits
192.0.0.0 to
223.255.255.255
224.0.0.0 to
239.255.255.255
IP addressing: CIDR
• Classful addressing:
– inefficient use of address space, address space
exhaustion
– e.g., class B net allocated enough addresses for 65K
hosts, even if only 2K hosts in that network
• CIDR: Classless InterDomain Routing
– network portion of address of arbitrary length
– address format: a.b.c.d/x, where x is # bits in
network portion of address
host
network
part
part
11001000 00010111 00010000 00000000
200.23.16.0/23
IP Address
Class-based address:
class
7 bits
A
0 network
B
C
D
1.0.0.0 to
127.255.255.255
host
14 bits
10
network
128.0.0.0 to
191.255.255.255
host
21 bits
110
network
host
28 bits
1110
multicast address
32 bits
192.0.0.0 to
223.255.255.255
224.0.0.0 to
239.255.255.255
IP addressing: CIDR
• Classful addressing:
– inefficient use of address space, address space
exhaustion
– e.g., class B net allocated enough addresses for 65K
hosts, even if only 500 hosts in that network
• CIDR: Classless InterDomain Routing
– network portion of address of arbitrary length
– address format: a.b.c.d/x, where x is # bits in
network portion of address
host
network
part
part
11001000 00010111 00010000 00000000
200.23.16.0/23
CIDR
• Network address: 200.23.16.0/23
– /23 : network mask
• More efficient use of address
– Consider a network with 500 hosts
– Classful address: a class B address, wasting over 64K
addresses
– CIDR: a network with /23
– One class B address can be used for 128 such networks using
CIDR
• Routing difficulty
– Classful: only need the IP address to determine the network add
– CIDR: also need network mask information to determine the
network address
– Longest match first
IP addresses: how to get one?
Q: How does host get IP address?
• hard-coded by system admin in a file
– Wintel: control-panel->network>configuration->tcp/ip->properties
– UNIX: /etc/rc.config
• DHCP: Dynamic Host Configuration Protocol:
dynamically get address from as server
– “plug-and-play” : host automatically obtain
an IP and related info
– mobile computing
IP addresses: how to get one?
Q: How does network get network part of IP
addr?
A: gets allocated portion of its provider
ISP’s address space (a good example for
CIDR)
ISP's block
11001000 00010111 00010000 00000000
200.23.16.0/20
Organization 0
Organization 1
Organization 2
...
11001000 00010111 00010000 00000000
11001000 00010111 00010010 00000000
11001000 00010111 00010100 00000000
…..
….
200.23.16.0/23
200.23.18.0/23
200.23.20.0/23
….
Organization 7
11001000 00010111 00011110 00000000
200.23.30.0/23
IP routing
• IP address: 32-bit
identifier for host,
router interface
• interface: connection
between host/router
and physical link
223.1.1.1
223.1.2.1
223.1.1.2
223.1.1.4
223.1.1.3
223.1.2.9
223.1.3.27
223.1.2.2
– router’s typically have
223.1.3.2
223.1.3.1
multiple interfaces
– host may have multiple
interfaces
– IP addresses associated
223.1.1.1 = 11011111 00000001 00000001 00000001
with each interface
223
1
Network address: 223.1.1.0/24
1
1
IP Routing
• IP address:
– network part (high
order bits) is used
for routing
– host part (low order
bits) not used for
routing
223.1.1.1
223.1.2.1
223.1.1.2
223.1.1.4
223.1.1.3
223.1.2.9
223.1.3.27
223.1.2.2
LAN
223.1.3.1
223.1.3.2
network consisting of 3 IP networks
(for IP addresses starting with 223,
first 24 bits are network address)
Getting a datagram from source to
dest.
forwarding table in A
Dest. Net. next router Nhops
223.1.1
223.1.2
223.1.3
Others
IP datagram:
misc source dest
fields IP addr IP addr
data
• datagram remains
unchanged, as it
travels source to
destination
• addr fields of interest
here
• Default router for all
other networks
A
223.1.1.4
223.1.1.4
223.1.1.4
1
2
2
x
223.1.1.1
223.1.2.1
B
223.1.1.2
223.1.1.4
223.1.2.9
223.1.2.2
223.1.1.3
223.1.3.1
223.1.3.27
223.1.3.2
E
Getting a datagram from source to
dest.
forwarding table in A
misc
data
fields 223.1.1.1 223.1.1.3
Starting at A, send IP
datagram addressed to
B:
• look up net. address of B in
forwarding table
• find B is on same net. as A
• link layer will send
datagram directly to B
inside link-layer frame
– B and A are directly
connected
Dest. Net. next router Nhops
223.1.1
223.1.2
223.1.3
A
223.1.1.4
223.1.1.4
1
2
2
223.1.1.1
223.1.2.1
B
223.1.1.2
223.1.1.4
223.1.2.9
223.1.2.2
223.1.1.3
223.1.3.1
223.1.3.27
223.1.3.2
E
Getting a datagram from source to
dest. forwarding table in A
misc
data
fields 223.1.1.1 223.1.2.3
Dest. Net. next router Nhops
223.1.1
223.1.2
223.1.3
Starting at A, dest. E:
• look up network address of E in
forwarding table
• E on different network
– A, E not directly attached
• routing table: next hop router to
E is 223.1.1.4
• link layer sends datagram to
router 223.1.1.4 inside linklayer frame
• datagram arrives at 223.1.1.4
• continued…..
A
223.1.1.4
223.1.1.4
1
2
2
223.1.1.1
223.1.2.1
B
223.1.1.2
223.1.1.4
223.1.2.9
223.1.2.2
223.1.1.3
223.1.3.1
223.1.3.27
223.1.3.2
E
Getting a datagram from source to
dest.
misc
data
fields 223.1.1.1 223.1.2.3
Arriving at 223.1.4, destined for
223.1.2.2
• look up network address of E in
router’s forwarding table
• E on same network as router’s
interface 223.1.2.9
– router, E directly attached
• link layer sends datagram to
223.1.2.2 inside link-layer frame
via interface 223.1.2.9
• datagram arrives at 223.1.2.2!!!
(hooray!)
forwarding table in router
Dest. Net router Nhops interface
223.1.1
223.1.2
223.1.3
A
-
1
1
1
223.1.1.4
223.1.2.9
223.1.3.27
223.1.1.1
223.1.2.1
B
223.1.1.2
223.1.1.4
223.1.2.9
223.1.2.2
223.1.1.3
223.1.3.1
223.1.3.27
223.1.3.2
E
CIDR Routing
network
part
host
part
11001000 00010111 00010000 00000000
200.23.16.0/23
network
part
host
part
11001000 00010111 00000000 00000000
200.23.0.0/17
CIDR routing: longest match first
IP Fragmentation & Reassembly
• network links have MTU
(max.transfer size) - largest
possible link-level frame.
– different link types,
different MTUs
• large IP datagram divided
(“fragmented”) within net
– one datagram becomes
several datagrams
– “reassembled” only at
final destination
– IP header bits used to
identify, order related
fragments
fragmentation:
in: one large datagram
out: 3 smaller datagrams
reassembly
IP Fragmentation and Reassembly
Example
• 4000 byte
datagram
• MTU = 1500
bytes
length ID fragflag offset
=4000 =x
=0
=0
One large datagram becomes
several smaller datagrams
length ID fragflag offset
=1500 =x
=1
=0
length ID fragflag
=1500 =x
=1
offset
=1480/8
length ID fragflag
=1040 =x
=0
offset
=2960/8
LAN Addresses and ARP
32-bit IP address:
• network-layer address
• used to get datagram to destination IP network (recall IP
network definition)
LAN (or MAC or physical or Ethernet) address:
• used to get datagram from one interface to another
physically-connected interface (same network)
• 48 bit MAC address (for most LANs)
burned in the adapter ROM
LAN Addresses and ARP
Each adapter on LAN has unique LAN address
LAN Address (more)
• MAC address allocation administered by IEEE
• manufacturer buys portion of MAC address space (to
assure uniqueness)
• Analogy:
(a) MAC address: like Social Security Number
(b) IP address: like postal address
• MAC flat address => portability
– can move LAN card from one LAN to another
• IP hierarchical address NOT portable
– depends on IP network to which node is attached
Recall earlier routing discussion
Starting at A, given IP
datagram addressed to B:
A
• look up net. address of B, find B
on same net. as A
• link layer send datagram to B
inside link-layer frame
frame source,
dest address
B’s MAC A’s MAC
addr
addr
223.1.1.1
223.1.2.1
223.1.1.2
223.1.1.4 223.1.2.9
B
223.1.1.3
datagram source,
dest address
A’s IP
addr
B’s IP
addr
datagram
frame
223.1.3.27
223.1.3.1
IP payload
223.1.2.2
223.1.3.2
E
ARP: Address Resolution Protocol
Question: how to determine
MAC address of B
knowing B’s IP address?
• Each IP node (Host,
Router) on LAN has
ARP table
• ARP Table: IP/MAC
address mappings for
some LAN nodes
< IP address; MAC address;
TTL>
–
TTL (Time To Live):
time after which
address mapping will
be forgotten (typically
20 min)
ARP protocol
• A wants to send datagram to
B, and A knows B’s IP address.
• Suppose B’s MAC address is
not in A’s ARP table.
• A broadcasts ARP query
packet, containing B's IP
address
– all machines on LAN
receive ARP query
• B receives ARP packet, replies
to A with its (B's) MAC address
– frame sent to A’s MAC
address (unicast)
• A caches (saves) IP-to-MAC
address pair in its ARP table
until information becomes old
(times out)
– soft state: information that
times out (goes away)
unless refreshed
• ARP is “plug-and-play”:
– nodes create their ARP
tables without intervention
from net administrator
Routing to another LAN
walkthrough: send datagram from A to B via R
assume A know’s B IP address
A
R
• Two ARP tables in router R, one for each IP
network (LAN)
B
• A creates datagram with source A, destination B
• A uses ARP to get R’s MAC address for 111.111.111.110
• A creates link-layer frame with R's MAC address as dest, frame
contains A-to-B IP datagram
• A’s data link layer sends frame
• R’s data link layer receives frame
• R removes IP datagram from Ethernet frame, sees its destined
to B
• R uses ARP to get B’s physical layer address
• R creates frame containing A-to-B IP datagram sends to B
A
R
B
ICMP: Internet Control Message
Protocol
• used by hosts, routers, gateways to communication
network-level information
• network-layer “above” IP:
– ICMP msgs carried in IP datagrams
• Two types:
– error reporting
•
•
•
•
unreachable host, network, port, protocol,
fragment needed but DF bit set
Time exceeded (TTL)
etc.
– Query/response
• Echo request/reply
• Timestamp request/reply
• Address mask request/reply
ICMP
Type
0
3
3
3
3
3
3
4
Code
0
0
1
2
3
6
7
0
8
9
10
11
12
0
0
0
0
0
description
echo reply (ping)
dest. network unreachable
dest host unreachable
dest protocol unreachable
dest port unreachable
dest network unknown
dest host unknown
source quench (congestion
control - not used)
echo request (ping)
route advertisement
router discovery
TTL expired
bad IP header
Query
x
Error
x
x
x
x
x
x
x
x
x
x
x
x
ICMP
IP datagram
IP header
8-bit type 8-bit code
ICMP message
16-bit checksum
Contents depends on type and code
Error message
• ICMP error message:
– ICMP header:
• type, code, checksum,
– ICMP message
• IP header plus first 8 bytes of IP datagram causing error
• To prevent broadcast storm: NOT generate ICMP in
response to
–
–
–
–
–
ICMP error message
Dest=IP broadcast address
Link layer broadcast
A fragment other than the first
Source address not defined as a single host
Ping
• Basic connectivity test
• uses ICMP eco request/reply messages
instead of UDP/TCP.
• Client/server paradigm
• Usually implemented in the kernel.
• “man ping”
Format
code(0)
type (0)
identifier
16-bit checksum
sequence no.
Optional data
Ping
bread% ping -s shannon.cs.ucdavis.edu
PING shannon.cs.ucdavis.edu: 56 data bytes
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=0. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=1. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=2. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=3. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=4. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=5. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=6. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=7. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=8. time=0. ms
64 bytes from shannon.cs.ucdavis.edu (169.237.6.199): icmp_seq=9. time=0. ms
…
----shannon.cs.ucdavis.edu PING Statistics---30 packets transmitted, 30 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
Ping
bread% ping -s mark.ecn.purdue.edu
PING mark.ecn.purdue.edu: 56 data bytes
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=0. time=66. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=1. time=64. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=3. time=64. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=4. time=65. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=5. time=64. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=8. time=65. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=10. time=65. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=11. time=65. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=12. time=65. ms
64 bytes from mark.ecn.purdue.edu (128.46.209.167): icmp_seq=15. time=64. ms
^C
----mark.ecn.purdue.edu PING Statistics---18 packets transmitted, 10 packets received, 44% packet loss
round-trip (ms) min/avg/max = 64/65/66
Traceroute
• By Van Jacobson
• See route that IP datagram follow
• Use ICMP and TTL
– A router gets an IP datagram with TTL 0/1, discards
the packet and sends back an ICMP to the source
“time exceeded”.
– Source sends UDP fragment with 1,2,3, TTL values
– IP packet contains an UDP with unused post #. dest.
Replies “port unreachable” ICMP message.
Traceroute
bread% traceroute ector.cs.purdue.edu
traceroute: Warning: Multiple interfaces found; using 169.237.6.16 @ qfe0
traceroute to ector.cs.purdue.edu (128.10.2.10), 30 hops max, 40 byte packets
1 169.237.5.254 (169.237.5.254) 0.594 ms 0.337 ms 0.298 ms
2 169.237.246.238 (169.237.246.238) 0.533 ms 0.479 ms 0.474 ms
3 128.120.2.49 (128.120.2.49) 0.547 ms 0.475 ms 0.475 ms
4 core0.ucdavis.edu (128.120.0.30) 0.616 ms 0.671 ms 0.642 ms
5 area0-area14p.ucdavis.edu (128.120.0.222) 0.570 ms 0.468 ms 0.821 ms
6 area14p-border20.ucdavis.edu (128.120.0.250) 1.149 ms 0.691 ms 3.132 ms
7 dc-oak-dc2--ucd-ge.cenic.net (137.164.24.225) 4.751 ms 2.434 ms 4.521 ms
8 dc-oak-dc1--oak-dc2-ge.cenic.net (137.164.22.36) 2.394 ms 4.217 ms 2.452 ms
9 dc-svl-dc1--oak-dc1-10ge.cenic.net (137.164.22.30) 201.245 ms 5.091 ms 183.393 ms
10 dc-sol-dc1--svl-dc1-pos.cenic.net (137.164.22.28) 13.421 ms 11.258 ms 11.155 ms
11 hpr-lax-hrp1--dc-lax-dc1-ge.cenic.net (137.164.22.13) 11.571 ms 14.390 ms 11.809 ms
12 abilene-LA--hpr-lax-gsr1-10ge.cenic.net (137.164.25.3) 13.431 ms 11.417 ms 11.289 ms
13 snvang-losang.abilene.ucaid.edu (198.32.8.95) 19.141 ms 20.516 ms 19.117 ms
14 kscyng-snvang.abilene.ucaid.edu (198.32.8.103) 54.300 ms 53.943 ms 53.998 ms
15 iplsng-kscyng.abilene.ucaid.edu (198.32.8.80) 64.783 ms 68.220 ms 63.659 ms
16 ul-abilene.indiana.gigapop.net (192.12.206.250) 63.567 ms 63.381 ms 63.025 ms
17 tel-210-m10-01-gp.tcom.purdue.edu (192.5.40.9) 65.017 ms * 64.982 ms
18 cs-2u01-c3550-01-242.tcom.purdue.edu (128.210.242.51) 65.527 ms 65.282 ms 65.083 ms
19 * ector.cs.purdue.edu (128.10.2.10) 65.528 ms *
DHCP: Dynamic Host Configuration
Protocol
Goal: allow host to dynamically obtain its IP address from
network server when it joins network
Can renew its lease on address in use
Allows reuse of addresses (only hold address while connected an
“on”
Support for mobile users who want to join network (more shortly)
DHCP overview:
– host broadcasts “DHCP discover” msg
– DHCP server responds with “DHCP offer” msg
– host requests IP address: “DHCP request” msg
– DHCP server sends address: “DHCP ack” msg
DHCP client-server scenario
A
B
223.1.2.1
DHCP
server
223.1.1.1
223.1.1.2
223.1.1.4
223.1.2.9
223.1.2.2
223.1.1.3
223.1.3.1
223.1.3.27
223.1.3.2
E
arriving DHCP
client needs
address in this
network
DHCP client-server scenario
DHCP server: 223.1.2.5
DHCP discover
src : 0.0.0.0, 68
dest.: 255.255.255.255,67
yiaddr: 0.0.0.0
transaction ID: 654
DHCP offer
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 654
Lifetime: 3600 secs
DHCP request
time
src: 0.0.0.0, 68
dest:: 255.255.255.255, 67
yiaddrr: 223.1.2.4
transaction ID: 655
Lifetime: 3600 secs
DHCP ACK
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 655
Lifetime: 3600 secs
arriving
client
NAT: Network Address Translation
rest of
Internet
local network
(e.g., home network)
10.0.0/24
10.0.0.4
10.0.0.1
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 word is concerned:
– no need to be allocated range of addresses from ISP: just one IP address is used 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, 80
138.76.29.7, 5001 10.0.0.1, 3345
……
……
S: 10.0.0.1, 3345
D: 128.119.40.186, 80
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.1
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:
– 60,000 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
• Initial motivation: 32-bit address space
completely allocated by 2008.
• Additional motivation:
– header format helps speed processing/forwarding
– header changes to facilitate QoS
– new “anycast” address: route to “best” of several
replicated servers
• IPv6 datagram format:
– fixed-length 40 byte header
– no fragmentation allowed
IPv6 Header (Cont)
Priority: identify priority among datagrams in flow
Flow Label: identify datagrams in same “flow.”
(concept of“flow” not well defined).
Next header: identify upper layer protocol for data
Other Changes from IPv4
• Checksum: removed entirely to reduce
processing time at each hop
• Options: allowed, but outside of header,
indicated by “Next Header” field
• ICMPv6: new version of ICMP
– additional message types, e.g. “Packet Too
Big”
– multicast group management functions
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?
• Two proposed approaches:
– Dual Stack: some routers with dual stack (v6, v4) can
“translate” between formats
– Tunneling: IPv6 carried as payload in IPv4 datagram
among IPv4 routers
Dual Stack Approach
A
B
C
D
E
F
IPv6
IPv6
IPv4
IPv4
IPv6
IPv6
Flow: X
Src: A
Dest: F
Src:A
Dest: F
Src:A
Dest: F
Flow: ??
Src: A
Dest: F
data
data
data
data
B-to-C:
IPv4
B-to-C:
IPv4
B-to-C:
IPv6
A-to-B:
IPv6
Tunneling
Logical view:
Physical view:
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
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
What is mobility?
• spectrum of mobility, from the network
perspective:
no mobility
mobile user, using
same access point
high mobility
mobile user,
connecting/
disconnecting
from network
using DHCP.
mobile user, passing
through multiple
access point while
maintaining ongoing
connections (like cell
phone)
Mobility: Vocabulary
home network: permanent
“home” of mobile
(e.g., 128.119.40/24)
Permanent address:
address in home
network, can always be
used to reach mobile
e.g., 128.119.40.186
home agent: entity that will
perform mobility functions on
behalf of mobile, when mobile
is remote
wide area
network
correspondent
Mobility: more vocabulary
Permanent address: remains
constant (e.g., 128.119.40.186)
visited network: network in
which mobile currently
resides (e.g., 79.129.13/24)
Care-of-address: address in
visited network.
(e.g., 79,129.13.2)
wide area
network
correspondent: wants
to communicate with
mobile
Foreign agent: entity in
visited network that
performs mobility
functions on behalf of
mobile.
How do you contact a mobile friend:
Consider friend frequently
changing addresses, how do
you find her?
• search all phone
books?
• call her parents?
• expect her to let you
know where he/she
is?
I wonder where
Alice moved to?
Mobility: approaches
• Let routing handle it: routers advertise permanent
address of mobile-nodes-in-residence via usual routing
table exchange.
– routing tables indicate where each mobile located
– no changes to end-systems
• Let end-systems handle it:
– indirect routing: communication from correspondent
to mobile goes through home agent, then forwarded
to remote
– direct routing: correspondent gets foreign address of
mobile, sends directly to mobile
Mobility: approaches
• Let routing handle it: routers advertise permanent
not
address of mobile-nodes-in-residence
via usual routing
scalable
table exchange.
to millions of
mobiles
– routing tables indicate
where each mobile located
– no changes to end-systems
• let end-systems handle it:
– indirect routing: communication from correspondent
to mobile goes through home agent, then forwarded
to remote
– direct routing: correspondent gets foreign address of
mobile, sends directly to mobile
Mobility: registration
visited network
home network
2
1
wide area
network
foreign agent contacts home
agent home: “this mobile is
resident in my network”
End result:
• Foreign agent knows about mobile
• Home agent knows location of mobile
mobile contacts
foreign agent on
entering visited
network
Mobility via Indirect Routing
foreign agent
receives packets,
forwards to mobile
home agent intercepts
packets, forwards to
foreign agent
home
network
visited
network
3
wide area
network
correspondent
addresses packets
using home address
of mobile
1
2
4
mobile replies
directly to
correspondent
Indirect Routing: comments
• Mobile uses two addresses:
– permanent address: used by correspondent (hence
mobile location is transparent to correspondent)
– care-of-address: used by home agent to forward
datagrams to mobile
• foreign agent functions may be done by mobile itself
• triangle routing: correspondent-home-network-mobile
– inefficient when
correspondent, mobile
are in same network
Forwarding datagrams to remote
mobile
foreign-agent-to-mobile packet
packet sent by home agent to foreign
agent: a packet within a packet
dest: 79.129.13.2
dest: 128.119.40.186
dest: 128.119.40.186
Permanent address:
128.119.40.186
dest: 128.119.40.186
packet sent by
correspondent
Care-of address:
79.129.13.2
Indirect Routing: moving between
networks
• suppose mobile user moves to another network
–
–
–
–
registers with new foreign agent
new foreign agent registers with home agent
home agent update care-of-address for mobile
packets continue to be forwarded to mobile (but with
new care-of-address)
• Mobility, changing foreign networks transparent:
on going connections can be maintained!
Mobility via Direct Routing
correspondent forwards
to foreign agent
foreign agent
receives packets,
forwards to mobile
home
network
4
wide area
network
2
correspondent
requests, receives
foreign address of
mobile
visited
network
1
3
4
mobile replies
directly to
correspondent
Mobility via Direct Routing: comments
• overcome triangle routing problem
• non-transparent to correspondent:
correspondent must get care-of-address
from home agent
– What happens if mobile changes networks?
Mobile IP
• RFC 3220
• has many features we’ve seen:
– home agents, foreign agents, foreign-agent
registration, care-of-addresses, encapsulation
(packet-within-a-packet)
• three components to standard:
– agent discovery
– registration with home agent
– indirect routing of datagrams
Mobile IP: agent discovery
• agent advertisement: foreign/home agents
advertise service by broadcasting ICMP
16
0
8= 9)
24
messages (typefield
type = 9
H,F bits: home
and/or foreign agent
R bit: registration
required
checksum
=9
code = 0
=9
standard
ICMP fields
router address
type = 16
length
registration lifetime
sequence #
RBHFMGV
bits
reserved
0 or more care-ofaddresses
mobility agent
advertisement
extension
Mobile IP: registration example
home agent
HA: 128.119.40.7
foreign agent
COA: 79.129.13.2
visited network: 79.129.13/24
ICMP agent adv.
COA: 79.129.13.2
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification: 714
encapsulation format
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification:714
….
registration reply
time
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
encapsulation format
….
registration reply
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
….
Mobile agent
MA: 128.119.40.186