draft-ietf-netlmm-nohost-req-00.txt   draft-ietf-netlmm-nohost-req-01.txt 
J. Kempf, J. Kempf,
Editor Editor
Internet Draft K. Leung Internet Draft K. Leung
Document: draft-ietf-netlmm-nohost-req-00.txt P. Roberts Document: draft-ietf-netlmm-nohost-req-01.txt P. Roberts
K. Nishida K. Nishida
G. Giaretta G. Giaretta
M. Liebsch M. Liebsch
Expires: August, 2006 Feburary, 2006 Expires: October, 2006 April, 2006
Requirements and Gap Analysis for IP Local Mobility Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-00.txt) (draft-ietf-netlmm-nohost-req-01.txt)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have been applicable patent or other IPR claims of which he or she is aware have been
or will be disclosed, and any of which he or she becomes aware will be or will be disclosed, and any of which he or she becomes aware will be
disclosed, in accordance with Section 6 of BCP 79. disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also (IETF), its areas, and its working groups. Note that other groups may also
skipping to change at page 1, line 40 skipping to change at page 1, line 40
other than as "work in progress." other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In draft-kempf-netlmm-nohost-ps, the problems with using global IP mobility In this document, design goals for a network-based localized mobility
management protocols for local mobility and some problems with existing management protocol are discussed.
localized mobility management protocols are described. In this document, we
explore requirements for localized mobility management in more detail. An
extensive gap analysis against the protocols illustrates where existing
protocols are able to fulfill the requirements and where they are lacking.
Table of Contents Table of Contents
1.0 Introduction.....................................................2 1.0 Introduction.....................................................2
2.0 Requirements for Localized Mobility Management...................3 2.0 Goals for Localized Mobility Management..........................2
3.0 Gap Analysis.....................................................8 3.0 Security Considerations..........................................8
4.0 Security Considerations.........................................18 4.0 Author Information...............................................9
5.0 Recommendation..................................................18 5.0 Informative References..........................................10
6.0 Author Information..............................................19 6.0 IPR Statements..................................................11
7.0 Informative References..........................................20 7.0 Disclaimer of Validity..........................................12
8.0 IPR Statements..................................................21 8.0 Copyright Notice................................................12
9.0 Disclaimer of Validity..........................................22 9.0 Appendix: Gap Analysis..........................................12
10.0 Copyright Notice................................................22
11.0 Changes in 01 (remove before publication).......................22
1.0 Introduction 1.0 Introduction
In draft-kempf-netlmm-nohost-ps [1], the basic problems that occur when a In [1], the basic problems that occur when a global mobility protocol is
global mobility protocol is used for managing local mobility are described, used for managing local mobility are described, and three basic approaches
and two basic approaches to localized mobility management - the host-based to localized mobility management - the host-based approach that is used by
approach that is used by most IETF protocols and the WLAN switch approach - most IETF protocols, the WLAN switch approach, and using a standard routing
are examined. The conclusion from the problem statement document is that IGP to distribute host routes - are examined. The conclusion from the
neither approach has a complete solution to the problem. While the WLAN problem statement document is that none of the approaches has a complete
switch approach is most convenient for network operators and users because solution to the problem. While the WLAN switch approach is most convenient
it requires no mobile node support, the proprietary nature limits for network operators and users because it requires no mobile node support,
interoperability and the restriction to a single wireless link type and the proprietary nature limits interoperability and the restriction to a
wired backhaul link type restricts scalablity. The IETF host-based protocols single wireless link type and wired backhaul link type restricts scalablity.
require host software stack changes that may not be compatible with all The IETF host-based protocols require host software stack changes that may
global mobility protocols, and also require specialized and complex security not be compatible with all global mobility protocols, and also require
transactions with the network that may limit deployability. specialized and complex security transactions with the network that may
limit deployability. The use of an IGP to distribute host routes has
scalability and deployment limitations.
This document develops more detailed requirements for a localized mobility This document develops more detailed goals for a network-based localized
management protocol and analyzes existing protocols against those mobility management protocol. In Section 2.0, we review a list of goals that
requirements. In Section 2.0, we review a list of requirements that are are desirable in a network-based localized mobility management solution.
desirable in a localized mobility management solution. Section 3.0 performs Section 3.0 briefly outlines security considerations. More discussion of
a gap analysis against the requirements of proposed solutions to localized security can be found in the threat analysis document [2]. The architecture
mobility management. Section 4.0 briefly outlines security considerations. of the NETLMM protocol for which the goals in this document have been
Finally, in Section 5.0, a recommendation is made for the development of a formulated is described in Section 4 of [1].
network-based approach to localized mobility management.
1.1 Terminology 1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753 [2] and in [2]. Mobility terminology in this draft follows that in RFC 3753 [3] and in [1].
In addition, the following terms are used here:
Node
A node can be either an end host or router that is served by the
localized mobility management domain. Such a node may perform global
mobility management (e.g. NEMO [3] or MIPv6[5]). In this case, the IP
address obtained by the node from the localized mobility management
domain is the care-of address.
Host-Based Approach
A host-based approach to localized mobility management requires binding
between a local care-of address and a regional care-of address at a
mobility anchor within the localized mobility management domain. The
binding is maintained by the mobile node and requires software in the
mobile node's stack to perform the binding. The localized mobility
service is authorized with the mobility anchor point separately from
network access. An example is HMIPv6 [20]. A mobility anchor is a kind
of localized mobility management domain gateway. The regional care-of
address is fixed at the mobility anchor while the local care-of address
on the access router changes when the mobile node moves to a new IP
link.
Micromobility Approach
A micromobility approach to localized mobility management requires host
route propagation from the mobile node to a collection of specialized
routers in the localized mobility management domain along a path back
to a boundary router at the edge of the localized mobility management
domain. A boundary router is a kind of localized mobility management
domain gateway. Localized mobility management is authorized with the
access router, but reauthorization with each new access router is
necessary on IP link movement, in addition to any reauthorization for
basic network access. The host routes allow the mobile node to maintain
the same IP address when it moves to a new IP link, and still continue
to receive packets on the new IP link.
Edge Mobility Approach
In the edge mobility approach to localized mobility management, the
access routers update bindings between the mobile node's care-of
address and the mobile node's current IP link. The bindings are
maintained at an edge mobility anchor point. The mobile node is not
involved in localized mobility management beyond movement detection.
The mobile node requires no special authorization for localized
mobility management service beyond the authorization required for basic
network access. A mobile node's IP address does not change when the
mobile node moves from one access router to another within the coverage
area of the edge mobility anchor point, because the mobility anchor and
access routers take care of changing the routing.
2.0 Requirements for Localized Mobility Management 2.0 Goals for Localized Mobility Management
Any localized mobility solution must naturally address the three problems Any localized mobility solution must naturally address the three problems
described in [1]. In addition, the side effects of introducing such a described in [1]. In addition, the side effects of introducing such a
solution into the network need to be limited. In this section, we address solution into the network need to be limited. In this section, we address
requirements on a localized mobility solution including both solving the goals on a localized mobility solution including both solving the basic
basic problems and limiting the side effects. problems and limiting the side effects.
Some basic requirements of all IETF protocols are not discussed in detail Some basic goals of all IETF protocols are not discussed in detail here, but
here, but any solution is expected to satisfy them. These requirements are any solution is expected to satisfy them. These goals are interoperability,
interoperability, scalability, and minimal requirement for specialized scalability, and minimal goal for specialized network equipment. A good
network equipment. A good discussion of their applicability to IETF discussion of their applicability to IETF protocols can be found in [5].
protocols can be found in [4].
Out of scope for the initial requirements discussion are QoS, multicast, and Out of scope for the initial goals discussion are QoS, multicast, and
dormant mode/paging. While these are important functions for mobile nodes, dormant mode/paging. While these are important functions for mobile nodes,
they are not part of the base localized mobility management problem. In they are not part of the base localized mobility management problem. In
addition, mobility between localized mobility management domains is not addition, mobility between localized mobility management domains is not
covered here. It is assumed that this is covered by the global mobility covered here. It is assumed that this is covered by the global mobility
management protocols. management protocols.
2.1 Handover Performance Improvement (Requirement #1) 2.1 Handover Performance Improvement (Goal #1)
Handover packet loss occurs because there is usually latency between when Handover packet loss occurs because there is usually latency between when
the wireless link handover starts and when the IP link handover completes. the wireless link handover starts and when the IP link handover completes.
During this time the mobile node is unreachable at its former topological During this time the mobile node is unreachable at its former topological
location on the old IP link where correspondents are sending packets and to location on the old IP link where correspondents are sending packets and to
which the routing system is routing them. Such misrouted packets are which the routing system is routing them. Such misrouted packets are
dropped. This aspect of handover performance optimization has been the dropped. This aspect of handover performance optimization has been the
subject of an enormous amount of work, both in other SDOs, to reduce the subject of an enormous amount of work, both in other SDOs, to reduce the
latency of wireless link handover, and in the IETF and elsewhere, to reduce latency of wireless link handover, and in the IETF and elsewhere, to reduce
the latency in IP link handover. Many solutions to this problem have been the latency in IP link handover. Many solutions to this problem have been
proposed at the wireless link layer and at the IP layer. One aspect of this proposed at the wireless link layer and at the IP layer. One aspect of this
requirement for localized mobility management is that the processing delay goal for localized mobility management is that the processing delay for
for changing the routing after handover must be minimal, in order to avoid changing the routing after handover must approach as closely as possible the
excessive packet loss. Ideally, if network-side link layer support is sum of the delay associated with link layer handover and the delay required
available for handling movement detection, the routing update should for active IP layer movement detection, in order to avoid excessive packet
complete within the time required for wireless link handover. loss. Ideally, if network-side link layer support is available for handling
movement detection prior to link handover or as part of the link handover
process, the routing update should complete within the time required for
wireless link handover.
Note that a related problem occurs when traffic packets are not routed Note that a related problem occurs when traffic packets are not routed
through a global mobility anchor such as a Mobile IP home agent. Route through a global mobility anchor such as a Mobile IP home agent. Route
optimized Mobile IPv6 [5] and HIP [6] are examples. A loss of connectivity optimized Mobile IPv6 [6] and HIP [7] are examples. A loss of connectivity
can occur when both sides of the IP conversation are mobile and they both can occur when both sides of the IP conversation are mobile and they both
hand over at the same time. The two sides must use a global mobility anchor hand over at the same time. The two sides must use a global mobility anchor
point, like a home agent or rendezvous server, to re-establish the point, like a home agent or rendezvous server, to re-establish the
connection, but there may be substantial packet loss until the problem is connection, but there may be substantial packet loss until the problem is
discovered. Another aspect of this requirement is that the solution must discovered. Another aspect of this goal is that the solution must ensure
ensure that connectivity is not lost when both ends are mobile and move at that connectivity is not lost when both ends are mobile and move at the same
the same time. time.
In both cases, the loss of accurate routing caused the connection to In both cases, the loss of accurate routing causes the connection to
experience an interruption which may cause service degradation for real time experience an interruption which may cause service degradation for real time
traffic such as voice traffic such as voice
2.2 Reduction in Handover-related Signaling Volume (Requirement #2) 2.2 Reduction in Handover-related Signaling Volume (Goal #2)
Considering Mobile IPv6 as the global mobility protocol (other mobility Considering Mobile IPv6 as the global mobility protocol (other mobility
protocols require about the same or somewhat less), if a mobile node is protocols require about the same or somewhat less), if a mobile node is
required to reconfigure on every move between IP links, the following set of required to reconfigure on every move between IP links, the following set of
signaling messages must be done: signaling messages must be done:
1) Movement detection using DNA [7] or possibly a link specific protocol, 1) Movement detection using DNA [8] or possibly a link specific protocol,
2) Any link layer or IP layer AAA signaling, such as 802.1x [8] or PANA [9]. 2) Any link layer or IP layer AAA signaling, such as 802.1x [9] or PANA
The mobile node may also or instead have to obtain a router certificate [10]. The mobile node may also or instead have to obtain a router
using SEND [10], if the certificate is not already cached, certificate using SEND [11], if the certificate is not already cached,
3) Router discovery which may be part of movement detection, 3) Router discovery which may be part of movement detection,
4) If stateless address autoconfiguration is used, address configuration and 4) If stateless address autoconfiguration is used, address configuration and
Duplicate Address Detection (unless optimistic Duplicate Address Duplicate Address Detection (unless optimistic Duplicate Address
Detection [11] is used). If stateful address configuration is used, then Detection [12] is used). If stateful address configuration is used, then
DHCP is used for address configuration, DHCP is used for address configuration,
5) Binding Update to the home agent, 5) Binding Update to the home agent,
6) If route optimization is in effect, return routability to establish the 6) If route optimization is in effect, return routability to establish the
binding key, binding key,
7) Binding Update to correspondent nodes for route optimization. 7) Binding Update to correspondent nodes for route optimization.
Note that Steps 1-2 will always be necessary, even for intra-link mobility, Note that Steps 1-2 will always be necessary, even for intra-link mobility,
and Step 3 will be necessary even if the mobile node's care-of address can and Step 3 will be necessary even if the mobile node's care-of address can
remain the same when it moves to a new access router. remain the same when it moves to a new access router.
This is a lot of signaling just to get up on a new IP link. Furthermore, in The result is approximately 10 messages at the IP level before a mobile node
some cases, the mobile node may need to engage in "heartbeat signaling" to can be ensured that it is established on a link and has full IP
keep the connection with the correspondent or global mobility anchor fresh, connectivity. Furthermore, in some cases, the mobile node may need to engage
for example, return routability in Mobile IPv6 must be done at a maximum in "heartbeat signaling" to keep the connection with the correspondent or
every 7 minutes even if the mobile node is standing still. The requirement global mobility anchor fresh, for example, return routability in Mobile IPv6
is that handover signaling volume from the localized mobility management must be done at a maximum every 7 minutes even if the mobile node is
protocol should be no more than what is needed to securely redirect a mobile standing still.
node's traffic within the localized mobility management domain.
2.3 Location privacy (Requirement #3) The goal is that handover signaling volume from the mobile node to the
network should be no more than what is needed for the mobile node to perform
secure IP level movement detection, in cases where no link layer support
exists. If link layer support exists for IP level movement detection, the
mobile node may not need to perform any additional IP level signaling after
handover.
Location privacy in the context of IP mobility refers to hiding the 2.3 Location privacy (Goal #3)
geographic location of mobile users. Although general location privacy
issues have been discussed in [13], the location privacy referred to here Although general location privacy issues have been discussed in [14], the
focuses on the IP layer and involves the basic property of the IP address location privacy referred to here focuses on the IP layer. In most wireless
that may change due to the mobility. The location information should not be IP network deployments, different IP subnets are used to cover different
revealed to nor deduced by the correspondent node without the authorization geographical areas. It is therefore possible to derive a topological to
of the mobile node's owner. Since the localized mobility management protocol geographical map, in which particular IPv6 subnet prefixes are mapped to
is responsible for the mobile node's mobility within the local mobility management particular geographical locations. The precision of the map depends on the
domain, it should conceal geographical movement of the mobile node. size of the geographic area covered by a particular subnet: if the area is
large, then knowing the subnet prefix won't provide much information about
the precise geographical location of a mobile node within the subnet.
When a mobile node moves geographically, it also moves topologically between
subnets. In order to maintain routability, the mobile node must change its
local IP address when it moves between subnets. A correspondent node or
eavesdropper can use the topological to geographical map to deduce in real
time where a mobile node - and therefore its user - is located. Depending on
how precisely the geographical location can be deduced, this information
could be used to compromise the privacy or even cause harm to the user. The
geographical location information should not be revealed to nor be deducible
by the correspondent node or an eavesdropper without the authorization of
the mobile node's owner.
The threats to location privacy come in a variety of forms. Perhaps least The threats to location privacy come in a variety of forms. Perhaps least
likely is a man in the middle attack in which traffic between a likely is a man in the middle attack in which traffic between a
correspondent and the mobile node is intercepted and the mobile node's correspondent and the mobile node is intercepted and the mobile node's
location is deduced from that, since man in the middle attacks in the location is deduced from that, since man in the middle attacks in the
Internet tend to be fairly rare. More likely are attacks in which the Internet tend to be fairly rare. More likely are attacks in which the
correspondent is the attacker or the correspondent or even mobile node correspondent is the attacker or the correspondent or even the mobile node
itself are relaying information on the care-of address change to someone. itself is relaying information on the local address change to an attacker.
The owner of the correspondent or mobile node might not even be aware of the The owner of the correspondent or mobile node might not even be aware of the
problem if an attacker has installed spyware or some other kind of exploit problem if an attacker has installed spyware or some other kind of exploit
on the mobile node and the malware is relaying the change in care-of address and the malware is relaying the change in local address to the attacker.
to an attacker. Host-based localized mobility management solutions in which the
correspondent only sees a regional address but the host still maintains a
local address are unsatisfactory because they still have a potential for
malware on the mobile node itself to reveal a change in the local address.
Note that the location privacy referred to here is different from the Note that the location privacy referred to here is different from the
location privacy discussed in [15][16][17]. The location privacy discussed location privacy discussed in [16][17][18]. The location privacy discussed
in these drafts primarily concerns modifications to the Mobile IPv6 protocol in these drafts primarily concerns modifications to the Mobile IPv6 protocol
to eliminate places where an eavesdropper could track the mobile node's to eliminate places where an eavesdropper could track the mobile node's
movement by correlating home address and care of address. movement by correlating home address and care of address.
The requirement is that the location information should not be revealed to In order to reduce the risk from location privacy compromises as a result of
nor deduced by the correspondent node without the authorization of the IP address changes, the goal for NETLMM is to remove the need to change IP
mobile node's owner as long as the mobile node remains within the localized address as mobile node moves across IP links. Keeping the IP address fixed
mobility management domain. Since the localized mobility management protocol removes any possibility for the correspondent node to deduce the precise
is responsible for the mobile node mobility within the localized mobility geographic location of the mobile node without the user's authorization, as
management domain, it should conceal the geographical movement of the mobile well as any possibility that malware on the mobile node could inadvertently
node. reveal the mobile node's location to an attacker. Note that keeping the
address constant doesn't completely remove the possibility of deducing the
geographical location, since a local address still is required. However, it
does allow the network to be deployed such that the mapping between the
geographic and topological location is considerably less precise. If the
mapping is not precise, an attacker can only deduce in real time that the
mobile node is somewhere in a large geographic area, like, for example, a
metropolitan region or even a small country, reducing the possibility that
the attacker can cause harm to the user.
2.4 Efficient Use of Wireless Resources (Requirement #4) 2.4 Efficient Use of Wireless Resources (Goal #4)
Advances in wireless PHY and MAC technology continue to increase the Advances in wireless PHY and MAC technology continue to increase the
bandwidth available from limited wireless spectrum, but even with technology bandwidth available from limited wireless spectrum, but even with technology
increases, wireless spectrum remains a limited resource. Unlike wired increases, wireless spectrum remains a limited resource. Unlike wired
network links, wireless links are constrained in the number of bits/Hertz by network links, wireless links are constrained in the number of bits/Hertz by
their coding technology and use of physical spectrum, which is fixed by the their coding technology and use of physical spectrum, which is fixed by the
PHY. It is not possible to lay an extra cable if the link becomes PHY. It is not possible to lay an extra cable if the link becomes
increasingly congested as is the case with wired links. increasingly congested as is the case with wired links.
Some existing localized mobility management solutions increase packet size Some existing localized mobility management solutions increase packet size
over the wireless link by adding tunneling or other per packet overhead. over the wireless link by adding tunneling or other per packet overhead.
While header compression technology can remove header overhead, header While header compression technology can remove header overhead, header
compression does not come without cost. Requiring header compression on the compression does not come without cost. Requiring header compression on the
wireless access points increases the cost and complexity of the access wireless access points increases the cost and complexity of the access
points, and increases the amount of processing required for traffic across points, and increases the amount of processing required for traffic across
the wireless link. Since the access points tend to be a critical bottleneck the wireless link. Since the access points tend to be a critical bottleneck
in wireless access networks for real time traffic (especially on the in wireless access networks for real time traffic (especially on the
downlink), reducing the amount of per-packet processing is important. While downlink), reducing the amount of per-packet processing is important. While
header compression probably cannot be completely eliminated, especially for header compression probably cannot be completely eliminated, especially for
real time media traffic, simplifying compression to reduce processing cost real time media traffic, simplifying compression to reduce processing cost
is an important requirement. is an important goal.
The requirement is that the localized mobility management protocol should The goal is that the localized mobility management protocol should not
not introduce any new signaling or increase existing signaling over the air. introduce any new signaling or increase existing signaling over the air.
2.5 Reduction of Signaling Overhead in the Network (Requirement #5) 2.5 Reduction of Signaling Overhead in the Network (Goal #5)
While bandwidth and router processing resources are typically not as While bandwidth and router processing resources are typically not as
constrained in the wired network, wired networks tend to have higher constrained in the wired network, wired networks tend to have higher
bandwidth and router processing constraints than the backbone. These bandwidth and router processing constraints than the backbone. These
constraints are a function of the cost of laying fiber or wiring to the constraints are a function of the cost of laying fiber or wiring to the
wireless access points in a widely dispersed geographic area. Therefore, any wireless access points in a widely dispersed geographic area. Therefore, any
solutions for localized mobility management should minimize signaling within solutions for localized mobility management should minimize signaling within
the wired network as well. the wired network as well.
2.6 No Extra Security Between Mobile Node and Network (Requirement #6) 2.6 No Extra Security Between Mobile Node and Network (Goal #6)
Localized mobility management protocols that have signaling between the Localized mobility management protocols that have signaling between the
mobile node and network require a security association between the mobile mobile node and network require a security association between the mobile
node and the network entity that is the target of the signaling. node and the network entity that is the target of the signaling.
Establishing a security association specifically for localized mobility Establishing a security association specifically for localized mobility
service in a roaming situation may prove difficult, because provisioning a service in a roaming situation may prove difficult, because provisioning a
mobile node with security credentials for authenticating and authorizing mobile node with security credentials for authenticating and authorizing
localized mobility service in each roaming partner's network may be localized mobility service in each roaming partner's network may be
unrealistic from a deployment perspective. Reducing the complexity of mobile unrealistic from a deployment perspective. Reducing the complexity of mobile
node to network security for localized mobility management can therefore node to network security for localized mobility management can therefore
skipping to change at page 7, line 17 skipping to change at page 6, line 47
the mobility anchor point. The network infrastructural element therefore the mobility anchor point. The network infrastructural element therefore
becomes a possible target for DoS attacks, even if mobile nodes are properly becomes a possible target for DoS attacks, even if mobile nodes are properly
authenticated. A properly authenticated mobile node can either willfully or authenticated. A properly authenticated mobile node can either willfully or
inadvertently give the network infrastructural element address to an inadvertently give the network infrastructural element address to an
attacker. attacker.
In summary, ruling out mobile node involvement in local mobility management In summary, ruling out mobile node involvement in local mobility management
simplifies security by removing the need for service-specific credentials to simplifies security by removing the need for service-specific credentials to
authenticate and authorize the mobile node for localized mobility management authenticate and authorize the mobile node for localized mobility management
in the network and by limiting the possibility of DoS attacks on network in the network and by limiting the possibility of DoS attacks on network
infrastructural elements. The requirement is that support for localized infrastructural elements. The goal is that support for localized mobility
mobility management should not require additional security between the management should not require additional security between the mobile node
mobile node and the network. and the network.
2.7 Support for Heterogeneous Wireless Link Technologies (Requirement #7) 2.7 Support for Heterogeneous Wireless Link Technologies (Goal #7)
The number of wireless link technologies available is growing, and the The number of wireless link technologies available is growing, and the
growth seems unlikely to slow down. Since the standardization of a wireless growth seems unlikely to slow down. Since the standardization of a wireless
link PHY and MAC is a time consuming process, reducing the amount of work link PHY and MAC is a time consuming process, reducing the amount of work
necessary to interface a particular wireless link technology to an IP necessary to interface a particular wireless link technology to an IP
network is necessary. A localized mobility management solution should network is necessary. A localized mobility management solution should
ideally require minimal work to interface with a new wireless link ideally require minimal work to interface with a new wireless link
technology. technology.
In addition, an edge mobility solution should provide support for multiple In addition, an edge mobility solution should provide support for multiple
skipping to change at page 7, line 43 skipping to change at page 7, line 21
required that the localized mobility management solution support handover required that the localized mobility management solution support handover
from one wireless link technology to another without change in IP address. from one wireless link technology to another without change in IP address.
The reason is because a change in network interface typically requires that The reason is because a change in network interface typically requires that
the hardware interface associated with one wireless link technology be the hardware interface associated with one wireless link technology be
brought up and configured, and this process typically requires that the IP brought up and configured, and this process typically requires that the IP
stack for the new interface card be configured on the mobile node from the stack for the new interface card be configured on the mobile node from the
driver up. Requiring that the mobile node IP stack circumvent this process driver up. Requiring that the mobile node IP stack circumvent this process
to keep the IP address constant would be a major change in the way the IP to keep the IP address constant would be a major change in the way the IP
stack software is implemented. stack software is implemented.
The requirement is that the localized mobility management protocol should The goal is that the localized mobility management protocol should not use
not use any wireless link specific information for basic routing management, any wireless link specific information for basic routing management, though
though it may be used for other purposes, such as identifying a mobile node. it may be used for other purposes, such as identifying a mobile node.
2.8 Support for Unmodified Mobile Nodes (Requirement #8) 2.8 Support for Unmodified Mobile Nodes (Goal #8)
In the wireless LAN switching market, no modification of the software on the In the wireless LAN switching market, no modification of the software on the
mobile node is required to achieve "IP mobility" (which means localized mobile node is required to achieve "IP mobility" (which means localized
mobility management). Being able to accommodate unmodified mobile nodes mobility management). Being able to accommodate unmodified mobile nodes
enables a service provider to offer service to as many customers as enables a service provider to offer service to as many customers as
possible, the only constraint being that the customer is authorized for possible, the only constraint being that the customer is authorized for
network access. network access.
Another advantage of minimizing mobile node software for localized mobility Another advantage of minimizing mobile node software for localized mobility
management is that multiple global mobility management protocols can be management is that multiple global mobility management protocols can be
supported with a localized mobility management solution that does not have supported with a localized mobility management solution that does not have
mobile node involvement. While Mobile IPv6 is clearly the global mobility mobile node involvement. While Mobile IPv6 is clearly the global mobility
management protocol of primary interest going forward, there are a variety management protocol of primary interest going forward, there are a variety
of global mobility management protocols that might also need support, of global mobility management protocols that might also need support,
including proprietary protocols needing support for backward compatibility including proprietary protocols needing support for backward compatibility
reasons. Within IETF, both HIP and Mobike are likely to need support in reasons. Within IETF, both HIP and Mobike are likely to need support in
addition to Mobile IPv6, and Mobile IPv4 support may also be necessary. addition to Mobile IPv6, and Mobile IPv4 support may also be necessary.
Note that this requirement does NOT mean that the mobile node has no Note that this goal does NOT mean that the mobile node has no software at
software at all associated with mobility or wireless. The mobile node must all associated with mobility or wireless. The mobile node must have some
have some kind of global mobility protocol if it is to move from one domain kind of global mobility protocol if it is to move from one domain of edge
of edge mobility support to another, although no global mobility protocol is mobility support to another, although no global mobility protocol is
required if the mobile node only moves within the coverage area of the required if the mobile node only moves within the coverage area of the
localized mobility management protocol. Also, every wireless link protocol localized mobility management protocol. Also, every wireless link protocol
requires handover support on the mobile node in the physical and MAC layers, requires handover support on the mobile node in the physical and MAC layers,
typically in the wireless interface driver. Information passed from the MAC typically in the wireless interface driver. Information passed from the MAC
layer to the IP layer on the mobile nodenode may be necessary to trigger IP layer to the IP layer on the mobile node may be necessary to trigger IP
signaling for IP link handover. Such movement detection support at the IP signaling for IP link handover. Such movement detection support at the IP
level may be required in order to determine whether the mobile node's level may be required in order to determine whether the mobile node's
default router is still reachable after the move to a new access point has default router is still reachable after the move to a new access point has
occurred at the MAC layer. Whether or not such support is required depends occurred at the MAC layer. Whether or not such support is required depends
on whether the MAC layer can completely hide link movement from the IP on whether the MAC layer can completely hide link movement from the IP
layer. For a wireless link protocol such as the 3G protocols, the mobile layer. For a wireless link protocol such as the 3G protocols, the mobile
node and network undergo an extensive negotiation at the MAC layer prior to node and network undergo an extensive negotiation at the MAC layer prior to
handover, so it may be possible to trigger routing update without any IP handover, so it may be possible to trigger routing update without any IP
protocol involvement. However, for a wireless link protocol such as IEEE protocol involvement. However, for a wireless link protocol such as IEEE
802.11 in which there is no network involvement in handover, IP layer 802.11 in which there is no network involvement in handover, IP layer
movement detection signaling from the mobile node may be required to trigger movement detection signaling from the mobile node may be required to trigger
routing update. routing update.
The requirement is that the localized mobility management solution should be The goal is that the localized mobility management solution should be able
able to support any mobile node that walks up to the link and has a wireless to support any mobile node that walks up to the link and has a wireless
interface that can communicate with the network, without requiring localized interface that can communicate with the network, without requiring localized
mobility management software on the mobile node. mobility management software on the mobile node.
2.9 Support for IPv4 and IPv6 (Requirement #9) 2.9 Support for IPv4 and IPv6 (Goal #9)
While most of this document is written with IPv6 in mind, localized mobility While most of this document is written with IPv6 in mind, localized mobility
management is a problem in IPv4 networks as well. A solution for localized management is a problem in IPv4 networks as well. A solution for localized
mobility that works for both versions of IP is desirable, though the actual mobility that works for both versions of IP is desirable, though the actual
protocol may be slightly different due to the technical details of how each protocol may be slightly different due to the technical details of how each
IP version works. From Requirement #8 (Section 2.8), minimizing mobile node IP version works. From Goal #8 (Section 2.8), minimizing mobile node support
support for localized mobility means that ideally no IP version-specific for localized mobility means that ideally no IP version-specific changes
changes would be required on the mobile node for localized mobility, and would be required on the mobile node for localized mobility, and that global
that global mobility protocols for both IPv4 and IPv6 should be supported. mobility protocols for both IPv4 and IPv6 should be supported. Any IP
Any IP version-specific features would be confined to the network protocol. version-specific features would be confined to the network protocol.
2.10 Re-use of Existing Protocols Where Sensible (Goal #10)
Many existing protocols are available as Internet Standards upon which the
NETLMM protocol can be built. The design of the protocol should have a goal
to re-use existing protocols where it makes architectural and engineering
sense to do so. The design should not, however, attempt to re-use existing
protocols where there is no real architectural or engineering reason. For
example, the suite of Internet Standards contains several good candidate
protocols for the transport layer, so there is no real need to develop a new
transport protocol specifically for NETLMM. Re-use is clearly a good
engineering decision in this case, since backward compatibility with
existing protocol stacks is important. On the other hand, the network-based,
localized mobility management functionality being introduced by NETLMM is a
new piece of functionality, and therefore any decision about whether to re-
use an existing global mobility management protocol should carefully
consider whether re-using such a protocol really meets the needs of the
functional architecture for network-based localized mobility management. The
case for re-use is not so clear in this case, since there is no compelling
backward compatibility argument.
3.0 Security Considerations
There are two kinds of security issues involved in network-based localized
mobility management: security between the mobile node and the network, and
security between network elements that participate in the network-based
localized mobility management protocol
Security between the mobile node and the network itself consists of two
parts: threats involved in localized mobility management in general, and
threats to the network-based localized mobility management from the host.
The first is discussed above in Sections 2.3 and 2.6. The second is
discussed in the threat analysis document [28].
For threats to network-based localized mobility management, the basic threat
is an attempt by an unauthorized party to signal a bogus mobility event.
Such an event must be detectable. This requires proper bidirectional
authentication and authorization of network elements that participate in the
network-based localized mobility management protocol, and data origin
authentication on the signaling traffic between network elements.
4.0 Author Information
James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com
Phil Roberts
Motorola Labs
Schaumberg, IL
USA
Email: phil.roberts@motorola.com
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 Torino
Italy
Phone: +39 011 2286904
Email: gerardo.giaretta@tilab.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de
5.0 Informative References
[1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch,
M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet
Draft, work in progress.
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based Localized
Mobillity Management", Internet draft, work in progress.
[3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753,
June, 2004.
[4] Devarapalli,V., Wakikawa, R., Petrescu, A., Thubert, P., "Network
Mobility (NEMO) Basic Support Protocol", RFC 3963, January, 2005.
[5] Carpenter, B., "Architectural Principles of the Internet," RFC 1958,
June, 1996.
[6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6",
RFC 3775.
[7] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host
Identity Protocol", Internet Draft, work in progress.
[8] Choi, J, and Daley, G., "Goals of Detecting Network Attachment in
IPv6", Internet Draft, work in progress.
[9] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June,
2001.
[10] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A.,
"Protocol for Carrying Authentication for Network Access (PANA)",
Internet Draft, work in progress.
[11] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor
Discovery (SEND)", RFC 3971, March, 2005.
[12] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work in
Progress.
[13] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law
and Policy in the US, EU, and Japan", ISOC Member Briefing #15,
http://www.isoc.org/briefings/015/index.shtml
[14] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and
Patil, B., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem
Statement", Internet Draft, work in progress.
[15] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol",
Internet Draft, work in progress.
[16] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet
Draft, work in progress.
[17] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., "Solutions
for IP Address Location Privacy in the presence of IP Mobility",
Internet Draft, work in progress.
[18] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol for
Protecting Movement of Mobile Nodes in Mobile IPv6", Internet Draft,
work in progress.
[19] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H.,
Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for
Hosts and Routers", Internet Draft, work in progress.
[20] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July,
2005.
[21] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140,
August, 2005.
[22] Kempf, J., and Koodli, R., "Bootstrapping a Symmetric IPv6 Handover Key
from SEND", Internet Draft, work in progress.
[23] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design,
Implementation and Evaluation of Cellular IP", IEEE Personal
Communications, June/July 2000.
[24] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A
domain-based approach for supporting mobility in wide-area wireless
networks", in Proceedings of the International Conference on Networking
Protocols (ICNP), 1999.
[25] "Mobile VPN Network Configuration Alternatives", IP Unplugged,
http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
[26] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142,
Feburary, 1990.
[27] Moy, J., "OSPF Version 2", STD 54, April, 1998.
[28] Threat analysis draft, TBD
6.0 IPR Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might
not be available; nor does it represent that it has made any independent
effort to identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of
licenses to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the IETF
on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights that
may cover technology that may be required to implement this standard.
Please address the information to the IETF at ietf-ipr@ietf.org.
7.0 Disclaimer of Validity
This document and the information contained herein are provided on an "AS
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
8.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
9.0 Appendix: Gap Analysis
3.0 Gap Analysis
This section discusses a gap analysis between existing proposals for solving This section discusses a gap analysis between existing proposals for solving
localized mobility management and the requirements in Section. 2.0. localized mobility management and the goals in Section. 2.0.
3.1 Mobile IPv6 with Local Home Agent 9.1 Mobile IPv6 with Local Home Agent
One option is to deploy Mobile IPv6 with a locally assigned home agent in One option is to deploy Mobile IPv6 with a locally assigned home agent in
the local network. This solution requires the mobile node to somehow be the local network. This solution requires the mobile node to somehow be
assigned a home agent in the local network when it boots up. This home agent assigned a home agent in the local network when it boots up. This home agent
is used instead of the home agent in the home network. The advantage of this is used instead of the home agent in the home network. The advantage of this
option is that the no special solution is required for edge mobility - the option is that no special solution is required for edge mobility - the
mobile node reuses the global mobility management protocol for that purpose mobile node reuses the global mobility management protocol for that purpose
- if the mobile node is using Mobile IPv6. One disadvantage is that Mobile - if the mobile node is using Mobile IPv6. One disadvantage is that Mobile
IP has no provision for handover between home agents. Although such handover IP has no provision for handover between home agents. Although such handover
should be infrequent, it could be quite lengthy and complex. should be infrequent, it could be quite lengthy and complex.
The analysis of this approach against the requirements above is the The analysis of this approach against the goals above is the following.
following.
Requirement #1: If the mobile node does not perform route optimization, this Goal #1: If the mobile node does not perform route optimization, this
solution reduces, but does not eliminate, IP link handover related solution reduces, but does not eliminate, IP link handover related
performance problems. performance problems.
Requirement #2: Similarly to Requirement #1, signaling volume is reduced if Goal #2: Similarly to Goal #1, signaling volume is reduced if no route
no route optimization signaling is done on handover. optimization signaling is done on handover.
Requirement #3: Location privacy is preserved for external correspondents, Goal #3: Location privacy is preserved for external correspondents, but the
but the mobile node itself still maintains a local care-of address which a mobile node itself still maintains a local care-of address which a worm or
worm or other exploit could misuse. If the mobile node does perform route other exploit could misuse. If the mobile node does perform route
optimization, location privacy may be compromised, and this solution is no optimization, location privacy may be compromised, and this solution is no
better than having a remote home agent. better than having a remote home agent.
Requirement #4: If traffic is not route optimized, the mobile node still Goal #4: If traffic is not route optimized, the mobile node still pays for
pays for an over-the-air tunnel to the locally assigned home agent. The an over-the-air tunnel to the locally assigned home agent. The overhead here
overhead here is exactly the same as if the mobile node's home agent in the is exactly the same as if the mobile node's home agent in the home network
home network is used and route optimization is not done. is used and route optimization is not done.
Requirement #5: If the localized mobility management domain is large, the Goal #5: If the localized mobility management domain is large, the mobile
mobile node may suffer from unoptimzed routes since handover and mobility node may suffer from unoptimzed routes. RFC 3775 [6] provides no support for
between home agents is not supported. notifying a mobile node that another localized home agent is available for a
more optimized route, or for handing over between home agents. A mobile node
would have to perform the full home agent bootstrap procedure, including
establishing a new IPsec SA with the new home agent.
Requirement #6: A local home agent in a roaming situation requires the guest Goal #6: A local home agent in a roaming situation requires the guest mobile
mobile node to have the proper credentials to authenticate with the local node to have the proper credentials to authenticate with the local home
home agent in the serving network. In addition, as in Requirement #3, the agent in the serving network. Although the credentials used for network
local home agent's address could become the target of a DoS attack if access authentication could also be used for mobile service authentication
revealed to an attacker. So a local home agent would provide no benefit for and authorization if the local home agent uses EAP over IKEv2 to
this requirement. authenticate the mobile node with its home AAA server, the two sets of
credentials are in principle different, and could require additional
credential provisioning. In addition, as in Goal #3, if binding updates are
done in cleartext over the access network or the mobile node has become
infected with malware, the local home agent's address could be revealed to
attackers and the local home agent could become the target of a DoS attack.
So a local home agent would provide no benefit for this goal.
Requirement #7: This solution supports multiple wireless technologies in Goal #7: This solution supports multiple wireless technologies in separate
separate IP link subnets. No special work is required to interface a local IP link subnets. No special work is required to interface a local home agent
home agent to different wireless technologies. to different wireless technologies.
Requirement #8: The mobile node must support Mobile IPv6 in order for this Goal #8: The mobile node must support Mobile IPv6 in order for this option
option to work. So mobile node changes are required and other IP mobility to work. So mobile node changes are required and other IP mobility protocols
protocols are not supported. are not supported.
Requirement #9: This solution requires separate locally assigned home agents Goal #9: The Mobile IPv6 working group is working on modifying the protocol
for Mobile IPv4 and Mobile IPv6 since the local home agent should have MIP to allow registration of IPv4 care-of addresses in an IPv6 home agent, and
functions or IPv4 or IPv6 in conjunction with IP version of global mobility also to allow a mobile node to have an IPv4 care of address [19].
protocol, or some way to register an IPv4 care of address to home address
mapping in an Mobile IPv6 home agent. While there are a couple of proposals
currently active in the IETF for this (see [18] for one), it is not clear at
this point whether they will be adopted for standards track development.
3.2 Hierarchical Mobile IPv6 (HMIPv6) Goal #10 This solution re-uses an existing protocol, Mobile IPv6.
HMIPv6 [20] provides the most complete localized mobility management 9.2 Hierarchical Mobile IPv6 (HMIPv6)
solution available today as an Internet RFC. In HMIPv6, a localized mobility
anchor called a MAP serves as a routing anchor for a regional care-of HMIPv6 [21] provides the most complete localized mobility management
address. When a mobile node moves from one access router to another, the solution available today as an RFC. In HMIPv6, a localized mobility anchor
mobile node changes the binding between its regional care-of address and called a MAP serves as a routing anchor for a regional care-of address. When
local care-of address at the MAP. No global mobility management signaling is a mobile node moves from one access router to another, the mobile node
required, since the care-of address seen by correspondents does not change. changes the binding between its regional care-of address and local care-of
This part of HMIPv6 is similar to the solution outlined in Section 3.1; address at the MAP. No global mobility management signaling is required,
however, HMIPv6 also allows a mobile node to hand over between MAPs. since the care-of address seen by correspondents does not change. This part
of HMIPv6 is similar to the solution outlined in Section 9.1; however,
HMIPv6 also allows a mobile node to hand over between MAPs.
Handover between MAPs and MAP discovery requires configuration on the Handover between MAPs and MAP discovery requires configuration on the
routers. MAP addresses are advertised by access routers. Handover happens by routers. MAP addresses are advertised by access routers. Handover happens by
overlapping MAP coverage areas so that, for some number of access routers, overlapping MAP coverage areas so that, for some number of access routers,
more than one MAP may be advertised. Mobile nodes need to switch MAPs in the more than one MAP may be advertised. Mobile nodes need to switch MAPs in the
transition area, and then must perform global mobility management update and transition area, and then must perform global mobility management update and
route optimization to the new regional care-of address, if appropriate. route optimization to the new regional care-of address, if appropriate.
The analysis of this approach against the requirements above is the The analysis of this approach against the goals above is the following.
following.
Requirement #1 This solution shortens, but does not eliminate, the latency Goal #1 This solution shortens, but does not eliminate, the latency
associated with IP link handover, since it reduces the amount of signaling associated with IP link handover, since it reduces the amount of signaling
and the length of the signaling paths. and the length of the signaling paths.
Requirement #2 Signaling volume is reduced simply because no route Goal #2 Signaling volume is reduced simply because no route optimization
optimization signaling is done on handover within the coverage area of the signaling is done on handover within the coverage area of the MAP.
MAP.
Requirement #3 Location privacy is preserved for external correspondents, Goal #3 Location privacy is preserved for external correspondents, but the
but the mobile node itself still maintains a local care-of address which a mobile node itself still maintains a local care-of address which a worm or
worm or other exploit could access by sending the local care-of address to other exploit could access by sending the local care-of address to third
third malicious node to enable it to track the mobile node's location. malicious node to enable it to track the mobile node's location.
Requirement #4 The mobile node always pays for an over-the-air tunnel to the Goal #4 The mobile node always pays for an over-the-air tunnel to the MAP.
MAP. If the mobile node is tunneling through a global home agent or VPN If the mobile node is tunneling through a global home agent or VPN gateway,
gateway, the wired link experiences double tunneling. Over-the-air tunnel the wired link experiences double tunneling. Over-the-air tunnel overhead
overhead can be removed by header compression, however. can be removed by header compression, however.
Requirement #5 From Requirement #1 and Requirement #4, the signaling Goal #5 From Goal #1 and Goal #4, the signaling overhead is no more or less
overhead is no more or less than for mobile nodes whose global mobility than for mobile nodes whose global mobility management anchor is local.
management anchor is local. However, because MAP handover is possible, However, because MAP handover is possible, routes across large localized
routes across large localized mobility management domains can be improved mobility management domains can be improved thereby improving wired network
thereby improving wired network resource utilization by using multiple MAPs resource utilization by using multiple MAPs and handing over, at the expense
and handing over, at the expense of the configuration and management of the configuration and management overhead involved in maintaining
overhead involved in maintaining multiple MAP coverage areas. multiple MAP coverage areas.
Requirement #6 In a roaming situation, the guest mobile node must have the Goal #6 In a roaming situation, the guest mobile node must have the proper
proper credentials to authenticate with the MAP in the serving network. In credentials to authenticate with the MAP in the serving network. In
addition, since the mobile node is required to have a unicast address for addition, since the mobile node is required to have a unicast address for
the MAP that is either globally routed or routing restricted to the local the MAP that is either globally routed or routing restricted to the local
administrative domain, the MAP is potentially a target for DoS attacks administrative domain, the MAP is potentially a target for DoS attacks
across a wide swath of network topology. across a wide swath of network topology.
Requirement #7 This solution supports multiple wireless technologies in Goal #7 This solution supports multiple wireless technologies in separate IP
separate IP link subnets. link subnets.
Requirement #8 This solution requires modification to the mobile nodes. In Goal #8 This solution requires modification to the mobile nodes. In
addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes,
and is not a good match for other global mobility management protocols. and is not a good match for other global mobility management protocols.
Requirement #9 Currently, there is no IPv4 version of this protocol; Goal #9 Currently, there is no IPv4 version of this protocol; although there
although there is an expired Internet draft with a design for a regional is an expired Internet draft with a design for a regional registration
registration protocol for Mobile IPv4 that has similar functionality. protocol for Mobile IPv4 that has similar functionality. It is possible that
the same IPv4 transition solution as used for Mobile IPv6 could be used
[19].
3.3 Combinations of Mobile IPv6 with Optimizations Goal #10 This solution re-uses an existing protocol, HMIPv6.
9.3 Combinations of Mobile IPv6 with Optimizations
One approach to local mobility that has received much attention in the past One approach to local mobility that has received much attention in the past
and has been thought to provide a solution is combinations of protocols. The and has been thought to provide a solution is combinations of protocols. The
general approach is to try to cover gaps in the solution provided by MIPv6 general approach is to try to cover gaps in the solution provided by MIPv6
by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6 by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6
and HMIPv6 + FMIPv6 are discussed. and HMIPv6 + FMIPv6 are discussed.
3.3.1 MIPv6 + FMIPv6 9.3.1 MIPv6 + FMIPv6
As discussed in Section 3.1, the use of MIPv6 with a dynamically assigned, As discussed in Section 9.1, the use of MIPv6 with a dynamically assigned,
local home agent cannot fulfill the requirements. A fundamental limitation local home agent cannot fulfill the goals. A fundamental limitation is that
is that Mobile IPv6 cannot provide seamless handover (i.e. Requirement #1). Mobile IPv6 cannot provide seamless handover (i.e. Goal #1). FMIPv6 has been
FMIPv6 has been defined with the intent to improve the handover performance defined with the intent to improve the handover performance of MIPv6. For
of MIPv6. For this reason, the combined usage of FMIPv6 and MIPv6 with a this reason, the combined usage of FMIPv6 and MIPv6 with a dynamically
dynamically assigned local home agent has been proposed to handle local assigned local home agent has been proposed to handle local mobility.
mobility.
Note that this gap analysis only applies to localized mobility management, Note that this gap analysis only applies to localized mobility management,
and it is possible that MIPv6 and FMIPv6 might still be acceptable for and it is possible that MIPv6 and FMIPv6 might still be acceptable for
global mobility management. global mobility management.
The analysis of this combined approach against the requirements follows. The analysis of this combined approach against the goals follows.
Requirement #1 FMIPv6 provides a solution for handover performance Goal #1 FMIPv6 provides a solution for handover performance improvement that
improvement that should fulfill the requirements raised by real-time should fulfill the goals raised by real-time applications in terms of
applications in terms of jitter, delay and packet loss. The location of the jitter, delay and packet loss. The location of the home agent (in local or
home agent (in local or home domain) does not affect the handover latency. home domain) does not affect the handover latency.
Requirement #2 FMIPv6 requires the mobile node to perform extra signaling with the Goal #2 FMIPv6 requires the mobile node to perform extra signaling with the
access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
in standard MIPv6, whenever the mobile node moves to another IP link, it in standard MIPv6, whenever the mobile node moves to another IP link, it
must send a Binding Update to the home agent. If route optimization is used, must send a Binding Update to the home agent. If route optimization is used,
the mobile node also performs return routability and sends a Binding Update the mobile node also performs return routability and sends a Binding Update
to each correspondent node. Nonetheless, it is worth noting that FMIPv6 to each correspondent node. Nonetheless, it is worth noting that FMIPv6
should result in a reduction of the amount of IPv6 Neighbor Discovery should result in a reduction of the amount of IPv6 Neighbor Discovery
signaling on the new link. signaling on the new link.
Requirement #3 The mobile node mantains a local care-of address. If route Goal #3 The mobile node mantains a local care-of address. If route
optimization is not used, location privacy can be achieved using bi- optimization is not used, location privacy can be achieved using bi-
directional tunneling. However, as mentioned in Section 3.1, a worm or other directional tunneling. However, as mentioned in Section 9.1, a worm or other
malware can exploit this care of address by sending it to a third malicious malware can exploit this care of address by sending it to a third malicious
node. node.
Requirement #4 As stated for Requirement #2, the combination of MIPv6 and Goal #4 As stated for Goal #2, the combination of MIPv6 and FMIPv6 generates
FMIPv6 generates extra signaling overhead. For data packets, in addition to extra signaling overhead. For data packets, in addition to the Mobile IPv6
the Mobile IPv6 over-the-air tunnel, there is a further level of tunneling over-the-air tunnel, there is a further level of tunneling between the
between the mobile node and the previous access router during handover. This mobile node and the previous access router during handover. This tunnel is
tunnel is needed to forward incoming packets to the mobile node addressed to needed to forward incoming packets to the mobile node addressed to the
the previous care-of address. Another reason is that, even if the mobile previous care-of address. Another reason is that, even if the mobile node
node has a valid new care-of address, the mobile node cannot use the new has a valid new care-of address, the mobile node cannot use the new care of
care of address directly with its correspondents without performing route address directly with its correspondents without performing route
optimization to the new care of address. This implies that the transient optimization to the new care of address. This implies that the transient
tunnel overhead is in place even for route optimized traffic. tunnel overhead is in place even for route optimized traffic.
Requirement #5 FMIPv6 generates extra signaling overhead between previous Goal #5 FMIPv6 generates extra signaling overhead between the previous
the access router and the new access router for the HI/HAck exchange. access router and the new access router for the HI/HAck exchange. Concerning
Concerning data packets, the use of FMIPv6 for handover performance data packets, the use of FMIPv6 for handover performance improvement implies
improvement implies a tunnel between the previous access router and the a tunnel between the previous access router and the mobile node that adds
mobile node that adds some overhead in the wired network. This overhead has some overhead in the wired network. This overhead has more impact on star
more impact on star topology deployments, since packets are routed down to topology deployments, since packets are routed down to the old access
the old access router, then back up to the aggregation router and then back router, then back up to the aggregation router and then back down to the new
down to the new access router. access router.
Requirement #6 In addition to the analysis for Mobile IPv6 with local home Goal #6 In addition to the analysis for Mobile IPv6 with local home agent in
agent in Section 3.1, FMIPv6 requires the mobile node and the previous Section 9.1, FMIPv6 requires the mobile node and the previous access router
access router to share a security association in order to secure FBU/FBA to share a security association in order to secure FBU/FBA exchange. So far,
exchange. So far, only a SEND-based solution has been proposed and this only a SEND-based solution has been proposed and this requires the mobile
requires the mobile node to use autoconfigured Cryptographically Generated Addresses node to use autoconfigured Cryptographically Generated Addresses (CGAs)[22].
(CGAs)[21]. This precludes stateful address allocation using DHCP, which This precludes stateful address allocation using DHCP, which might be a
might be a necessary deployment in certain circumstances. Another solution necessary deployment in certain circumstances. Another solution based on AAA
based on AAA is under study but it could require extra signaling overhead is under study but it could require extra signaling overhead over the air
over the air and in the wired network and it could raise performance issues. and in the wired network and it could raise performance issues.
Requirement #7 MIPv6 and FMIPv6 support multiple wireless technologies, so Goal #7 MIPv6 and FMIPv6 support multiple wireless technologies, so this
this requirement is fufilled. goal is fufilled.
Requirement #8 The mobile node must support both MIPv6 and FMIPv6, so it is Goal #8 The mobile node must support both MIPv6 and FMIPv6, so it is not
not possible to satisfy this requirement. possible to satisfy this goal.
Requirement #9 Work is underway to extend MIPv6 with the capability to run Goal #9 Work is underway to extend MIPv6 with the capability to run over
over both IPv6-enabled and IPv4-only networks [18]. FMIPv6 only supports both IPv6-enabled and IPv4-only networks [19]. FMIPv6 only supports IPv6.
IPv6. Even though an IPv4 version of FMIP has been recently proposed, it is Even though an IPv4 version of FMIP has been recently proposed, it is not
not clear how it could be used together with FMIPv6 in order to handle fast clear how it could be used together with FMIPv6 in order to handle fast
handovers across any wired network. handovers across any wired network.
3.3.2 HMIPv6 + FMIPv6 Goal #10 This solution re-uses existing protocols, Mobile IPv6 and FMIPv6.
9.3.2 HMIPv6 + FMIPv6
HMIPv6 provides several advantages in terms of local mobility management. HMIPv6 provides several advantages in terms of local mobility management.
However, as seen in Section 3.2, it does not fulfill all the requirements However, as seen in Section 9.2, it does not fulfill all the goals
identified in Section 2.0. In particular, HMIPv6 does not completely identified in Section 2.0. In particular, HMIPv6 does not completely
eliminate the IP link handover latency. For this reason, FMIPv6 could be eliminate the IP link handover latency. For this reason, FMIPv6 could be
used together with HMIPv6 in order to cover the gap. used together with HMIPv6 in order to cover the gap.
Note that even if this solution is used, the mobile node is likely to need Note that even if this solution is used, the mobile node is likely to need
MIPv6 for global mobility management, in contrast with the MIPv6 with MIPv6 for global mobility management, in contrast with the MIPv6 with
dynamically assigned local home agent + FMIPv6 solution. Thus, this solution dynamically assigned local home agent + FMIPv6 solution. Thus, this solution
should really be considered MIPv6 + HMIPv6 + FMIPv6. should really be considered MIPv6 + HMIPv6 + FMIPv6.
The analysis of this combined approach against the requirements follows. The analysis of this combined approach against the goals follows.
Requirement #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP Goal #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP link
link handovers. In particular, FMIPv6 is expected to fulfill the handovers. In particular, FMIPv6 is expected to fulfill the goals on jitter,
requirements on jitter, delay and packet loss raised by real-time delay and packet loss raised by real-time applications.
applications.
Requirement #2 Both FMIPv6 and HMIPv6 require extra signaling compared with Goal #2 Both FMIPv6 and HMIPv6 require extra signaling compared with Mobile
Mobile IPv6. As a whole the mobile node performs signaling message exchanges IPv6. As a whole the mobile node performs signaling message exchanges at
at each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. However,
However, as mentioned in Section 3.2, the use of HMIPv6 reduces the as mentioned in Section 9.2, the use of HMIPv6 reduces the signaling
signaling overhead since no route optimization signaling is done for intra- overhead since no route optimization signaling is done for intra-MAP
MAP handovers. In addition, na´ve combinations of FMIPv6 and HMIPv6 often handovers. In addition, na´ve combinations of FMIPv6 and HMIPv6 often result
result in redundant signaling. There is much work in the academic literature in redundant signaling. There is much work in the academic literature and
and the IETF on more refined ways of combining signaling from the two the IETF on more refined ways of combining signaling from the two protocols
protocols to avoid redundant signaling. to avoid redundant signaling.
Requirement #3 HMIPv6 may preserve location privacy, depending on the Goal #3 HMIPv6 may preserve location privacy, depending on the dimension of
dimension of the geographic area covered by the MAP. As discussed in Section the geographic area covered by the MAP. As discussed in Section 9.2, the
3.2, the mobile node still maintains a local care-of address that can be mobile node still maintains a local care-of address that can be exploited by
exploited by worms or other malware. worms or other malware.
Requirement #4 As mentioned for Requirement #2, the combination of HMIPv6 Goal #4 As mentioned for Goal #2, the combination of HMIPv6 and FMIPv6
and FMIPv6 generates a lot of signaling overhead in the network. Concerning generates a lot of signaling overhead in the network. Concerning payload
payload data, in addition to the over-the-air MIPv6 tunnel, a further level data, in addition to the over-the-air MIPv6 tunnel, a further level of
of tunneling is established between mobile node and MAP. Notice that this tunneling is established between mobile node and MAP. Notice that this
tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is
directly applied to HMIPv6 networks, there is a third temporary handover- directly applied to HMIPv6 networks, there is a third temporary handover-
related tunnel between the mobile node and previous access router. Again, related tunnel between the mobile node and previous access router. Again,
there is much work in the academic literature and IETF on ways to reduce the there is much work in the academic literature and IETF on ways to reduce the
extra tunnel overhead on handover by combining HMIP and FMIP tunneling. extra tunnel overhead on handover by combining HMIP and FMIP tunneling.
Requirement #5 The signaling overhead in the network is not reduced by Goal #5 The signaling overhead in the network is not reduced by HMIPv6, as
HMIPv6, as mentioned in Section 3.2. Instead, FMIPv6 generates extra mentioned in Section 9.2. Instead, FMIPv6 generates extra signaling overhead
signaling overhead between the previous access router and new access router between the previous access router and new access router for HI/HAck
for HI/HAck exchange. For payload data, the same considerations as for exchange. For payload data, the same considerations as for Goal #4 are
Requirement #4 are applicable. applicable.
Requirement #6 FMIPv6 requires the mobile node and the previous access Goal #6 FMIPv6 requires the mobile node and the previous access router to
router to share a security association in order to secure the FBU/FBA share a security association in order to secure the FBU/FBA exchange. In
exchange. In addition, HMIPv6 requires that the mobile node and MAP share an addition, HMIPv6 requires that the mobile node and MAP share an IPsec
IPsec security association in order to secure LBU/LBA exchange. The only security association in order to secure LBU/LBA exchange. The only well
well understood approach to set up an IPsec security association using of understood approach to set up an IPsec security association using of
certificates, but this may raise deployment issues. Thus, the combination of certificates, but this may raise deployment issues. Thus, the combination of
FMIPv6 and HMIPv6 doubles the amount of mobile node to network security FMIPv6 and HMIPv6 doubles the amount of mobile node to network security
protocol required, since security for both FMIP and HMIP must be deployed. protocol required, since security for both FMIP and HMIP must be deployed.
Requirement #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so Goal #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so this
this requirement is fufilled. goal is fufilled.
Requirement #8 The mobile node must support both HMIPv6 and FMIPv6 Goal #8 The mobile node must support both HMIPv6 and FMIPv6 protocols, so
protocols, so this requirement is not fulfilled. this goal is not fulfilled.
Requirement #9 Currently there is no IPv4 version of HMIPv6. There is an Goal #9 Currently there is no IPv4 version of HMIPv6. There is an IPv4
IPv4 version of FMIP but it is not clear how it could be used together with version of FMIP but it is not clear how it could be used together with
FMIPv6 in order to handle fast handovers across any wired network. FMIPv6 in order to handle fast handovers across any wired network.
3.4 Micromobility Protocols Goal #10 This solution re-uses existing protocols, HMIPv6 and FMIPv6.
9.4 Micromobility Protocols
Researchers have defined some protocols that are often characterized as Researchers have defined some protocols that are often characterized as
micromobility protocols. Two typical protocols in this category are micromobility protocols. Two typical protocols in this category are
Cellular-IP [22] and HAWAII [23]. Researchers defined these protocols before Cellular-IP [23] and HAWAII [24]. Researchers defined these protocols before
local mobility optimizations for Mobile IP such as FMIP and HMIP were local mobility optimizations for Mobile IP such as FMIP and HMIP were
developed, in order to reduce handover latency. developed, in order to reduce handover latency.
The micromobility approach to localized mobility management requires host
route propagation from the mobile node to a collection of specialized
routers in the localized mobility management domain along a path back to a
boundary router at the edge of the localized mobility management domain. A
boundary router is a kind of localized mobility management domain gateway.
Localized mobility management is authorized with the access router, but
reauthorization with each new access router is necessary on IP link
movement, in addition to any reauthorization for basic network access. The
host routes allow the mobile node to maintain the same IP address when it
moves to a new IP link, and still continue to receive packets on the new IP
link.
Cellular IP and HAWAII have a few things in common. Both are compatible Cellular IP and HAWAII have a few things in common. Both are compatible
with Mobile IP and are intended to provide a higher level of handover with Mobile IP and are intended to provide a higher level of handover
performance in local networks than was previously available with Mobile IP performance in local networks than was previously available with Mobile IP
without such extensions as HMIP and FMIP. Both use host routes installed in without such extensions as HMIP and FMIP. Both use host routes installed in
a number of routers within a restricted routing domain. Both define specific a number of routers within a restricted routing domain. Both define specific
messaging to update those routes along the forwarding path and specify how messaging to update those routes along the forwarding path and specify how
the messaging is to be used to update the routing tables and forwarding the messaging is to be used to update the routing tables and forwarding
tables along the path between the mobile and a micromobility domain boundary tables along the path between the mobile and a micromobility domain boundary
router at which point Mobile IP is to used to handle scalable global router at which point Mobile IP is to used to handle scalable global
mobility. Unlike the FMIP and HMIP protocols, however, these protocols do mobility. Unlike the FMIP and HMIP protocols, however, these protocols do
skipping to change at page 15, line 36 skipping to change at page 19, line 25
mobile node generates a routing table entry, and perhaps multiple forwarding mobile node generates a routing table entry, and perhaps multiple forwarding
table entries, in every router along the path. Since mobile nodes can have table entries, in every router along the path. Since mobile nodes can have
multiple global care of addresses in IPv6, this can result in a large multiple global care of addresses in IPv6, this can result in a large
expansion in router state throughout the micromobility routing domain. expansion in router state throughout the micromobility routing domain.
Although the extent of the scalability for micromobility protocols is still Although the extent of the scalability for micromobility protocols is still
not clearly understood from a research standpoint, it seems certain that not clearly understood from a research standpoint, it seems certain that
they will be less scalable than the Mobile IP optimization enhancements, and they will be less scalable than the Mobile IP optimization enhancements, and
will require more specialized gear in the wired network. will require more specialized gear in the wired network.
The following is a gap analysis of the micromobility protocols against the The following is a gap analysis of the micromobility protocols against the
requirements in Section 2.0: goals in Section 2.0:
Requirement #1 The micromobility protocols reduce handover latency by Goal #1 The micromobility protocols reduce handover latency by quickly
quickly fixing up routes between the boundary router and the access router. fixing up routes between the boundary router and the access router. While
While some additional latency may be expected during host route propagation, some additional latency may be expected during host route propagation, it is
it is typically much less than experienced with standard Mobile IP. typically much less than experienced with standard Mobile IP.
Requirement #2 The micromobility protocols require signaling from the mobile Goal #2 The micromobility protocols require signaling from the mobile node
node to the access router to initiate the host route propagation, but that to the access router to initiate the host route propagation, but that is a
is a considerable reduction over the amount of signaling required to considerable reduction over the amount of signaling required to configure to
configure to a new IP link. a new IP link.
Requirement #3 No care-of address changes are exposed to correspondent nodes Goal #3 No care-of address changes are exposed to correspondent nodes or the
or the mobile node itself while the mobile node is moving in the mobile node itself while the mobile node is moving in the micromobility-
micromobility-managed network. Because there is no local care-of address, managed network. Because there is no local care-of address, there is no
there is no threat from malware that exposes the location by sending the threat from malware that exposes the location by sending the care-of address
care-of address to an adversary. to an adversary.
Requirement #4 The only additional over-the-air signaling is involved in Goal #4 The only additional over-the-air signaling is involved in
propagating host routes from the mobile node to the network upon movement. propagating host routes from the mobile node to the network upon movement.
Since this signaling would be required for movement detection in any case, Since this signaling would be required for movement detection in any case,
it is expected to be minimal. Mobile node traffic experiences no overhead. it is expected to be minimal. Mobile node traffic experiences no overhead.
Requirement #5 Host route propagation is required throughout the wired Goal #5 Host route propagation is required throughout the wired network. The
network. The volume of signaling could be more or less depending on the volume of signaling could be more or less depending on the speed of mobile
speed of mobile node movement and the size of the wired network. node movement and the size of the wired network.
Requirement #6 The mobile node only requires a security association of some Goal #6 The mobile node only requires a security association of some type
type with the access router. Because the signaling is causing routes to the with the access router. Because the signaling is causing routes to the
mobile node's care-of address to change, the signaling must prove mobile node's care-of address to change, the signaling must prove
authorization to hold the address. authorization to hold the address.
Requirement #7 The micromobility protocols support multiple wireless Goal #7 The micromobility protocols support multiple wireless technologies,
technologies, so this requirement is satisfied. so this goal is satisfied.
Requirement #8 The mobile node must support some way of signaling the access Goal #8 The mobile node must support some way of signaling the access router
router on link handover, but this is required for movement detection anyway. on link handover, but this is required for movement detection anyway. The
The nature of the signaling for the micromobility protocols may mobile node nature of the signaling for the micromobility protocols may mobile node
software changes, however. software changes, however.
Requirement #9 Most of the work on the micromobility protocols was done in Goal #9 Most of the work on the micromobility protocols was done in IPv4,
IPv4, but little difference could be expected for IPv6. but little difference could be expected for IPv6.
3.5 Standard Internal Gateway Route Distribution Protocols (OSPF and IS-IS) Goal #10 This solution does not reuse an existing protocol because there is
currently no Internet Standard protocol for micromobility.
9.5 Standard Internal Gateway Route Distribution Protocols (OSPF and IS-IS)
It has also been suggested that instead of using a specialized It has also been suggested that instead of using a specialized
micromobility routing protocol in the access network, a standardized micromobility routing protocol in the access network, a standardized
Internal Gateway route distribution Protocol (IGP) such as IS-IS [25] or Internal Gateway route distribution Protocol (IGP) such as IS-IS [26] or
OSPF [26] should be used to distribute host routes. Host route messages are OSPF [27] should be used to distribute host routes. Host route messages are
formatted in the IGPs by including a subnet mask in the route information formatted in the IGPs by including a subnet mask in the route information
update, indicating that the address is a /32 for IPv4 or a /128 for IPv6 update, indicating that the address is a /32 for IPv4 or a /128 for IPv6
instead of a subnet prefix. Since IGPs typically distribute route instead of a subnet prefix. Since IGPs typically distribute route
information by flooding, every router in the domain obtains a copy of the information by flooding, every router in the domain obtains a copy of the
host route eventually. Using an IGP instead of a micromobility protocol has host route eventually. Using an IGP instead of a micromobility protocol has
the advantage that standardized routing equipment can be used for all the advantage that standardized routing equipment can be used for all
routers in the access network, and, if a particular router goes down, the routers in the access network, and, if a particular router goes down, the
host routes maintained along alternate routes should be sufficient to host routes maintained along alternate routes should be sufficient to
continue routing, unlike micromobility protocols where only targeted routers continue routing, unlike micromobility protocols where only targeted routers
have the host routes. have the host routes.
skipping to change at page 17, line 6 skipping to change at page 20, line 50
traveled by the mobile node's traffic has occurred. Because micromobility traveled by the mobile node's traffic has occurred. Because micromobility
protocols target host routes back to the micromobility domain border router, protocols target host routes back to the micromobility domain border router,
convergence can potentially be achieved more quickly. Tunnel-based solutions convergence can potentially be achieved more quickly. Tunnel-based solutions
such as HMIP don't suffer from convergence latency because only the two such as HMIP don't suffer from convergence latency because only the two
endpoints need to know the routing. As a result, the internal routing endpoints need to know the routing. As a result, the internal routing
tables updated by the IGP remain stable when a mobile node moves. The tables updated by the IGP remain stable when a mobile node moves. The
movement does not affect routing of traffic to other mobile nodes due to movement does not affect routing of traffic to other mobile nodes due to
intensive path computation. intensive path computation.
Another disadvantage of using an IGP is that each router in the domain must Another disadvantage of using an IGP is that each router in the domain must
maintain a full host route table for all hosts. This requirement raises a maintain a full host route table for all hosts. This goal raises a
scalability issue. For example, an experiment [24] using OSPF to distribute scalability issue. For example, an experiment [25] using OSPF to distribute
host routes through an access network consisting of a collection of rather host routes through an access network consisting of a collection of rather
smallish enterprise routers indicated that about 25,000 routes could be smallish enterprise routers indicated that about 25,000 routes could be
supported in 22 Mb of memory before performance started to degrade. This supported in 22 Mb of memory before performance started to degrade. This
works out to about 0.88 kb/host. Scaling this up to, say, 10 million hosts works out to about 0.88 kb/host. Scaling this up to, say, 10 million hosts
(what one might expect in a large metropolitan area such as Tokyo or San (what one might expect in a large metropolitan area such as Tokyo or San
Francisco) would require about 8.8 Gb of memory per router. While memory Francisco) would require about 8.8 Gb of memory per router. While memory
costs continue to drop, the amount of processing power for searching a costs continue to drop, the amount of processing power for searching a
routing database of that size essentially means that each router in the routing database of that size essentially means that each router in the
domain must have the same processing power as a high end, border router. domain must have the same processing power as a high end, border router.
Micromobility and tunnel- based solutions don't suffer from this problem, Micromobility and tunnel- based solutions don't suffer from this problem,
because the host route is local to the tunnel endpoints. Other routers in because the host route is local to the tunnel endpoints. Other routers in
the domain route based on highly scalable shortest matching network prefix the domain route based on highly scalable shortest matching network prefix
method. method.
The following is a gap analysis of host route distribution using a The following is a gap analysis of host route distribution using a
standardized IGP against the requirements in Section 2.0: standardized IGP against the goals in Section 2.0:
Requirement #1 Host route distribution using an IGP is likely to suffer from Goal #1 Host route distribution using an IGP is likely to suffer from
increased handover latency due to a lag time as routes converge over the increased handover latency due to a lag time as routes converge over the
access network. The exact amount of latency depends on the convergence access network. The exact amount of latency depends on the convergence
characteristics of the particular IGP and the topology of the access characteristics of the particular IGP and the topology of the access
network, i.e. how fast convergence occurs along routes taken by the mobile network, i.e. how fast convergence occurs along routes taken by the mobile
node's traffic. node's traffic.
Requirement #2 Host route distribution using an IGP requires signaling from Goal #2 Host route distribution using an IGP requires signaling from the
the mobile node to the access router to initiate the host route propagation, mobile node to the access router to initiate the host route propagation, but
but that is a considerable reduction over the amount of signaling required that is a considerable reduction over the amount of signaling required to
to configure to a new IP link. However, if a mobile node is moving quickly, configure to a new IP link. However, if a mobile node is moving quickly, the
the flooding traffic necessary to propagate a host route may not converge flooding traffic necessary to propagate a host route may not converge before
before the mobile node hands over again. This could result in a cacscading the mobile node hands over again. This could result in a cacscading series
series of host route updates that never converge. Whether or not this effect of host route updates that never converge. Whether or not this effect occurs
occurs depends on the size of the localized mobility domain, and so the need depends on the size of the localized mobility domain, and so the need to
to ensure convergence places an upper bound on the size of the domain or ensure convergence places an upper bound on the size of the domain or
expected movement speed of the mobile nodes. expected movement speed of the mobile nodes.
Requirement #3 No care-of address changes are exposed to correspondent nodes Goal #3 No care-of address changes are exposed to correspondent nodes or the
or the mobile node itself while the mobile node is moving in the localized mobile node itself while the mobile node is moving in the localized mobility
mobility management domain. Because there is no local care-of address, there management domain. Because there is no local care-of address, there is no
is no threat from malware that exposes the location by sending the care-of threat from malware that exposes the location by sending the care-of address
address to an adversary. to an adversary.
Requirement #4 The only additional over-the-air signaling involved is Goal #4 The only additional over-the-air signaling involved is signaling
signaling from the mobile node to the access router indicating that the from the mobile node to the access router indicating that the mobile node
mobile node has moved. Mobile node traffic experiences no overhead. has moved. Mobile node traffic experiences no overhead.
Requirement #5 Host route propagation is required throughout the wired Goal #5 Host route propagation is required throughout the wired network. The
network. The volume of signaling could be more or less depending on the volume of signaling could be more or less depending on the speed of mobile
speed of mobile node movement and the size of the wired network. node movement and the size of the wired network.
Requirement #6 The mobile node only requires a security association of some Goal #6 The mobile node only requires a security association of some type
type with the access router. Because the signaling is causing routes to the with the access router. Because the signaling is causing routes to the
mobile node's care-of address to change, the signaling must prove mobile node's care-of address to change, the signaling must prove
authorization to hold the address. authorization to hold the address.
Requirement #7 This requirement is satisfied by default, since the IGPs are Goal #7 This goal is satisfied by default, since the IGPs are used over the
used over the wired backbone. wired backbone.
Requirement #8 The mobile node needs to perform some kind of active movement Goal #8 The mobile node needs to perform some kind of active movement
detection with proof of identity to trigger the host route distribution, but detection with proof of identity to trigger the host route distribution, but
this kind of signaling is needed for movement regardless of whether this kind of signaling is needed for movement regardless of whether
localized mobility management is deployed. Depending on the wireless link localized mobility management is deployed. Depending on the wireless link
type, this may be handled by the wireless link layer. type, this may be handled by the wireless link layer.
Requirement #9 Since the IGPs support both IPv4 and IPv6, both are Goal #9 Since the IGPs support both IPv4 and IPv6, both are supported by
supported by this technique. this technique.
4.0 Security Considerations
There are two kinds of security issues involved in network-based localized
mobility management: security between the mobile node and the network, and
security between network elements that participate in the network-based
localized mobility management protocol
Security between the mobile node and the network itself consists of two
parts: threats involved in localized mobility management in general, and
threats to the network-based localized mobility management from the host.
The first is discussed above in Sections 2.3 and 2.6. The second is
discussed in the threat analysis document [27].
For threats to network-based localized mobility management, the basic threat
is an attempt by an unauthorized party to signal a bogus mobility event.
Such an event must be detectable. This requires proper bidirectional
authentication and authorization of network elements that participate in the
network-based localized mobility management protocol, and data origin
authentication on the signaling traffic between network elements.
5.0 Recommendation
In view of the gap analysis in Section 3.0, none of the existing solutions
provide complete coverage of the requirements. FMIPv6 provides a complete
solution to Requirement 3.1 but to no other requirement. FMIP, HMIP and
micromobility protocols require that the mobile node is modified to support the
additional functionality. But as analyzed above, the functionality provided
by each protocol is does not fully support the set of requirements discussed
in Section 2.0.
We therefore recommend that a new, network based localized mobility
management protocol be developed that minimizes or eliminates mobile node
involvement in localized mobility management. Such a localized mobility
management protocol can be treated as part of the network infrastructure.
This kind of architecture is required to address the gaps with existing
protocols described in Section 3.0. The new localized mobility management
protocol can be paired with a link layer specific IP link handover
optimization protocol, such as are provided by wireless LAN switches, or an
IP link handover optimization protocol, such as FMIPv6, to eliminate
handover related packet latency. The protocol should minimize the number of
specialized routers in the localized mobility management domain to reduce
the amount of state update needed upon movement and to allow standardized
network equipment to be used where mobility support is not required.
With the edge mobility approach, a mobile node has a single IP address that
does not change when the mobile node moves from one access router to
another, because the mobility anchor and access routers take care of
changing the routing. An edge mobility approach does not require a separate
security association with a network element, reducing the amount of overhead
required to get a connection up on the network. In an edge mobility approach,
mobile nodes only have link local addresses for access routers, so it is
much more difficult to mount off-link DoS attacks, and on-link attacks are
easier to trace and stop. With the edge mobility approach, no authentication
and authorization is necessary beyond that necessary for initial network
access and whatever additional authentication and authorization is required
by the wireless link layer upon movement between access points.
6.0 Author Information
James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com
Phil Roberts
Motorola Labs
Schaumberg, IL
USA
Email: phil.roberts@motorola.com
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 Torino
Italy
Phone: +39 011 2286904
Email: gerardo.giaretta@tilab.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de
7.0 Informative References
[1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch,
M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet
Draft, work in progress.
[2] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753,
June, 2004.
[3] Devarapalli,V., Wakikawa, R., Petrescu, A., Thubert, P., "Network
Mobility (NEMO) Basic Support Protocol", RFC 3963, January, 2005.
[4] Carpenter, B., "Architectural Principles of the Internet," RFC 1958,
June, 1996.
[5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6",
RFC 3775.
[6] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host
Identity Protocol", Internet Draft, work in progress.
[7] Choi, J, and Daley, G., " Goals of Detecting Network Attachment in
IPv6", Internet Draft, work in progress.
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June,
2001.
[9] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A.,
"Protocol for Carrying Authentication for Network Access (PANA)",
Internet Draft, work in progress.
[10] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor
Discovery (SEND)", RFC 3971, March, 2005.
[11] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work in
Progress.
[12] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law
and Policy in the US, EU, and Japan", ISOC Member Briefing #15,
http://www.isoc.org/briefings/015/index.shtml
[13] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and
Patil, B., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem
Statement", Internet Draft, work in progress.
[14] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol",
Internet Draft, work in progress.
[15] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet
Draft, work in progress.
[16] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., "Solutions
for IP Address Location Privacy in the presence of IP Mobility",
Internet Draft, work in progress.
[17] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol for
Protecting Movement of Mobile Nodes in Mobile IPv6", Internet Draft,
work in progress.
[18] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H.,
Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for
Hosts and Routers", Internet Draft, work in progress.
[19] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July,
2005.
[20] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140,
August, 2005.
[21] Kempf, J., and Koodli, R., "Bootstrapping a Symmetric IPv6 Handover Key
from SEND", Internet Draft, work in progress.
[22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design,
Implementation and Evaluation of Cellular IP", IEEE Personal
Communications, June/July 2000.
[23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A
domain-based approach for supporting mobility in wide-area wireless
networks", in Proceedings of the International Conference on Networking
Protocols (ICNP), 1999.
[24] "Mobile VPN Network Configuration Alternatives", IP Unplugged,
http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
[25] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142,
Feburary, 1990.
[26] Moy, J., "OSPF Version 2", STD 54, April, 1998.
[27] Threat analysis draft, TBD
8.0 IPR Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might
not be available; nor does it represent that it has made any independent
effort to identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of
licenses to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the IETF
on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights that
may cover technology that may be required to implement this standard.
Please address the information to the IETF at ietf-ipr@ietf.org.
9.0Disclaimer of Validity
This document and the information contained herein are provided on an "AS
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
10.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
11.0 Changes in 01 (remove before publication) Goal #10 This solution re-uses existing protocols, OSPF or IS-IS.
- Changed wording so as not to seem to exclude mobile routers; 9.6 Summary
. Changed "host" to "mobile node" when the wireless device is meant, The following table summarizes the discussion in Section 9.1 through 9.5. In
. Changed "host" or "host-based" when localized mobility management is the table, a "M" indicates that the protocol completely meets the goal, a
described to be "mobile node", "P" indicates that it partially meets the goal, and an "X" indicates that it
does not meet the goal.
. Removed definition for "host" and added a definition to Section 1.1 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
for "mobile node" to indicate that the end device is meant to apply to -------- -- -- -- -- -- -- -- -- -- ---
mobile routers that use a global mobility management protocol such as
NEMO in addition to terminals,
- Modified Section 2.7 to indicate that support for multiple wireless link MIPv6 P X X X X X M X M M
technologies is not meant to include keeping the same IP address when a new
wireless interface is activated on the mobile device,
- Modified Section 2.8 to indicate that unmodified mobile node support is HMIPv6 P X X X P X M X X M
meant to apply only to localized mobility management, and is not meant to
exclude global mobility management or driver changes needed to support
handover at the wireless link layer,
- Changed the text in Section 4.0 to clarify the difference in the threat MIPv6 +
from host-side malware for global mobility protocols such as Mobile IPv6 and FMIPv6 M X X X P X M X P M
localized mobility management,
- Rewrote Section 4 to remove text that duplicates discussions in Section
2.3 and 2.6, and focused instead on the threat to the NETLMM protocol
itself.
- Added Section 3.5 discussing use of standardized IGPs for host route HMIPv6 +
distribution. FMIPv6 M X X X X X M X X M
- Added text to each subsection in Section 2 that clearly and explicitly Micro. M M M M P M M M P X
states the requirement for the NETLMM protocol. Previously, the
requirements were in some cases only implicit in the discussion.
- Added reference to Threat Analysis draft (TBD). IGP X M M M X M M M M M
 End of changes. 130 change blocks. 
638 lines changed or deleted 613 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/