Network Working Group Hesham Soliman, Ericsson
INTERNET-DRAFT Claude Castellucia, INRIA
Expires: February 2001 Karim El-Malki, Ericsson
Ludovic Bellier, INRIA
September, 2000
Hierarchical MIPv6 mobility management
<draft-soliman-mobileip-hmipv6-01.txt>
Status of this memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
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
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, Casteluccia, El-Malki, Bellier [Page 1]
INTERNET-DRAFT HMIPv6 ****,2000
TABLE OF CONTENTS
1. Introduction.............................................3
3. Hierarchical Mobility Management using MIPv6.............5
4. Overview of the MIPv6 Hierarchical Mobility Management...6
5. Neighbour Discovery extension - MAP discovery............9
6. MIPV6 extensions - Sending Binding Updates..............10
7. MN Operation............................................11
7.1 MAP Discovery...........................................11
7.2 Sending Binding Updates.................................12
7.3 Receiving packets in a foreign network..................12
7.4 Fast Handoff scenario...................................13
8. MAP Operation...........................................14
8.1 MAP Discovery..................................._.......14
8.2 Receiving and forwarding Packets for a MN...............14
8.3 Fast handoff scenario...................................15
9. HA Operation............................................15
10. AAA Considerations for IPv6.............................16
11. Acknowledgements........................................16
12. Notice Regarding Intellectual Property Rights...........16
13. References..............................................17
14. Authors' addresses......................................17
Soliman, Casteluccia, 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 regional
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 options are proposed in this memo for the use
of a MAP. A MN may use the MAP as an alternate-care-of address (COA)
or form a Regional COA (RCOA) on the MAP's subnet 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 4.1 and 4.2.
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 3.
This draft assumes the generic case of scaleable multi-level
Hierarchical Mobile IP (HMIP) networks and is therefore applicable to
HMIP networks in general. Hierarchical MIPv6 (HMIPv6)can assist with
speeding up MIP Handoffs, hence offering advantages which are
especially important for the support of real-time services.
3. Hierarchical Mobility Management using MIPv6
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 is achieved by using
the MIPv6 protocol combined with layer 2 features to manage both IP
micro and macro mobility, leading to rationalisation and less complex
implementations in the MN and other network nodes. 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 [5] 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 the radio interface. Just like MIPv6, this solution is
independent of the underlying access technology, allowing Fast
Soliman, Casteluccia, El-Malki, Bellier [Page 3]
INTERNET-DRAFT HMIPv6 ****,2000
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.
The introduction of the MAP concept will further diminish signalling
generated by MIPv6 over the radio interface. This is due to the fact
that a MN only needs to perform one regional update (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 ch 10.
4. Overview of the MIPv6 Hierarchical Mobility Management
In order to introduce hierarchical mobility management in MIPv6, the
protocol is extended with a new function. The proposed new
functionality is the Mobility Anchor Point (MAP). It simply provides
an optional mobility management function that can be located at any
level in the hierarchy starting from the access router upwards.
The MAP may be used by a MN as an alternate-COA [1] while roaming
within a certain MAP domain. Alternatively, the MN MAY choose to use
a Regional Care of Address (RCOA) on the MAP's subnet as its own COA
while roaming within a MAP's domain. In the latter case, 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.
When the MAP is used as an alternate COA, the MAP will receive all
packets on behalf of the MN and will encapsulate and forward them
directly to the MN's current address. If the MN changes its current
address within a regional MAP domain, it needs to register the new
address with the MAP. 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 [5].
The detailed extensions to MIPv6 and operations of the different
nodes will be explained later in this document.
Although the proposed method is independent of the network topology,
it is best suited to a hierarchical network or one with multi-access
technologies. It should be noted that the MAP concept is simply an
extension to the MIPv6 protocol. Hence a MAP-aware MN with an
implementation of MIPv6 MAY choose to use the MAP or simply use the
Soliman, Casteluccia, El-Malki, Bellier [Page 4]
INTERNET-DRAFT HMIPv6 ****,2000
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 domain.
_______
| 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 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.
Soliman, Casteluccia, El-Malki, Bellier [Page 5]
INTERNET-DRAFT HMIPv6 ****,2000
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. Other service discovery methods may also be used
for the same purpose. If a router advertisement is used for MAP
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.
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 MAP-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 MAP-aware it MAY choose
to use the MAP implementation. If so, the MN will first need to
register with a MAP by sending it a BU containing its Home Address
and current address. 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
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. Since all packets will be tunnelled by the MAP, 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, containng 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.
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)
Soliman, Casteluccia, El-Malki, Bellier [Page 6]
INTERNET-DRAFT HMIPv6 ****,2000
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 use its current
address as a COA as well.
4.1 Using a MAP's address as a COA
Using a MAP as an alternate-COA may be a useful tool for some
mobility scenarios. 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
act as a MAP 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 witihn the
backbone.
In this case the MAP option will be advertised by the AR that the MN
is connected to. The MN SHOULD 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 for the
MAP registrations. This is essential to allow a MAP to forward
packets to the right COA 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 MUST 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 tunnel the packet to the correct destination
(i.e. the MN's current address).
4.2 Using a Regional COA (RCOA) on a MAP's subnet
Soliman, Casteluccia, El-Malki, Bellier [Page 7]
INTERNET-DRAFT HMIPv6 ****,2000
In this scenario, 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.
After forming the RCOA, the MN sends a BU to the MAP. The BU will
bind the RCOA (similar to a Home Address) to its LCOA. The BU MUST
have both the A and D flags set. 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 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.
5. Neighbour Discovery extension - 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 and the MAP's global IP address.
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, 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. 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.
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 |
Soliman, Casteluccia, El-Malki, Bellier [Page 8]
INTERNET-DRAFT HMIPv6 ****,2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix / Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirements for this option is 8n.
Fields:
Type Message type. To be assigned.
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 this MAP. An 8 bit unsigned
integer. A value of 255 means lowest
preference.
Plen The prefix length in this option. A prefix
length value of 128 indicates that the MAP
option contians the MAP's IP address.
R Indicates that the MN MUST form a RCOA
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.
Soliman, Casteluccia, El-Malki, Bellier [Page 9]
INTERNET-DRAFT HMIPv6 ****,2000
6. MIPV6 extensions - Sending Binding Updates
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| Res | Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Description of extensions to the BU option:
M If set indicates a MAP registration.
Res 3 bit reserved field
7. MN OPERATION
This section is concerned with the extensions to the MN's operation
in a foreign network due to the introduction of the MAP. Unless
otherwise specified, the normal MN operation in [1] applies.
7.1 MAP discovery
When a MAP-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.
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.
Soliman, Casteluccia, El-Malki, Bellier [Page 10]
INTERNET-DRAFT HMIPv6 ****,2000
If no MAP options are found in the router advertisement, the MN MUST
use the MIPv6 protocol as specified in [1]. If the MN receives a
duplicated MAP option ( having the same IP address or prefix) with
different preference values or Distance values, the MAP IP address
SHOULD not be used as an Alternate-COA in any BU's sent by the MN.
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.
7.2 Registration with the MAP - Sending Binding Updates
After MAP discovery has taken place, a MN can register with one or
more MAPs. The MN performs this regional registration by sending a BU
to the MAP with the appropriate flags set. The contents of the BU
will depend on the MAP's mode of operation.
When registering with a MAP, the A flag SHOULD be set and the M flag
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 or a RCOA from the MAP's
subnet 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.
If the MN uses a MAP's address as an alternate-COA, then for each
home address registration sent to the HA with a MAP's address as the
COA, a BU MUST be sent to the same MAP using the same home address.
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.
7.3 Receiving packets in a foreign network
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.
Soliman, Casteluccia, El-Malki, Bellier [Page 11]
INTERNET-DRAFT HMIPv6 ****,2000
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 generic 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.
8. MAP Operation
8.1 MAP Discovery
As mentioned previously, 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. 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.
8.2 Receiving and forwarding Packets for a MN
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.
The MAP will need to determine how it should act based on the
information given in the BU. Two different modes of operation are
described below.
8.2.1 Using a MAP's address as a COA
Soliman, Casteluccia, El-Malki, Bellier [Page 12]
INTERNET-DRAFT HMIPv6 ****,2000
In this scenario, 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 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.
8.2.2 Using a RCOA on the MAP's subnet
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.
8.3 The MAP as a Mobile Router (MR)
In the case where a Mobile Router (MR) is located in a foreign
network, the MR will not be able to obtain a new network prefix for
the MNs attached to it. Hence, the MR MUST act as a MAP and advertise
the MAP option to the MNs attached to it. The MAP option MUST have
the M flag set to ensure that the MNs register with it. This will
allow the MNs to be reachable without advertising host specific
routes to other routers within the network. This approach maintains
IPv6 route aggregation and ensures that no additional routing table
entries are required due to the MR's network mobility.
9. HA Operation
The Home Agent operations are affected in a minor way by the
introduction of the MAP. The only impact due to HMIPv6 on the HA
implementation is that when tunnelling packets to the MN with
destination addresses other than the addresses registered by the MN
Soliman, Casteluccia, El-Malki, Bellier [Page 13]
INTERNET-DRAFT HMIPv6 ****,2000
in its Home Registration, the HA MUST 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.
10. 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.
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 secrity 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.
11. Acknowledgements
The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft.
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 (Ericsson) and Erik Nordmark (Sun) for their comments on the
draft.
12. Notice Regarding Intellectual Property Rights
Ericsson may seek patent or other intellectual property protection
for some or all of the technologies disclosed in this document. If
any standards arising from this disclosure are or become protected by
one or more patents assigned to Ericsson, Ericsson intends to
disclose those patents and license them on reasonable and non-
discriminatory terms. Future revisions of this draft may contain
additional information regarding specific intellectual property
protection sought or received.
13. References
[1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-12.txt, February 2000.
Soliman, Casteluccia, El-Malki, Bellier [Page 14]
INTERNET-DRAFT HMIPv6 ****,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] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
1996.
[4] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4".
(work in progress)
[5] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv6".
draft-elmalki-handoffsv6-00.txt (work in progress)
14. Appendix A: Planned additions to future revisions
In addition to the existing proposal, the following sections are
planned for future revisions:
- MAP discovery. Other ways for dynamic MAP discovery are being
investigated. The reuse of Router renumbering has been suggested and
if suited, it may be included in the next revision.
- 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.
15. 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
Soliman, Casteluccia, El-Malki, Bellier [Page 15]
INTERNET-DRAFT HMIPv6 ****,2000
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
Ericsson Radio Systems AB
Access Networks Research
SE-164 80 Stockholm
SWEDEN
Phone: +46 8 7573561
Fax: +46 8 7575720
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, Casteluccia, El-Malki, Bellier [Page 16]