Transcript Intro. to Mobile IP

Network Layer and Mobile IP
1
Motivation for Mobile IP
 Routing

based on IP destination address, network prefix (e.g. 129.13.42)
determines physical subnet
2
Motivation for Mobile IP
 Routing


based on IP destination address, network prefix (e.g. 129.13.42)
determines physical subnet
change of physical subnet implies change of IP address to have a
topological correct address (standard IP) or needs special entries
in the routing tables
3
Motivation for Mobile IP
 Routing


based on IP destination address, network prefix (e.g. 129.13.42)
determines physical subnet
change of physical subnet implies change of IP address to have a
topological correct address (standard IP) or needs special entries in
the routing tables
 Keeping the IP address while moving


Specific routes to end-systems
change of all routing table entries to forward packets to the right
destination
• does not scale with the number of mobile hosts and frequent changes in
the location, security problems
 Changing the IP address



adjust the host IP address depending on the current location
almost impossible to find a mobile system, DNS updates take a long
time
TCP connections break, security problems
4
Requirements of Mobile IP (RFC
3344, was: 3220, was: 2002)
 Transparency



mobile end-systems keep their IP address
continuation of communication after interruption of link possible
point of connection to the fixed network can be changed
 Compatibility



support of the same layer 2 protocols as IP
no changes to current end-systems and routers required
mobile end-systems can communicate with fixed systems
 Security

authentication of all registration messages
 Efficiency and scalability


only little additional messages to the mobile system required
(connection typically via a low bandwidth radio link)
world-wide support of a large number of mobile systems in the
whole Internet
5
Terminology
 Mobile Node (MN)
 system (node) that can change the point of connection
to the network without changing its IP address
 Home Agent (HA)
 system in the home network of the MN, typically a router
 registers the location of the MN, tunnels IP datagrams to the COA
 Foreign Agent (FA)
 system in the current foreign network of the MN, typically a
router
 forwards the tunneled datagrams to the MN, typically also the
default router for the MN
 Care-of Address (COA)
 address of the current tunnel end-point for the MN
• Foreign agent COA: Many MN using the FA can share this COA
• Co-located COA: MN temporarily acquired an additional IP
address which acts as COA (can be chosen, e.g., via DHCP)
 actual location of the MN from an IP point of view
 Correspondent Node (CN): communication partner
6
Example network
HA
MN
router
home network
mobile end-system
Internet
(physical home network
for the MN)
FA
foreign
network
router
(current physical network
for the MN)
CN
end-system
router
7
Example network
HA
MN
router
home network
mobile end-system
Internet
(physical home network
for the MN)
FA
foreign
network
router
(current physical network
for the MN)
CN
end-system
router
8
Data transfer to the mobile system
HA
2
MN
home network
Internet
receiver
3
FA
1
CN
sender
foreign
network
1. Sender sends to the IP address of MN,
HA intercepts packet (proxy ARP)
2. HA tunnels packet to COA, here FA,
by encapsulation
3. FA forwards the packet
to the MN
9
Data transfer from the mobile system
HA
1
home network
MN
sender
Internet
FA
foreign
network
1. Sender sends to the IP address
of the receiver as usual,
FA works as default router
CN
receiver
10
Overview
home
network
COA
router
FA
router
HA
MN
foreign
network
Internet
CN
router
3.
home
network
router
HA
router
FA
2.
MN
4.
Internet
foreign
network
1.
CN
router
11
Network integration
 Agent Advertisement



HA and FA periodically send advertisement messages into their
physical subnets (ICMP packets)
MN listens to these messages and detects, if it is in the home or a
foreign network (standard case for home network)
MN reads a COA from the FA advertisement messages
 Registration (always limited lifetime!)


MN signals COA to the HA via the FA, HA acknowledges via FA to
MN
these actions have to be secured by authentication
 Advertisement




