HMIPv6

Hierarchical Mobile IPv6 Mobility Management

Byung-Jin Han
Internet Management Technology Lab. School of Information & Communication Engineering, h l f f i i i i i Sungkyunkwan Univ. 300 Cheoncheon-dong, Jangan-gu, Suwon-si, Gyeonggi-do, Korea. Tel : +82-31-290-7222, Fax : +82-31-299-6673 bjhan@imtl.skku.ac.kr

Contents
Introduction Terminology Overview of HMIPv6 Mobile IPv6 Extension Neighbor Discovery Extension g y Protocol Operation MAP Discovery Updating Previous MAPs Detection and Recovery from MAP Failures Security Considerations References

Introduction
Hierarchical Mobile IPv6
Utilizing a new node called the Mobility Anchor Point (MAP)

Limitation of MIPv6
MIPv6 allows nodes to move within the Internet topology while maintaining reachability and on-going connections between MN and CNs. CN
To do this a MN sends BUs to its HA and all CNs, every time it moves

MAP help to reduce additional delay

Eliminating additional delay from the time critical handover period Significantly improve the performance In wireless links, reduces the number of message

Introduction
Location of MAP
MAP can be located at any level in a hierarchical network of routers (include AR)

Solution with MAP

The MN sends BU to the local MAP rather than the HA and CNs The MN sends only one BU to MAP rather than the number of CNs times

Aim of Hierarchical Mobility Management Model y g

A MAP is essentially a local HA Enhancing the performance of MIPv6
While minimizing the impact on MIPv6 or other IPv6 protocols

Support FMIPv6 for achieving seamless mobility Allows MNs to hide their location from CNs and HAs while using route optimization

Terminology
Access Router
The AR is the MNs default router The AR aggregates the outbound traffic of MNs gg g

Mobility Anchor Point (MAP)

A router located in a network visited by the mobile node The MAP is used by the MN as a local HA One or more MAPs can exist within a visited network

Regional Care-of Address (RCoA)

An RCoA is an address on the MAPs subnet Auto-configured by the MN when receiving the MAP option

HMIPv6-aware Mobile Node

An MN that can receive and process the MAP option and send local binding update (BU with the M flag)

On-link Care-of Address (LCoA)

Simply referred as the CoA but used to distinguish it from RCoA

Local Binding Update

The MN sends a Local Binding Update to the MAP Establish a binding between the RCoA and LCoA
5

Overview of HMIPv6
HMIPv6 scheme introduces a new function
The MAP and minor extensions to the MN operation

Overview
An MN entering a MAP domain will receive RA containing information on one ore more local MAPs
The MN can bind its LCoA with RCoA h b d h MAP acting as a local HA

If the MN changes its current address with in a local MAP domain (LCoA)
It only needs to register the new address with MAP l d t i t th dd ith Only RCoA need to be registered with CN and HA

MAP domains boundaries are defined by the ARs advertising the MAP information to the attached MNs HMIPv6 is simply an extension of MIPv6
MAP HMIPv6-aware MN HMIP 6

HMIPv6 Operation
HMIPv6 Operation

HA Internet

CN

HA Internet

CN

MN (HoA) ( )

MN (HoA) ( )

Handoff

Handoff MAP

AR1

AR2

AR1

AR2

MN (CoA1) Handoff < MIPv6 >

MN (CoA2)

MN (LCoA1,RCoA) Handoff < HMIPv6 >

MN (LCoA2,RCoA)

HMIPv6 Operation
New RA option
MN will discover the global address of the MAP New option contain this information (MAP option) Also inform distance of the MAP from MN

MAP discovery
Every time the MN detects movement
It will also detect whether it is still in the same MAP domain RA used to detect movement via MAP option When change MAP address MN change MAP by sending BU to its HA and CNs

Local Binding Update

RCoA used as local HoA Src = LCoA, Dst = MAP, Addr in HoA Dst Option = RCoA MAP store this information in its Binding Cache
Use for forward packet to MN from HA for CNs

MAP does not modify the contents of the original packet

Route ti i ti i b il bl R t optimization is abailable
8

Mobile IPv6 Extensions

Local Binding Update
Added

Sequence # Reserved Mobility Options Lifetime

A H L K M

M bit
If set to 1 it indicates a MAP registration

When MN registers with the MAP

M and A flags MUST be set to distinguish BU to HA or CNs

Neighbour Discovery Extension

MAP option message format (RA message)
Type Length Dist Pref R Reserved

Valid Lifetime Global IP Address for MAP

Type
IPv6 Neighbor Discovery option : 23

