One document matched: draft-ietf-mobileip-hmipv6-01.txt
Differences from draft-ietf-mobileip-hmipv6-00.txt
IETF Mobile IP Working Group Hesham Soliman, Ericsson
INTERNET-DRAFT Claude Castelluccia, INRIA
Karim El-Malki, Ericsson
Ludovic Bellier, INRIA
September, 2000
Hierarchical MIPv6 mobility management
<draft-ietf-mobileip-hmipv6-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This draft introduces some extensions for MIPv6 and neighbour
discovery to allow for the introduction of a hierarchical MIPv6
mobility management model. The proposed hierarchical mobility
management for MIPv6 will reduce the amount of signalling to CNs and
the HA and may also improve the performance of MIPv6 in terms of
handoff speed. Moreover, HMIPv6 is well-suited to implement access
control and handoffs between different access technologies.
Soliman, Castelluccia, El-Malki, Bellier [Page 1]
INTERNET-DRAFT HMIPv6 ****,2000
TABLE OF CONTENTS
1. Introduction.............................................3
2. Overview of HMIPv6.......................................3
3. Neighbour Discovery extension - MAP option message ......7
4. MIPv6 extension - BU extension ..........................8
5. Basic mode: Supporting MNs with a Regional COA (RCOA)....8
5.1 MN Operations........................................9
5.2 MAP operations.......................................9
5.3 HA operations.......................................10
5.4 CN operations.......................................10
6. Extended mode: Using the MAP COA as an alternate-COA....10
6.1 MN Operations.......................................11
6.2 MAP operations......................................12
6.3 HA operations.......................................12
6.4 CN operations.......................................13
7. Comparison between the two MAP modes....................13
8. MAP Discovery...........................................14
8.1 Dynamic MAP discovery ............................15
8.2 Using Router Renumbering for MAP discovery........15
8.3 New Destination option for MAP discovery..........16
8.4 MN operations.....................................17
9. Smooth Handoffs.........................................18
10. Notes on MAP selection by the MN........................19
11. Security Considerations.................................19
12. AAA Considerations for IPv6.............................19
13. Acknowledgements........................................20
14. Notice Regarding Intellectual Property Rights...........20
15. References..............................................20
16. Appendix A: Future additions............................21
17. Authors' addresses......................................21
Soliman, Castelluccia, El-Malki, Bellier [Page 2]
INTERNET-DRAFT HMIPv6 ****,2000
1. Introduction
This draft introduces the concept of a Hierarchical Mobile IPv6
network, utilizing a new node called the Mobility Anchor Point (MAP).
In Mobile IPv6 there are no Foreign Agents, but there is still the
need to provide a central point to assist with MIP handoffs.
Similarly to MIPv4, Mobile IPv6 can benefit from reduced mobility
signalling with external networks by employing a local hierarchical
structure. For this reason a new Mobile IPv6 node, called the
Mobility Anchor Point (MAP), is used and can be located at any level
in a hierarchical Mobile IPv6 network including the Access Router
(AR). Unlike FAs in IPv4, a MAP is not required on each subnet. Two
different MAP modes are proposed in this memo. A MN may use a MAP's
address as an alternate-care-of address (COA) (Extended mode) or form
a Regional COA (RCOA) on the MAP's subnet (Basic mode) while roaming
within a hierarchical (MAP) domain, where such a domain involves all
access routers advertising that MAP. The two options are described in
detail in chapters 5 and 6.
The MAP will limit the amount of Mobile IPv6 signalling outside the
domain and will support Fast Handoffs to help Mobile Nodes in
achieving seamless mobility. Other advantages of the introduction of
the MAP functionality are covered in chapter 2.
The aim of introducing the hierarchical mobility management model in
MIPv6 is to enhance the network performance while minimising the
impact on MIPv6 or other IPv6 protocols.
This draft assumes the generic case of a scaleable multi-level
hierarchy.
2. Overview of HMIPv6
This hierarchical MIPv6 scheme introduces a new function, the
Mobility Anchor Point(MAP), and minor extensions to the MN and the
Home Agent operations. The CN operation will not be affected.
The introduction of the MAP concept minimises the latency due to
handoffs between access routers. Furthermore, the addition of
bicasting to a MAP allows for Fast Handoffs [4] which will minimise
the packet losses due to handoffs and consequently improve the
throughput of best effort services and performance of real time data
services over a radio interface. Just like MIPv6, this solution is
independent of the underlying access technology, allowing Fast
Handoffs within, or between, different types of access networks.
Furthermore, a smooth architectural migration can be achieved from
Hierarchical MIPv4 networks, since a dual operation of IPv4 and IPv6
Hierarchies will be possible making use of the similarity in
architecture.
Soliman, Castelluccia, El-Malki, Bellier [Page 3]
INTERNET-DRAFT HMIPv6 ****,2000
The introduction of the MAP concept will further diminish signalling
generated by MIPv6 over a radio interface. This is due to the fact
that a MN only needs to perform one local BU (MAP) when changing its
layer 3 access point within the MAP domain. The advantage can be
easily seen when compared to other scenarios (no MAP) where at least
two BUs (Binding Updates) will be sent (to one CN and HA). A MAP may
also interact with the AAA protocol to perform key distribution
during handoffs and eliminate the need for re-authentication as
explained in chapter 11.
The MAP will receive all packets on behalf of the MN it is serving
and will encapsulate and forward them directly to the MN's current
address. If the MN changes its current address within a local MAP
domain, it only needs to register the new address with the MAP (since
the global CoA does not change).
This makes the MN's mobility transparent to the CNs it is
communicating with. The MAP can also be used to execute a Fast
Handoff between ARs as explained in [4].
When the MN uses a RCoA, a MAP acts essentially as a local Home Agent
(HA) for the MN. A MAP domain's boundaries are defined by the Access
Routers (ARs) advertising the MAP information to the attached Mobile
Nodes. The control of a MAP's mode of operation (as an alternate-CoA
or a local HA) is left to the network administrator's discretion.
The detailed extensions to MIPv6 and operations of the different
nodes will be explained later in this document.
It should be noted that the MAP concept is simply an extension to the
MIPv6 protocol. Hence an HMIPv6-aware MN with an implementation of
MIPv6 MAY choose to use the MAP or simply use the standard MIPv6
implementation as it sees fit. Furthermore, a MN can at any time stop
using the MAP. This provides great flexibility, both from a MN or a
network operations point of view.
The network architecture shown below illustrates an example of the
use of the MAP in a foreign network.
Soliman, Castelluccia, El-Malki, Bellier [Page 4]
INTERNET-DRAFT HMIPv6 ****,2000
_______
| HA |
|_______| _______
\ | CN |
\ |_______|
\___ |
\ |
\ ____|
_\___|_
| |
| MAP |
|_______|
/ \
/ \
/ \
/ \
____/____ \_________
| | | |
| AR1/MAP | | AR2/MAP |
|_________| |_________|
| |
| |
__\/____ \/
| |
| MN |
|________|
__________________\
Movement /
Figure 1: Hierarchical MIPv6 domain
In Figure 1, the MAP can help in providing seamless mobility for the
MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2),
while communicating with the CN. It is possible to use multi-level
hierarchies of routers and implement the MAP functionality in AR1 and
AR2 if needed. It should be noted that AR1 and AR2 could be two
points of attachment in the same RAN (Radio Access Network) or in
different RANs.
Upon arrival in a foreign domain, the MN will discover the global
address of the MAP. This address is stored in the Access Routers
and communicated to the MN via Router Advertisements. The discovery
phase will also inform the MN of the distance of the MAP from the MN.
For example, the MAP could also be implemented in AR1 and AR2, in
which case the MN can choose the first hop MAP, second hop MAP, or
both.
A Router advertisement extension is proposed later in this document
for MAP discovery.Router Renumbering [5] is also proposed for MAP
discovery as shown below. If a router advertisement is used for MAP
Soliman, Castelluccia, El-Malki, Bellier [Page 5]
INTERNET-DRAFT HMIPv6 ****,2000
discovery, as described in this document, all ARs belonging to the
MAP domain MUST advertise the MAP's IP address. The same concept
should be used if other methods of MAP discovery are introduced in
future. The MAP option in the router advertisement should inform the
MN about the chosen mode of operation for the MAP.
The process of MAP discovery continues as the MN moves from one
subnet to the next. As the MN roams within a MAP's domain, the same
information announcing the MAP should be received. If a change in the
advertised MAP's address is received, the MN should act on the change
by sending the necessary Binding Updates to its HA and CNs.
If the MN is not HMIPv6-aware then the discovery phase will fail
resulting in the MN using the MIPv6 [1] protocol for its mobility
management. On the other hand, if the MN is HMIPv6-aware it MAY
choose to use its HMIPv6 implementation. If so, the MN will first
need to register with a MAP by sending it a BU containing its Home
Address and on-link address (LCOA). In the case where the MN uses the
MAP as an alternate-COA, the Home address used in the BU is the MNs
Home Address on its home subnet. On the other hand, if the MN is
using a Regional COA (RCOA), the Home address used in the BU is the
RCOA. The MAP MUST store this information in its Binding Cache to be
able to forward packets to their final destination when received from
the different CNs or HAs.
The MN will always need to know the original sender of any received
packets. In the case where the MAP is used as an alternate-COA, all
packets will be tunnelled by the MAP, hence the MN is not always able
to determine whether the packets were originally tunnelled from the
Home Agent or received directly from a CN. This knowledge is needed
by the MN to decide whether a BU needs to be sent to a CN in order to
initiate route optimisation. For this purpose a check needs to be
performed on the internal packet's routing header to find out whether
the packet was tunnelled by the HA or originated from a CN using
route optimisation instead. If a routing header exists in the
internal packet, containing its alternate-COA (MAP address or RCOA)
and the MN's Home Address as the final destination, then route
optimisation was used. Otherwise, triangular routing through the HA
was used. This check on the routing header (as opposed to the check
on the source of the tunnelled packets in [1]) can be used for both
modes of operation as well as the standard operation described in
[1].
To use the network bandwidth in a more efficient manner, a MN may
decide to register with more than one MAP simultaneously and use each
MAP address for a specific group of CNs. For example, in Fig 1, if
the CN happens to exist on the same link as the MN, it would be more
efficient to use the first hop MAP (in this case assume it is AR1)
for communication between them. This will avoid sending all packets
via the "highest" MAP in the hierarchy and hence result in a more
efficient usage of network bandwidth. The MN can also use its current
Soliman, Castelluccia, El-Malki, Bellier [Page 6]
INTERNET-DRAFT HMIPv6 ****,2000
on-link address (LCOA) as a COA.
3. Neighbour Discovery extension - The MAP option message format
The following figure illustrates the new MAP option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Distance | Pref |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Plen |R|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirements for this option is 8n.
Fields:
Type Message type. TBA.
Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The value 0 is invalid.
Nodes MUST silently discard an ND packet that
contains an option with length zero.
Distance An 8 bit unsigned integer showing the distance
from the receiver of the advertisement. It
MUST be set to one in the initial
advertisement, if dynamic MAP discovery is
used.
Pref The preference of a MAP. An 8 bit unsigned
integer. A value of 255 means lowest
preference.
Plen The prefix length in this option. The prefix
length in this option. A prefix length value
of 128 indicates that the MAP address should
be used as an alternate-COA. A prefix length
Soliman, Castelluccia, El-Malki, Bellier [Page 7]
INTERNET-DRAFT HMIPv6 ****,2000
value different from 128 indicates that the MN
should configure its RCoA using the prefix
lenght and the MAP address.
R Indicates that the MN MUST form a RCOA. If
this flag is set the Plen value MUST be less
than 128.
M Indicates that the MN MUST use the MAP's
Own IP address as an alternate-COA
Global Address One of the MAP's global addresses.
To ensure a secure communication between routers, router
advertisements containing the MAP option SHOULD be authenticated by
AH. In the case where this authentication is not possible, a network
operator may prefer to manually configure all the ARs to send the MAP
option.
4. MIPv6 extension - Binding Update
This section outlines the extensions proposed to the BU option used
by the MN in MIPv6. A new flag is added: the M flag that indicates
MAP registration. When a MN registers with the MAP, the M flag MUST
be set to distinguish this registration from a Home Registration or a
BU being sent to a CN.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D|M|B|Res| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Description of extensions to the BU option:
M If set indicates a MAP registration.
B When set indicates a request for bicasting all
packets to both COAs of the MN. This BU will add
another COA to the MAP's Binding Cache. This flag
MUST only be set if the M flag is set.
Res 2 bit reserved field
Soliman, Castelluccia, El-Malki, Bellier [Page 8]
INTERNET-DRAFT HMIPv6 ****,2000
5. Basic Mode: Supporting Mobile Nodes with a Regional COA (RCOA)
This section defines a basic mode of HMIPv6 that is required to
support Mobile Nodes.
In the basic mode, the MN would have two addresses, a RCOA on the
MAP's subnet and an on-link COA (LCOA). This RCOA is formed in a
stateless manner by combining the MAP's subnet prefix received in the
MAP option with the MNs interface identifier.
As illustrated in this section, the basic mode is very simple in the
sense that it only requires special treatment at the Mobile Nodes.
The HA is unchanged. The MAP is merely a "local" HA that maps the
MN's RCoA to an LCoA.
5.1 MN Operations
When a MN moves into a new MAP domain (i.e. its MAP changes), it
needs to get 2 COAs:
A global address in the MAP's subnet and an on-link one (LCoA). These
addresses maybe formed in a stateless or stateful manner.
After forming the RCOA, the MN sends a regular MIPv6 BU to the MAP
(it specifies its RCoA in the Home Address field. No alternate CoA
sub-option is used. The LCoA is used as the source address of the
BU).
This BU will bind the MN's RCOA (similar to a Home Address) to its
LCOA. The MAP (acting as a HA) will then perform DAD for the MN's
RCOA on its subnet. If successful, the MAP will return a Binding
Acknowlegement (BAck) to the MN indicating a successful registration.
Otherwise, the MAP MUST return a BAck with the appropriate fault
code. No new error codes are needed for this operation.
The MN MUST also register its new RCoA with its HA by sending a BU
that specifies the binding (RCoA, HomeAddress) as in MIPv6 (The home
address field of the BU is set to the Home Address. An alternate-CoA
suboption is used and set to the RCoA). It can also send a similar BU
(i.e. that specifies the binding between the Home Address and the
RCoA) to its current CNs.
The MN should wait for the BAck from the MAP before registering with
its HA. In order to speed up handoff between MAPs, a MN may send a BU
to its previous MAP specifying its new LCoA. Packets in transit that
reach the previous MAP are then forwarded to the new LCoA.
The MAP will receive packets addressed to the MN's RCOA (from the HA
or CNs). Packets will be tunnelled from the MAP to the MN's LCOA. The
MN will decapsulate the packets and process the packet in the normal
manner.
Soliman, Castelluccia, El-Malki, Bellier [Page 9]
INTERNET-DRAFT HMIPv6 ****,2000
When the MN moves locally (i.e. its MAP does not change), it MUST
only register its new LCoA with its MAP. In this case, the RCoA stays
unchanged.
Note a MN can send a BU containing its LCoA (instead of its RCoA)
with CNs who share the same link. Packets will then be routed
directly without going through the MAP.
5.2 MAP Operations
In this mode, a MAP acts exactly like a HA. It intercepts all the
packets addressed to the Mobile Nodes it serves and tunnelled them to
the corresponding LCoA.
In this scenario, a MAP would have no knowledge of the MN's Home
address. The MN will send a BU to the MAP with the M, A and D flags
set. The aim of this BU is to inform the MAP that the MN has formed a
RCOA (contained in the BU as a Home address) and request that a MAP
performs DAD on its behalf. This is identical to the HA operation in
[1]. If the operation was successful, the MAP MUST respond with a
BAck to the MN indicating a successful operation. Otherwise a BAck is
sent with the appropriate error code. No new error codes are
introduced for HMIPv6.
The MAP then acts as a proxy between the RCoA and the LCoA.
Packets addressed to the RCOA are then intercepted by the MAP, using
proxy NDP, encapsulated and routed to the MN position (LCoA).
5.3 HA Operations
The support of basic mode in HMIPv6 is completly transparent to the
HA operation. Packets addressed to a MN's Home Address will be
forwarded by the HA to its RCoA as described in [1].
5.4 CN Operations
Both HMIPv6 modes are completely transparent to CNs.
6. Extended mode: Using the MAP's advertised address as an alternate-CoA
In some mobility scenarios it may not be possible for a MN to get a
RCOA on the MAP's subnet. One example for these scenarios is shown in
this chapter. However, network operators may have other reasons for
choosing this HMIPv6 mode of operation. A comparison between the two
modes of operation will be shown below.
In the case where a MN is also a router to which several MN's may be
connected (eg. a Personal Area Network), it would not be possible for
such router to obtain a new network prefix within a visited network.
Hence, MNs connected to such router will end up with topologically
incorrect addresses. By having the Mobile Router (MR) act as a MAP
Soliman, Castelluccia, El-Malki, Bellier [Page 10]
INTERNET-DRAFT HMIPv6 ****,2000
within the visited network, MNs connected to it may use it as an
alternate-COA when registering with their HA and other CNs.
Hence, maintaining the IPv6 powerful aggregation of routes within the
backbone, while receiving route-optimised packets sent to the MNs
attached to the Mobile Router (MAP).
In this case the MAP option will be advertised by the MR that the MN
is connected to. The MN MUST send a BU to the HA and CNs including
the MAP's address as an alternate-COA. Hence all packets addressed to
the MN will be sent through the MAP's address as specified by the MN
in its BU. The MAP will (acting like a HA) tunnel the packets
addressed to the MN to its current address. The details of the MAP
operation will be given later in this document.
The Home Address contained in the MAP registration MUST be the same
Home Address sent in the Home Agent registration. If a MN sends
different BU's for different Home Addresses (in the case it has
multiple Home Addresses), the same process MUST be performed first
for the MAP registrations. This is essential to allow a MAP to
forward packets to the right MN when they are tunnelled from the HA.
The MN SHOULD also have a prefix length of 128 in its BUs to the HA.
This would stop the HA from being proxy for other unregistered Home
addresses.
The MAP will need to know how the final destination in the packet
corresponds to the registered address of a MN. This should be obvious
when the packets are sent from a CN to the global Home Address of the
MN or to the COA with a routing header. However, if the HA tunnels
packets with addresses other than the MN's Home Address (eg. Site-
local), of which the MAP would have no knowledge, the HA SHOULD add a
routing header to the outer packet. This routing header MUST use one
of the MN's registered Home Addresses as the final destination. This
will enable the MAP to tunnell the packet to the correct destination
(i.e. the MN's current address).
6.1 MN Operations
After MAP discovery has taken place, a MN can register with one or
more MAPs. The MN performs this local registration by sending a BU
to the MAP with the appropriate flags set.
When registering with a MAP, the A flag SHOULD be set and the M flag
(see section 4.5) MUST be set in the BU. The H flag MUST not be set
when registering with a MAP. A MN SHOULD wait for a BAck (Binding
Acknowledgement) from the MAP before using the MAP address as an
alternate COA in its BUs.
After successfully performing registration with a MAP, a MN can start
sending BUs, with it's Alternate-COA,to CNs and its HA. The MAP's IP
address or RCOA MUST be included in the Alternate-COA sub-option.
Soliman, Castelluccia, El-Malki, Bellier [Page 11]
INTERNET-DRAFT HMIPv6 ****,2000
The MN SHOULD send a separate home registration BU for each home
address, with the prefix length value set to 128. This stops the HA
from forming home addresses for that MN on each link that the HA is
connected to, thus ensuring consistency in the Binding Caches of both
the MAP and HA for the MN.
When in a foreign network, a MN needs to know which path a packet has
taken from the CN to the MN. That is, whether triangular routing was
used via the HA or route optimisation was used. When using HMIPv6,
all packets received from a CN will be tunnelled by the MAP to the
MN.
When using the MAP's address as a COA, packets tunnelled by the HA
to the MAP will be decapsulated and then encapsulated again with the
MAP's address as the source address of the outer header.
Therefore a check on whether the packet was tunnelled by the HA will
not be sufficient to decide whether route optimisation is required.
Hence, a check for the existence of a routing header in the
encapsulated packet (i.e. with CN as source address), where the MN's
home address is the final address, will be sufficient to determine
whether the path was route optimised or not.
If the routing header does not exist, the MN SHOULD send a BU with
the appropriate information to initiate route optimisation.
It should be noted that such check is generic and would work for all
the various use cases of MIPv6 including the different MAP modes of
operation in this memo.
6.2 HA Operations
If the MN uses a MAP address, the Home Agent operations are affected
in a minor way.
The only impact due to this HMIPv6 mode on the HA implementation is
that when tunnelling packets to the MN with destination addresses
other than the addresses registered by the MN in its Home
Registration, the HA SHOULD include a routing header in the outer
packet with the MN's registered home address as the final
destination. This is done to enable the MAP to find the right routing
entry for the MN, since it has no knowledge of a non-unicast global
home address for the MN.
6.3 MAP Operations
The MAP operation is in many ways similar to the HA operation
described in [1] with some modifications. Upon reception of a BU from
a MN with the M flag set, and provided it is allowed to accept this
message (i.e. no local policy restrictions) the MAP MUST process the
BU and if successful, add the information to its Binding Cache.
Soliman, Castelluccia, El-Malki, Bellier [Page 12]
INTERNET-DRAFT HMIPv6 ****,2000
The BU from the MN will contain its LCOA as a source address and its
Home address. A MAP MUST first check if the MN is authorised to use
the MAP in this mode. If so, the MAP SHOULD process the BU in the
normal manner.
If the A flag was set, the MAP MUST send a BAck to the MN.
All packets directed to the MN will be received by the MAP and
tunnelled to the MN. Upon reception of an encapsulated packet, from a
MN's HA, with no routing header in the outer packet, the packet is
decapsulated in the normal way. If the inside packet contains a
destination address that doesn't belong to the MAP, the MAP should
check its Binding Cache to see if the address belongs to any of its
registered MN's. If it does, the packet MUST be tunnelled to the MN's
current address. Otherwise, the packet is processed in the normal
way.
If the encapsulated packet contains a routing header in the outer
packet containing the MN's home address as the next destination, the
MAP MUST process the routing header in the normal way, then tunnel
the packet to the MN's current address.
When a packet containing a routing header is received (from a CN) the
routing header is processed as usual and the packet is then
encapsulated to the MN.
6.4 CN Operations
In this mode, HMIPv6 is transparent to CNs.
7. Comparison between the HMIPv6 modes of operation
In this memo two different modes of operation are defined for HMIPv6
depending on the MN's choice of its COA when located in a foreign
network. As shown above the selection of the mode of operation is
done based on the information sent in the MAP option. Such
information MUST be configurable by the network administrator. Hence
some administrators may allow a MN to only obtain a RCOA or use the
MAP's address as an alternate-COA. To simplify MN and MAP
implementations, only one mode is used by the MAP at a time.
The use of RCOA is very simple as it is completely independant of the
HA's implementation. intercepted by the MAP (using a HA
implementation) and encapsulated again to the MN. On the other hand,
if the MAP's COA is used, the MAP will decapsulate the packets and
then encapsulate them again to the MN.
Hence, in the latter case, only one additional IPv6 header is needed
as opposed to two headers in the former. If an appropriate header
compression mechanism is used, this may not be an issue. However, if
no header compression is used, it maybe more efficient for the MN to
Soliman, Castelluccia, El-Malki, Bellier [Page 13]
INTERNET-DRAFT HMIPv6 ****,2000
use the MAP's COA as an alternate-COA.
Another aspect of the comparison, is the Duplicate Address Detection
(DAD) required when performing the initial registration with the MAP.
If a RCOA is used, the MAP MUST perform DAD for that address. On the
other hand, if the MAP address is used as an alternate-COA, there
will be no need to perform DAD as the BU sent to the MAP will bind
the MN's home address to the LCOA. Since no DAD for the LCOA or the
Alternate-COA (being the MAP's address) is required by the MAP, the
registration can be faster when using the MAP address as an
alternate-COA. This aspect of the comparison may not be relevant if
no inter-MAP handoffs are expected when roaming within the visited
network (ie. one MAP domain in the visited network). However, if
inter-MAP handoffs are expected, the time taken to perform DAD by the
MAP may become significant.
In the case where RCOA is used, to avoid DAD delays during inter-MAP
mobility, the MN MAY register its new LCoA with its previous MAP.
Packets will be redirected from the previous MAP to the new LcoA
while DAD is performed. In this scenario the time taken to perform
DAD by the MAP in the RCOA mode might be not be an issue.
8. MAP discovery
This section describes how a MN obtains the MAP address and subnet
prefix. Two different methods for MAP discovery are defined below.
Dynamic MAP Discovery is based on propagating the MAP option from the
MAP to the MN through certain (configured) router interfaces within
the hierarchy. This would require manual configuration of the MAP and
the routers receiving the MAP option to allow them to propagate the
option on certain interfaces.
Aother method based on Router Renumbering [5] is also shown below. In
this method, no manual configuration is required for routers within
the hierarchy. The MAP option is sent directly from a central node to
all ARs within a MAP domain. This method is best suited to large
networks where manually configuring all routers within a hierarchy
maybe a significantly tedious operation. On the other hand, when
using this method, any changes in the MAP option's parameters (eg.
preference) would require manual intervention.
8.1 Dynamic MAP Discovery
The process of MAP discovery can be performed in many different ways.
In this document, router advertisements are used for the discovery
phase by introducing a new option. The access router is required to
send the MAP option in all router advertisements. This option
includes the distance from the MN in terms of number of hops, the
preference for this particular MAP, the MAP's global IP address and
eventually the MAP's subnet prefix.
Soliman, Castelluccia, El-Malki, Bellier [Page 14]
INTERNET-DRAFT HMIPv6 ****,2000
The ARs can be configured manually or automatically with this
information. In the case of automatic configuration, each MAP in the
network needs to be configured with a default preference, the right
interfaces to send this option on and, if necessary, the IP address
to be sent. The initial value of the "Distance" field MUST be set to
a value of one. Upon reception of a router advertisement with the MAP
option and given that a router is configured to resend this option on
certain interfaces, the router MUST copy the option and resend it
after incrementing the Distance field by one. If the router was also
a MAP, it SHOULD send its own option in the same advertisement.
If a router receives more than one MAP option for the same MAP, from
two different interfaces, it should choose the option with the
smaller distance field.
In this manner information about a MAP at a certain level in a
hierarchy can be dynamically passed to a MN. Furthermore, by
performing the discovery phase in this way, different MAP nodes are
able to change their preferences dynamically based on the local
policies, node overload or other load sharing protocols being used.
8.2 Using Router Renumbering for MAP discovery
The Router Renumbering (RR) mechanism described in [5] defines a set
of messages that can be used to renumber certain interfaces on a
router without manual configuration of such router. RR messages are
authenticated and protected against replay attacks. The same concept
can be used here to configure a router to propagate the MAP option on
certain interfaces.
To be able to achieve this a new PCO command, PROPAGATE, is defined.
This command is part of the Prefix Code Operation (PCO) and is
included in the Match Prefix part of the message. A PCO message sent
to a router with the PROPAGATE command MUST only contain one or more
MAP options in the Use Prefix part of the message.
Upon reception of this message, a router will propagate the MAP
option on the designated interface, after incrementing the Distance
field's value by one.
This mechanism can be used to configure AR's to advertise one or more
MAP options. This is best suited to large networks or for cases where
third party networks may exist between the MAP and ARs.
Soliman, Castelluccia, El-Malki, Bellier [Page 15]
INTERNET-DRAFT HMIPv6 ****,2000
8.2.1 Extension to the Match Prefix Part of RR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | OpLength | Ordinal | MatchLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinLen | MaxLen | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MatchPrefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Fields:
OpCode An unsigned 8-bit field specifying the operation to be
performed when the associated MatchPrefix matches an
interface's prefix or address. Values are:
1 the ADD operation
2 the CHANGE operation
3 the SET-GLOBAL operation
4 the PROPAGATE operation (new code).
8.3 MAP Discovery using a new destination option
For more flexibility and simplicity, a new destination option is
designed to allow a MAP to send its parameters directly to the Access
Routers it is serving. This new destination option has to be sent
periodically in order to refresh the state of the
routers. The format of this MAP destination option is described
below. It contains a type, a length and a data fields. The data field
contains the MAP option defined in Section 3.
As a result when a router receives a message with a MAP destination
option, it simply retrieves the data field and insert it in its
router advertissement.
The alignment requirement for this destination option is 8n+2.
Soliman, Castelluccia, El-Malki, Bellier [Page 16]
INTERNET-DRAFT HMIPv6 ****,2000
8.4 MN Operations
When a HMIPv6-aware MN receives a router advertisement, it should
search for the MAP option. One or more options may be found for
different IP addresses or subnet prefixes.
A MN SHOULD register with the MAP having the lowest preference value.
A MAP with a preference value of 255 SHOULD not be used in the MAP
registration. A MN MAY however choose to register with one MAP rather
than another depending on the value received in the Distance field,
as long as the preference value is below 255.
If a MN has access to several ARs simultaneously, it SHOULD use a
LCoA on the subnet defined by the AR that advertises its current MAP.
A MN SHOULD store the received option(s) and choose at least one MAP
to register with. Storing the options is essential as they will be
compared to other options received later for the purpose of the move
detection algorithm.
If no MAP options are found in the router advertisement, the MN MUST
use the MIPv6 protocol as specified in [1].
Finally if the M flag is set in the MAP option, the MN MUST register
with the MAP and inform its HA.
A MN MAY choose to register with more than one MAP simultaneously or
use both MAP address and its own address as COAs simultaneously with
different CNs.
8.5 MAP Operation for Dynamic MAP Discovery
When Dynamic MAP Discovery is used, the MAP discovery is done via
router advertisements having the new MAP option added. A MAP will be
configured to send its option or relay other MAPs' options on certain
interfaces. The choice of interfaces is done by the network operator
and depends on the network architecture. A default preference value
should be assigned to each MAP. It should be noted that a MAP can
change its preference value at any time due to various reasons (e.g.
node overload or load sharing). A preference value of 255 means
that the MAP SHOULD not be chosen by a MN. This value could be
reached in cases of node overload or node failures.
The MAP option is propagated down the hierarchy. Each router along
the path to the access router will increment the Distance field by
one. If a router that is also a MAP receives advertisements from
other MAPs, it SHOULD add its own MAP option and propagate both
options to the next level in the hierarchy.
Soliman, Castelluccia, El-Malki, Bellier [Page 17]
INTERNET-DRAFT HMIPv6 ****,2000
9. Smooth Handoff
A MAP should be able to handle smooth handoffs. When a mobile host
moves into a new MAP domain, the MN should send a BU to the previous
MAP requesting to forward packets addressed to the MN's new CoA. This
is similar to the smooth handoff mechanism of Mobile IPv6.
10. Notes on MAP selection by the MN
HMIPv6 provides a very flexible mechanism for local mobility
management within a visited network. As explained earlier a MAP can
exist on any level in a hierarchy including the AR. Several MAPs can
be located within a hierarchy independantly of each other. In
addition, overlapping MAP domains are also allowed and recommended.
Both static and dynamic hierarchies are supported for either mode of
operation. Hence the discussion below is independant of the MAP's
mode of operation.
When the MN receives a router Advertisement including a MAP option,
it should perform actions according to the following movement
detection mechanisms. In a Hierarchical Mobile IP network such as the
one described in this draft, the MN SHOULD be:
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
The above means that the MN will register with any "new" MAP
advertised by the AR (Eager).
The method by which the MN determines whether the MAP is a "new" MAP
is described above. The MN should not release existing
bindings until it no longer receives its MAP option or the lifetime
of its existing binding expires (Lazy).
This Eager-Lazy approach described above will assist in providing a
fallback mechanism in case one of the MAP routers crash as it would
reduce the time it takes for a MN to inform its CNs and HA about its
new COA.
10.1 MAP selection in a static multi-level hierarchy
For a MN to select one or more MAPs in a static multi-level
hierarchy, in an optimised manner, several factors need to be
considered.
In terms of the Distance based selection in a multi-level hierarchy,
a MN may choose to register with the furthest MAP to avoid frequent
reregistrations. This is particularly important for fast MNs that
will perform frequent handoffs. In this scenario, the choice of a
further MAP would reduce the probability of having to change a MAP
and informing all CNs and the HA.
Soliman, Castelluccia, El-Malki, Bellier [Page 18]
INTERNET-DRAFT HMIPv6 ****,2000
If the distance between the MN and the furthest MAP is large, and
other MAPs are located in between, a MN may choose to register its
LCOA with the closer MAP and register its closer RCOA/alternate-COA
with the further one. For example, the MN may receive two MAP
options, one with a distance of 5 (MAP5) and another with a distance
of 10 (MAP10). To reduce the delays in MAP registration during
handoff, a MN may bind its LCOA to the address acquired from MAP5
(LCOA, MAP5) in the BU sent to MAP5, and bind its MAP10 address to
the MAP5 address (MAP10,MAP5) in its BU that is sent to MAP10. The MN
can then inform CNs of either one of its addresses (LCOA, MAP5,
MAP10) when sending BUs to them. Packets sent to MAP10 will be
forwarded to MAP5 and then to the LCOA of the MN.
10.2 MAP selection in a flat mobility management architecture
Network operators may choose a flat architecture in some cases where
a MIP handoff may be considered a rare event. In these scenarios
operators may choose to include the MAP function in ARs only. The
inclusion of the MAP function in ARs can still be quite useful to
reduce the time required to update all CNs and the HA. In this
scenario, a MN may choose a MAP (in the AR) as an anchor point when
performing a handoff. This kind of dynamic hierarchy (or anchor
chaining) is only recommended for cases where inter-AR movement is
not frequent. This is to avoid additional delays in packet delivery
as well as overloading ARs with traffic that no longer belongs to
their subnets.
11. Security considerations
HMIPv6 does not introduce more security problems than Mobile
IPv6. The IPSec SA are created by using the home address of the
mobile host.
A mobile host has to register with its home agent and with the
Mobility Anchor Point. All registration messages between the MN and
the MAP have to be authenticated. This means that the mobile host
has to share an authentication key (private or public) with all
MAPs it may visit. These keys can be pre-installed manually or
obtained dynamically via IKE or AAA servers.
12. AAA Considerations for IPv6
The MAP can be utilised to perform access control on MNs and may
interact with the protocol which will be defined for AAA in IPv6. The
MAP can speed up a handoff by having the MN's security credentials
which will allow it to verify whether a certain node is allowed
access to the network. This allows greater efficiency in distributing
keys only to certain nodes in the network.
Soliman, Castelluccia, El-Malki, Bellier [Page 19]
INTERNET-DRAFT HMIPv6 ****,2000
One example of the interaction between a MAP and the AAA
infrastructure can be seen when considering the handoff scenario. A
MAP can store the MN's security credentials after the MN is allowed
network access by the AAA infrastructure. During an intra-domain
handoff, the MAP could pass the MN's security credentials to the
"new" AR to avoid performing the AAA process. These credentials
depend on the access enforcement policies in AAAv6 and will not be
covered by this draft.
13. Acknowledgements
The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft.
The authors from INRIA would also like to thank the members of the
French RNRT MobiSecV6 project (BULL, France Telecom and INRIA) for
testing our implementation and for their valuable feedbacks. They
would also like to thank the French Governement for partially funding
this project.
In addition, the authors would like to thank the following members of
the working group in alphabetical order: Eva Gustaffson (Ericsson),
Dave Johnson (Rice University), Annika Jonsson (Ericsson), Fergal
Ladley and Erik Nordmark (Sun) for their comments on the draft.
14. Notice Regarding Intellectual Property Rights
see http://www.ietf.org/ietf/IPR/ERICSSON-General
15. References
[1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-12.txt, February 2000.
[2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
Tunnel Management", draft-ietf-mobileip-reg-tunnel-02.txt
(work in progress), March 2000.
[3] K. El Malki and H. Soliman "Fast Handoffs in Mobile IPv4".
(work in progress).
[4] K. El Malki and H. Soliman "Fast Handoffs in Mobile IPv6".
draft-elmalki-handoffsv6-00.txt (work in progress).
[5] M. Crawford "Router Renumbering for IPv6". RFC 2984.
[6] S. Thomson and T. Narten "IPv6 Stateless Address
Autoconfiguration". RFC 2462.
[7] T. Narten, E. Nordmark and W. Simpson "Neighbour Discovery for
IP version 6 ". RFC 2461.
Soliman, Castelluccia, El-Malki, Bellier [Page 20]
INTERNET-DRAFT HMIPv6 ****,2000
16. Appendix A: Planned additions to future revisions
In addition to the existing proposal, the following sections are
planned for future revisions:
- quick discovery of MAP failures will be essential for the
reliability of this mechanism. Some suggestions for handling these
scenarios will be included in future revisions.
- Detailed notes for implementors will also be added.
17. Authors' Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola M/S M8-540
6000 Connection Drive 1501 West Shure Drive
Irving, TX 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
Questions about this memo can also be directed to:
Hesham Soliman
Ericsson Australia
61 Rigall St., Broadmeadows
Melbourne, Victoria 3047
AUSTRALIA
Phone: +61 3 93012049
Fax: +61 3 93014280
E-mail: Hesham.Soliman@ericsson.com.au
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: claude.castelluccia@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Karim El Malki
Soliman, Castelluccia, El-Malki, Bellier [Page 21]
INTERNET-DRAFT HMIPv6 ****,2000
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: ludovic.bellier@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Soliman, Castelluccia, El-Malki, Bellier [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-21 09:39:42 |