HA advertises the IP address of the MN (as for fixed systems),
i.e. standard routing information
routers adjust their entries, these are stable for a longer time
(HA responsible for a MN over a longer period of time)
packets to the MN are sent to the HA,
independent of changes in COA/FA
12
Agent advertisement
ICMP Router Discover
Message, RFC 1256:
Enable hosts attached to
multicast or broadcast
networks to discover the IP
0
7 8
15 16
23 24
31
addresses of their
type
code
checksum
neighboring routers.
#addresses addr. size
lifetime
type = 9, code = 0; agent
router address 1
routes traffic from mobile &
preference level 1
non-mobile nodes
router address 2
Lifetime : length of time this
preference level 2
advertisement is valid
...
Preference level : how eager
the router is to get a new
type = 16
length
sequence number
node
ICMP packets
R B H F M G r T reserved
registration lifetime
type = 16; agent does not route
COA 1
anything other than mobile traffic
COA 2
length = 6 + 4 * #COAs
R: registration required
Sequence Number:
B: busy, no more registrations
The count of Agent Advertisement
H: offers home agent services
messages sent since the agent was
F: offers foreign agent services
initialized.
M: minimal encapsulation
Registration Lifetime: The longest
G: GRE encapsulation
lifetime (in seconds) that this agent is
r: =0, ignored
willing to accept in any Registration
T: FA supports reverse tunneling
Request. A value of 0xffff indicates
reserved: =0, ignored
infinity
13
Registration
MN
MN
HA
FA
HA
t
COA is co-located
MN sends request directly
HA and vice versa.
Same registration procedure
is used for MNs returning to
their home network
If the MN received an agent
advertisement from the FA it
should register via this FA if
R bit is set in the
advertisement
t
COA is at the FA
MN sends registration request containing the COA to FA
which forwards the request to HA
HA sets up a mobility binding
•Mobile node’s home IP address and current COA
•Lifetime of registration
14
IP Packet Format
0
4
Version
8
HLen
16
TOS
31
Length
Ident
TTL
19
Flags
Protocol
Offset
Checksum
SourceAddr
DestinationAddr
Options (variable)
Data
Pad
(variable)
Datagram format (20 to 24 bytes)
1.
Version
2.
HLen: length of header in 32-bit words
3.
TOS, Type of Service: allow packets to be treated
differently based on application needs
4. Length: bytes of datagram (including header, max
65,535)
5.
Indent, Offset , Flag: information used for
fragmentation
6.
TTL, time to live: discard looping packets; 64 is the
current default
7.
Protocol: higher-level protocol (TCP = 6, UDP
=17, …)
8.
Checksum: calculated for IP header considered as a
sequence of 16-bit words
9.
SourceAddr, DestinationAddr: IP defines its own
global address space, independent of physical
networks
10. Options, Pad: rarely use
15
Mobile IP registration request
UDP packet is used ( low overheads &
better performance compared to TCP in
wireless environments)
0
16
31
UDP destination port: 434
SrcPort
DstPort
Length
Checksum
Data
Header Format
Protocol Field = 17
0
4
Version
8
HLen
IP Packet carrying the
UDP packet
16
TOS
31
Length
Ident
TTL
19
Flags
Protocol
UDP data: fields
relevant for mobile IP
registration requests
MN
Offset
Checksum
SourceAddr
0
7 8
type = 1
15 16
S B DMG r T x
home address
home agent
COA
23 24
lifetime
31
DestinationAddr
Options (variable)
Data
Pad
(variable)
identification
extensions . . .
FA or HA (depending on the location of the COA)
16
Mobile IP registration request (cont.)
0
7 8
type = 1
15 16
S B DMG r T x
home address
home agent
COA
23 24
lifetime
31
identification
extensions . . .
S: MN wants HA to retain prior mobility bindings (simultaneous bindings)
B: MN wants to receive the broadcast packets which have been received by HA in home network
D: MN uses a co-located COA & takes care of de-capsulation at tunnel endpoint
M: minimal encapsulation is used
G: generic encapsulation routing is used
r: =0, ignored
T: reverse tunneling requested
x: =0, ignored
Lifetime: validity of the registration in seconds (zero indicates deregistration; all bits set indicates
infinity)
home address: the fixed IP address of MN
home agent: the IP address of HA
COA : tunnel endpoint
identification: 64 bit generated by MN to identify a request and match it with registration replies
used for protection against replay attacks of registrations
17
extensions : contain at least parameters for authentication.
Mobile IP registration reply
lifetime: how many seconds the
registration is valid if (successful)
home address: address of MN
home agent: addresses HA
7 8
0
Example codes:
registration successful
0 registration accepted
1 registration accepted, but simultaneous
mobility bindings unsupported
registration denied by FA
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 home agent failed authentication
69 requested Lifetime too long
registration denied by HA
129 administratively prohibited
130 insufficient resources
131 mobile node failed authentication
132 foreign agent failed authentication
133 registration Identification mismatch
135 too many simultaneous mobility
bindings
type = 3
15 16
code
home address
home agent
31
lifetime
identification
extensions . . .
identification: 64-bit, used to match
registration requests with replies (value
based on identification field from the
registration and the authentication method)
extensions: must at least contain
parameters for authentication
18
Overview
home
network
COA
router
FA
router
HA
MN
foreign
network
Internet
CN
router
3.
home
network
router
HA
router
FA
2.
MN
4.
Internet
foreign
network
1.
CN
router
19
Encapsulation
original IP header
new IP header
original data
new data
outer header
inner header
original data
3.
home
network
router
HA
router
FA
2.
MN
4.
Internet
foreign
network
1.
CN
router
20
IP Header
0
4
Version
8
HLen
16
TOS
31
Length
Ident
TTL
19
Flags
Protocol
Offset
Checksum
SourceAddr
DestinationAddr
Options (variable)
Data
Pad
(variable)
Datagram format (20 to 24 bytes)
1.
Version
2.
HLen: length of header in 32-bit words
3.
TOS, Type of Service: allow packets to be treated
differently based on application needs
4. Length: bytes of datagram (including header, max
65,535)
5.
Indent, Offset , Flag: information used for
fragmentation
6.
TTL, time to live: discard looping packets; 64 is the
current default
7.
Protocol: higher-level protocol (TCP = 6, UDP
=17, …)
8.
Checksum: calculated for IP header considered as a
sequence of 16-bit words
9.
SourceAddr, DestinationAddr: IP defines its own
global address space, independent of physical
networks
10. Options, Pad: rarely use
21
Encapsulation I
 Encapsulation of one packet into another as payload
 e.g. IPv6 in IPv4 (6Bone), Multicast in Unicast (Mbone)
 here: e.g. IP-in-IP-encapsulation, minimal encapsulation or
