mip4_Group2_Final
Download
Report
Transcript mip4_Group2_Final
Alvaro Agudelo
Alexander Tucker
Wael Kdouh
Suresh Srinivasan
1
Content
• IPv4 over Stationary Environments
• MIPv4 overview
• Micro-mobility
• Agent Discovery
• Registration
• Mobile Node Communication
• Issues
• Low-latency handoffs
• Regional Registration
• Dynamic HA Assignments
• Security
2
• ARP example
• ICMP example
• Message Flow example
3
ARP example
Host A boots:
Internet
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
A
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
4
ARP broadcast
ARP broadcast
from A.
IP MAC
Internet
ARP caches
Updated.
Router (R1)
198.100.1.2 00:0b:23:78:c2:11
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
( arp –a )
A
IP MAC
198.100.1.2 00:0b:23:78:c2:11
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
5
ARP example
ARP cache
entries expire
IP MAC
Internet
Router (R1)
198.100.1.2 00:0b:23:78:c2:11
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
A
IP MAC
198.100.1.2 00:0b:23:78:c2:11
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
6
ARP example
B wants to
talk to A,
but B does not
have an entry on
Its ARP cache for
IPA
IP MAC
Internet
A
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
IP MAC
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
7
ARP request
ARP request
from B
to (ff:ff:ff:ff:ff:ff)
(IPA)
IP MAC
Internet
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
IP MAC
198.100.1.3 00:10:b5:78:5b:6c
A
IP MAC
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
8
ARP reply
ARP reply
from A
to MACB
IP MAC
Internet
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
MACR1=00:00:0c:07:ac:18
IP MAC
198.100.1.3 00:10:b5:78:5b:6c
A
IP MAC
198.100.1.2 00:0b:23:78:c2:11
BCN
IPA: 198.100.1.2
MACA=00:0b:23:78:c2:11
IPB: 198.100.1.3
MACB=00:10:b5:78:5b:6c
9
ARP request
Hardware Type=1 (Ethernet)
Protocol Address Type=0x0800 (IPv4 Address)
Hardware Address Size=6 (MAC address size)
Protocol Address Size=4 (IPv4 address size)
Operation: 1 (ARP request)
Src MAC address: MACB=00:10:b5:78:5b:6c
Src IP address: IPB: 198.100.1.3
Dst MAC address: ff:ff:ff:ff:ff:ff
Dst IP address: IPA: 198.100.1.2
ARP data
Frame
Header
Frame Data
Dst MAC address: ff:ff:ff:ff:ff:ff
Src MAC address: MACB=00:10:b5:78:5b:6c
Frame Type=0x0806 (ARP frame)
10
ARP reply
Hardware Type=1 (Ethernet)
Protocol Address Type=0x0800 (IPv4 Address)
Hardware Address Size=6 (MAC address size)
Protocol Address Size=4 (IPv4 address size)
Operation: 2 (ARP reply)
Src MAC address: MACA=00:0b:23:78:c2:11
Src IP address: IPA: 198.100.1.2
Dst MAC address: MACB=00:10:b5:78:5b:6c
Dst IP address: IPB: 198.100.1.3
ARP data
Frame
Header
Frame Data
Dst MAC address: MACB=00:10:b5:78:5b:6c
Src MAC address: MACA=00:0b:23:78:c2:11
Frame Type=0x0806 (ARP frame)
11
ICMP example
Before sending
packets, A
needs a default
router
Internet
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
IP NextHOP
A
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
12
ICMP Router Advertisement
Router 1 sends
periodically
Internet
ICMP Router
Advertisements
To all-systems multicast
Address ( 224.0.0.1 ) or
if not supported,
to the limited
broadcast address
( 255.255.255.255 )
A
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
13
ICMP example
Routing tables
are updated
Router (R1)
Internet
N1: 198.100.x.x
R1IP=198.100.1.1
IP NextHOP
x 198.100.1.1
A
IP NextHOP
x 198.100.1.1
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
14
ICMP example
Routing entries
expire
Router (R1)
Internet
N1: 198.100.x.x
R1IP=198.100.1.1
IP NextHOP
x 198.100.1.1
A
IP NextHOP
x 198.100.1.1
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
15
ICMP example
A needs to send
packets but there
Router (R1)
is no default
Internet
router
(or A just booted and
R1IP=198.100.1.1
cannot wait for the
next router
advertisement)
IP NextHOP
A
N1: 198.100.x.x
IP NextHOP
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
16
ICMP Router Solicitation
A sends an
ICMP Router
Solicitation
to all-routers
multicast address
( 224.0.0.2 ) or
if not supported,
to the limited
broadcast address
( 255.255.255.255 )
A
Internet
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
BCN
IPA: 198.100.1.2
IPB: 198.100.1.3
17
ICMP example
R1 reads the
Internet
packet and
sends an ICMP
Router Advertisement
(Unicast)
Router (R1)
N1: 198.100.x.x
R1IP=198.100.1.1
IP NextHOP
x 198.100.1.1
A
BCN
IPA: 198.100.1.2
Routing table
In A is updated
IPB: 198.100.1.3
18
Router Solicitation
Type=10 (Router Solicitation)
Code=0
Version=4 (IPv4)
TTL=1
Protocol=0x01 (ICMP)
Src = IPA: 198.100.1.2
Dst = 224.0.0.2
ICMP
Header
Datagram
Header
All Routers group
Frame
Header
ICMP Data
Datagram Data
Frame Data
Dst MAC address: ff:ff:ff:ff:ff:ff
Src MAC address: MACA=00:0b:23:78:c2:11
Frame Type=0x0800 (IP frame)
19
Router Advertisement
Type=9 (Router Advertisement)
Code=0
Number of Addresses=1
Lifetime=1800 seconds (30min)
Router Address 1 = R1IP: 198.100.1.1
Preference Level 1 = p1
Version=4 (IPv4)
TTL=1
Protocol=0x01 (ICMP)
Src = R1IP: 198.100.1.1
Dst = 224.0.0.1
ICMP
Header
Datagram
Header
All Systems group
Frame
Header
ICMP Data
Datagram Data
Frame Data
Dst MAC address: ff:ff:ff:ff:ff:ff
Src MAC address: MACR1=00:00:0c:07:ac:18
Frame Type=0x0800 (IP frame)
20
Message Flow example
Router (R4)
Router (R3)
Dst
Router (R2)
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
Router (R1)
Sending datagrams from Src to Dst …
Src
21
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
22
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
23
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
N2: 172.16.x.x
Internet
Dst: DstIP: 172.16.2.2
Src: SrcIP
: 198.100.1.2
N1:
198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
24
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
Internet
N2: 172.16.x.x
135.157.x.x
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
25
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
R2
Dst: DstIP: 172.16.2.2
R3IP=155.174.3.1
R2IP=172.16.2.1
Src: SrcIP : 198.100.1.2
R4IP=155.174.3.2
N3: 155.174.x.x
135.209.x.x
N2: 172.16.x.x
135.157.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
26
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
135.209.x.x
N2: 172.16.x.x
135.157.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
27
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
135.209.x.x
N2: 172.16.x.x
135.157.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
28
Message Flow example
Dst
DstIP: 172.16.2.2
R4
R3
Dst: DstIP: 172.16.2.2
Src: SrcIP : 198.100.1.2
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
135.209.x.x
N2: 172.16.x.x
135.157.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
29
• Terminology
• CCoA example
• FCoA example
30
Protocol Requirements
• When MN changes its link-layer point of attachment to the Internet, it
must be able to communicate with other nodes without changing its IP
address
• A MN must be able to communicate with other nodes that do not have
mobility functions (i.e stationary hosts)
• Use authentication to protect against remote redirection attacks
Goals
• Minimize MN’s power consumption
• Minimize the number of administrative messages over MN’s link
• Minimize the size of those messages
31
Mobile IPv4 example
Dst
DstIP: 172.16.2.2
R4
R3
R2
R3IP=155.174.3.1
R2IP=172.16.2.1
R4IP=155.174.3.2
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Src
CN SrcIP: 198.100.1.2
32
Terminology
Mobile Node (MN)
Home Address (HoA): 172.16.2.2
Care-of Address (CoA): 155.174.3.3
Foreign Agent (FA)
R3
Permanent
Temporal
Home Agent (HA)
Foreign Network
Home Network
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN CNIP: 198.100.1.2
Corresponding Node (CN)
33
Strategy
MN
HoA: 172.16.2.2
CoA: 155.174.3.3
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
34
CCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
Co-located care-of Address
R3
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
35
CCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
R3
Dst: CCoA : 155.174.3.3
Src: HAIP : 172.16.2.1
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
HA
HoA CoA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
36
CCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
Dst: CCoA : 155.174.3.3
Src: HAIP : 172.16.2.1
Dst: CCoA : 155.174.3.3
Src: HAIP : 172.16.2.1
R3
Dst: CCoA : 155.174.3.3
Src: HAIP : 172.16.2.1
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Protocol ID in IP header:
0x04 for IP in IP encapsulation
0x37 for Minimal encapsulation
0x2F for GRE encapsulation
CN
CN CNIP: 198.100.1.2
37
CCoA example
MN
HoA: 172.16.2.2
CCoA:
155.174.3.3
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
Dst: CCoA : 155.174.3.3
Src: HAIP : 172.16.2.1
R3
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
38
CCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
R3
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
39
FCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
Foreign Agent care-of Address
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
40
FCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
R3
FA
Dst: FCoA : 155.174.3.2
Src: HAIP : 172.16.2.1
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
HA
HoA CoA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
N1: 198.100.x.x
Internet
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
41
FCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
Dst: FCoA : 155.174.3.2
Src: HAIP : 172.16.2.1
R3
FA
Dst: FCoA : 155.174.3.2
Src:FAIP=155.174.3.2
HAIP : 172.16.2.1
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
42
FCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
Dst: FCoA : 155.174.3.2
Src: HAIP : 172.16.2.1
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
43
FCoA example
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
Dst: FCoA : 155.174.3.2
Src: HAIP : 172.16.2.1
FA
HoA MAC R3
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
44
FCoA example
MN
Dst: HoA: 172.16.2.2
Src: CNIP : 198.100.1.2
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
45
Mobile IPv4 Characteristics
•
•
•
•
•
Transparency: to applications, transport layer protocols, most routers
Interoperability with IPv4: no special addressing scheme
Scalability: mobility across the global Internet
Security: all messages are authenticated
Macro mobility: It is suited for long duration moves instead of fast
network transitions (where link-layer handoffs are better).
46
• Wireless Links
• Handoff example
• Operating Rates
47
Wireless Links
Cellular technologies offer Micro-Mobility which can handle fast
switching between network access points.
SGSN
Base Station
48
Handoff example
49
Operating Rates
A large scale mobile network can be realized by building MIP
on top of a cellular technology.
Operating rates for wireless links:
GPRS (2.5 G) : 170 kbps
EDGE (2.5 G) : 384 kbps
WCDMA (3G) : 2 Mbps
Operating rates for other underlying network technologies:
Ethernet (10 Base S, 10 Base 2, 10 Base T) : 10 Mbps
Fast Ethernet (100 Base T) : 100 Mbps
Gigabit Ethernet (1000 Base T) : 1 Gbps
FDDI : 100 Mbps
50
• Purpose
• HA discovery
• FA discovery
•Agent Solicitation
•Agent Advertisement
•Agent Advertisement Extensions
•Agent Considerations
51
Purpose
• MN can find out if it is currently connected to its home
network or to a foreign network.
• MN can detect that it has moved from one network to
another.
• MN can find the FCoA offered by a FA.
52
HA discovery
HoA: 172.16.2.2
MN
MACMN: 00:08:02:da:4c:2d
HA
R3
FA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
MN boots
, data-link layer bindings are resolved.
53
HA discovery
HoA: 172.16.2.2
MN
MACMN: 00:08:02:da:4c:2d
HA
R3
FA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
MN broadcasts an Agent Solicitation
CN
CN CNIP: 198.100.1.2
54
HA discovery
HoA: 172.16.2.2
MN
MACMN: 00:08:02:da:4c:2d
HA
R3
FA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
HA responds with a unicast agent
Advertisement
CN
CN CNIP: 198.100.1.2
55
HA discovery
HoA: 172.16.2.2
MN
MACMN: 00:08:02:da:4c:2d
HA
R3
FA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
HA keeps sending multicast agent advertisements
before the advertisement lifetime expires.
CN
CN CNIP: 198.100.1.2
56
FA discovery
HoA: 172.16.2.2
MN
MACMN: 00:08:02:da:4c:2d
HA
R3
FA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
MN moves
57
FA discovery
MN
HoA: 172.16.2.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
Link-layer handoff finishes.
Link-layer mechanisms can be used to decide that MN
has changed its point of attachment:
Agents can be discovered by a link-layer protocol.
N1: 198.100.x.x
R1
R1IP=198.100.1.1
CN
CN CNIP: 198.100.1.2
58
Case 1
MN
HoA: 172.16.2.2
HA entry: expired
FA entry: valid
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
MN receives an advertisement from FA
MN knows that it moved, so it can register.
CN
CN CNIP: 198.100.1.2
59
Case 2
MN
HoA: 172.16.2.2
HA entry: expired
Other Agent entries: expired
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
MN does not know if it moved.
MN can broadcast an Agent Solicitation
CN
CN CNIP: 198.100.1.2
60
Case 2
MN
HoA: 172.16.2.2
FCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
FA responds with a unicast agent
Advertisement.
MN learns FAIP and MACFA
CN
CN CNIP: 198.100.1.2
61
Case 3
MN
HoA: 172.16.2.2
CCoA: 155.174.3.3
MACMN: 00:08:02:da:4c:2d
R3
HA
R3IP=155.174.3.1
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
There is no Foreign Agent; MN Boots.
A DHCP server in Network 3 can assign an
available IP address from the database.
CN
CN CNIP: 198.100.1.2
62
Agent Solicitation
Router Solicitation
Must be one
Version=4 (IPv4)
TTL=1
Protocol=0x01 (ICMP)
Src = IPMN: 198.100.1.2
Dst = 224.0.0.11
ICMP
Header
Datagram
Header
All Agents group
Frame
Header
Type=10 (Router Solicitation)
Code=0
ICMP Data
Datagram Data
Frame Data
Dst MAC address: ff:ff:ff:ff:ff:ff
Src MAC address: MACMN
Frame Type=0x0800 (IP frame)
63
Agent Advertisement
Type=9 (Router Advertisement)
Code=0, 16 (0common traffic)
Number of Addresses=1
Lifetime in seconds
Router Address 1 = R3IP:155.174.3.1
Preference Level 1 = p1
Version=4 (IPv4)
TTL=1
Protocol=0x01 (ICMP)
Src = FAIP: 155.174.3.2
Dst = 224.0.0.1
Mobility Agent
Advertisement
Extension
ICMP
Header
Datagram
Header
PrefixLengths
Extension
Onebyte
Padding
ICMP Data
Datagram Data
All Systems group
Frame
Header
Frame Data
Dst MAC address: ff:ff:ff:ff:ff:ff
Src MAC address: MACFA
Frame Type=0x0800 (IP frame)
64
Mobility Agent Advertisement Extension
8
0
TYPE(16)
24
16
LENGTH
LIFETIME
31
SEQUENCE NUM
CODE
RESERVED
CARE-OF ADDRESSES
LENGTH size in octets without TYPE
and LENGTH fields
CODE: RBHFMGrT
R – Registration required
(CCoA not allowed)
SEQUENCE NUM count of advertisements
B – Busy (do not send registrations)
to help recipient know about lost messages.
H – Home Agent
Range: [0,256]
F – Foreign Agent
M – I receive tunneled datagrams with
Registration LIFETIME maximum time
Minimal encapsulation
to accept registrations or 0xffff for infinity
G – I receive tunneled datagrams with
Generic Routing Encapsulation
r – zero
Foreign-Agent specific
T – Foreign Agent supports
reverse Tunneling
65
Agent Advertisement Extensions
Type=16
Length=…
Sequence=1
Registration Lifetime=0xffff
Code=RBHFMGrT
Care-of Address: FCoA: 155.174.3.2
= FAIP.
Type=19 (Prefix-Length Extension)
Length= …
Prefix Length 1=16
Mobility Agent
Advertisement
Extension
ICMP
Header
Type=9 (Router Advertisement)
Code=0, 16 (0common traffic)
Number of Addresses=1
Lifetime in seconds
Router Address 1 = R3IP:155.174.3.1
Preference Level 1 = p1
PrefixLengths
Extension
Onebyte
Padding
ICMP Data
To make ICMP
Header even.
66
Agent Considerations
• A mobility agent must choose a maximum rate for agent
advertisements in order to save network bandwidth.
• The mobile agent that receives an agent solicitation must
not validate the source IP address.
• Through configuration changes, a mobility agent may
send agent advertisements only when receiving an Agent
solicitation.
• If the home network is a virtual network, the home agent
will not send advertisements. The mobile nodes with this
home network are treated as being away from home.
67
• Purpose
• Registration Request
• Registration Reply
• Registration Message Format
• Registration Extensions
68
Purpose
• When visiting a Foreign Network, the MN can request
forwarding services from HA.
• MN can inform the HA of their current care-of address.
• MN can renew a registration that will expire soon.
• MN can deregister when it returns home.
• MN can discover its home address.
• MN can maintain simultaneous registrations.
• MN can deregister specific COAs.
69
MN
Registration Request
HoA: 172.16.2.2
FCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Registration request from MN to FA
FA learns HoA and MACMN
CN
CN CNIP: 198.100.1.2
70
MN
Registration Request
HoA: 172.16.2.2
FCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Registration request from FA to HA
CN
CN CNIP: 198.100.1.2
71
MN
Registration Reply
HoA: 172.16.2.2
FCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Registration reply from HA to FA
CN
CN CNIP: 198.100.1.2
72
MN
Registration Reply
HoA: 172.16.2.2
FCoA: 155.174.3.2
MACMN: 00:08:02:da:4c:2d
R3
FA
HA
R3IP=155.174.3.1
FAIP=155.174.3.2
HAIP=172.16.2.1
N3: 155.174.x.x
N2: 172.16.x.x
Internet
N1: 198.100.x.x
R1
R1IP=198.100.1.1
Registration reply from FA to MN
CN
CN CNIP: 198.100.1.2
73
Registration Message Format
8
0
TYPE(1 or 3)
16
FLAGS
31
LIFETIME
HOME ADDRESS
CARE-OF ADDRESS
IDENTIFICATION
EXTENSIONS …
TYPE 1:request, 3:reply
LIFETIME # seconds the registration is valid.
0 means immediate deregistration.
All ones means infinite lifetime.
IDENTIFICATION: generated by MN to match requests
with replies, and to ignore old messages.
74
FLAGS: SBDMGrTx
S Simultaneous bindings: Add binding in HA instead of updating it.
This flag avoids many registrations
messages when MN changes
Foreign Networks rapidly.
Request for HA to tunnel a copy of
each datagram to each active
COA.
75
FLAGS: SBDMGrTx
S Simultaneous bindings: Add binding in HA instead of updating it.
B Broadcast datagrams: send a copy of broadcasts received by HA
from the home network.
MN
HA
FA
Foreign Network
R3
Home Network
76
FLAGS: SBDMGrTx
S Simultaneous bindings: Add binding in HA instead of updating it.
B Broadcast datagrams: send a copy of broadcasts received by HA from
the home network.
D Decapsulation by Mobile Node: MN will decapsulate (CCoA case).
M Request to use Minimal Encapsulation
G Request to use GRE encapsulation
r zero
T Request reverse tunneling ( MN CN through HA )
x zero
HA-specific
FA-specific
77
Status Codes
Successful:
0 Registration accepted
1 Registration accepted, but ‘S’ request unsupported.
Denied by FA:
71 poorly formed reply
72 requested encapsulation unavailable
Denied by HA:
135 Too many ‘S’ bindings.
136 Unknown HA address.
Denied by (FA, HA):
66, 130 Insufficient resources
67, 131 MN failed authentication
68, 132 (HA, FA) failed authentication
70, 134 poorly formed request
78
Registration Request: MNFA
Src port= SPMN
Dst port= 434
Type=1 (request)
Flags=SBDMGrTx
Lifetime=seconds remaining
Home Address: HoA: 172.16.2.2
Home Agent: HAIP: 172.16.2.1
Care-of Address: FCoA: 155.174.3.2
Identification: …
Version=4 (IPv4)
TTL=1
Protocol=0x11 (UDP)
Src = HoA: 172.16.2.2
Dst = FAIP: 155.174.3.2
or 224.0.0.11 (all agents for
link-layer agent discovery)
Frame
Header
UDP
Header
Datagram
Header
Registration
Request
Extensions
UDP Data
Datagram Data
Frame Data
Dst MAC address: MACFA
Src MAC address: MACMN
Frame Type=0x0800 (IP frame)
79
Registration Request: FAHA
Src port= SPFA
Dst port= 434
Type=1 (request)
Flags=SBDMGrTx
Lifetime=seconds remaining
Home Address: HoA: 172.16.2.2
Home Agent: HAIP: 172.16.2.1
Care-of Address: FCoA: 155.174.3.2
Identification: …
Version=4 (IPv4)
TTL=64
Protocol=0x11 (UDP)
Src = FAIP: 155.174.3.2
Dst = HAIP: 172.16.2.1
Frame
Header
UDP
Header
Datagram
Header
Registration
Request
Extensions
UDP Data
Datagram Data
Frame Data
Dst MAC address: MACHA
Src MAC address: MACFA
Frame Type=0x0800 (IP frame)
80
Registration Reply: HAFA
Src port= Any
Dst port= SPFA
Type=3 (reply)
Code=0 (registration accepted)
Lifetime=seconds granted by HA
Home Address: HoA: 172.16.2.2
Home Agent: HAIP: 172.16.2.1
Identification: …
Version=4 (IPv4)
TTL=64
Protocol=0x11 (UDP)
Src = HAIP: 172.16.2.1
Dst = FAIP: 155.174.3.2
Frame
Header
Registration
Reply
UDP
Header
Datagram
Header
Extensions
UDP Data
Datagram Data
Frame Data
Dst MAC address: MACFA
Src MAC address: MACHA
Frame Type=0x0800 (IP frame)
81
Registration Reply: FAMN
Src port= Any
Dst port= SPMN
Type=3 (reply)
Code=0 (registration accepted)
Lifetime=seconds granted by FA
Home Address: HoA: 172.16.2.2
Home Agent: HAIP: 172.16.2.1
Identification: …
Version=4 (IPv4)
TTL=1
Protocol=0x11 (UDP)
Src = FAIP: 155.174.3.2
Dst = HoA: 172.16.2.2
Frame
Header
Registration
Reply
UDP
Header
Datagram
Header
Extensions
UDP Data
Datagram Data
Frame Data
Dst MAC address: MACMN
Src MAC address: MACFA
Frame Type=0x0800 (IP frame)
82
Registration Extensions
• Mobile-Home Authentication Extension
• Mobile-Foreign Authentication Extension
• Foreign-Home Authentication Extension
83
• Communication on a Foreign Network
• Proxy ARP
• Gratuitous ARP
• Communication on the Home Network
84
MN communication on a Foreign Network
• Relaxing the rules for IP addressing :
– MN FA : MN is allowed to use IPSrc=HoA
– FA MN : FA is allowed to use IPDst=HoA
• FA cannot use ARP to find the MACMN. FA has to keep all
MN information from the registration request including the
MACMN. MN also disables processing ARP requests.
• Because IPMN=HoA, the Foreign Network and the ISP that
connects it to the Internet must inhibit Ingress Filtering to
allow an arbitrary source address.
• MN CN follows the shortest path. The reply does not.
85
Proxy ARP
Host A sends an ARP request to obtain MACMN.
HA sends an ARP reply to A with MACHA.
(HA sends the reply in behalf of MN)
IP MAC
IPMN MACHA
A
MN
B
HA
FA
Foreign Network
R3
Home Network
86
Gratuitous ARP
IP MAC
HA sends an ARP broadcasts
(not in response to any requests)
IPMN MACHA
A
MN
IP MAC
IPMN MACHA
B
HA
FA
Foreign Network
R3
Registration
Internet
Home Network
87
MN communication on the Home Network
• HA is usually the router that connects the home network with the rest
of the Internet so that HA can easily intercept and tunnel datagrams
that arrive for MN from outside.
• When HA accepts a registration request, it performs a gratuitous ARP
on behalf of MN, and starts using Proxy ARP to reply to requests for
MACMN.
• When Src, and Dst are in the same subnet, IP protocol specifies
direct delivery, so Src will not forward datagrams to the default router
(HA) if Dst=MN. In this case, Src will use ARP to bind IPMN. (HA
replies the ARP request)
• Proxy ARP solves the problem of having multiple routers in the home
network: only one acts as HA and tunnels datagrams while the others
are deceived through ARP that MN is directly attached.
88
• The Two-Crossing Problem
• Other Issues
89
Two-Crossing Problem
B wants to talk to MN. (Common because of Spatial Locality of Reference)
R3 is B’s default router and it is not the FA.
HA Intercepts the datagrams for MN and tunnels them back to FA
A
MN
B
HA
FA
R3
Foreign Network
Internet
Home Network
If this situation is likely to happen, propagate host-specific routes.
90
Other Issues
•
The Two-Crossing problem (or 2X problem) illustrates a major disadvantage
of mobile IP: inefficient routing. Another example: MNCN follows shortest
path, but CNMN goes through HA: Triangular routing. Solution Approach:
HA sends bind update over UDP to CN with COA (CN should support
binding protocol. CN needs to encapsulates datagrams)
•
Tunneling makes it difficult to debug network errors: ICMP report of
Unreachable Destination (type 3) contains IP header + the next 64 bits of the
datagram that caused the problem. Traceroute would use this information to
know which address is unreachable, but since the datagram is encapsulated,
it cannot know.
•
Asymmetric routing makes Path MTU a difficult problem (used by non-TCP
mechanisms to enhance performance). The Ideal MSS (Maximum Segment
Size) is the minimum MTU along the path so that the maximum amount of
information can be sent without fragmentation.
91
Low Latency Handoffs
For MIPv4
92
Overview
• Issues:
– As a mobile node moves from one network to another, data
flow will be interrupted because the MN can only be
connected to one FA at a time, causing packet loss
– During the process of disconnection from one FA and
connection to another FA, there is a delay of traffic called
latency
93
Overview
•
Sources of latency that are usually
sequential and cause packet
loss/interruption
1.
2.
3.
•
Layer 2 latency – Time between link layer detachment from
previous network to link reattachment at new network
Advertisement latency -Latency at Layer 3 between the Mobile
Node attaching to new link and receiving a broadcast Foreign
Agent Advertisement.
Registration latency - Latency at Layer 3 between the Mobile
Node receiving the Foreign Agent Advertisement and completing
registration with the Foreign Agent and Home Agent.
Reduce latency by overlapping the above
94
But first, some definitions
•
•
•
•
•
low latency handoff - L3 handoff in which the period of time during
which the MN is unable to receive packets is minimized.
low loss handoff - L3 handoff in which the number of packets dropped
or delayed is minimized. Low loss handoff is often called smooth
handoff.
seamless handoff - L3 handoff that is both low latency and low loss
bi-directional edge tunnel (BET) - A bi-directional tunnel established
between two FAs for purposes of temporarily routing a MN's traffic
to/from it on a new subnet without requiring the MN to change CoA,
referred to in the presentation as just a “tunnel”
IP address identifier - IP address of a MN or FA, or an L2 identifier
that allows an FA to deduce the IP address of a MN or FA.
95
Two general solutions (1)
• PRE-REGISTRATION handoff method
– Allow connection of mobile node to both FA's during
handover
– L3 before L2 means that the new TCP connection is
established for the MN before the MN switches networks
– L2 triggers initiate this (from MN, MN-initiated & from FA, FAinitiated)
Remember:
Layer 2 is the data link layer - logical link control, media access control, hardware
addressing, error detection and handling, (LLC & MAC)
Layer 3 is the network layer - IP (or in this case mobile IP)
• So PRE-REGISTRATION the latency at layer 2 and 3
are overlapped to occur simultaneously!
96
Two general solutions (2)
• POST-REGISTRATION handoff method
– Provide data flow from new FA before registration at new FA
occurs
– L2 before L3 means that the MN has moved to the new
network but uses the old TCP connection to the previous FA
• L2 latency still exists, but the Advertisement and
Registration latency is dealt with after handoff !
97
What is a “trigger”
• Triggers = signals that start a handoff between wireless
networks and happen at the L2 layer
Remember:
Layer 2 is the data link layer - logical link control, media access control,
hardware addressing, error detection and handling, (LLC & MAC)
• For mobile IP usage, these should be considered abstractions
that contain mandatory information that can be used for any type
of Layer 2
• L2 Triggers can be received by and defined as:
– MN – can receive mobile trigger (L2-MT) or link-up (L2-LU)
– oFA - can receive source trigger (L2-ST) or link-down (L2-LD)
– nFA - can receive target trigger (L2-TT) or link-up (L2-LU)
98
Types of trigger (1)
L2 Trigger
Mobile Trigger
(L2-MT)
Source Trigger (L2-ST)
Received by
MN
oFA
Method
PRE-Mobile initiated
PRE-network
initiated
What?
An L2 trigger that occurs
at the MN informing of
movement to a certain
nFA (Mobile Trigger)
An L2 trigger that occurs at oFA,
informing the oFA that L2 handoff is about to
occur.
When?
Enough in advance of the
L2 handover so that MN
can still solicit
ProxyRtAdv from oFA
Enough in advance
of the L2 handover
for FA to send
proxyRtAdv to MN
Parameters
nFA IP address identifier
nFA IP address identifier
MN IP address identifier
POST source trigger
Enough in advance of
the L2 handover for
oFA and nFA to
exchange HRqst/Hrply
99
Types of trigger (2)
L2 Trigger
Target Trigger
(L2-TT)
Link-Up
(L2-LU)
Link-Down
(L2-LD)
Received by
nFA
MN or nFA
oFA
Method
PRENetwork
initiated
PRE & POST
POST
What?
An L2 trigger that occurs
at nFA, informing the
nFA that a MN is about to
be handed off to nFA.
An L2 trigger that
occurs at the MN or
nFA, informing
that the L2 link
between MN and nFA
is established.
An L2 trigger that
occurs at the oFA,
informing the oFA
that the L2 link
between MN and
oFA is lost.
When?
Same as source trigger
When radio link
between MN & nFA is
established
When radio link
between MN & oFA
is lost
Parameters
oFA IP address identifier
MN IP address identifier
MN, nFA IP or L2
address
MN IP address
identifer
POST
Target
trigger
100
More on PRE-Registration (1)
• L2 triggers (L2-MT, L2-ST) initiate this type
• MN registers in advance (I.e. before it moves to new
wireless network) with nFA
• TCP connection exists through a oFA<->nFA tunnel
to nFA until MN actually moved to network served via
nFA
• Until the MN actually completes the L2 handoff to the
new FA and establishes the new L2 link, the new FA
can receive packets for which it does not have a link
layer connection.
101
More on PRE-Registration (2)
•
•
•
PRE-REGISTRATION won’t work unless the FA or MN are able to obtain an L2
trigger that indicates pending L2 handoff
The L2 trigger must allow enough time for the PRE-REGISTRATION handoff
procedure to be performed.
The PRE-REGISTRATION Handoff method is applicable in the following cases:
–
–
–
when the MN has locally defined policies that determine a preference for one access
over another, for example due to service cost within the same or different technology,
and therefore where it is necessary to allow the MN to select the appropriate FA with
which to connect,
when L2 security between the MN and the FA is either not present or cannot be relied
upon to provide adequate security,
when the trigger to initiate the handoff is received at the MN
– scenarios where a period of service disruption due to layer 3 is not
acceptable, e.g. performing real-time communications
102
PRE-REGISTRATION – FA solicitations of adverts #1
#2
nFa
#3
nFa
Ha
Router Soliciatation
oFa
#1
nFa
#4
nFa
MN
The oFA that is currently serving the
network that the MN polls FA’s in
adjacent networks for their information.
The TTL in the Router Solicitation = 1 so
only adjacent FA’s are polled.
103
PRE-REGISTRATION – current FA RT Adverts back
The FA that is currently serving the
network that the MN is in caches all the
most current Router Advertisements
from surrounding FA’s. This is done
periodically with the minimum
requirement being every one second.
Also note that the cached
Advertisements contain link-layer
extensions of one type or another.
Router Advertisements are also sent
with a TTL = 1.
#2
nFa
#3
nFa
Ha
Router Advertisement #4 + LLE
oFa
#1
nFa
#4
nFa
Cache:
#1 nFa advert
…
#4 nFa advert
MN
104
PRE-REGISTRATION variations on the
standard MIP messages
• An MN, in MIPv4, sends a Router Solicitation directly to an FA to
begin the registration process. However for a Mobile Initiated
PRE-REGISTRATION, the MN sends a ProxyRouterSolicitation
to the oFA about the nFA.
• In the case of network initiated PRE-REGISTRATION, the MN
received a ProxyRouterAdverstisement for the nFA through the
oFA. This ProxyRouterAdvertisement contains the nFA’s layer 2
address in a Generalized Link Layer Extension
• Note that the “proxy” here is the oFA and the MN is registering
with an FA which is not only one hop away, thus need some
other way to send addresses then in layer 2 or layer 3 data
packets. Hence the use of GLLEs.
105
L2 address and Link Layer Extenstions
Generalized Link Layer Extensions have a generic format as follows:
Type Length Sub-Type Identifier (1-7)
LLA
The actual data corresponding to the Identifier:
e.g. IMSI, IMSI, MAC, MAC, IP, AP, IP
1
2
3
4
5
6
7
Link Layer Sub-Type ID
3GPP2 International Mobile Station Identity & Connection ID
3GPP International Mobile Subscriber Identity
Ethernet 48 bit MAC address [5]
64 bit Global ID, EUI-64 [6]
Solicited IP Address
Access Point Identifier
FA IP Address
Note in the following diagrams, IP addresses are indicated, but in reality,
any identifier as mentioned above can be used in the LLE’s
106
PRE-REGISTRATION – current oFA RT Adverts back
(network initiated source trigger L2-ST)
Got an L2-ST signal!
MN moving to #4
network – got nFA
IP and MN IP from
the L2-ST
Buffer this
reply and start
buffering data
too, no L2 yet!!
Registration Request to nFa #4 – oFA has nFA’s IP address
MN
Agent Solicitation to nFa #4 or L2-UP
Time between L2 trigger at oFA & actual L2 handoff
(1st 4 messages) is crucial. If not possible MN may
set “S” bit in Registration Request to allow reception
of packets from both oFA and nFA. This applies to
this and following scenarios.
#4
nFa
Registration Reply + Data packets
ProxyRouterAdvertisement nFa #4 +LLE
Also, the TTL of this Advertisement = 1
Got an L2-UP
signal! From
MN – start
sending
oFa
Registration Requdest to nFa #4
Cache:
#1 nFa advert
…
#4 nFa advert
X
Ha
MN
MN is moving
107
PRE-REGISTRATION – current FA RT Adverts back
(network initiated target trigger L2-TT)
Buffer this reply
and start
buffering data
too, no L2 yet !!
X
Got an L2-TT
signal w/ MN
& oFA IP’s. MN
moving my
network, send
an advert to
the MN’s IP
Ha
Tunnel Agent Advertisement to MN – MUST BE AUTHENTICATED
Cache:
#1 nFa advert
…
#4 nFa advert
Registration Request to nFa #4
#4
nFa
Agent Solicitation to nFa #4
MN
Registration Reply + Data packets
ProxyRouterAdvertisement nFa #4
Registration Requdest to nFa #4
oFa
MN
MN is moving
108
PRE-REGISTRATION – current FA RT Adverts back
(mobile initiated L2-MT)
X
Buffer this
reply and start
buffering data
too
Registration Request to nFa #4
Cache:
#1 nFa advert
…
#4 nFa advert
#4
nFa
Registration Requdest to nFa #4
Registration Reply + Data packets
ProxyRouterSolicitation nFa #4 IP
oFa
ProxyRouterAdvertisement nFa #4
Got a L2-MT signal it
has nFA’s IP address,
moving to #4 – have to
solicit registration with
that nFA
Ha
MN
MN
MN is moving
109
PRE-REGISTRATION – Security Considerations
(L2 Address)
Ha
Registration Request to nFa #4
Cache:
#1 nFa advert
…
#4 nFa advert
Registration Requdest to nFa #4
All FAs involved in PRE-REGISTRATION handoffs
MUST HAVE security associations with other
neighboring FA’s to authenticate and protect the
integrity of them and to allow solicitations
between them.
A FA must not accept solictations or advertisements
from sources that are not authenticated.
Got a L2-MT
signal, moving
to #4 – have
to register!
#4
nFa
Registration Reply + Data packets
ProxyRouterAdvertisement nFa #4
ProxyRouterSolicitation nFa #4
oFa
MN
MN
MN is moving
110
POST-Registration Handoffs
•
•
•
•
•
Recall: L2 latency still exists, but the Advertisement and Registration latency is
dealt with after handoff
L2 actually becomes disconnected, L3 persists
method uses bi-directional edge tunnels (BETs) or unidirectional tunnels to
transfer data between the oFA and nFA while performing a low latency change in
the L2 point of attachment for the MN without requiring any involvement by the
MN
oFA becomes the anchorFA and MN still uses it even after hand off
MN is still actually registered with oFA the whole time
111
More on POST-Registration
•
•
•
•
allows FAs to communicate directly about a pending handoff,
best for technologies where the link layer imposes hard deadlines on handoff
time windows
This makes POST-REGISTRATION best for handoffs between FAs that support
the same radio access technology
POST-REGISTRATION handoff is appropriate in the following cases:
–
–
–
L2 triggers are available on the network to indicate that L2 handoff is pending.
Pre-provisioned security mechanisms are in place to allow fast and secure messaging
between the FAs and between the MN and an FA.
Access point choice by the MN is not a concern or choice requires user intervention
and therefore is not on the critical path for handoff.
112
POST-Registration new messages – Handoff Request
• Message and field definitions
H=0 & N=0 & R=1, then this is a
request to renew the tunnel
Source or Target triggers
handoff request
H = 1 & N = 0, L2-ST at oFA
H = 0 & N = 1, L2-TT at nFA
Type
M=1, sending FA will use Minimal Encapsulation at tunnel
G=1, FA sending message will use GRE Encapsualtion
for tunnel
T=1: HRqst(s) – oFA supports both fwd and rev tunnel
HRqst(t) – nFA requesting reverse tunnel service
B=1: HRqst(s) only, MN request for nFA to use
reverse tunnel to HA if nFA will not reverse tunnel
to oFA
HNRMGTB
Lifetime – seconds of life for tunnel service for MN.
Reserved
Context is as follows:
Reserved
HRqst(t): lifetime requested by nFA for reverse tunnel, 0 = reverse tunnel uneeded
HRqst(s): max time oFA will maintain reverse and forward tunnel, 0= refusal to tunnel
HRqst<r>: renewal for indicated lifetime, 0 = terminate tunnel immediately
MN Home Address: HRqst(s), the home address of the MN
HA Address: HRqst(s), the HA address of the mobile node
Identification
Extensions … needs LLA + MN's L2 address
113
POST-Registration new messages – Handoff Reply
• Message and field definitions
M=1, sending FA will use Minimal Encapsulation at tunnel
H=0 & N=0 & R=1, then this is a
request to renew the tunnel
G=1, FA sending message will use GRE Encapsualtion
for tunnel
T=1: HRply(s) – nFA requesting reverse tunnel service
HRply(t) – oFA provides both fwd & rev tunnel
H = 1 & N = 0, this is reply to HRqst(s)
H = 0 & N = 1, this is reply to HRqst(t)
Type
B=1: HRply(t) only, MN request for nFA to use reverse
tunnel to HA if nFA will not reverse tunnel to oFA, this
can only be sent if T bit not sent in HRqst(t)
HNRMGTB
Reserved Code –
0 = handoff request OK,
1= handoff cannot be
perfomed
Lifetime - seconds of life for bi-directional tunnel for MN.
Reserved
HRply(t): max time oFA will grant to nFA
HRply(s): lifetime requested by nFA, less then max sent in HRqst
Hrply{r}: amount of time tunnel life will be extended
MN Home Address: HRply(t), the home address of the MN
HA Address: HRply(t), the HA address of the mobile node
Identification
Extensions: FA-FA Authentication Extension used to secure the HRply message
114
POST-Registration new messages – Handoff To Third
• Message and field definitions – same as HRqst & HRply with a few differences
– If HTT sent in response to L2-ST to initiate a handoff, fields & extensions
are the same as a HRqst(s)
– If HTT sent in response to L2-TT to initiate a handoff, fields & extensions
are the same as a HRqst(t)
Tunnel bits are never set in all cases !!
H = 1 & N = 1 are always set
in all cases !!
Type
Lifetime -
HNRMGTB
seconds of life for bi-directional tunnel for MN
Reserved
Code
Reserved
MN Home Address
HA Address
Identification
Solicited IP Address Option: containing aFA's Address &
LLA Option: containing the L2 address of the MN Extensions
115
POST-Registration L2-ST at oFA
Ha
MN moving to new
network. Got a L2-ST
signal, contains MN’s L2
address and nFA
identifier (IP or other)
Handoff Rqst H=1, N=0, lifetime, HA & MN’s IP, LLA w/ MN’s L2 addr
Handoff Reply, H=0, N=0, R=0, if T=1, rev tunnel duration=lifetime
MN L2-LD signal that
MN is not connected
start tunnel & send data
via nFa
nFa
oFa
Got a L2-LU signal
from MN start
delivering data
buffered and new
data
X
MN
MN
MN is moving
I am still taking to oFA,
but can re-register with
nfa if I want, if I do, nFA
become aFA. If I move
again without
registering, my oFA
becomes an aFA
116
POST-Registration L2-TT at nFA
Ha
MN moving to this
network. Got a L2-TT
signal, contains MN’s L2
address and oFA identifier
(IP or other)
Handoff Request, H=0, N=1, lifetime, LLA w/ MN’s L2 addr, T= rev tunnel req
Handoff Reply, N=1, H=0, R=0, if T=1, then tunnel duration=lifetime
MN L2-LD signal that
MN is not connected
start tunnel & send data
via nFa
nFa
oFa
Got a L2-LU signal
from MN start
delivering data
buffered and new
data
X
MN
MN
MN is moving
I am still taking to oFA,
but can re-register with
nfa if I want, if I do, nFA
become aFA. If I move
again without
registering, my oFA
becomes an aFA
117
POST-Registration – Security Considerations
Ha
Interesting issue because a MN will be receiving packets from
an FA that which it has never registered with. Messages
between oFA/aFA and nFA MUST also be authenticated.
All FAs involved in low latency handoffs MUST HAVE security
associations with other neighboring FA’s via a variety of
mechanisms (shared keys and such) that minimally must be
manually configured.
Got a L2-TT
signal, MN
moving to my
network
Handoff Request
Handoff Reply
MN L2-LD signal that
MN is not connected
start tunnel & send data
via nFa
nFa
oFa
Got a L2-LU signal
from MN start
delivering data
buffered and new
data
L2 triggers must also be
secured and guarentee
that both the L2
addresses and IP
addresses of the MN’s and
MN FA’s are authentic.
MN is moving
MN
I am still
taking to oFA,
but can reregister with
nfa if I want
118
POST-Registration 3rd party hand off
• MN has already established an aFA
• The aFA is not in the current or destination network
• MN retains L3 connection to aFA, so no L3 change
119
POST-Registration three party handoff L2-ST
Ha
aFa
Add message specific
Icons w/ bits
X
MN moving to new
network. Got a L2-ST
signal with MN’s IP and
nFA’s IP identifier.
MN L2-LD signal that
MN is not connected do
a HRqst(r ) to stop
tunnel from oFA to aFa.
NOTE: if tunnel from aFa
to nFa has not been
established yet, must do
immediately !
HTT received, am I
already tunneling for
this MN?
No: register with aFa
Yes: nFa = aFa so
after get L2-LU start
routing to MN
HTT w/ H=1, N=1, MN’s IP, MN’s HA IP, LLA w/MN L2, LLA w/ nFA IP
Handoff Reply(s)
nFa
oFa
Got a L2-LU signal
from MN start
delivering data
buffered and new
data
MN
MN
MN is moving
I am still
taking via aFA,
but can reregister with
nFa if I want
120
POST-Registration three party handoff L2-TT
HTT received, am I already
tunneling for this MN?
No: register with aFa
Yes: nFa = aFa so after get
L2-LU start routing to MN
Ha
aFa
Add message specific
Icons w/ bits
MN L2-LD signal that
MN is not connected do
a HRqst(r ) to stop
tunnel from oFA to aFa.
NOTE: if tunnel from aFa
to nFa has not been
established yet, must do
immediately !
MN moving to new
network. Got a L2-TT
signal with MN’s L2
addr and oFA’s IP
identifier.
X
Handoff Request(t)
HTT w/ H=1, N=1, MN’s IP, MN’s HA IP, LLA w/MN L2, LLA w/nFA IP
nFa
oFa
Got a L2-LU signal
from MN start
delivering data
buffered and new
data
MN
MN
MN is moving
I am still
taking via aFA,
but can reregister with
nFa if I want
121
Some notes on Tunneling service
• The MN’s current FA can signal the aFA to keep the BET alive by
renewal with no registration needed from the MN
• The aforementioned HRqst (r ) and Hrply(r ) messages are used
between FA’s for BET renewal and include the R (renewal) bit set
and a lifetime indicated
• However aFA always controlls the tunnel and can shorten the
requested lifetime or deny renewal
• The aFA will terminate the BET if the lifetime expires before a
renewal message arrives
122
Some notes on Mobile IP Registrations
• The MN’s current FA can also signal the aFA to cancel & terminate
the BET, if this is the case, the FA must start MIP registration with
the MN
• The MN should attempt to register with the nFA via an Agent
Solicitation before the lifetime expires or if a renewal of the BET is
denied
• The MN can also decide to do registration at any time by sending an
Agent solicitation
• MN must do registration if it receives an Agent Advertisement
123
One last option
• Uses both- Combined Handoff Method
• This method protects the MN from delays caused by errors such as
loss of one of the Mobile IP PRE-Reg messages
• Both PRE & POST started at same time
– Timer at nFA started on the PRE process after Registration Req
message
– if PRE can be done before timer pops for L2 handover
• then go with PRE Registration
– Otherwise nFA contacts oFA to automatically start forwarding
traffic to nFA to prepare for POST Registration
124
Summary Comparison
• The POST-REGISTRATION handoff
– approach allows FAs to communicate directly about a
pending handoff, same L3 link is used
– does not require any IP layer messages to be sent to or from
a MN prior to the L2 handoff event
– only L2 latency is seen during handoff procedure
– best between FAs that support the same radio access
technology where MN does not have to be involved
• PRE-REGISTRATION
– overlaps the L3 and L2 latencies and possibly already
redirects packets before the L2 link is down
– requires MN interaction with the network
– best for radio technologies that also require such interaction
– best for heterogeneous technology handoffs that require the
125
MN to participate
Performance Considerations
• Study [4] did a comparison that demonstrated:
• POST-REGISTRATION
– less loss packets then PRE-REGISTRATION
– some packets have slightly larger delays
– better suited to tight L2 trigger timing
– influence of the handoff on the stream’s delay starts later as
well as lasts longer ( i.e. packet loss and latency happen
later)
• PRE-REGISTRATION
– higher quantity of packets are lost
– fewer packets then POST-REGISTRATION experience
delay, but those late packets have very much higher delays
126
127
Registration
Registration
When the mobile node is away from home, it registers its care-ofaddress with its home agent. Mobile node registers it’s care-of-address each time it
changes its care-of-address.
Public IP network
(Eg., Internet, ISP)
Home Agent
Foreign Agent1
Foreign Agent2
Home Network
Visited Network
Disadvantages
If the distance between the visited network and the home network of
the mobile node is large the signaling delay for these registrations may be long. This
condition is worsen if the MN switches from one FA to another FA within the visited
network introducing unnecessary signaling delay for registrations with the home
agent.
128
Regional Registration
Regional Registration
Registration local to the visited domain. The regional registration is
performed via a new network entity called a Gateway foreign agent and introduces a
layer of hierarchy in the visited domain.
Public IP network
(Eg., Internet, ISP)
Gateway Foreign Agent
Home Agent
Foreign Agent1
Home Network
Foreign Agent2
Visited Network
Advantages
Regional Registration reduce the number of signaling messages to the home
network, and reduce the signaling delay when a mobile node moves from one foreign
agent to another within the same visited domain. This will both decrease the load on
the home network, and speed up the process of handover within the visited domain.129
Protocol Overview
Public IP network
(Eg., Internet, ISP)
GFA ADDRESS
Gateway Foreign Agent
Home Agent
Foreign Agent1
Home Network
Foreign Agent2
Visited Network
In case of regional registrations, the care-of-address that is registered at the home is
the address of a GFA. The GFA keeps a visitor list of all the mobile nodes currently
registered with it. Since the care-of-address registered at the home agent is the GFA
address, it will not change when the mobile node changes the foreign agent under the
same GFA. Thus, the home agent does not need to be informed of any further mobile
node movements within the visited domain.
130
Advertising Foreign Agent and GFA
Type
Length
Sequence Number
Gateway Foreign Agent
Life Time
Foreign Agent1
AAM
R B H FM GV T S
I reserved
Foreign Agent2
AAM
Visited Network
Zero or More Care-ofAddress
Flag I: This domain supports Regional Registration
If the ‘I’ flag is set, there must be at least one care-of-address in the agent
advertisement message, but that address may be set to “all ones” address.
If the ‘I’ flag is set, and there is only one care-of-address (which is not all ones), it is
the address of the FA.
If the ‘I’ flag is set, and there are multiple care-of-address, the first care-of-address is
the local FA, and the last care-of-address is the GFA.
Note: AAM is Agent advertisement message
131
Home Registration
MN Compares the domain part of the foreign agent NAI, from AAM, with the domain
part of its own NAI, to determine whether it is in its home domain or in a visited
domain.
Mobile node uses two messages to register with Home agent
Registration Request Message
Registration Reply Message
Registration Message extension
Mobile node can use any of the following address as the care-of-address:
FA as care-of-address
GFA as care-of-address
Co-located care-of-address
Zero’s as care-of-address
All one’s as care-of-address
132
Registration Request Message
Type
S B D M G r
T x
Life Time
Home Address
Home Agent
Care-of-Address
Identification
Extension……….
Type: TBD (Regional Registration Request)
Life Time: no of seconds the registration is valid, 0 means immediate deregistration and
All ones means infinite lifetime.
Home address: The IP address of the mobile node’s home agent.
Home agent: The IP address of the mobile node’s home agent.
Care-of Address: The IP address for the end of the tunnel.
133
Registration Reply Message
Type
Code
Life Time
Home Address
Home Agent
Identification
Extension……….
Type: TBD (Registration Reply)
Code: A value indicating the result of the registration request.
Life Time: If the code field indicates that the registration was accepted, the lifetime field is
set to the number of seconds remaining before the registration is considered
expired. A value of zero indicates that the mobile node has been de-registered.
A value of 0xffff indicates infinity.
Home address: The IP address of the mobile node’s home agent.
Home agent: The IP address of the mobile node’s home agent.
134
GFA IP Address Extension
Type
Length
GFA IP Address
GFA IP Address…..
Type: TBD (GFA IP address)
Length: 4
GFA IP Address: The GFA IP address
field contains the gateway foreign
agent’s publicly routable address.
The mobile node can request for a dynamically assigned GFA by sending a
registration request message with the care-of-address field set to zero.
If the mobile node requests a dynamically assigned GFA, the GFA adds a GFA
IP address extension to the RReqM before relaying it to the HA.
When Home agent receives a RReqM with care-of-address set to zero, and a
GFA IP address extension, it registers the GFA IP address as the care-ofaddress of the mobile node.
The home agent includes the GFA IP address in the RRpyM from the RReqM.
The GFA IP address appears before the mobile-home Authentication ext. in the
RRpyM
135
Hierarchical Foreign Agent Extension
Type
Length
FA IP Address
FA IP Address…..
Type: TBD (GFA IP address)
Length: 4
FA IP Address: The IP address of the
foreign agent relaying the RReqM
When this extension is added to a RReqM by a foreign agent, the receiving
mobility agent sets up a pending registration record for the mobile node, using
the IP address in the Hierarchical Foreign agent extension as the care-ofaddress for the mobile node.
The extension must be appended at the end of all previous extensions that had
been included in the registration message as received by the foreign agent.
The receiving foreign agent must remove the hierarchical foreign agent
extension added by the sending foreign agent in the RReqM.
The hierarchical foreign agent extension should be protected by a FA-FA
authentication extension.
136
MN using FA as care-of-address
Public IP network
(Eg., Internet, ISP)
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
Visited Network
Home Network
IF the care-of-address in the registration request is the address of the foreign agent, the
foreign agent relays the message directly to the home agent.
For each pending or current home registration, the foreign agent maintains a visitor list entry.
137
MN using GFA as care-of-address
Public IP network
(Eg., Internet, ISP)
RRP
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
Visited Network
Home Network
If the care-of address in the Registration Request is the address of a GFA (or
zero), the foreign agent adds a Hierarchical Foreign Agent extension, including
its own address, to the Registration Request message, and relays it to the GFA.
The Hierarchical Foreign Agent extension MUST be appended at the end of all
previous extensions that were included in the Registration Request message
when the foreign agent received it.
138
MN using GFA as care-of-address
(continued……)
If the Hierarchical Foreign Agent extension comes after the MN-FA authentication
extension, the GFA will remove it from the Registration Request message and then
sends the request to the home agent.
Upon receipt of the Registration Reply message, the GFA consults its pending
registration record to find the care-of address within its domain that is currently used
by the mobile node, and sends the Registration Reply to that care-of address.
139
MN using co-located care-of-address
Public IP network
(Eg., Internet, ISP)
RRP
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
Visited Network
Home Network
A mobile node with a co-located care-of address might also want to use Regional
Registrations.
The mobile node MAY then generate a Registration Request message, with the GFA
address in the care-of address field, and send it directly to the GFA (not via a foreign
agent).
In this case, the mobile node MUST add a Hierarchical Foreign Agent extension,
including its co-located care-of address, to the Registration Request before sending
it.
140
MN using co-located care-of-address
(continued……)
If the mobile node has established a mobility security association with the GFA, the
Hierarchical Foreign Agent extension will be placed after the MN-HA authentication
extension and before the MN-FA authentication extension. Otherwise the Hierarchical
Foreign Agent extension will be placed before the MN-HA authentication extension.
If the Replay extension is present in a home registration, and follows the MN-HA
authentication extension, the GFA will remove the Replay extension after performing
any necessary processing, before sending the home registration to the home agent.
141
MN using zero’s as care-of-address
Public IP network
(Eg., Internet, ISP)
RRP-W/ext
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
Visited Network
Home Network
When the mobile node requests that a GFA address is dynamically assigned to it by
setting the care-of-address in a registration request to zero, the mobile node and its
home agent must support the GFA IP address extension.
If the care-of address in the Registration Request is the address of a GFA (or zero),
the foreign agent adds a Hierarchical Foreign Agent extension, including its own
address, to the Registration Request message, and relays it to the GFA.
142
MN using zero’s as care-of-address
(continued…….)
The Hierarchical Foreign Agent extension MUST be appended at the end of all
previous extensions that were included in the Registration Request message when
the foreign agent received it.
If the care-of address field of the Registration Request is set to zero, the GFA assigns
a GFA care-of address for this Mobile Node, and adds a GFA IP Address extension
with this address to the Registration Request message and then sends the request to
the home agent.
143
MN using one’s as care-of-address
Public IP network
(Eg., Internet, ISP)
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
Visited Network
Home Network
A mobile node that doesn’t support regional registration copies an “all ones” in the
care-of-address from an advertisement.
If the foreign agent receives a registration request where the care-of-address is set to
“all ones”, it must reply with the code field set to “Poorly Formed Request”.
144
Regional Registration
Public IP network
(Eg., Internet, ISP)
GFA ADDRESS
Gateway Foreign Agent
Home Agent
Foreign Agent1
Foreign Agent2
RRRR
Home Network
Visited Network
Once the home agent has registered the GFA address as the care-of address of the
mobile node, the mobile node may perform regional registrations.
If the advertised GFA care-of address is the same as the one the mobile node
registered during its last home registration, or the realm part of the newly advertised
FA-NAI matches the FA-NAI advertised by the mobile nodes previous FA. Then the
mobile node can perform regional registration
145
Regional Registration (Continued…)
The mobile node issues a regional registration request message via the new foreign
agent.
The mobile node may register one of the following when performing regional
registration
FA as care-of-address
Co-located care-of-address
Zero’s as care-of-address
The new FA adds a Hierarchical foreign agent extension to the message and relays it
to the GFA, if it does not contain care-of-address in the regional registration request.
Based on the information in the hierarchical foreign agent extension, the GFA
updates the mobile node’s current point of attachment in its visitor list.
GFA then issues a regional registration reply to the mobile node via the foreign agent.
146
Regional Registration Request Message
Type
S B D M G r
T x
Lifetime
Home Address
GFA IP Address
Care-of-Address
Identification
Extension……….
Type: TBD (Regional Registration Request)
GFA IP address: The IP address of the gateway foreign agent.
Care-of Address: Care-of address of local foreign agent; May be set to all ones.
Extensions: For the Regional Registration Request, the Hierarchical foreign agent
extension is also an allowable extension in addition to those which are allowable for the
registration request message.
147
Regional Registration Reply Message
Type
Code
Lifetime
Home Address
Regional FA IP Address
Identification
Extension……….
Type: TBD (Regional Registration Reply)
Regional FA IP address: The IP address of the gateway foreign agent.
Extensions: The regional FA IP address is the address of the regional foreign agent
generating the regional registration reply message. For the two-level hierarchy, it may be
the address of the GFA. For more levels of hierarchy, it may be the address of an
intermediate RFA.
148
Mobile node consideration
The mobile node maintains the following information:
• The link-layer address of the foreign agent to which the Registration Request
was sent, if applicable,
• The IP destination address of the Registration Request
• The care-of address used in the registration
• The Identification value sent in the registration
• The originally requested Lifetime, and
• The remaining Lifetime of the pending registration.
• The GFA address
• The style of replay protection in use for the regional registration
• The Identification value for the regional registration.
149
Foreign agent consideration
When the foreign agent receives a Regional Registration Request message from a
mobile node, addressed to a GFA, it processes the message generally according to
the rules of processing a Registration Request message addressed to a home agent.
The only difference is that the GFA IP address field replaces the home agent address
field. If that address belongs to a known GFA, the foreign agent forwards the request
to the indicated GFA. Otherwise, the foreign agent will generate a Regional
Registration Reply with error code UNKNOWN_GFA.
For each pending or current registration, the foreign agent maintains a visitor list
entry.
150
GFA consideration
If the GFA accepts a request for regional registration, it MUST set the lifetime to be
no greater than the remaining lifetime of the mobile node's registration with its home
agent, and put this lifetime into the corresponding Regional Registration Reply.
The GFA MUST NOT accept a request for a regional registration if the lifetime of the
mobile node's registration with its home agent has expired. In that case the GFA
sends a Regional Registration Reply with the value in the Code field set to
NO_HOME_REG.
If the GFA receives a tunneled packet from a foreign agent in its domain, then after
de-capsulation the GFA looks to see whether it has an entry in its visitor list for the
source IP address of the inner IP header after de-capsulation.
If so, then it checks the visitor list to see whether reverse tunneling has
been requested; if it was requested, the GFA re-encapsulates the packet
with its own address as the source IP address, and the address of the home
agent as the destination IP address.
151
152
The Idea
• Assign an optimal HA for a Mobile IP session.
153
1) If the distance between the visited network and the
home network of the mobile node is large, the
signaling delay for these registrations may be long.
2) In a large scale Mobile IP deployment, it is
cumbersome to provision MNs with multiple HA
addresses
3) To achieve some form of load balancing between
multiple HAs in the network.
154
The technique
• Proposing a messaging mechanism for
dynamic home agent assignment and
home agent redirection during initial
registration.
Redirected HA Extension
155
The technique
• Proposing a messaging mechanism for
dynamic home agent assignment and
home agent redirection during initial
registration.
Dynamic HA Extension
156
Problem Highlight
157
• Mobile IP requires that a Mobile Node (MN)
have a static Home Agent (HA) and a
permanent home IP address, which is not
always desirable for MNs, especially MNs in
a commercial ISP domain.
158
• Furthermore, for some big network
domains such as national wireless network
service providers, the MN’s current
network attach point could be far away
from the static HA and hence could cause
severe triangle routing problems.
159
• Finally, when a MN keeps migrating to a
nearby Foreign Agent (FA) if the MN is fast
moving, which is typical for wireless
network subscribers, the signaling with
the remote HA will cause an unacceptable
long delay.
160
Solution
161
Dynamic Home Agent Assignment
162
Dynamic Home Agent Assignment
Dynamic Home address Assignment
FA Pending registration request
NAI (Network Access Identifier)
163
Network Access Identifier
• For example using the user name as an Identifier.
164
Dynamic Home Agent Assignment
“The Gory Details”
• Mobile IPv4 discovers the mobile node's home agent using
subnet-directed broadcast IP address in the home agent field
of the Registration Request.
Drawbacks:
1) Assumes fixed network prefix and fixed home address
HA on Fixed Network Signaling delay can’t be avoided.
2)Some routers drop directed broadcast packets.
165
The Dynamic HA address
Extension
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type
| Sub-Type |
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
HA-Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Type:
sub-type 1 = Requested HA Extension
sub-type 2 = Redirected HA Extension
All-zero-one-Address: 255.255.255.255 indicates a preference for an HA in the home
domain. An address of 0.0.0.0 indicates no preference for home
vs. visited domain.
166
The Gory Details
• Messaging for dynamic HA assignment.
• Messaging for HA redirection.
167
Messaging for dynamic HA
assignment
1)
The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR.
If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in
the Registration Request.
2) The MN sets the Home Agent address field in the Registration Request to the HA address (instead of
setting it to ALL-ZERO-ONE-ADDR). The MN also adds the same HA address in the Requested HA
Extension in the Registration Request.
3) The MN sends the Registration Request to the "Requested HA". If the Requested HA Extension is
present, Requested HA is specified in the "HA Address" of this extension. The FA forwards the
Registration Request to the address in the HA field of the Request.
4) The "Requested HA" is the home agent that processes the Registration Request. It creates mobility
binding for successful Registration Request. It also sends a Registration Reply to the MN.
5) The MN obtains an "Assigned HA" address from the HA field in the successful Registration Reply and
uses it for the remainder of the session.
(Note that the "Assigned HA" will be same as the "Requested HA").
6) Subsequent Registration Request messages for renewal are sent to the Assigned HA.
168
Messaging for dynamic HA
assignment
MN
FA
Requested/Assigned
1
2
3
4
5
169
Messaging for HA redirection
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONEADDR.
2.
The MN sends the Registration Request to the "Requested HA". If the MN
is aware of an HA address, it can add that address in the Requested HA Extension in
Registration Request.
3.
When the HA receives the Registration Request, if the HA field is set to ALL-ZERO-ONE-ADDR,
the HA may reject the request with Reply code REDIRECT-HA-REQ and suggest an alternate HA.
If the HA rejects the Request, the HA field in the Reply is set to this HAs address. The IP address
of the HA that is the target of the redirection is specified in Redirected HA Extension.
The presence of this extension is mandatory when the reply code is set to REDIRECT-HA-REQ.
HA sends the Reply to the FA/MN.
4. FA sends the Reply to the MN.
5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA address from Redirected HA
Extension. The MN then sends a Registration Request to Redirected HA. The MN may choose to
add Requested HA extension in this new Registration Request.
170
Messaging for HA redirection
MN
FA
Requested/Assigned
Redirected HA
1
2
3
4
5
171
What if the mobile node is not
aware of desired HA Address
• This is solved by the presence of an AAA
server.
172
Advantages Dynamic Home Agent
Assignment
• Lower Signaling Delay.
• Automated operation of home address as
well as home agent address.
• Capabilities to specify priorities.
173
Security Considerations
174
The big picture
• Mobile computers will be connected to the network via
wireless links. Such links are particularly vulnerable to
passive eavesdropping, active replay attacks, and other
active attacks.
175
Message Authentication Codes
• Home Agents, Foreign Agent and Mobile node must be
able to perform authentication.
• Default Algorithm:HMAC-MD5 with key size 128 bits.
176
Key Management
• Key distribution without Network Key Management
Protocol.
• Not required for all messages between Mobile node and
Home Agent.
• Commercial Environment requires authentication of all
messages for billing and legitimacy purposes.
177
Picking a Good Random Number
• Strength Of an authentication mechanism depends on
the following factors:
1) Innate strength of the authentication algorithm.
2) The secrecy of the key.
Generated Randomly
3) The strength of the key.
178
Privacy
• Authentication not Encryption.
• Data Privacy: Use Encryption.
• Location Privacy: Use Tunneling.
179
Replay Protection for Registration
Requests
180
Replay Protection for Registration
Requests
•
•
Two methods for generating the Identification
field:
1) Timestamps (mandatory)
2) “Nonces” (optional)
Low order 32-bits copied from registration
request to Registration reply for matching
purposes.
181
Timestamps
• Generating node inserts current time of day.
• Receiving node checks the timestamp to calculate the
difference.
• Synchronized time of day clocks.
• Synchronization of clocks must also be authenticated.
• NTP is a protocol designed to synchronize the clocks of
computers over a network.
• Lower order 32 bits are filled from the timestamp.
• Higher order 32 bits are filled randomly.
182
183
“Nonces”
• Source node “A” generates a new random number and
expects the destination node “B” to return the same
number in the reply and vice versa.
• Most use authentication code to protect against
alteration.
184
Intersting Link:
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
185
Thank You
186
[RP1994]
Reynolds, J., Postel J., “Assigned Numbers” STD 2, RFC 1700,
October 1994.
[COM2000] Comer, Douglas, “Mobile IP” in Internetworking with TCP/IP, Vol 1,
ed. Prentice Hall, New Jersey, 2000, p. 377-386
[KOR2002] Körpeoğlu, Ibrahim,
http://www.cs.bilkent.edu.tr/~korpe/courses/cs515-fall2002 , 2002.
[PER2002] Perkins, Ed., “IP Mobility Support for IPv4”, RFC 3344, August 2002.
[PIL2004] Pillai, Krish, Lecture on “Mobile IP” as part of the class
Internetworking Protocols and Programming.
[1] C. Perkins, Ed, “IP Mobility Support for IPv4”, RFC 3344, August 2002
[2] K. El Malki (editor), “Low Latency Handoffs in Mobile IPv4”,draft-ietf-mobileip-lowlatency-handoffs-v407.txt, October 2003.
[3] Nat Natarajan, “Support of Layer 2 Triggers for Faster Handoffs”, IEEE802.20-3-107.pdf
[4] C. Blondiaa, O. Casalsb, Ll. Cerdàb, N. Van den Wijngaerta, G. Willemsa, P. De Cleyna,
“Performance Comparison of Low Latency Mobile IP schemes”
[HLK2002] Harte, Lawrence, Levine, Richard, Kikta, Roman, “Handoff” in
3G Wireless Demystified, ed. McGraw-Hill, New York, 2002, p 50.
187