Dist
4-bit unsigned integer identifying the distance between MAP and the receiver Default 1, it does not mean hops

R
When set to 1, it indicates that the MN MUST from an RCoA based on the prefix in the MAP option

Global Address
One of the MAPs global addresses The 64-bit prefix extracted from this address MUST be configured in the MAP to be used for RCoA construction by the MN

10

Protocol Operation
Mobile Node Operation
When a MN moves into a new MAP domain
It needs to configure two CoAs An RCoA on the MAPs link and an on-link CoA (LCoA) The RCoA is formed in a stateless manner Local BU to the MAP with the A and M flags set After forming RCoA, MN send local BU Local BU include RCoA in Home Address Option No alternate-CoA option is need
S = LCoA D = MAP RCoA HoA Opt AH Hdr Payload Binding Update Option (Mobility Header)

This BU will bind RCoA and LCoA MAP perform DAD and return a BAck to MN BAck MUST with Type 2 Routing Header

Following successful registration with the MAP

A bi-directional tunnel between the MN and the MAP is established
S = LC A LCoA D = MAP ESP Hd Hdr S = RC A RCoA D = CN Payload P l d ESP Tail T il Auth A h

11

Protocol Operation
Mobile Node Operation
RCoA
Multiple RCoA is allowed and MUST BU for each RCoA MUST NOT use one RCoA (from MAP1) as a CoA in its BU to another MAP (MAP2) This would force packets to be encapsulated several times

Binding Update RCoA with HA and CNs g p

After registering with MAP, the MN MUST register its new RCoA with its HA and CNs
S = LCoA D = MAP ESP Hdr S = RCoA D = HA Payload ESP Tail Auth

S = RCoA

D = HA HoA

HoA Opt

ESP Hdr

Payload

ESP Tail

Auth

Binding U d t O ti Bi di Update Option (Mobility Header)

Handover between MAPs

A MN SHOULD send a local BU to its previous MAP, specifying its new LCoA MAP In order to speed up and reduce packet loss

Handover within MAP domain

Only register its new LCoA with its MAP RCoA does not change 12

Protocol Operation
Mobile Node Operation
Sending Packet to CNs
S = LCoA D = MAP ESP Hdr S = RCoA D = CN HoA Opt HoA Payload ESP Tail Auth

13

Protocol Operation
MAP Operation
The MAP act like a HA
It intercepts all packets addressed to registered MNs tunnels them to LCoA, which is stored in Binding Cache

A MAP has no knowledge of the MNs HoA Local BU

The MN will send a local BU to the MAP with M and A flags set This BU inform the MAP that MN has formed an RCoA If Successful the MAP Must return a BAck to the MN Identical to HA

MAP MUST be able to accept packets tunneled from the MN MAP intercepted packets addressed to the RCoA
Using proxy Neighbour Advertisement then encapsulated and routed to the MNs LCoA

MAP MAY be configured with the list

The list of valid on-link prefixes that MN can use to derive LCoAs This is useful for network operators to stop MN from continuing to use the MAP after moving to a different administrative domain Error code 129 (BAck) 14

Protocol Operation
Local Mobility Management Optimization with in a MAP Domain
For short-term communication in MIPv6
Particularly communication that may easily be retried upon failure MN MAY choose to directly use one of its CoA as the source of packet Does not requiring HoA destination option

For short-term communication in HMIPv6

MN can use its RCoA as the source of packet It provide local mobility movement, but global Is would be useful for several application (e.g. web browsing) This mechanism can provide A way of obtaining route optimization without BU to the CNs

Location Privacy L i Pi
In HMIPv6
An MN hides its LCoA from its CNs and its HA by using RCoA Tracking of a MN is difficult

15

MAP Discovery
MAP Discovery
Describes
How a MN obtains the MAP address and subnet Prefix How ARs in a domain discover MAPs

Dynamic MAP Discovery

Based on propagating the MAP option in Ras from the MAP to MN via certain routers Requirement Manual configuration of MAP Allowing the routers receiving the MAP option to propagate the option

RAs are used for Dynamic MAP Discovery by introducing new option AR is required to send the MAP option in its Ras
MAP option includes distance vector, preference, MAPs global IP p ,p , g

16

MAP Discovery
Dynamic MAP Discovery
The AR within a MAP domain
May be configured dynamically with the information related to the MAP options ARs may obtain this information by listening for RAs with MAP options

Each MAP in the network

Preference value Default 10 Needs to be configured with Distance is set to a default 1

Router receiving a RA with the MAP option

Increment the Distance field by one and re-send it If receiving router also MAP, send MAP options together If a router receive more than one MAP option for the same MAP from two different interfaces, it MUST choose smallest one