GRE (Generic Record Encapsulation)
 IP-in-IP-encapsulation (mandatory, RFC 2003)
 tunnel between HA and COA
outer header: ver.: 4 ; P-in-IP: 4
DS(TOS): copied from inner header.
length: covers complete
encapsulated packet
IP identification, flags, fragment
offset: no special meaning for mobile
IP and are set according to RFC 791
inner header
Only TTL is changed (decremented by 1)
Packet is just one (logical) hop
away for the MN
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
IP-in-IP
IP checksum
IP address of HA
Care-of address COA
ver. IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload
22
Encapsulation II
 Minimal encapsulation
(optional)




avoids repetition of
identical fields
e.g. TTL, IHL, version,
DS (RFC 2474, old: TOS)
only applicable for
unfragmented packets,
no space left for
fragment identification
min. encap. = 55
IP-in-IP
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
IP-in-IP
IP checksum
IP address of HA
Care-of address COA
ver. IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload
Minimal encapsulation
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
min. encap.
IP checksum
IP address of HA
care-of address COA
lay. 4 protoc. S reserved
IP checksum
IP address of MN
original sender IP address (if S=1)
TCP/UDP/ ... payload
23
Generic Routing Encapsulation
GRE: allows encapsulation of packets of
one protocol into payload portion of a
packet of another protocol (not only IP
packets in IP packets)
may be copied
from original IP
header
47
RFC 1701
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
GRE
IP checksum
IP address of HA
Care-of address COA
C R K S s rec.
rsv.
ver.
protocol
checksum (optional)
offset (optional)
key (optional)
sequence number (optional)
routing (optional)
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload
outer header
new header
GRE
header
original
header
original data
original
header
original data
new data
C: checksum contains valid information (a valid IP
checksum of GRE header and payload)
R: offset and routing fields are present
offset: offset in bytes for the first source routing entry
routing: has a variable length and contains fields for
source routing
K : key field may be used for authentication
S: sequence number field is present; also strict source
routing is used
rec.: a counter; number of allowed recursive
encapsulations;
When a packet arrives at an encapsulator If not zero,
packet is encapsulated and field decremented by one
rsv : 0; ignored
ver : GRE version; 0
protocol : protocol of packet following GRE header;
0 x 800 for IP
24
Generic Routing Encapsulation (cont)
 simplified header of GRE following RFC 2784

