draft-ietf-netlmm-nohost-req-01.txt   draft-ietf-netlmm-nohost-req-02.txt 
J. Kempf, Internet Draft J. Kempf,
Editor Editor
Internet Draft K. Leung Document: draft-ietf-netlmm-nohost-req-02.txt
Document: draft-ietf-netlmm-nohost-req-01.txt P. Roberts
K. Nishida
G. Giaretta
M. Liebsch
Expires: October, 2006 April, 2006 Expires: December, 2006 June, 2006
Goals for Network-based Localized Mobility Management (NETLMM) Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-01.txt) (draft-ietf-netlmm-nohost-req-02.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
or will be disclosed, and any of which he or she becomes aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with Section 6 of BCP 79. aware will be 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
(IETF), its areas, and its working groups. Note that other groups may also Task Force (IETF), its areas, and its working groups. Note that
distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six
may be updated, replaced, or obsoleted by other documents at any time. It is months and may be updated, replaced, or obsoleted by other
inappropriate to use Internet-Drafts as reference material or to cite them documents at any time. It is inappropriate to use Internet-Drafts
other than as "work in progress." as reference material or to cite them 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.
Contributors
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC
Editor's limit of 5 names.
Abstract Abstract
In this document, design goals for a network-based localized mobility In this document, design goals for a network-based localized
management protocol are discussed. mobility management protocol are discussed.
Table of Contents Table of Contents
1.0 Introduction.....................................................2 1.0 Introduction.............................................2
2.0 Goals for Localized Mobility Management..........................2 2.0 Goals for Localized Mobility Management..................2
3.0 Security Considerations..........................................8 3.0 IANA Considerations.....................................10
4.0 Author Information...............................................9 4.0 Security Considerations.................................10
5.0 Informative References..........................................10 5.0 Author's Addresses......................................11
6.0 IPR Statements..................................................11 6.0 Informative References..................................12
7.0 Disclaimer of Validity..........................................12 7.0 IPR Statements..........................................13
8.0 Copyright Notice................................................12 8.0 Disclaimer of Validity..................................13
9.0 Appendix: Gap Analysis..........................................12 9.0 Copyright Notice........................................14
10.0 Appendix: Gap Analysis..................................14
1.0 Introduction 1.0 Introduction
In [1], the basic problems that occur when a global mobility protocol is In [1], the basic problems that occur when a global mobility
used for managing local mobility are described, and three basic approaches protocol is used for managing local mobility are described, and two
to localized mobility management - the host-based approach that is used by basic approaches to localized mobility management - the host-based
most IETF protocols, the WLAN switch approach, and using a standard routing approach that is used by most IETF protocols, and the proprietary
IGP to distribute host routes - are examined. The conclusion from the WLAN switch approach used between WLAN switches in different
problem statement document is that none of the approaches has a complete subnets - are examined. The conclusion from the problem statement
solution to the problem. While the WLAN switch approach is most convenient document is that none of the approaches has a complete solution to
for network operators and users because it requires no mobile node support, the problem. While the WLAN switch approach is most convenient for
the proprietary nature limits interoperability and the restriction to a network operators and users because it requires no software on the
single wireless link type and wired backhaul link type restricts scalablity. mobile node other than the standard drivers for WiFi, the
The IETF host-based protocols require host software stack changes that may proprietary nature limits interoperability and the restriction to a
not be compatible with all global mobility protocols, and also require single wireless link type and wired backhaul link type restricts
specialized and complex security transactions with the network that may scalablity. The IETF host-based protocols require host software
limit deployability. The use of an IGP to distribute host routes has stack changes that may not be compatible with all global mobility
scalability and deployment limitations. protocols, and also require 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 goals for a network-based localized This document develops more detailed goals for a network-based
mobility management protocol. In Section 2.0, we review a list of goals that localized mobility management protocol. In Section 2.0, we review a
are desirable in a network-based localized mobility management solution. list of goals that are desirable in a network-based localized
Section 3.0 briefly outlines security considerations. More discussion of mobility management solution. Section 3.0 briefly outlines security
security can be found in the threat analysis document [2]. The architecture considerations. More discussion of security can be found in the
of the NETLMM protocol for which the goals in this document have been threat analysis document [2]. The architecture of the NETLMM
formulated is described in Section 4 of [1]. protocol for which the goals in this document have been formulated
is described in Section 4 of [1].
1.1 Terminology 1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753 [3] and in [1]. Mobility terminology in this draft follows that in RFC 3753 [3] and
in [1].
2.0 Goals for Localized Mobility Management 2.0 Goals for Localized Mobility Management
Any localized mobility solution must naturally address the three problems Section 2 of [1] describes three problems with using a global
described in [1]. In addition, the side effects of introducing such a mobility management protocol for localized mobility management. Any
solution into the network need to be limited. In this section, we address localized mobility management protocol must naturally address these
goals on a localized mobility solution including both solving the basic three problems. In addition, the side effects of introducing such a
problems and limiting the side effects. solution into the network need to be limited. In this section, we
address goals on a localized mobility solution including both
solving the basic problems (Goals 1, 2, 3) and limiting the side
effects (Goals 4+).
Some basic goals of all IETF protocols are not discussed in detail here, but Some basic goals of all IETF protocols are not discussed in detail
any solution is expected to satisfy them. These goals are interoperability, here, but any solution is expected to satisfy them. These goals are
scalability, and minimal goal for specialized network equipment. A good fault tolerance, robustness, interoperability, scalability, and
discussion of their applicability to IETF protocols can be found in [5]. minimal specialized network equipment. A good discussion of their
applicability to IETF protocols can be found in [4].
Out of scope for the initial goals discussion are QoS, multicast, and Out of scope for the initial goals discussion are QoS, multicast,
dormant mode/paging. While these are important functions for mobile nodes, and dormant mode/paging. While these are important functions for
they are not part of the base localized mobility management problem. In mobile nodes, they are not part of the base localized mobility
addition, mobility between localized mobility management domains is not management problem. In addition, mobility between localized
covered here. It is assumed that this is covered by the global mobility mobility management domains is not covered here. It is assumed that
management protocols. this is covered by the global mobility management protocols.
2.1 Handover Performance Improvement (Goal #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
the wireless link handover starts and when the IP link handover completes. between when the wireless link handover starts and when the IP
During this time the mobile node is unreachable at its former topological subnet configuration and global mobility management signaling
location on the old IP link where correspondents are sending packets and to completes. During this time the mobile node is unreachable at its
which the routing system is routing them. Such misrouted packets are former topological location on the old link where correspondents
dropped. This aspect of handover performance optimization has been the are sending packets and to which they are being forwarded. Such
subject of an enormous amount of work, both in other SDOs, to reduce the misrouted packets are dropped. This aspect of handover performance
latency of wireless link handover, and in the IETF and elsewhere, to reduce optimization has been the subject of an enormous amount of work,
the latency in IP link handover. Many solutions to this problem have been both in other SDOs, to reduce the latency of wireless link
proposed at the wireless link layer and at the IP layer. One aspect of this handover, in the IETF and elsewhere, to reduce the latency in IP
goal for localized mobility management is that the processing delay for handover. Many solutions to this problem have been proposed at the
changing the routing after handover must approach as closely as possible the wireless link layer and at the IP layer. One aspect of this goal
sum of the delay associated with link layer handover and the delay required for localized mobility management is that the processing delay for
for active IP layer movement detection, in order to avoid excessive packet changing the forwarding after handover must approach as closely as
loss. Ideally, if network-side link layer support is available for handling possible the sum of the delay associated with link layer handover
movement detection prior to link handover or as part of the link handover and the delay required for active IP layer movement detection, in
process, the routing update should complete within the time required for order to avoid excessive packet loss. Ideally, if network-side link
wireless link handover. layer support is available for handling movement detection prior to
link handover or as part of the link handover process, the routing
Note that a related problem occurs when traffic packets are not routed update should complete within the time required for wireless link
through a global mobility anchor such as a Mobile IP home agent. Route handover. This delay is difficult to quantify, but for voice
optimized Mobile IPv6 [6] and HIP [7] are examples. A loss of connectivity traffic, the entire handover delay including Layer 2 handover time
can occur when both sides of the IP conversation are mobile and they both and IP handover time should be between 40-70 ms to avoid any
hand over at the same time. The two sides must use a global mobility anchor degradation in call quality.
point, like a home agent or rendezvous server, to re-establish the
connection, but there may be substantial packet loss until the problem is
discovered. Another aspect of this goal is that the solution must ensure
that connectivity is not lost when both ends are mobile and move at the same
time.
In both cases, the loss of accurate routing causes the connection to A goal of the protocol is to reduce the loss of accurate forwarding
experience an interruption which may cause service degradation for real time to reduce interruptions which may cause user-perceptible service
traffic such as voice degradation for real time traffic such as voice.
2.2 Reduction in Handover-related Signaling Volume (Goal #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
protocols require about the same or somewhat less), if a mobile node is mobility protocols require about the same or somewhat less), if a
required to reconfigure on every move between IP links, the following set of mobile node is required to reconfigure on every move between links,
signaling messages must be done: the following signaling must be performed:
1) Movement detection using DNA [8] or possibly a link specific protocol, 1) Movement detection using DNA [6] or possibly a link specific
2) Any link layer or IP layer AAA signaling, such as 802.1x [9] or PANA protocol,
[10]. The mobile node may also or instead have to obtain a router 2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or
certificate using SEND [11], if the certificate is not already cached, PANA [8]. The mobile node may also or instead have to obtain a
router authorization certificate using SEND [9], 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
Duplicate Address Detection (unless optimistic Duplicate Address configuration and Duplicate Address Detection (unless optimistic
Detection [12] is used). If stateful address configuration is used, then Duplicate Address Detection [10] is used) including for link
local addresses. 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
binding key, establish the 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
and Step 3 will be necessary even if the mobile node's care-of address can mobility. Step 3 will be necessary even if the mobile node's care-
remain the same when it moves to a new access router. of address can remain the same when it moves to a new access
router. Steps 5 through 7 are only necessary when Mobile IPv6 is
used.
The result is approximately 10 messages at the IP level before a mobile node The result is approximately 10 messages at the IP level before a
can be ensured that it is established on a link and has full IP mobile node can be ensured that it is established on a link and has
connectivity. Furthermore, in some cases, the mobile node may need to engage full IP connectivity. Furthermore, in some cases, the mobile node
in "heartbeat signaling" to keep the connection with the correspondent or may need to engage in "heartbeat signaling" to keep the connection
global mobility anchor fresh, for example, return routability in Mobile IPv6 with the correspondent or global mobility anchor fresh, for
must be done at a maximum every 7 minutes even if the mobile node is example, return routability in Mobile IPv6 must be done at a
standing still. maximum every 7 minutes even if the mobile node is standing still.
The goal is that handover signaling volume from the mobile node to the The goal is that handover signaling volume from the mobile node to
network should be no more than what is needed for the mobile node to perform the network should be no more than what is needed for the mobile
secure IP level movement detection, in cases where no link layer support node to perform secure IP level movement detection, in cases where
exists. If link layer support exists for IP level movement detection, the no link layer support exists. If link layer support exists for IP
mobile node may not need to perform any additional IP level signaling after level movement detection, the mobile node may not need to perform
handover. any additional IP level signaling after handover.
2.3 Location privacy (Goal #3) 2.3 Location privacy (Goal #3)
Although general location privacy issues have been discussed in [14], the Although general location privacy issues have been discussed in
location privacy referred to here focuses on the IP layer. In most wireless [11], the location privacy referred to here focuses on the IP
IP network deployments, different IP subnets are used to cover different layer. In most wireless IP network deployments, different IP
geographical areas. It is therefore possible to derive a topological to subnets are used to cover different geographical areas. It is
geographical map, in which particular IPv6 subnet prefixes are mapped to therefore possible to derive a topological to geographical map, in
particular geographical locations. The precision of the map depends on the which particular IPv6 subnet prefixes are mapped to particular
size of the geographic area covered by a particular subnet: if the area is geographical locations. The precision of the map depends on the
large, then knowing the subnet prefix won't provide much information about size of the geographic area covered by a particular subnet: if the
the precise geographical location of a mobile node within the subnet. 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 When a mobile node moves geographically, it also moves
subnets. In order to maintain routability, the mobile node must change its topologically between subnets. In order to maintain routability,
local IP address when it moves between subnets. A correspondent node or the mobile node must change its local IP address when it moves
eavesdropper can use the topological to geographical map to deduce in real between subnets. A correspondent node or eavesdropper can use the
time where a mobile node - and therefore its user - is located. Depending on topological to geographical map to deduce in real time where a
how precisely the geographical location can be deduced, this information mobile node - and therefore its user - is located. Depending on how
could be used to compromise the privacy or even cause harm to the user. The precisely the geographical location can be deduced, this
geographical location information should not be revealed to nor be deducible information could be used to compromise the privacy or even cause
by the correspondent node or an eavesdropper without the authorization of 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 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. One is
likely is a man in the middle attack in which traffic between a a man in the middle attack in which traffic between a correspondent
correspondent and the mobile node is intercepted and the mobile node's and the mobile node is intercepted and the mobile node's location
location is deduced from that, since man in the middle attacks in the is deduced from that. Others are attacks in which the correspondent
Internet tend to be fairly rare. More likely are attacks in which the itself is the attacker, and the correspondent deliberately starts a
correspondent is the attacker or the correspondent or even the mobile node session with the mobile node in order to track its location by
itself is relaying information on the local address change to an attacker. noting the source address of packets originating from the mobile
The owner of the correspondent or mobile node might not even be aware of the node. Note that the location privacy referred to here is different
problem if an attacker has installed spyware or some other kind of exploit from the location privacy discussed in [14][15][16]. The location
and the malware is relaying the change in local address to the attacker. privacy discussed in these drafts primarily concerns modifications
Host-based localized mobility management solutions in which the to the Mobile IPv6 protocol to eliminate places where an
correspondent only sees a regional address but the host still maintains a eavesdropper could track the mobile node's movement by correlating
local address are unsatisfactory because they still have a potential for home address and care of address.
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
location privacy discussed in [16][17][18]. The location privacy discussed
in these drafts primarily concerns modifications to the Mobile IPv6 protocol
to eliminate places where an eavesdropper could track the mobile node's
movement by correlating home address and care of address.
In order to reduce the risk from location privacy compromises as a result of In order to reduce the risk from location privacy compromises as a
IP address changes, the goal for NETLMM is to remove the need to change IP result of IP address changes, the goal for NETLMM is to remove the
address as mobile node moves across IP links. Keeping the IP address fixed need to change IP address as mobile node moves across links.
removes any possibility for the correspondent node to deduce the precise Keeping the IP address fixed removes any possibility for the
geographic location of the mobile node without the user's authorization, as correspondent node to deduce the precise geographic location of the
well as any possibility that malware on the mobile node could inadvertently mobile node without the user's authorization. Note that keeping the
reveal the mobile node's location to an attacker. Note that keeping the address constant doesn't completely remove the possibility of
address constant doesn't completely remove the possibility of deducing the deducing the geographical location, since a local address still is
geographical location, since a local address still is required. However, it required. However, it does allow the network to be deployed such
does allow the network to be deployed such that the mapping between the that the mapping between the geographic and topological location is
geographic and topological location is considerably less precise. If the considerably less precise. If the mapping is not precise, an
mapping is not precise, an attacker can only deduce in real time that the attacker can only deduce in real time that the mobile node is
mobile node is somewhere in a large geographic area, like, for example, a somewhere in a large geographic area, like, for example, a
metropolitan region or even a small country, reducing the possibility that metropolitan region or even a small country, reducing reducing the
the attacker can cause harm to the user. granularity of the location information.
2.4 Efficient Use of Wireless Resources (Goal #4) 2.4 Efficient Use of Wireless Resources (Goal #4)
Advances in wireless PHY and MAC technology continue to increase the Advances in wireless physical layer and medium access control layer
bandwidth available from limited wireless spectrum, but even with technology technology continue to increase the bandwidth available from
increases, wireless spectrum remains a limited resource. Unlike wired limited wireless spectrum, but even with technology increases,
network links, wireless links are constrained in the number of bits/Hertz by wireless spectrum remains a limited resource. Unlike wired network
their coding technology and use of physical spectrum, which is fixed by the links, wireless links are constrained in the number of bits/Hertz
PHY. It is not possible to lay an extra cable if the link becomes by their coding technology and use of physical spectrum, which is
increasingly congested as is the case with wired links. fixed by the physical layer. It is not possible to lay an extra
cable if the link becomes increasingly congested as is the case
with wired links.
Some existing localized mobility management solutions increase packet size While header compression technology can remove header overhead, it
over the wireless link by adding tunneling or other per packet overhead. does not come without cost. Requiring header compression on the
While header compression technology can remove header overhead, header wireless access points increases the cost and complexity of the
compression does not come without cost. Requiring header compression on the access points, and increases the amount of processing required for
wireless access points increases the cost and complexity of the access traffic across the wireless link. Header compression also requires
points, and increases the amount of processing required for traffic across special software on the host, which may or may not be present.
the wireless link. Since the access points tend to be a critical bottleneck Since the access points tend to be a critical bottleneck in
in wireless access networks for real time traffic (especially on the 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
header compression probably cannot be completely eliminated, especially for important. While header compression probably cannot be completely
real time media traffic, simplifying compression to reduce processing cost eliminated, especially for real time media traffic, simplifying
is an important goal. compression to reduce processing cost is an important goal.
The goal is that the localized mobility management protocol should not The goal is that the localized mobility management protocol should
introduce any new signaling or increase existing signaling over the air. not introduce any new signaling or increase existing signaling over
the air.
2.5 Reduction of Signaling Overhead in the Network (Goal #5) 2.5 Limit the 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
constrained in the wired network, wired networks tend to have higher as constrained in the wired network, access networks tend to have
bandwidth and router processing constraints than the backbone. These somewhat stronger bandwidth and router processing constraints than
constraints are a function of the cost of laying fiber or wiring to the the backbone. These constraints are a function of the cost of
wireless access points in a widely dispersed geographic area. Therefore, any laying fiber or wiring to the wireless access points in a widely
solutions for localized mobility management should minimize signaling within dispersed geographic area. Therefore, any solutions for localized
the wired network as well. mobility management should minimize signaling within the wired
network as well.
2.6 No Extra Security Between Mobile Node and Network (Goal #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
mobile node and network require a security association between the mobile the mobile node and network require a security association between
node and the network entity that is the target of the signaling. the mobile node and the network entity that is the target of the
Establishing a security association specifically for localized mobility signaling. Establishing a security association specifically for
service in a roaming situation may prove difficult, because provisioning a localized mobility service in a roaming situation may prove
mobile node with security credentials for authenticating and authorizing difficult, because provisioning a mobile node with security
localized mobility service in each roaming partner's network may be credentials for authenticating and authorizing localized mobility
unrealistic from a deployment perspective. Reducing the complexity of mobile service in each roaming partner's network may be unrealistic from a
node to network security for localized mobility management can therefore deployment perspective. Reducing the complexity of mobile node to
network security for localized mobility management can therefore
reduce barriers to deployment. reduce barriers to deployment.
Removing mobile node involvement in localized mobility management also If the access router deduces mobile node movement based on active
limits the possibility of DoS attacks on network infrastructural elements. IP-level movement detection by the mobile node, then authentication
In a host based approach, the mobile node is required to have a global or is required for the IP-level movement detection messages from the
restricted routing local IP address for a network infrastructure element, mobile node to ensure that the mobile node is authorized to possess
the mobility anchor point. The network infrastructural element therefore the address used for the movement detection. The authorization may
becomes a possible target for DoS attacks, even if mobile nodes are properly be at the IP level or it may be tied to the original network access
authenticated. A properly authenticated mobile node can either willfully or authentication and wireless link layer authorization for handover.
inadvertently give the network infrastructural element address to an Some wireless link layers, especially cellular protocols, feature
attacker. full support and strong security for handover at the link level,
and require no IP support for handover. If such wireless link
security is not available, however, then it must be provided at the
IP level. Security threats to the NETLMM protocol are discussed in
[2].
In summary, ruling out mobile node involvement in local mobility management In summary, ruling out mobile node involvement in local mobility
simplifies security by removing the need for service-specific credentials to management simplifies security by removing the need for service-
authenticate and authorize the mobile node for localized mobility management specific credentials to authenticate and authorize the mobile node
in the network and by limiting the possibility of DoS attacks on network for localized mobility management in the network. This puts
infrastructural elements. The goal is that support for localized mobility localized mobility management on the same level as basic IP
management should not require additional security between the mobile node routing. Hosts obtain this service as part of their network access.
and the network. If the access network policy wants to deny localized mobility
management to a mobile node, it can do so at the time network
access authentication occurs, in a manner the reverse of how some
networks restrict routing to the Internet before network access
authentication and open it afterwards.
The goal is that support for localized mobility management should
not require security between the mobile node and the network other
than that required for network access or local link security (such
as SEND [9]).
2.7 Support for Heterogeneous Wireless Link Technologies (Goal #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
growth seems unlikely to slow down. Since the standardization of a wireless the growth seems unlikely to slow down. Since the standardization
link PHY and MAC is a time consuming process, reducing the amount of work of a wireless link physical and medium access control layers is a
necessary to interface a particular wireless link technology to an IP time consuming process, reducing the amount of work necessary to
network is necessary. A localized mobility management solution should interface a particular wireless link technology to an IP network is
ideally require minimal work to interface with a new wireless link necessary. A localized mobility management solution should 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
wireless link technologies within the network in separate subnets. It is not multiple wireless link technologies. It is not required that the
required that the localized mobility management solution support handover localized mobility management solution support handover from one
from one wireless link technology to another without change in IP address. wireless link technology to another without change in IP address,
The reason is because a change in network interface typically requires that but this possibility should not be precluded.
the hardware interface associated with one wireless link technology be
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
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
stack software is implemented.
The goal is that the localized mobility management protocol should not use The goal is that the localized mobility management protocol should
any wireless link specific information for basic routing management, though not use any wireless link specific information for basic routing
it may be used for other purposes, such as identifying a mobile node. management, though it may be used for other purposes, such as
identifying a mobile node.
2.8 Support for Unmodified Mobile Nodes (Goal #8) 2.8 Support for Unmodified Mobile Nodes (Goal #8)
In the wireless LAN switching market, no modification of the
software on the mobile node is required to achieve localized
mobility management. Being able to accommodate unmodified mobile
nodes enables a service provider to offer service to as many
customers as possible, the only constraint being that the customer
is authorized for network access.
In the wireless LAN switching market, no modification of the software on the Another advantage of minimizing mobile node software for localized
mobile node is required to achieve "IP mobility" (which means localized mobility management is that multiple global mobility management
mobility management). Being able to accommodate unmodified mobile nodes protocols can be supported. There are a variety of global mobility
enables a service provider to offer service to as many customers as management protocols that might also need support, including
possible, the only constraint being that the customer is authorized for proprietary or wireless link technology-specific protocols needing
network access. support for backward compatibility reasons. Within the Internet,
both HIP [12] and Mobike [13] are likely to need support in
Another advantage of minimizing mobile node software for localized mobility addition to Mobile IPv6, and Mobile IPv4 support may also be
management is that multiple global mobility management protocols can be necessary.
supported with a localized mobility management solution that does not have
mobile node involvement. While Mobile IPv6 is clearly the global mobility
management protocol of primary interest going forward, there are a variety
of global mobility management protocols that might also need support,
including proprietary protocols needing support for backward compatibility
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.
Note that this goal does NOT mean that the mobile node has no software at Note that this goal does NOT mean that the mobile node has no
all associated with mobility or wireless. The mobile node must have some software at all associated with mobility or wireless. The mobile
kind of global mobility protocol if it is to move from one domain of edge node must have some kind of global mobility protocol if it is to
mobility support to another, although no global mobility protocol is move from one domain of edge mobility support to another and
required if the mobile node only moves within the coverage area of the maintain session continuity, although no global mobility protocol
localized mobility management protocol. Also, every wireless link protocol is required if the mobile node only moves within the coverage area
requires handover support on the mobile node in the physical and MAC layers, of the localized mobility management protocol or no session
typically in the wireless interface driver. Information passed from the MAC continuity is required during global movement. Also, every wireless
layer to the IP layer on the mobile node may be necessary to trigger IP link protocol requires handover support on the mobile node in the
signaling for IP link handover. Such movement detection support at the IP physical and medium access control layers, typically in the
level may be required in order to determine whether the mobile node's wireless interface driver. Information passed from the medium
default router is still reachable after the move to a new access point has access control layer to the IP layer on the mobile node may be
occurred at the MAC layer. Whether or not such support is required depends necessary to trigger IP signaling for IP handover. Such movement
on whether the MAC layer can completely hide link movement from the IP detection support at the IP level may be required in order to
layer. For a wireless link protocol such as the 3G protocols, the mobile determine whether the mobile node's default router is still
node and network undergo an extensive negotiation at the MAC layer prior to reachable after the move to a new access point has occurred at the
handover, so it may be possible to trigger routing update without any IP medium access control layer. Whether or not such support is
protocol involvement. However, for a wireless link protocol such as IEEE required depends on whether the medium access control layer can
802.11 in which there is no network involvement in handover, IP layer completely hide link movement from the IP layer. For a wireless
movement detection signaling from the mobile node may be required to trigger link protocol such as the 3G protocols, the mobile node and network
routing update. undergo an extensive negotiation at the medium access control layer
prior to handover, so it may be possible to trigger routing update
without any IP protocol involvement. However, for a wireless link
protocol such as IEEE 802.11 in which the decision for handover is
entirely in the hands of the mobile node, IP layer movement
detection signaling from the mobile node may be required to trigger
a routing update.
The goal is that the localized mobility management solution should be able The goal is that the localized mobility management solution should
to support any mobile node that walks up to the link and has a wireless be able to support any mobile node that joins the link and that has
interface that can communicate with the network, without requiring localized a wireless interface that can communicate with the network, without
mobility management software on the mobile node. requiring localized mobility management software on the mobile
node.
2.9 Support for IPv4 and IPv6 (Goal #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
management is a problem in IPv4 networks as well. A solution for localized mobility management is a problem in IPv4 networks as well. A
mobility that works for both versions of IP is desirable, though the actual solution for localized mobility that works for both versions of IP
protocol may be slightly different due to the technical details of how each is desirable, though the actual protocol may be slightly different
IP version works. From Goal #8 (Section 2.8), minimizing mobile node support due to the technical details of how each IP version works. From
for localized mobility means that ideally no IP version-specific changes Goal #8 (Section 2.8), minimizing mobile node support for localized
would be required on the mobile node for localized mobility, and that global mobility means that ideally no IP version-specific changes would be
mobility protocols for both IPv4 and IPv6 should be supported. Any IP required on the mobile node for localized mobility, and that global
version-specific features would be confined to the network protocol. mobility protocols for both IPv4 and IPv6 should be supported. Any
IP version-specific features would be confined to the network
protocol.
2.10 Re-use of Existing Protocols Where Sensible (Goal #10) 2.10 Re-use of Existing Protocols Where Sensible (Goal #10)
Many existing protocols are available as Internet Standards upon which the Many existing protocols are available as Internet Standards upon
NETLMM protocol can be built. The design of the protocol should have a goal which the NETLMM protocol can be built. The design of the protocol
to re-use existing protocols where it makes architectural and engineering should have a goal to re-use existing protocols where it makes
sense to do so. The design should not, however, attempt to re-use existing architectural and engineering sense to do so. The design should
protocols where there is no real architectural or engineering reason. For not, however, attempt to re-use existing protocols where there is
example, the suite of Internet Standards contains several good candidate no real architectural or engineering reason. For example, the suite
protocols for the transport layer, so there is no real need to develop a new of Internet Standards contains several good candidate protocols for
transport protocol specifically for NETLMM. Re-use is clearly a good the transport layer, so there is no real need to develop a new
engineering decision in this case, since backward compatibility with transport protocol specifically for NETLMM. Re-use is clearly a
existing protocol stacks is important. On the other hand, the network-based, good engineering decision in this case, since backward
localized mobility management functionality being introduced by NETLMM is a compatibility with existing protocol stacks is important. On the
new piece of functionality, and therefore any decision about whether to re- other hand, the network-based, localized mobility management
use an existing global mobility management protocol should carefully functionality being introduced by NETLMM is a new piece of
consider whether re-using such a protocol really meets the needs of the functionality, and therefore any decision about whether to re-use
functional architecture for network-based localized mobility management. The an existing global mobility management protocol should carefully
case for re-use is not so clear in this case, since there is no compelling consider whether re-using such a protocol really meets the needs of
backward compatibility argument. 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 2.11 Localized Mobility Management Independent of Global Mobility
There are two kinds of security issues involved in network-based localized Management
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 Localized mobility management should be implementable and
parts: threats involved in localized mobility management in general, and deployable independently of any global mobility management
threats to the network-based localized mobility management from the host. protocol. This enables the choice of local and global mobility
The first is discussed above in Sections 2.3 and 2.6. The second is management to be made independently of particular protocols that
discussed in the threat analysis document [28]. are implemented and deployed to solve the two different sorts of
mobility management problems. The operator can choose a particular
localized mobility management protocol according to the specific
features of their access network. It can subsequently upgrade the
localized mobility management protocol on its own, without even
informing the mobile nodes. Similarly, the mobile nodes can use a
global mobility management protocol that best suits their
requirements, or even not use one at all. Also, a mobile node can
move into a new access network without having to check that it
understands the localized mobility management protocol being used
there.
For threats to network-based localized mobility management, the basic threat The goal is that the implementation and deployment of the localized
is an attempt by an unauthorized party to signal a bogus mobility event. mobility management protocol should not restrict, or be restricted
Such an event must be detectable. This requires proper bidirectional by, the choice of global mobility management protocol.
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 2.12 Configurable Data Plane Forwarding between Mobility Anchor and
Access Router
Different network operators may require different types of
forwarding options between the mobility anchor and the access
routers for mobile node data plane traffic. An obvious forwarding
option that has been used in past IETF localized mobility
management protocols is IP-IP encapsulation for bidirectional
tunneling. The tunnel endpoints could be the mobility anchor and
the access routers. But other options are possible. Some network
deployments may prefer routing-based solutions. Others may require
security tunnels using IPsec ESP encapsulation if part of the
localized mobility management domain runs over a public access
network and the network operator wants to protect the traffic.
A goal of the NETLMM protocol is to allow the forwarding between
the mobility anchor and access routers to be configurable depending
on the particulars of the network deployment. Configurability is
not expected to be dynamic as in controlled by the arrival of a
mobile node; but rather, configuration is expected to be similar in
time scale to configuration for routing. The NETLMM protocol may
designate a default forwarding mechanism. It is also possible that
additional work may be required to specify the interaction between
a particular forwarding mechanism and the NETLMM protocol, but this
work is not in scope of the NETLMM base protocol.
3.0 IANA Considerations
There are no IANA considerations for this document.
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 [2].
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 Author's Addresses
James Kempf James Kempf
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: +1 408 451 4711 Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
Kent Leung Kent Leung
skipping to change at page 10, line 18 skipping to change at page 12, line 9
Email: gerardo.giaretta@tilab.com Email: gerardo.giaretta@tilab.com
Marco Liebsch Marco Liebsch
NEC Network Laboratories NEC Network Laboratories
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
69115 Heidelberg 69115 Heidelberg
Germany Germany
Phone: +49 6221-90511-46 Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de Email: marco.liebsch@ccrle.nec.de
5.0 Informative References 6.0 Informative References
[1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch, [1] Kempf, J., editor, "Problem Statement for IP Local Mobility,"
M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet Internet Draft, Work in Progress.
Draft, work in progress. [2] Vogt, C., and Kempf, J., "Security Threats to Network-based
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based Localized Localized Mobillity Management", Internet draft, Work in
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. Progress.
[13] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law [3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
and Policy in the US, EU, and Japan", ISOC Member Briefing #15, 3753, June, 2004.
http://www.isoc.org/briefings/015/index.shtml [4] Carpenter, B., "Architectural Principles of the Internet,"
[14] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and RFC 1958, June, 1996.
Patil, B., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem [5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
Statement", Internet Draft, work in progress. IPv6", RFC 3775.
[15] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol", [6] Choi, J, and Daley, G., "Goals of Detecting Network
Internet Draft, work in progress. Attachment in IPv6", Internet Draft, work in progress.
[16] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
Draft, work in progress. 802.1x, June, 2001.
[8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin,
A., "Protocol for Carrying Authentication for Network Access
(PANA)", Internet Draft, work in progress.
[9] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[10] Moore, N., "Optimistic Neighbor Discovery", Internet Draft,
Work in Progress.
[11] 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.
[12] Moskowitz, R., and Nikander, P., "Host Identity Protocol
(HIP) Architecture", RFC 4423, May, 2006.
[13] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", Internet Draft, Work in Progress.
[14] Koodli, R., "IP Address Location Privacy and IP Mobility",
Internet Draft, Work in Progress.
[15] 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.
[16] 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.
[17] 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.
[18] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
4068, July, 2005.
[17] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., "Solutions [19] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
for IP Address Location Privacy in the presence of IP Mobility", "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
Internet Draft, work in progress. 4140, August, 2005.
[18] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol for [20] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6
Protecting Movement of Mobile Nodes in Mobile IPv6", Internet Draft, Handover Key using SEND", Internet Draft, work in progress.
work in progress. [21] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta,
[19] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H., G., and Bournelle, J., "Handover Keys Using AAA", Internet
Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for Draft, Work in Progress.
Hosts and Routers", Internet Draft, work in progress. [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
[20] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July, "Design, Implementation and Evaluation of Cellular IP", IEEE
2005. Personal Communications, June/July 2000.
[21] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., [23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, "HAWAII: A domain-based approach for supporting mobility in
August, 2005. wide-area wireless networks", in Proceedings of the
[22] Kempf, J., and Koodli, R., "Bootstrapping a Symmetric IPv6 Handover Key International Conference on Networking Protocols (ICNP),
from SEND", Internet Draft, work in progress. 1999.
[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 7.0 IPR Statements
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in this to pertain to the implementation or use of the technology described
document or the extent to which any license under such rights might or might in this document or the extent to which any license under such
not be available; nor does it represent that it has made any independent rights might or might not be available; nor does it represent that
effort to identify any such rights. Information on the procedures with it has made any independent effort to identify any such rights.
respect to rights in RFC documents can be found in BCP 78 and BCP 79. 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 Copies of IPR disclosures made to the IETF Secretariat and any
licenses to be made available, or the result of an attempt made to obtain a assurances of licenses to be made available, or the result of an
general license or permission for the use of such proprietary rights by attempt made to obtain a general license or permission for the use
implementers or users of this specification can be obtained from the IETF of such proprietary rights by implementers or users of this
on-line IPR repository at http://www.ietf.org/ipr. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights that copyrights, patents or patent applications, or other proprietary
may cover technology that may be required to implement this standard. rights that may cover technology that may be required to implement
Please address the information to the IETF at ietf-ipr@ietf.org. this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
7.0 Disclaimer of Validity 8.0 Disclaimer of Validity
This document and the information contained herein are provided on an "AS This document and the information contained herein are provided on
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
8.0 Copyright Notice 9.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject to the Copyright (C) The Internet Society (2006). This document is
rights, licenses and restrictions contained in BCP 78, and except as set subject to the rights, licenses and restrictions contained in BCP
forth therein, the authors retain all their rights. 78, and except as set forth therein, the authors retain all their
rights.
9.0 Appendix: Gap Analysis 10.0 Appendix: Gap Analysis
This section discusses a gap analysis between existing proposals for solving This section discusses a gap analysis between existing proposals
localized mobility management and the goals in Section. 2.0. for solving localized mobility management and the goals in Section.
2.0.
9.1 Mobile IPv6 with Local Home Agent 10.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
the local network. This solution requires the mobile node to somehow be agent in the local network. This solution requires the mobile node
assigned a home agent in the local network when it boots up. This home agent to somehow be assigned a home agent in the local network when it
is used instead of the home agent in the home network. The advantage of this boots up. This home agent is used instead of the home agent in the
option is that no special solution is required for edge mobility - the home network. The advantage of this option is that no special
mobile node reuses the global mobility management protocol for that purpose solution is required for edge mobility - the mobile node reuses the
- if the mobile node is using Mobile IPv6. One disadvantage is that Mobile global mobility management protocol for that purpose - if the
IP has no provision for handover between home agents. Although such handover mobile node is using Mobile IPv6.
should be infrequent, it could be quite lengthy and complex.
The analysis of this approach against the goals above is the following. The analysis of this approach against the goals above is the
following.
Goal #1: If the mobile node does not perform route optimization, this Goal #1 Handover Performance Improvement: If the mobile node does
solution reduces, but does not eliminate, IP link handover related not perform route optimization, this solution reduces, but does not
performance problems. eliminate, IP handover related performance problems.
Goal #2: Similarly to Goal #1, signaling volume is reduced if no route Goal #2 Reduction in Handover-related Signaling Volume: Similarly
optimization signaling is done on handover. to Goal #1, signaling volume is reduced if no route optimization
signaling is done on handover.
Goal #3: Location privacy is preserved for external correspondents, but the Goal #3 Location privacy: Location privacy is preserved for
mobile node itself still maintains a local care-of address which a worm or external correspondents, but the mobile node itself still maintains
other exploit could misuse. If the mobile node does perform route a local care-of address. If the mobile node performs route
optimization, location privacy may be compromised, and this solution is no optimization, location privacy may be compromised, but not
better than having a remote home agent. performing route optimization is no better than having a remote
home agent.
Goal #4: If traffic is not route optimized, the mobile node still pays for Goal #4 Efficient Use of Wireless Resources: If traffic is not
an over-the-air tunnel to the locally assigned home agent. The overhead here route optimized, the mobile node still pays for an over-the-air
is exactly the same as if the mobile node's home agent in the home network tunnel to the locally assigned home agent. The overhead here is
is used and route optimization is not done. exactly the same as if the mobile node's home agent in the home
network is used and route optimization is not done.
Goal #5: If the localized mobility management domain is large, the mobile Goal #5 Limit the Signaling Overhead in the Network: If the
node may suffer from unoptimzed routes. RFC 3775 [6] provides no support for localized mobility management domain is large, the mobile node may
notifying a mobile node that another localized home agent is available for a suffer from unoptimzed routes. RFC 3775 [5] provides no support for
more optimized route, or for handing over between home agents. A mobile node notifying a mobile node that another localized home agent is
would have to perform the full home agent bootstrap procedure, including available for a more optimized route, or for handing over between
establishing a new IPsec SA with the new home agent. 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.
Goal #6: A local home agent in a roaming situation requires the guest mobile Goal #6 No Extra Security Between Mobile Node and Network: A local
node to have the proper credentials to authenticate with the local home home agent in a roaming situation requires the guest mobile node to
agent in the serving network. Although the credentials used for network have the proper credentials to authenticate with the local home
access authentication could also be used for mobile service authentication agent in the serving network. Although the credentials used for
and authorization if the local home agent uses EAP over IKEv2 to network access authentication could also be used for mobile service
authenticate the mobile node with its home AAA server, the two sets of authentication and authorization if the local home agent uses EAP
credentials are in principle different, and could require additional over IKEv2 to authenticate the mobile node with its home AAA
credential provisioning. In addition, as in Goal #3, if binding updates are server, the two sets of credentials are in principle different, and
done in cleartext over the access network or the mobile node has become could require additional credential provisioning. In addition, as
infected with malware, the local home agent's address could be revealed to in Goal #3, if binding updates are done in cleartext over the
attackers and the local home agent could become the target of a DoS attack. access network or the mobile node has become infected with malware,
So a local home agent would provide no benefit for this goal. 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.
Goal #7: This solution supports multiple wireless technologies in separate Goal #7 Support for Heterogeneous Wireless Link Technologies: This
IP link subnets. No special work is required to interface a local home agent solution supports multiple wireless technologies with separate IP
to different wireless technologies. subnets for different links. No special work is required to
interface a local home agent to different wireless technologies.
Goal #8: The mobile node must support Mobile IPv6 in order for this option Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
to work. So mobile node changes are required and other IP mobility protocols support Mobile IPv6 in order for this option to work. So mobile
are not supported. node changes are required and other IP mobility protocols are not
supported.
Goal #9: The Mobile IPv6 working group is working on modifying the protocol Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is
to allow registration of IPv4 care-of addresses in an IPv6 home agent, and working on modifying the protocol to allow registration of IPv4
also to allow a mobile node to have an IPv4 care of address [19]. care-of addresses in an IPv6 home agent, and also to allow a mobile
node to have an IPv4 care of address [17].
Goal #10 This solution re-uses an existing protocol, Mobile IPv6. Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, Mobile IPv6.
9.2 Hierarchical Mobile IPv6 (HMIPv6) Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution merges localized mobility
management and global mobility management, so it does not support
the goal.
HMIPv6 [21] provides the most complete localized mobility management 10.2 Hierarchical Mobile IPv6 (HMIPv6)
solution available today as an RFC. In HMIPv6, a localized mobility anchor
called a MAP serves as a routing anchor for a regional care-of address. When HMIPv6 [19] provides the most complete localized mobility
a mobile node moves from one access router to another, the mobile node management solution available today. In HMIPv6, a localized
changes the binding between its regional care-of address and local care-of mobility anchor called a MAP serves as a routing anchor for a
address at the MAP. No global mobility management signaling is required, regional care-of address. When a mobile node moves from one access
since the care-of address seen by correspondents does not change. This part router to another, the mobile node changes the binding between its
of HMIPv6 is similar to the solution outlined in Section 9.1; however, regional care-of address and local care-of address at the MAP. No
global mobility management signaling is required, since the care-of
address seen by correspondents does not change. This part of HMIPv6
is similar to the solution outlined in Section 10.1; however,
HMIPv6 also allows a mobile node to hand over between MAPs. 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
routers. MAP addresses are advertised by access routers. Handover happens by the routers. MAP addresses are advertised by access routers.
overlapping MAP coverage areas so that, for some number of access routers, Handover happens by overlapping MAP coverage areas so that, for
more than one MAP may be advertised. Mobile nodes need to switch MAPs in the some number of access routers, more than one MAP may be advertised.
transition area, and then must perform global mobility management update and Mobile nodes need to switch MAPs in the transition area, and then
route optimization to the new regional care-of address, if appropriate. must perform global mobility management update and route
optimization to the new regional care-of address, if appropriate.
The analysis of this approach against the goals above is the following. The analysis of this approach against the goals above is the
following.
Goal #1 This solution shortens, but does not eliminate, the latency Goal #1 Handover Performance Improvement: This solution shortens,
associated with IP link handover, since it reduces the amount of signaling but does not eliminate, the latency associated with IP handover,
and the length of the signaling paths. since it reduces the amount of signaling and the length of the
signaling paths.
Goal #2 Signaling volume is reduced simply because no route optimization Goal #2 Reduction in Handover-related Signaling Volume: Signaling
signaling is done on handover within the coverage area of the MAP. volume is reduced simply because no route optimization signaling is
done on handover within the coverage area of the MAP.
Goal #3 Location privacy is preserved for external correspondents, but the Goal #3 Location privacy: Location privacy is preserved for
mobile node itself still maintains a local care-of address which a worm or external correspondents.
other exploit could access by sending the local care-of address to third
malicious node to enable it to track the mobile node's location.
Goal #4 The mobile node always pays for an over-the-air tunnel to the MAP. Goal #4 Use of Wireless Resources: The mobile node always pays for
If the mobile node is tunneling through a global home agent or VPN gateway, an over-the-air tunnel to the MAP. If the mobile node is tunneling
the wired link experiences double tunneling. Over-the-air tunnel overhead through a global home agent or VPN gateway, the wired link
can be removed by header compression, however. experiences double tunneling. Over-the-air tunnel overhead can be
removed by header compression, however.
Goal #5 From Goal #1 and Goal #4, the signaling overhead is no more or less Goal #5 Limit the Signaling Overhead in the Network: From Goal #1
than for mobile nodes whose global mobility management anchor is local. and Goal #4, the signaling overhead is no more or less than for
However, because MAP handover is possible, routes across large localized mobile nodes whose global mobility management anchor is local.
mobility management domains can be improved thereby improving wired network However, because MAP handover is possible, forwarding across large
resource utilization by using multiple MAPs and handing over, at the expense localized mobility management domains can be improved thereby
of the configuration and management overhead involved in maintaining improving wired network resource utilization by using multiple MAPs
multiple MAP coverage areas. and handing over, at the expense of the configuration and
management overhead involved in maintaining multiple MAP coverage
areas.
Goal #6 In a roaming situation, the guest mobile node must have the proper Goal #6 Extra Security Between Mobile Node and Network: In a
roaming situation, the guest mobile node must have the 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
the MAP that is either globally routed or routing restricted to the local address for the MAP that is either globally routed or routing
administrative domain, the MAP is potentially a target for DoS attacks restricted to the local administrative domain, the MAP is
across a wide swath of network topology. potentially a target for DoS attacks across a wide swath of network
topology.
Goal #7 This solution supports multiple wireless technologies in separate IP Goal #7 Support for Heterogeneous Wireless Link Technologies: This
link subnets. solution supports multiple wireless technologies with separate IP
subnets for different links.
Goal #8 This solution requires modification to the mobile nodes. In Goal #8 Support for Unmodified Mobile Nodes: This solution requires
addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, modification to the mobile nodes. In addition, the HMIPv6 design
and is not a good match for other global mobility management protocols. has been optimized for Mobile IPv6 mobile nodes, and is not a good
match for other global mobility management protocols.
Goal #9 Currently, there is no IPv4 version of this protocol; although there Goal #9 Currently, there is no IPv4 version of this protocol;
is an expired Internet draft with a design for a regional registration although there is an expired Internet draft with a design for a
protocol for Mobile IPv4 that has similar functionality. It is possible that regional registration protocol for Mobile IPv4 that has similar
the same IPv4 transition solution as used for Mobile IPv6 could be used functionality. It is possible that the same IPv4 transition
[19]. solution as used for Mobile IPv6 could be used [17].
Goal #10 This solution re-uses an existing protocol, HMIPv6. Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, HMIPv6.
9.3 Combinations of Mobile IPv6 with Optimizations Goal #11 Localized Mobility Management Independent of Global
Mobility Management: While HIMPv6 is technically a separate
protocol from MIPv6 and could in principle be implemented and
deployed without MIPv6, the design is very similar and
implementation and deployment would be easier if the mobile nodes
supported MIPv6.
One approach to local mobility that has received much attention in the past 10.3 Combinations of Mobile IPv6 with Optimizations
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
by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6
and HMIPv6 + FMIPv6 are discussed.
9.3.1 MIPv6 + FMIPv6 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 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 and HMIPv6 + FMIPv6 are
discussed.
As discussed in Section 9.1, the use of MIPv6 with a dynamically assigned, 10.3.1 MIPv6 with local home agent + FMIPv6
local home agent cannot fulfill the goals. A fundamental limitation is that
Mobile IPv6 cannot provide seamless handover (i.e. Goal #1). FMIPv6 has been
defined with the intent to improve the handover performance of MIPv6. For
this reason, the combined usage of FMIPv6 and MIPv6 with a dynamically
assigned local home agent has been proposed to handle local mobility.
Note that this gap analysis only applies to localized mobility management, As discussed in Section 10.1, the use of MIPv6 with a dynamically
and it is possible that MIPv6 and FMIPv6 might still be acceptable for assigned, local home agent cannot fulfill the goals. A fundamental
global mobility management. limitation is that Mobile IPv6 cannot provide seamless handover
(i.e. Goal #1). FMIPv6 [18] has been defined with the intent to
improve the handover performance of MIPv6. For this reason, the
combined usage of FMIPv6 and MIPv6 with a dynamically assigned
local home agent has been proposed to handle local mobility.
Note that this gap analysis only applies to localized mobility
management, and it is possible that MIPv6 and FMIPv6 might still be
acceptable for global mobility management.
The analysis of this combined approach against the goals follows. The analysis of this combined approach against the goals follows.
Goal #1 FMIPv6 provides a solution for handover performance improvement that Goal #1 Handover Performance Improvement: FMIPv6 provides a
should fulfill the goals raised by real-time applications in terms of solution for handover performance improvement that should fulfill
jitter, delay and packet loss. The location of the home agent (in local or the goals raised by real-time applications in terms of jitter,
delay and packet loss. The location of the home agent (in local or
home domain) does not affect the handover latency. home domain) does not affect the handover latency.
Goal #2 FMIPv6 requires the mobile node to perform extra signaling with the Goal #2 Reduction in Handover-related Signaling Volume: FMIPv6
access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as requires the mobile node to perform extra signaling with the access
in standard MIPv6, whenever the mobile node moves to another IP link, it router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
must send a Binding Update to the home agent. If route optimization is used, in standard MIPv6, whenever the mobile node moves to another link,
the mobile node also performs return routability and sends a Binding Update it must send a Binding Update to the home agent. If route
to each correspondent node. Nonetheless, it is worth noting that FMIPv6 optimization is used, the mobile node also performs return
should result in a reduction of the amount of IPv6 Neighbor Discovery routability and sends a Binding Update to each correspondent node.
signaling on the new link. Nonetheless, it is worth noting that FMIPv6 should result in a
reduction of the amount of IPv6 Neighbor Discovery signaling on the
new link.
Goal #3 The mobile node mantains a local care-of address. If route Goal #3 Location privacy: The mobile node mantains a local care-of
optimization is not used, location privacy can be achieved using bi- address. If route optimization is not used, location privacy can be
directional tunneling. However, as mentioned in Section 9.1, a worm or other achieved using bi-directional tunneling.
malware can exploit this care of address by sending it to a third malicious
node.
Goal #4 As stated for Goal #2, the combination of MIPv6 and FMIPv6 generates Goal #4 Use of Wireless Resources: As stated for Goal #2, the
extra signaling overhead. For data packets, in addition to the Mobile IPv6 combination of MIPv6 and FMIPv6 generates extra signaling overhead.
over-the-air tunnel, there is a further level of tunneling between the For data packets, in addition to the Mobile IPv6 over-the-air
mobile node and the previous access router during handover. This tunnel is tunnel, there is a further level of tunneling between the mobile
needed to forward incoming packets to the mobile node addressed to the node and the previous access router during handover. This tunnel is
previous care-of address. Another reason is that, even if the mobile node needed to forward incoming packets to the mobile node addressed to
has a valid new care-of address, the mobile node cannot use the new care of the previous care-of address. Another reason is that, even if the
address directly with its correspondents without performing route mobile node has a valid new care-of address, the mobile node cannot
optimization to the new care of address. This implies that the transient use the new care of address directly with its correspondents
tunnel overhead is in place even for route optimized traffic. without performing route optimization to the new care of address.
This implies that the transient tunnel overhead is in place even
for route optimized traffic.
Goal #5 FMIPv6 generates extra signaling overhead between the previous Goal #5 Limit the Signaling Overhead in the Network: FMIPv6
access router and the new access router for the HI/HAck exchange. Concerning generates extra signaling overhead between the previous access
data packets, the use of FMIPv6 for handover performance improvement implies router and the new access router for the HI/HAck exchange.
a tunnel between the previous access router and the mobile node that adds Concerning data packets, the use of FMIPv6 for handover performance
some overhead in the wired network. This overhead has more impact on star improvement implies a tunnel between the previous access router and
topology deployments, since packets are routed down to the old access the mobile node that adds some overhead in the wired network. This
router, then back up to the aggregation router and then back down to the new overhead has more impact on star topology deployments, since
access router. packets are routed down to the old access router, then back up to
the aggregation router and then back down to the new access router.
Goal #6 In addition to the analysis for Mobile IPv6 with local home agent in Goal #6 Extra Security Between Mobile Node and Network: In addition
Section 9.1, FMIPv6 requires the mobile node and the previous access router to the analysis for Mobile IPv6 with local home agent in Section
to share a security association in order to secure FBU/FBA exchange. So far, 10.1, FMIPv6 requires the mobile node and the previous access
only a SEND-based solution has been proposed and this requires the mobile router to share a security association in order to secure FBU/FBA
node to use autoconfigured Cryptographically Generated Addresses (CGAs)[22]. exchange. Two solutions have been proposed: a SEND-based solution
This precludes stateful address allocation using DHCP, which might be a [20] and an AAA-based solution [21]. Both solutions require
necessary deployment in certain circumstances. Another solution based on AAA additional support on the mobile node and in the network beyond
is under study but it could require extra signaling overhead over the air what is required for network access authentication.
and in the wired network and it could raise performance issues.
Goal #7 MIPv6 and FMIPv6 support multiple wireless technologies, so this Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6
goal is fufilled. and FMIPv6 support multiple wireless technologies, so this goal is
fufilled.
Goal #8 The mobile node must support both MIPv6 and FMIPv6, so it is not Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
possible to satisfy this goal. support both MIPv6 and FMIPv6, so it is not possible to satisfy
this goal.
Goal #9 Work is underway to extend MIPv6 with the capability to run over Goal #9 Support for IPv4 and IPv6: Work is underway to extend MIPv6
both IPv6-enabled and IPv4-only networks [19]. FMIPv6 only supports IPv6. with the capability to run over both IPv6-enabled and IPv4-only
Even though an IPv4 version of FMIP has been recently proposed, it is not networks [17]. FMIPv6 only supports IPv6. Even though an IPv4
clear how it could be used together with FMIPv6 in order to handle fast version of FMIP has been recently proposed, it is not clear how it
could be used together with FMIPv6 in order to handle fast
handovers across any wired network. handovers across any wired network.
Goal #10 This solution re-uses existing protocols, Mobile IPv6 and FMIPv6. Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses existing protocols, Mobile IPv6 and FMIPv6.
9.3.2 HMIPv6 + FMIPv6 Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution merges localized mobility
management and global mobility management, so it does not support
the goal.
HMIPv6 provides several advantages in terms of local mobility management. 10.3.2 HMIPv6 + FMIPv6
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
eliminate the IP link handover latency. For this reason, FMIPv6 could be
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 HMIPv6 provides several advantages in terms of local mobility
MIPv6 for global mobility management, in contrast with the MIPv6 with management. However, as seen in Section 10.2, it does not fulfill
dynamically assigned local home agent + FMIPv6 solution. Thus, this solution all the goals identified in Section 2.0. In particular, HMIPv6 does
should really be considered MIPv6 + HMIPv6 + FMIPv6. not completely eliminate the IP handover latency. For this reason,
FMIPv6 could be 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 MIPv6 for global mobility management, in contrast with the
MIPv6 with dynamically assigned local home agent + FMIPv6 solution.
Thus, this solution should really be considered MIPv6 + HMIPv6 +
FMIPv6.
The analysis of this combined approach against the goals follows. The analysis of this combined approach against the goals follows.
Goal #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP link Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both
handovers. In particular, FMIPv6 is expected to fulfill the goals on jitter, shorten the latency associated with IP handovers. In particular,
delay and packet loss raised by real-time applications. FMIPv6 is expected to fulfill the goals on jitter, delay and packet
loss raised by real-time applications.
Goal #2 Both FMIPv6 and HMIPv6 require extra signaling compared with Mobile Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6
IPv6. As a whole the mobile node performs signaling message exchanges at and HMIPv6 require extra signaling compared with Mobile IPv6. As a
each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. However, whole the mobile node performs signaling message exchanges at each
as mentioned in Section 9.2, the use of HMIPv6 reduces the signaling handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA.
overhead since no route optimization signaling is done for intra-MAP
handovers. In addition, na´ve combinations of FMIPv6 and HMIPv6 often result
in redundant signaling. There is much work in the academic literature and
the IETF on more refined ways of combining signaling from the two protocols
to avoid redundant signaling.
Goal #3 HMIPv6 may preserve location privacy, depending on the dimension of However, as mentioned in Section 10.2, the use of HMIPv6 reduces
the geographic area covered by the MAP. As discussed in Section 9.2, the the signaling overhead since no route optimization signaling is
mobile node still maintains a local care-of address that can be exploited by done for intra-MAP handovers. In addition, naive combinations of
worms or other malware. FMIPv6 and HMIPv6 often result in redundant signaling. There is
much work in the academic literature and the IETF on more refined
ways of combining signaling from the two protocols to avoid
redundant signaling.
Goal #4 As mentioned for Goal #2, the combination of HMIPv6 and FMIPv6 Goal #3 Location privacy: HMIPv6 may preserve location privacy,
generates a lot of signaling overhead in the network. Concerning payload depending on the dimension of the geographic area covered by the
data, in addition to the over-the-air MIPv6 tunnel, a further level of MAP.
tunneling is established between mobile node and MAP. Notice that this
tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is
directly applied to HMIPv6 networks, there is a third temporary handover-
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
extra tunnel overhead on handover by combining HMIP and FMIP tunneling.
Goal #5 The signaling overhead in the network is not reduced by HMIPv6, as Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the
mentioned in Section 9.2. Instead, FMIPv6 generates extra signaling overhead combination of HMIPv6 and FMIPv6 generates a lot of signaling
between the previous access router and new access router for HI/HAck overhead in the network. Concerning payload data, in addition to
exchange. For payload data, the same considerations as for Goal #4 are the over-the-air MIPv6 tunnel, a further level of tunneling is
applicable. established between mobile node and MAP. Notice that this tunnel is
in place even for route optimized traffic. Moreover, if FMIPv6 is
directly applied to HMIPv6 networks, there is a third temporary
handover-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 extra tunnel overhead on handover by
combining HMIP and FMIP tunneling.
Goal #6 FMIPv6 requires the mobile node and the previous access router to Goal #5 Limit the Signaling Overhead in the Network: The signaling
share a security association in order to secure the FBU/FBA exchange. In overhead in the network is not reduced by HMIPv6, as mentioned in
addition, HMIPv6 requires that the mobile node and MAP share an IPsec Section 10.2. Instead, FMIPv6 generates extra signaling overhead
security association in order to secure LBU/LBA exchange. The only well between the previous access router and new access router for
understood approach to set up an IPsec security association using of HI/HAck exchange. For payload data, the same considerations as for
certificates, but this may raise deployment issues. Thus, the combination of Goal #4 are applicable.
FMIPv6 and HMIPv6 doubles the amount of mobile node to network security
protocol required, since security for both FMIP and HMIP must be deployed.
Goal #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so this Goal #6 Security Between Mobile Node and Network: FMIPv6 requires
the mobile node and the previous access router to share a security
association in order to secure the FBU/FBA exchange. In addition,
HMIPv6 requires that the mobile node and MAP share an IPsec
security association in order to secure LBU/LBA exchange. The only
well understood approach to set up an IPsec security association is
the use of certificates, but this may raise deployment issues.
Thus, the combination of FMIPv6 and HMIPv6 doubles the amount of
mobile node to network security protocol required, since security
for both FMIP and HMIP must be deployed.
Goal #7 Support for Heterogeneous Wireless Link Technologies:
HMIPv6 and FMIPv6 support multiple wireless technologies, so this
goal is fufilled. goal is fufilled.
Goal #8 The mobile node must support both HMIPv6 and FMIPv6 protocols, so Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
this goal is not fulfilled. support both HMIPv6 and FMIPv6 protocols, so this goal is not
fulfilled.
Goal #9 Currently there is no IPv4 version of HMIPv6. There is an IPv4 Goal #9 Support for IPv4 and IPv6: Currently there is no IPv4
version of FMIP but it is not clear how it could be used together with version of HMIPv6. There is an IPv4 version of FMIP but it is not
FMIPv6 in order to handle fast handovers across any wired network. clear how it could be used together with FMIPv6 in order to handle
fast handovers across any wired network.
Goal #10 This solution re-uses existing protocols, HMIPv6 and FMIPv6. Goal #10 Re-use of Existing Protocols Where Sensible: This
solution re-uses existing protocols, HMIPv6 and FMIPv6.
9.4 Micromobility Protocols Goal #11 Localized Mobility Management Independent of Global
Mobility Management: While HIMPv6 is technically a separate
protocol from MIPv6 and could in principle be implemented and
deployed without MIPv6, the design is very similar and
implementation and deployment would be easier if the mobile nodes
supported MIPv6.
Researchers have defined some protocols that are often characterized as 10.4 Micromobility Protocols
micromobility protocols. Two typical protocols in this category are
Cellular-IP [23] and HAWAII [24]. Researchers defined these protocols before
local mobility optimizations for Mobile IP such as FMIP and HMIP were
developed, in order to reduce handover latency.
The micromobility approach to localized mobility management requires host Researchers have defined some protocols that are often
route propagation from the mobile node to a collection of specialized characterized as micromobility protocols. Two typical protocols in
routers in the localized mobility management domain along a path back to a this category are Cellular-IP [22] and HAWAII [23]. Researchers
boundary router at the edge of the localized mobility management domain. A defined these protocols before local mobility optimizations for
boundary router is a kind of localized mobility management domain gateway. Mobile IP such as FMIP and HMIP were developed, in order to reduce
Localized mobility management is authorized with the access router, but handover latency. Cellular-IP and HAWAII were proposed in the IETF
reauthorization with each new access router is necessary on IP link for standardization, but after some study in the IRTF, were
movement, in addition to any reauthorization for basic network access. The dropped. There are many micromobility protocols defined in the
host routes allow the mobile node to maintain the same IP address when it academic literature, but in this document, the term is used
moves to a new IP link, and still continue to receive packets on the new IP specifically to refer to Cellular-IP and HAWAII.
link.
Cellular IP and HAWAII have a few things in common. Both are compatible The micromobility approach to localized mobility management
with Mobile IP and are intended to provide a higher level of handover requires host route propagation from the mobile node to a
performance in local networks than was previously available with Mobile IP collection of specialized routers in the localized mobility
without such extensions as HMIP and FMIP. Both use host routes installed in management domain along a path back to a boundary router at the
a number of routers within a restricted routing domain. Both define specific edge of the localized mobility management domain. A boundary router
messaging to update those routes along the forwarding path and specify how is a kind of localized mobility management domain gateway.
the messaging is to be used to update the routing tables and forwarding Localized mobility management is authorized with the access router,
tables along the path between the mobile and a micromobility domain boundary but reauthorization with each new access router is necessary on
router at which point Mobile IP is to used to handle scalable global link movement, in addition to any reauthorization for basic network
mobility. Unlike the FMIP and HMIP protocols, however, these protocols do access. The host routes allow the mobile node to maintain the same
not require the mobile node to obtain a new care of address on each access IP address when it moves to a new link, and still continue to
router as it moves; but rather, the mobile node maintains the same care of receive packets on the new link.
address across the micromobility domain. From outside the micromobility
domain, the care of address is routed using traditional longest prefix
matching IP routing to the domain's boundary router, so the care of address
conceptually is within the micromobiity domain boundary router's subnet.
Within the micromobility domain, the care of address is routed to the
correct access router using host routes.
Cellular IP and HAWAII differ in a few aspects. Cellular IP seems to be Cellular IP and HAWAII have a few things in common. Both are
restricted, based on the nature of the protocol, to tree-based network compatible with Mobile IP and are intended to provide a higher
topologies. HAWAII claims to be applicable in both tree-based and more level of handover performance in local networks than was previously
complete network topologies. HAWAII documents more functionality in the available with Mobile IP without such extensions as HMIP and FMIP.
realm of reliability and QoS interworking. Both protocols involve the Both use host routes installed in a number of routers within a
mobile node itself in mobility operations, although this is also true of the restricted routing domain. Both define specific messaging to update
Mobile IP based optimizations, so both protocols raise the same security those routes along the forwarding path and specify how the
concerns with respect to authorizing address update as the Mobile IP based messaging is to be used to update the routing tables and forwarding
optimizations. HAWAII provides some analysis of network deployment tables along the path between the mobile and a micromobility domain
scenarios including scale, density, and efficiency, but some of these boundary router at which point Mobile IP is to used to handle
assumptions seem very conservative compared to realistic cellular type global mobility in a scalable way. Unlike the FMIP and HMIP
deployments. protocols, however, these protocols do not require the mobile node
to obtain a new care of address on each access router as it moves;
but rather, the mobile node maintains the same care of address
across the micromobility domain. From outside the micromobility
domain, the care of address is routed using traditional longest
prefix matching IP routing to the domain's boundary router, so the
care of address conceptually is within the micromobiity domain
boundary router's subnet. Within the micromobility domain, the care
of address is routed to the correct access router using host
routes.
Micromobility protocols have some potential drawbacks from a deployment and Micromobility protocols have some potential drawbacks from a
scalability standpoint. Both protocols involve every routing element between deployment and scalability standpoint. Both protocols involve every
the mobile device and the micromobility domain boundary router in all packet routing element between the mobile device and the micromobility
forwarding decisions specific to care of addresses for mobile nodes. domain boundary router in all packet forwarding decisions specific
Scalability is limited because each care of address corresponding to a to care of addresses for mobile nodes. Scalability is limited
mobile node generates a routing table entry, and perhaps multiple forwarding because each care of address corresponding to a mobile node
table entries, in every router along the path. Since mobile nodes can have generates a routing table entry, and perhaps multiple forwarding
multiple global care of addresses in IPv6, this can result in a large table entries, in every router along the path. Since mobile nodes
expansion in router state throughout the micromobility routing domain. can have multiple global care of addresses in IPv6, this can result
Although the extent of the scalability for micromobility protocols is still in a large expansion in router state throughout the micromobility
not clearly understood from a research standpoint, it seems certain that routing domain. Although the extent of the scalability for
they will be less scalable than the Mobile IP optimization enhancements, and micromobility protocols is still not clearly understood from a
will require more specialized gear in the wired network. research standpoint, it seems certain that they will be less
scalable than the Mobile IP optimization enhancements, and 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
goals in Section 2.0: against the goals in Section 2.0:
Goal #1 The micromobility protocols reduce handover latency by quickly Goal #1 Handover Performance Improvement: The micromobility
fixing up routes between the boundary router and the access router. While protocols reduce handover latency by quickly fixing up routes
some additional latency may be expected during host route propagation, it is between the boundary router and the access router. While some
typically much less than experienced with standard Mobile IP. additional latency may be expected during host route propagation,
it is typically much less than experienced with standard Mobile IP.
Goal #2 The micromobility protocols require signaling from the mobile node Goal #2 Reduction in Handover-related Signaling Volume: The
to the access router to initiate the host route propagation, but that is a micromobility protocols require signaling from the mobile node to
considerable reduction over the amount of signaling required to configure to the access router to initiate the host route propagation, but that
a new IP link. is a considerable reduction over the amount of signaling required
to configure to a new link.
Goal #3 No care-of address changes are exposed to correspondent nodes or the Goal #3 Location privacy: No care-of address changes are exposed to
mobile node itself while the mobile node is moving in the micromobility- correspondent nodes or the mobile node itself while the mobile node
managed network. Because there is no local care-of address, there is no is moving in the micromobility-managed network.
threat from malware that exposes the location by sending the care-of address
to an adversary.
Goal #4 The only additional over-the-air signaling is involved in Goal #4 Use of Wireless Resources: The only additional over-the-air
propagating host routes from the mobile node to the network upon movement. signaling is involved in propagating host routes from the mobile
Since this signaling would be required for movement detection in any case, node to the network upon movement. Since this signaling would be
it is expected to be minimal. Mobile node traffic experiences no overhead. required for movement detection in any case, it is expected to be
minimal. Mobile node traffic experiences no overhead.
Goal #5 Host route propagation is required throughout the wired network. The Goal #5 Limit the Signaling Overhead in the Network: Host route
volume of signaling could be more or less depending on the speed of mobile propagation is required throughout the wired network. The volume of
signaling could be more or less depending on the speed of mobile
node movement and the size of the wired network. node movement and the size of the wired network.
Goal #6 The mobile node only requires a security association of some type Goal #6 Security Between Mobile Node and Network: The mobile node
with the access router. Because the signaling is causing routes to the only requires a security association of some type with the access
mobile node's care-of address to change, the signaling must prove router. Because the signaling is causing routes to the mobile
node's care-of address to change, the signaling must prove
authorization to hold the address. authorization to hold the address.
Goal #7 The micromobility protocols support multiple wireless technologies, Goal #7 Support for Heterogeneous Wireless Link Technologies:
so this goal is satisfied. HMIPv6 The micromobility protocols support multiple wireless
technologies, so this goal is satisfied.
Goal #8 The mobile node must support some way of signaling the access router
on link handover, but this is required for movement detection anyway. The
nature of the signaling for the micromobility protocols may mobile node
software changes, however.
Goal #9 Most of the work on the micromobility protocols was done in IPv4,
but little difference could be expected for IPv6.
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
micromobility routing protocol in the access network, a standardized
Internal Gateway route distribution Protocol (IGP) such as IS-IS [26] or
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
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
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
the advantage that standardized routing equipment can be used for all
routers in the access network, and, if a particular router goes down, the
host routes maintained along alternate routes should be sufficient to
continue routing, unlike micromobility protocols where only targeted routers
have the host routes.
Distributing host routes with an IGP has some significant disadvantages
however. One is that flooding requires a certain amount of time to converge;
so for some period after the link handover blackout, delivery to a mobile
node that has moved will be disrupted until convergence along the routes
traveled by the mobile node's traffic has occurred. Because micromobility
protocols target host routes back to the micromobility domain border router,
convergence can potentially be achieved more quickly. Tunnel-based solutions
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
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
intensive path computation.
Another disadvantage of using an IGP is that each router in the domain must
maintain a full host route table for all hosts. This goal raises a
scalability issue. For example, an experiment [25] using OSPF to distribute
host routes through an access network consisting of a collection of rather
smallish enterprise routers indicated that about 25,000 routes could be
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
(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
costs continue to drop, the amount of processing power for searching a
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.
Micromobility and tunnel- based solutions don't suffer from this problem,
because the host route is local to the tunnel endpoints. Other routers in
the domain route based on highly scalable shortest matching network prefix
method.
The following is a gap analysis of host route distribution using a
standardized IGP against the goals in Section 2.0:
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
access network. The exact amount of latency depends on the convergence
characteristics of the particular IGP and the topology of the access
network, i.e. how fast convergence occurs along routes taken by the mobile
node's traffic.
Goal #2 Host route distribution using an IGP requires signaling from the
mobile node to the access router to initiate the host route propagation, but
that is a considerable reduction over the amount of signaling required to
configure to a new IP link. However, if a mobile node is moving quickly, the
flooding traffic necessary to propagate a host route may not converge before
the mobile node hands over again. This could result in a cacscading series
of host route updates that never converge. Whether or not this effect occurs
depends on the size of the localized mobility domain, and so the need to
ensure convergence places an upper bound on the size of the domain or
expected movement speed of the mobile nodes.
Goal #3 No care-of address changes are exposed to correspondent nodes or the
mobile node itself while the mobile node is moving in the localized mobility
management domain. Because there is no local care-of address, there is no
threat from malware that exposes the location by sending the care-of address
to an adversary.
Goal #4 The only additional over-the-air signaling involved is signaling
from the mobile node to the access router indicating that the mobile node
has moved. Mobile node traffic experiences no overhead.
Goal #5 Host route propagation is required throughout the wired network. The
volume of signaling could be more or less depending on the speed of mobile
node movement and the size of the wired network.
Goal #6 The mobile node only requires a security association of some type
with the access router. Because the signaling is causing routes to the
mobile node's care-of address to change, the signaling must prove
authorization to hold the address.
Goal #7 This goal is satisfied by default, since the IGPs are used over the Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
wired backbone. support some way of signaling the access router on link handover,
but this is required for movement detection anyway. The nature of
the signaling for the micromobility protocols may require mobile
node software changes, however.
Goal #8 The mobile node needs to perform some kind of active movement Goal #9 Re-use of Existing Protocols Where Sensible: Support for
detection with proof of identity to trigger the host route distribution, but IPv4 and IPv6: Most of the work on the micromobility protocols was
this kind of signaling is needed for movement regardless of whether done in IPv4, but little difference could be expected for IPv6.
localized mobility management is deployed. Depending on the wireless link
type, this may be handled by the wireless link layer.
Goal #9 Since the IGPs support both IPv4 and IPv6, both are supported by Goal #10 This solution does not reuse an existing protocol because
this technique. there is currently no Internet Standard protocol for micromobility.
Goal #10 This solution re-uses existing protocols, OSPF or IS-IS. Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution separates global and local
mobility management, since the micromobility protocols only support
localized mobility management.
9.6 Summary 10.5 Summary
The following table summarizes the discussion in Section 9.1 through 9.5. In The following table summarizes the discussion in Section 9.1
the table, a "M" indicates that the protocol completely meets the goal, a through 9.5. In the table, a "M" indicates that the protocol
"P" indicates that it partially meets the goal, and an "X" indicates that it completely meets the goal, a "P" indicates that it partially meets
does not meet the goal. the goal, and an "X" indicates that it does not meet the goal.
Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
-------- -- -- -- -- -- -- -- -- -- --- -------- -- -- -- -- -- -- -- -- -- ---
MIPv6 P X X X X X M X M M MIPv6 P X X X X X M X M M
HMIPv6 P X X X P X M X X M HMIPv6 P X X X P X M X X M
MIPv6 + MIPv6 +
FMIPv6 M X X X P X M X P M FMIPv6 M X X X P X M X P M
skipping to change at page 22, line 35 skipping to change at page 24, line 4
MIPv6 P X X X X X M X M M MIPv6 P X X X X X M X M M
HMIPv6 P X X X P X M X X M HMIPv6 P X X X P X M X X M
MIPv6 + MIPv6 +
FMIPv6 M X X X P X M X P M FMIPv6 M X X X P X M X P M
HMIPv6 + HMIPv6 +
FMIPv6 M X X X X X M X X M FMIPv6 M X X X X X M X X M
Micro. M M M M P M M M P X Micro. M M M M P M M M P X
IGP X M M M X M M M M M
 End of changes. 142 change blocks. 
862 lines changed or deleted 932 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/