MAP nodes are able to

Change their preferences d namicall thei p efe ences dynamically Node overload or load sharing

17

MAP Discovery
Mobile Node Operation
An HMIPv6 aware MN
When Receives a RA, it should search for the MAP option An MN SHOULD register the highest preference value MAY choose MAP depend on Distance field Valid lifetime of zero mean MAP failure

An MN MUST store the received options

In order to choose at least one MAP to register with Storing the option will be compared to other option received later For the purpose of the movement detection algorithm

If the R flag is set (in RA)

The MN MUST use its RCoA as the HoA when performing the MAP registration (local BU)

An MN MAY
Choose to register with more than one MAP simultaneously Use both RCoA and LCoA as CoA simultaneously with different CNs

18

Updating Previous MAPs

BU to Previous MAPs
When an MN moves into a new MAP domain
The MN may send a BU to the previous MAP Request to forward packets addressed to the MNs new CoA

An Administrator
MAY restrict the MAP from forwarding packets to LCoAs outside the MAPs domain MAP s

RECOMMENDED
However, it is RECOMMENDED that MAPs be allowed to forward packets To LCoAs associated with some of the Ars in neighbouring MAP domain in same g g administrative domain

19

Note on MAP Selection by the MN

MAP Selection by the MN SHOULD be
Eager to perform new bindings Lazy in releasing existing bindings

MAP Selection in a Distributed-MAP Environment

One or more MAPs
Does not means hierarchical structure of MAPs Does means provide redundancy

MAP selection algorithm

1. 2. 3. 4. 4 5.

Receive and parse all MAP options Arrange MAPs in a descending order by furthest distance Select first MAP in list If either preference or lifetime fields are zero select the following zero, Repeat
MAP1

MAP2 is better than MAP1

MAP2

MAPs

20

Detection and Recovery from MAP Failure

MAP Failure
MAP can be seen as a local HA
Like a HA, MAP is a single point of failure

If a MAP fails
Its binding cache content will be lost Resulting in loss of connection between MN and CNs

May be avoid by
Using more than one MAP on same link Some form of context transfer protocol between them p

MN can detect MAP Failure

When it receives a RA containing a MAP option with lifetime of zero
The MN start the MAP discovery process and attempt to registered with another MAP If presence of a protocol that transfer binding cache entries and provide same prefix Would save MN from updating CNs and HA

ARs can perform Dynamic detection of MAP Failure

By sending ICMP Echo request message to the MAP regulary
If no response is received an AR may try to aggresively send echo request If no reply is received a MAP option may be sent with a vaild lifetime value of zero

21

Security Consideration
The security relationship between the MN and MAP
Must be strong It MUST involve
Mutual authentication Integrity protection Protection against replay attack Confidentiality May be needed for payload traffic Is not required for binding updates to the MAP

22

Security Consideration
MN-MAP security
Initial authorization MAY be needed
In order to allow an MN to use the MAPs forwarding service MAP s Specifically for the Service, not for the RCoA Authorizing a MN to use the MAP service Can be done based on the identity of the MN exchanged during SA negotiation The authorization may be granted based on the MNs identity or identity of CA (Certificate Authority) If MN has certificate signed by trusted entity, it would be sufficient for the MAP to authorize the use of its service

Initial authorization does not needed

For using RCoA Because the RCoA is temporary and is not bou d to a pa t cu a node ecause t e Co s te po a y a d s ot bound particular ode MN does not have to initially prove that is owns its RCoA when it establish SA with MAP A MAP only need to ensure that A BU for a particular RCoA was issued by the same MN that established the SA for f ti l RC A i d b th th t t bli h d th f that SA

23

Security Consideration
MN-MAP security (contd)
The MAP does not need to have prior knowledge
the identity of MN nor its HoA As a result the SA between the MN and the MAP can be established using any key establishment protocols such as IKE

The MAP needs to set the SA for the RCoA

This can be IKE Identical step for HoA in IKE

If a binding cache entry already exists for a particular RCoA

No new SA should be established for such RCoA This prevents the mobile node from being able to re-establish a SA for the same RCoA

24

Security Consideration
MN CN security
HMIPv6 not impact to RR procedure
But careful In HOTI and COTI message Source address is HoA
S= LCoA D= MAP ESP Hdr S= RCoA D= HA ESP Hdr HOTI S= HoA D= CN Payy load ESP Tail Auth ESP Tail Auth

S= LCoA

D= MAP

ESP Hdr

S= RCoA

D= CN

Payload

ESP Tail

Auth

COTI

25

References
H. Soliman et al., Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.

26