more generalized version of GRE compared to RFC 1701
RFC 2784
C: checksum & reserved1 are present
C
reserved0
ver.
next 5 bits: zero
checksum (optional)
ver : 0
protocol: protocol of payload following RFC 3232
protocol
reserved1 (=0)
25
Optimization of packet forwarding
 Triangular Routing
 sender sends all packets via HA to MN
 higher latency and network load
 “Solutions”
 sender learns the current location of MN
 direct tunneling to this location
 HA informs a sender about the location of MN
 big security problems!
 Change of FA
 packets on-the-fly during the change can be lost
 new FA informs old FA to avoid packet loss, old FA now
forwards remaining packets to new FA
 this information also enables the old FA to release
resources for the MN
26
Reverse tunneling (RFC 3024, was: 2344)
HA
2
MN
home network
Internet
sender
1
FA
CN
receiver
3
foreign
network
1. MN sends to FA
2. FA tunnels packets to HA
by encapsulation
3. HA forwards the packet to the
receiver (standard case)
Agent Advertisements can carry requests for reverse tunneling
27
Why Reverse Tunneling?
 MN sends packets through FA; assumes
routing is independent of source address
 Assumption is not always true

Example: Firewalls filter packets coming from
outside containing a source address from
computers of the internal network
• MN cannot send a packet to a computer residing in its
home network
 Solution: a topologically correct reverse
tunnel from COA to HA

a packet from the MN encapsulated by the FA is
now topological correct
28
Why Reverse Tunneling? II
 Allow MN to participate in a multi-cast group
 MN in a foreign network needs a a reverse tunnel to
transmit multi-cast packets in a way that they emanate
from its home network
 Allow MN to use same TTL as when in Home
network

TTL might be low so that no packet is transmitted outside a
certain region
• From a foreign network, this TTL might be too low for packets
to reach same nodes as before
• Mobile IP is no longer transparent if a user has to adjust TTL
while MN moves

reverse tunnel represents only one hop, no matter how many
hops are really needed from foreign to home network
29
Mobile IP with reverse tunneling
 The standard is backwards compatible
 the extensions can be implemented easily and
cooperate with current implementations without
these extensions
 Agent Advertisements can carry requests for
reverse tunneling; See Agent Advertisement
30
Mobile IP and IPv6
 Mobile IP was developed for IPv4, but IPv6
simplifies the protocols

security is integrated and not an add-on
 authentication of registration is included




COA can be assigned via auto-configuration (DHCPv6 is one
candidate), every node has address autoconfiguration
no need for a separate FA, all routers perform router
advertisement which can be used instead of the special
agent advertisement; addresses are always co-located
MN can signal a sender directly the COA, sending via HA
not needed in this case (automatic path optimization)
“soft“ hand-over, i.e. without packet loss, between two
subnets is supported
• MN sends the new COA to its old router
• the old router encapsulates all incoming packets for the MN
and forwards them to the new COA
• authentication is always granted
31
Problems with mobile IP
 Security
 authentication with FA problematic, for the FA typically
belongs to another organization
 no protocol for key management and key distribution has
been standardized in the Internet
 patent and export restrictions
 Firewalls
 typically mobile IP cannot be used together with firewalls,
special set-ups are needed (such as reverse tunneling)
 QoS
 tunneling makes it hard to give a flow of packets a special
treatment needed for the QoS
 Security, firewalls, QoS etc. are topics of current
research and discussions!
32
Need for IP Micro-mobility support
 Large # of MNs changing networks quite
frequently

High load on the HAs & networks (registration & binding
updates)
 IP micro-mobility protocols offer fast and
seamless handover in limited geographical areas
HA knows only entry point to foreign network (not
details)
 Changes location within foreign network handled locally
 Only inform HA about major changes (i.e., changes of a
region)
 Example approaches:


Cellular IP (section 8.1.10.1); HAWAII (section 8.1.10.2);
Hierarchical Mobile IP (HMIP) (section 8.1.10.3)
33