< draft-ietf-netlmm-nohost-req-04.txt   draft-ietf-netlmm-nohost-req-05.txt >
Internet Draft J. Kempf, Editor Internet Draft J. Kempf, Editor
Document: draft-ietf-netlmm-nohost-req-04.txt August, 2006 Document: draft-ietf-netlmm-nohost-req-05.txt October, 2006
Expires: April, 2007
Expires: Feburary, 2007
Goals for Network-based Localized Mobility Management (NETLMM) Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-04.txt) (draft-ietf-netlmm-nohost-req-05.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 applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 44
Contributors Contributors
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
Marco Liebsch all contributed major effort to this document. Their Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC names are not included in the authors' section due to the RFC
Editor's limit of 5 names. Editor's limit of 5 names.
Abstract Abstract
In this document, design goals for a network-based localized In this document, design goals for a network-based localized
mobility management protocol are discussed. mobility management (NETLMM) 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 NETLMM Functional Architecture..........................3
3.0 IANA Considerations....................................10 3.0 Goals for the NETLMM Protocol...........................3
4.0 Security Considerations................................10 4.0 IANA Considerations....................................10
5.0 Acknowledgements.......................................11 5.0 Security Considerations................................11
6.0 Author's Addresses.....................................11 6.0 Acknowledgements.......................................11
7.0 Informative References.................................12 7.0 Author's Addresses.....................................11
8.0 Appendix: Gap Analysis.................................13 8.0 Normative References...................................12
9.0 IPR Statements.........................................23 9.0 Informative References.................................12
10.0 Disclaimer of Validity.................................23 10.0 IPR Statements.........................................13
11.0 Copyright Notice.......................................23 11.0 Disclaimer of Validity.................................13
12.0 Copyright Notice.......................................13
1.0 Introduction 1.0 Introduction
In [9], the basic problems that occur when a global mobility In [1], the basic problems that occur when a global mobility
protocol is used for managing local mobility are described, and two protocol is used for managing local mobility are described, and two
basic approaches to localized mobility management - the host-based currently used approaches to localized mobility management - the
approach that is used by most IETF protocols, and the proprietary host-based approach that is used by most IETF protocols, and the
WLAN switch approach used between WLAN switches in different proprietary WLAN switch approach used between WLAN switches in
subnets - are examined. The conclusion from the problem statement different subnets - are examined. The conclusion from the problem
document is that none of the approaches has a complete solution to statement document is that none of the approaches has a complete
the problem. While the WLAN switch approach is most convenient for solution to the problem. While the WLAN switch approach is most
network operators and users because it requires no software on the convenient for network operators and users because it requires no
mobile node other than the standard drivers for WiFi, the software on the mobile node other than the standard drivers for
proprietary nature limits interoperability and the restriction to a WiFi, the proprietary nature limits interoperability and the
single wireless link type and wired backhaul link type restricts restriction to a single last hop link type and wired backhaul link
scalability. The IETF host-based protocols require host software type restricts scalability. The IETF host-based protocols require
stack changes that may not be compatible with all global mobility host software stack changes that may not be compatible with all
protocols, and also require specialized and complex security global mobility protocols, and also require specialized and complex
transactions with the network that may limit deployability. The use security transactions with the network that may limit
of an IGP to distribute host routes has scalability and deployment deployability. The conclusion was that a localized mobility
limitations. management protocol that was network based and required no software
on the host for localized mobility management is desirable.
This document develops more detailed goals for a network-based This document develops a brief functional architecture and detailed
localized mobility management protocol. In Section 2.0, we review a goals for a network-based localized mobility management protocol
list of goals that are desirable in a network-based localized (NETLMM). Section 2.0 describes the functional architecture of
mobility management solution. Section 3.0 briefly outlines security NETLMM. In Section 3.0, a list of goals that are desirable in the
NETLMM protocol is presented. Section 4.0 concerns IANA
considerations. Section 5.0 briefly outlines security
considerations. More discussion of security can be found in the considerations. More discussion of security can be found in the
threat analysis document [20]. The architecture of the NETLMM threat analysis document [2].
protocol for which the goals in this document have been formulated
is described in Section 5 of [9].
1.1 Terminology 1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753 [13] Mobility terminology in this draft follows that in RFC 3753 [10]
and in [9]. and in [1]. In addition, the following terms are related to the
functional architecture described in Section 2.0:
2.0 Goals for Localized Mobility Management Localized Mobility Management Domain
Section 2 of [9] describes three problems with using a global An Access Network in the sense defined in [1] in which
mobility is handled by the NETLMM protocol.
Mobile Access Gateway
A Mobile Access Gateway (MAG) is a functional network
element that terminates a specific edge link and tracks
mobile node IP level mobility between edge links, through
NETLMM signaling with the Localized Mobility Anchor. The MAG
also terminates host routed data traffic from the Localized
Mobility Anchor for mobile nodes currently located within
the edge link under the MAG's control, and forwards data
traffic from mobile nodes on the edge link under its control
to the Localized Mobility Anchor.
Local Mobility Anchor
A Local Mobility Anchor (LMA) is a router that maintains a
collection of host routes and associated forwarding
information for mobile nodes within a localized mobility
management domain under its control. Together with the MAGs
associated with it, the LMA uses the NETLMM protocol to
manage IP node mobility within the localized mobility
management domain. Routing of mobile node data traffic is
anchored at the LMA as the mobile node moves around within
the localized mobility management domain.
2.0 NETLMM Functional Architecture
The NETLMM architecture consists of the following components.
Localized Mobility Anchors (LMAs) within the backbone network
maintain a collection of routes for individual mobile nodes within
the localized mobility management domain. The routes point to the
Mobile Access Gateways (MAGs) managing the links on which the
mobile nodes currently are located. Packets for a mobile node are
routed to and from the mobile node through tunnels between the LMA
and MAG. When a mobile node moves from one link to another, the MAG
sends a route update to the LMA. While some mobile node involvement
is necessary and expected for generic mobility functions such as
movement detection and to inform the MAG about mobile node
movement, no specific mobile node to network protocol will be
required for localized mobility management itself. Host stack
involvement in mobility management is thereby limited to generic
mobility functions at the IP layer, and no specialized localized
mobility management software is required.
3.0 Goals for the NETLMM Protocol
Section 2 of [1] describes three problems with using a global
mobility management protocol for localized mobility management. Any mobility management protocol for localized mobility management. Any
localized mobility management protocol must naturally address these localized mobility management protocol must naturally address these
three problems. In addition, the side effects of introducing such a three problems. In addition, the side effects of introducing such a
solution into the network need to be limited. In this section, we solution into the network need to be limited. In this section, we
address goals on a localized mobility solution including both address goals for NETLMM including both solving the basic problems
solving the basic problems (Goals 1, 2, 3) and limiting the side (Goals 1, 2, 3) and limiting the side effects (Goals 4+).
effects (Goals 4+).
Some basic goals of all IETF protocols are not discussed in detail Some basic goals of all IETF protocols are not discussed in detail
here, but any solution is expected to satisfy them. These goals are here, but any solution is expected to satisfy them. These goals are
fault tolerance, robustness, interoperability, scalability, and fault tolerance, robustness, interoperability, scalability, and
minimal specialized network equipment. A good discussion of their minimal specialized network equipment. A good discussion of their
applicability to IETF protocols can be found in [3]. applicability to IETF protocols can be found in [4].
Out of scope for the initial goals discussion are QoS, multicast, Out of scope for the initial goals discussion are QoS and dormant
and dormant mode/paging. While these are important functions for mode/paging. While these are important functions for mobile nodes,
mobile nodes, they are not part of the base localized mobility they are not part of the base localized mobility management
management problem. In addition, mobility between localized problem. In addition, mobility between localized mobility
mobility management domains is not covered here. It is assumed that management domains is not covered here. It is assumed that this is
this is covered by the global mobility management protocols. covered by the global mobility management protocols.
2.1 Handover Performance Improvement (Goal #1) 3.1 Handover Performance Improvement (Goal #1)
Handover packet loss occurs because there is usually latency Handover packet loss occurs because there is usually latency
between when the wireless link handover starts and when the IP between when the link handover starts and when the IP subnet
subnet configuration and global mobility management signaling configuration and global mobility management signaling completes.
completes. During this time the mobile node is unreachable at its During this time the mobile node is unreachable at its former
former topological location on the old link where correspondents topological location on the old link where correspondents are
are sending packets and to which they are being forwarded. Such sending packets. Such misrouted packets are dropped. This aspect of
misrouted packets are dropped. This aspect of handover performance handover performance optimization has been the subject of much
optimization has been the subject of an enormous amount of work, work, both in other SDOs and in the IETF, in order to reduce the
both in other SDOs, to reduce the latency of wireless link latency in IP handover. Many solutions to this problem have been
handover, in the IETF and elsewhere, to reduce the latency in IP proposed at the link layer and at the IP layer. One aspect of this
handover. Many solutions to this problem have been proposed at the goal for localized mobility management is that the processing delay
wireless link layer and at the IP layer. One aspect of this goal for changing the forwarding after handover must approach as closely
for localized mobility management is that the processing delay for as possible the sum of the delay associated with link layer
changing the forwarding after handover must approach as closely as handover and the delay required for active IP layer movement
possible the sum of the delay associated with link layer handover detection, in order to avoid excessive packet loss. Ideally, if
and the delay required for active IP layer movement detection, in network-side link layer support is available for handling movement
order to avoid excessive packet loss. Ideally, if network-side link detection prior to link handover or as part of the link handover
layer support is available for handling movement detection prior to process, the routing update should complete within the time
link handover or as part of the link handover process, the routing required for link handover. This delay is difficult to quantify,
update should complete within the time required for wireless link but for voice traffic, the entire handover delay including Layer 2
handover. This delay is difficult to quantify, but for voice handover time and IP handover time should be between 40-70 ms to
traffic, the entire handover delay including Layer 2 handover time avoid any degradation in call quality. Of course, if the link layer
and IP handover time should be between 40-70 ms to avoid any handover latency is too high, sufficient IP layer handover
degradation in call quality. performance for good real time service cannot be matched.
A goal of the protocol is to reduce the loss of accurate forwarding A goal of the NETLMM protocol - in networks where the link layer
to reduce interruptions which may cause user-perceptible service handover latency allows it - is to reduce the amount of latency in
degradation for real time traffic such as voice. IP handover, so that the combined IP and link layer handover
latency is less than 70 ms.
2.2 Reduction in Handover-related Signaling Volume (Goal #2) 3.2 Reduction in Handover-related Signaling Volume (Goal #2)
Considering Mobile IPv6 as the global mobility protocol (other Considering Mobile IPv6 [9] as the global mobility protocol (other
mobility protocols require about the same or somewhat less), if a mobility protocols require about the same or somewhat less), if a
mobile node using address autoconfiguration is required to mobile node using address autoconfiguration is required to
reconfigure on every move between links, the following signaling reconfigure on every move between links, the following signaling
must be performed: must be performed:
1) Link layer signaling required for handover and reauthentication. 1) Link layer signaling required for handover and reauthentication.
For example, in 802.11 [6] this is the Reassociate message For example, in 802.11 [7] this is the Reassociate message
together with 802.1x [7] reauthentication using EAP. together with 802.1x [8] reauthentication using EAP.
2) Active IP level movement detection, including router 2) Active IP level movement detection, including router
reachability. The DNA protocol [4] uses Router reachability. The DNA protocol [5] uses Router
Solicitation/Router Advertisement for this purpose. In addition, Solicitation/Router Advertisement for this purpose. In addition,
if SEND [1] is used and the mobile node does not have a if SEND [3] is used and the mobile node does not have a
certificate cached for the router, the mobile node must use certificate cached for the router, the mobile node must use
Certification Path Solicitation/Certification Path Advertisement Certification Path Solicitation/Certification Path Advertisement
to obtain a certification path. to obtain a certification path.
3) Two Multicast Listener Discovery (MLD) [19] REPORT messages, one 3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one
for each of the solicited node multicast addresses corresponding for each of the solicited node multicast addresses corresponding
to the link local address and the global address, to the link local address and the global address,
4) Two Neighbor Solicitation (NS) messages for duplicate address 4) Two Neighbor Solicitation (NS) messages for duplicate address
detection, one for the link local address and one for the global detection, one for the link local address and one for the global
address. If the addresses are unique, no response will be address. If the addresses are unique, no response will be
forthcoming. forthcoming.
5) Two NS messages from the router for address resolution of the 5) Two NS messages from the router for address resolution of the
link local and global addresses, and two Neighbor Advertisement link local and global addresses, and two Neighbor Advertisement
messages in response from the mobile node, messages in response from the mobile node,
6) Binding Update/Binding Acknowledgement between the mobile node 6) Binding Update/Binding Acknowledgement between the mobile node
and home agent to update the care of address binding, and home agent to update the care of address binding,
7) Return routability signaling between the correspondent node and 7) Return routability signaling between the correspondent node and
mobile node to establish the binding key, consisting of one Home mobile node to establish the binding key, consisting of one Home
Test Init/Home Test and Care of Test Init/Care of Test, Test Init/Home Test and Care of Test Init/Care of Test,
8) Binding Update/Binding Acknowledgement between the correspondent 8) Binding Update/Binding Acknowledgement between the correspondent
node and mobile node for route optimization. node and mobile node for route optimization.
Note that Steps 1-2 may be necessary, even for intra-link mobility, Note that Steps 1-2 may be necessary even for intra-link mobility,
if the wireless link protocol doesn't provide much help for IP if the last hop link protocol doesn't provide much help for IP
handover. Step 3-5 will be different if stateful address handover. Step 3-5 will be different if stateful address
configuration is used, since additional messages are required to configuration is used, since additional messages are required to
obtain the address. Steps 6-8 are only necessary when Mobile IPv6 obtain the address. Steps 6-8 are only necessary when Mobile IPv6
is used. The result is approximately 18 messages at the IP level, is used. The result is approximately 18 messages at the IP level,
where the exact number depends on various specific factors such as where the exact number depends on various specific factors such as
whether the mobile node has a router certificate cached or not, whether the mobile node has a router certificate cached or not,
before a mobile node can be ensured that it is established on a before a mobile node can be ensured that it is established on a
link and has full IP connectivity. link and has full IP connectivity. In addition to handover related
signaling, if the mobile node performs Mobile IPv6 route
optimization, it may be required to renew its return routability
key periodically (on the order of every 7 minutes) even if it is
not moving, resulting in additional signaling.
The goal is that handover signaling volume from the mobile node to The signaling required has a large impact on the performance of
the network should be no more than what is needed for the mobile handover, impacting Goal #1. Perhaps more importantly, the
node to perform secure IP level movement detection, in cases where aggregate impact from many mobile nodes of such signaling on
no link layer support exists. If link layer support exists for IP expensive shared links (such as wireless where the capacity of the
level movement detection, the mobile node may not need to perform link cannot easily be expanded) can result in reduced last hop link
any additional IP level signaling after handover. capacity for data traffic. Additoinally, in links where the end
user is charged for IP traffic, IP signaling is not without cost.
2.3 Location privacy (Goal #3) To address the issue of signaling impact described above, the goal
Although location privacy issues for Mobile IPv6 have been is that handover signaling volume from the mobile node to the
discussed in [12], the location privacy referred to here focuses on network should be no more than what is needed for the mobile node
the IP layer. In most wireless IP network deployments, different IP to perform secure IP level movement detection, in cases where no
subnets are used to cover different geographical areas. It is link layer support exists. Furthermore, NETLMM should not introduce
therefore possible to derive a topological to geographical map, in any additional signaling during handover beyond what is required
which particular IPv6 subnet prefixes are mapped to particular for IP level movement detection. If link layer support exists for
geographical locations. The precision of the map depends on the IP level movement detection, the mobile node may not need to
size of the geographic area covered by a particular subnet: if the perform any additional IP level signaling after link layer
area is large, then knowing the subnet prefix won't provide much handover.
information about the precise geographical location of a mobile
node within the subnet.
When a mobile node moves geographically, it also moves 3.3 Location Privacy (Goal #3)
topologically between subnets. In order to maintain routability,
the mobile node must change its local IP address when it moves
between subnets. If the mobile node sources packets with its local
IP address in the clear, for example through route optimization in
Mobile IPv6, the correspondent node or an eavesdropper can use the
topological to geographical map to deduce in real time where a
mobile node - and therefore its user - is located. Depending on how
precisely the geographical location can be deduced, this
information could be used to compromise the privacy or even cause
harm to the user. The geographical location information should not
be revealed to nor be deducible by the correspondent node or an
eavesdropper without the authorization of the mobile node's owner.
The threats to location privacy come in a variety of forms. One is In any IP network, there is a threat that an attacker can determine
a man in the middle attack in which traffic between a correspondent the physical location of a network node from the node's topological
and the mobile node is intercepted and the mobile node's location location. Depending on how an operator deploys their network, an
is deduced from that. Others are attacks in which the correspondent operator may choose to assign subnet coverage in a way that is
itself is the attacker, and the correspondent deliberately starts a tightly bound to geography at some timescale or it may choose to
session with the mobile node in order to track its location by assign it in ways in which the threat of someone finding a node
noting the source address of packets originating from the mobile physically based on its IP address is smaller. Allowing
node. Note that the location privacy referred to here is different the L2 attachment and L3 address to be less tightly bound is one
from the location privacy discussed in [12]. The location privacy tool for reducing this threat to location privacy.
discussed in these drafts primarily concerns modifications to the
Mobile IPv6 protocol to eliminate places where an eavesdropper Mobility introduces an additional threat. An attacker can track a
could track the mobile node's movement by correlating home address mobile node's geographical location in real time, if the victim
and care of address. mobile node must change its IP address as it moves from one subnet
to another through the covered geographical area. If the
granularity of the mapping between the IP subnets and geographical
area is small for the particular link type in use, the attacker can
potentially assemble enough information to find the victim in real
time.
In order to reduce the risk from location privacy compromises as a In order to reduce the risk from location privacy compromises as a
result of IP address changes, the goal for NETLMM is to remove the result of IP address changes, the goal for NETLMM is to remove the
need to change IP address as mobile node moves across links. need to change IP address as a mobile node moves across links in an
Keeping the IP address fixed removes any possibility for the access network. Keeping the IP address fixed over a large
correspondent node to deduce the precise geographic location of the geographical region fuzzes out the resolution of the mapping
mobile node without the user's authorization. Note that keeping the between the IP subnets and geographical area, regardless of how
address constant doesn't completely remove the possibility of small the natural deployment granularity may be. This reduces the
deducing the geographical location, since a local address still is chance that the attacker can deduce the precise geographic location
required. However, it does allow the network to be deployed such of the mobile node.
that the mapping between the geographic and topological location is
considerably less precise. If the mapping is not precise, an
attacker can only deduce in real time that the mobile node is
somewhere in a large geographic area, like, for example, a
metropolitan region or even a small country, reducing reducing the
granularity of the location information.
2.4 Efficient Use of Wireless Resources (Goal #4)
Advances in wireless physical layer and medium access control layer
technology continue to increase the bandwidth available from
limited wireless spectrum, but even with technology increases,
wireless spectrum remains a limited resource. Unlike wired network
links, wireless links are constrained in the number of bits/Hertz
by their coding technology and use of physical spectrum, which is
fixed by the physical layer. It is not possible to lay an extra
cable if the link becomes increasingly congested as is the case
with wired links.
While header compression technology can remove header overhead, it
does not come without cost. Requiring header compression on the
wireless access points increases the cost and complexity of the
access points, and increases the amount of processing required for
traffic across the wireless link. Header compression also requires
special software on the host, which may or may not be present.
Since the access points tend to be a critical bottleneck in
wireless access networks for real time traffic (especially on the
downlink), reducing the amount of per-packet processing is
important. While header compression probably cannot be completely
eliminated, especially for real time media traffic, simplifying
compression to reduce processing cost is an important goal.
The goal is that the localized mobility management protocol should
not introduce any new signaling or increase existing signaling over
the air.
2.5 Limit the Signaling Overhead in the Network (Goal #5)
While bandwidth and router processing resources are typically not 3.4 Limit Overhead in the Network (Goal #4)
as constrained in the wired network, access networks tend to have
somewhat stronger bandwidth and router processing constraints than
the backbone. These constraints are a function of the cost of
laying fiber or wiring to the wireless access points in a widely
dispersed geographic area. Therefore, any solutions for localized
mobility management should minimize signaling within the wired
network as well.
2.6 No Extra Security Between Mobile Node and Network (Goal #6) Access networks, including both the wired and wireless parts, tend
to have somewhat stronger bandwidth and router processing
constraints than the backbone. In the wired part of the network,
these constraints are a function of the cost of laying fiber or
wiring to the wireless access points in a widely dispersed
geographic area. In the wireless part of the network, these
constraints are due to the limitation on the number of bits per
Hertz imposed by the physical layer protocol. Therefore, any
solutions for localized mobility management should minimize
overhead within the access network.
Localized mobility management protocols that have signaling between 3.5 Simplify Mobile Node Mobility Management Security by Deriving from
the mobile node and network require a security association between IP Network Access and/or IP Movement Detection Security (Goal #5)
the mobile node and the network entity that is the target of the
signaling. Establishing a security association specifically for
localized mobility service in a roaming situation may prove
difficult, because provisioning a mobile node with security
credentials for authenticating and authorizing localized mobility
service in each roaming partner's network may be unrealistic from a
deployment perspective. Reducing the complexity of mobile node to
network security for localized mobility management can therefore
reduce barriers to deployment.
If the access router deduces mobile node movement based on active Localized mobility management protocols that have host involvement
IP-level movement detection by the mobile node, then authentication may require an additional security association between the mobile
is required for the IP-level movement detection messages from the node and the mobility anchor, and establishing this security
mobile node to ensure that the mobile node is authorized to possess association may require additional signaling between the mobile
the address used for the movement detection. The authorization may node and the mobility anchor (see [13] for an example). The
be at the IP level or it may be tied to the original network access additional security association requires extra signaling and
authentication and wireless link layer authorization for handover. therefore extra time to negotiate. Reducing the complexity of
Some wireless link layers, especially cellular protocols, feature mobile node to network security for localized mobility management
full support and strong security for handover at the link level, can therefore reduce barriers to deployment and improve
and require no IP support for handover. If such wireless link responsiveness. Naturally, such simplification must not come at the
security is not available, however, then it must be provided at the expense of maintaining strong security guarantees for both the
IP level. Security threats to the NETLMM protocol are discussed in network and mobile node.
[20].
In summary, ruling out mobile node involvement in local mobility In NETLMM, the network (specifically the MAG) derives the
management simplifies security by removing the need for service- occurrence of a mobility event requiring a routing update for a
specific credentials to authenticate and authorize the mobile node mobile node from link layer handover signaling or IP layer movement
for localized mobility management in the network. This puts detection signaling from the mobile node. This information is used
localized mobility management on the same level as basic IP to update routing for the mobile node at the LMA. The handover or
routing. Hosts obtain this service as part of their network access. movement detection signaling must provide the network with proper
authentication and authorization so that the network can
definitively identify the mobile node and determine its
authorization. The authorization may be at the IP level, for
example, using something like SEND [3] to secure IP movement
detection signaling, or it may be at the link level. Proper
authentication and authorization must be implemeted on link layer
handover signaling and/or IP level movement detection signaling in
order for the MAG to securely deduce mobile node movement events.
Security threats to the NETLMM protocol are discussed in [2].
The goal is that support for localized mobility management should The goal is that security for NETLMM mobile node mobility
not require security between the mobile node and the network other management should derive from IP network access and/or IP movement
than that required for network access or local link security (such detection security, such as SEND or network access authentication,
as SEND [1]). and not require any additional security associations or additional
signaling between the mobile node and the network.
2.7 Wireless Link Technology Agnostic (Goal #7) 3.6 Link Technology Agnostic (Goal #6)
The number of wireless link technologies available is growing, and The number of wireless link technologies available is growing, and
the growth seems unlikely to slow down. Since the standardization the growth seems unlikely to slow down. Since the standardization
of a wireless link physical and medium access control layers is a of a wireless link physical and medium access control layers is a
time consuming process, reducing the amount of work necessary to time consuming process, reducing the amount of work necessary to
interface a particular wireless link technology to an IP network is interface a particular wireless link technology to an IP network is
necessary. A localized mobility management solution should ideally necessary. When the last hop link is a wireless link, a localized
require minimal work to interface with a new wireless link mobility management solution should ideally require minimal work to
technology. interface with a new wireless link technology.
In addition, an edge mobility solution should provide support for In addition, an edge mobility solution should provide support for
multiple wireless link technologies. It is not required that the multiple wireless link technologies. It is not required that the
localized mobility management solution support handover from one localized mobility management solution support handover from one
wireless link technology to another without change in IP address, wireless link technology to another without change in IP address,
but this possibility should not be precluded. but this possibility should not be precluded.
The goal is that the localized mobility management protocol should The goal is that the localized mobility management protocol should
not use any wireless link specific information for basic routing not use any wireless link specific information for basic routing
management, though it may be used for other purposes, such as management, though it may be used for other purposes, such as
identifying a mobile node. securely identifying a mobile node.
2.8 Support for Unmodified Mobile Nodes (Goal #8) 3.7 Support for Unmodified Mobile Nodes (Goal #7)
In the wireless LAN switching market, no modification of the In the wireless LAN switching market, no modification of the
software on the mobile node is required to achieve localized software on the mobile node is required to achieve localized
mobility management. Being able to accommodate unmodified mobile mobility management. Being able to accommodate unmodified mobile
nodes enables a service provider to offer service to as many nodes enables a service provider to offer service to as many
customers as possible, the only constraint being that the customer customers as possible, the only constraint being that the customer
is authorized for network access. is authorized for network access.
Another advantage of minimizing mobile node software for localized Another advantage of minimizing mobile node software for localized
mobility management is that multiple global mobility management mobility management is that multiple global mobility management
protocols can be supported. There are a variety of global mobility protocols can be supported. There are a variety of global mobility
management protocols that might also need support, including management protocols that might also need support, including
proprietary or wireless link technology-specific protocols needing proprietary or link technology-specific protocols needing support
support for backward compatibility reasons. Within the Internet, for backward compatibility reasons. Within the Internet, both HIP
both HIP [14] and Mobike [5] are likely to need support in addition [11] and Mobike [6] are likely to need support in addition to
to Mobile IPv6, and Mobile IPv4 support may also be necessary. Mobile IPv6 [9], and Mobile IPv4 [12] support may also be
necessary.
Note that this goal does NOT mean that the mobile node has no Note that this goal does NOT mean that the mobile node has no
software at all associated with mobility or wireless. The mobile software at all associated with mobility. The mobile node must have
node must have some kind of global mobility protocol if it is to some kind of global mobility protocol if it is to move from one
move from one domain of edge mobility support to another and domain of edge mobility support to another and maintain session
maintain session continuity, although no global mobility protocol continuity, although no global mobility protocol is required if the
is required if the mobile node only moves within the coverage area mobile node only moves within the coverage area of the localized
of the localized mobility management protocol or no session mobility management protocol or no session continuity is required
continuity is required during global movement. Also, every wireless during global movement. Also, if the last hop link is a wireless
link protocol requires handover support on the mobile node in the link, every wireless link protocol requires handover support on the
physical and medium access control layers, typically in the mobile node in the physical and medium access control layers,
wireless interface driver. Information passed from the medium typically in the wireless interface driver. Information passed from
access control layer to the IP layer on the mobile node may be the medium access control layer to the IP layer on the mobile node
necessary to trigger IP signaling for IP handover. Such movement may be necessary to trigger IP signaling for IP handover. Such
detection support at the IP level may be required in order to movement detection support at the IP level may be required in order
determine whether the mobile node's default router is still to determine whether the mobile node's default router is still
reachable after the move to a new access point has occurred at the reachable after the move to a new access point has occurred at the
medium access control layer. Whether or not such support is medium access control layer. Whether or not such support is
required depends on whether the medium access control layer can required depends on whether the medium access control layer can
completely hide link movement from the IP layer. For a wireless completely hide link movement from the IP layer. For cellular type
link protocol such as the 3G protocols, the mobile node and network wireless link protocols, the mobile node and network undergo an
undergo an extensive negotiation at the medium access control layer extensive negotiation at the medium access control layer prior to
prior to handover, so it may be possible to trigger routing update handover, so it may be possible to trigger routing update without
without any IP protocol involvement. However, for a wireless link any IP protocol involvement. However, for a wireless link protocol
protocol such as IEEE 802.11 in which the decision for handover is such as IEEE 802.11 [7] in which the decision for handover is
entirely in the hands of the mobile node, IP layer movement entirely in the hands of the mobile node, IP layer movement
detection signaling from the mobile node may be required to trigger detection signaling from the mobile node may be required to trigger
a routing update. a routing update.
The goal is that the localized mobility management solution should The goal is that the localized mobility management solution should
be able to support any mobile node that joins the link and that has be able to support any mobile node that joins the link and that has
a wireless interface that can communicate with the network, without a interface that can communicate with the network, without
requiring localized mobility management software on the mobile requiring localized mobility management software on the mobile
node. node.
2.9 Support for IPv4 and IPv6 (Goal #9) 3.8 Support for IPv4 and IPv6 (Goal #8)
While most of this document is written with IPv6 in mind, localized While most of this document is written with IPv6 in mind, localized
mobility management is a problem in IPv4 networks as well. A mobility management is a problem in IPv4 networks as well. A
solution for localized mobility that works for both versions of IP solution for localized mobility that works for both versions of IP
is desirable, though the actual protocol may be slightly different is desirable, though the actual protocol may be slightly different
due to the technical details of how each IP version works. From due to the technical details of how each IP version works. From
Goal #8 (Section 2.8), minimizing mobile node support for localized Goal #7 (Section 3.7), minimizing mobile node support for localized
mobility means that ideally no IP version-specific changes would be mobility means that ideally no IP version-specific changes should
required on the mobile node for localized mobility, and that global be required on the mobile node for localized mobility, and that
mobility protocols for both IPv4 and IPv6 should be supported. Any global mobility protocols for both IPv4 and IPv6 should be
IP version-specific features would be confined to the network supported. Any IP version-specific features should be confined to
protocol. the network protocol.
2.10 Re-use of Existing Protocols Where Sensible (Goal #10) 3.9 Re-use of Existing Protocols Where Sensible (Goal #9)
Many existing protocols are available as Internet Standards upon Many existing protocols are available as Internet Standards upon
which the NETLMM protocol can be built. The design of the protocol which the NETLMM protocol can be built. The design of the protocol
should have a goal to re-use existing protocols where it makes should have a goal to re-use existing protocols where it makes
architectural and engineering sense to do so. The design should architectural and engineering sense to do so. The design should
not, however, attempt to re-use existing protocols where there is not, however, attempt to re-use existing protocols where there is
no real architectural or engineering reason. For example, the suite no real architectural or engineering reason. For example, the suite
of Internet Standards contains several good candidate protocols for of Internet Standards contains several good candidate protocols for
the transport layer, so there is no real need to develop a new the transport layer, so there is no real need to develop a new
transport protocol specifically for NETLMM. Re-use is clearly a transport protocol specifically for NETLMM. Re-use is clearly a
skipping to change at page 9, line 44 skipping to change at page 10, line 5
compatibility with existing protocol stacks is important. On the compatibility with existing protocol stacks is important. On the
other hand, the network-based, localized mobility management other hand, the network-based, localized mobility management
functionality being introduced by NETLMM is a new piece of functionality being introduced by NETLMM is a new piece of
functionality, and therefore any decision about whether to re-use functionality, and therefore any decision about whether to re-use
an existing global mobility management protocol should carefully an existing global mobility management protocol should carefully
consider whether re-using such a protocol really meets the needs of consider whether re-using such a protocol really meets the needs of
the functional architecture for network-based localized mobility the functional architecture for network-based localized mobility
management. The case for re-use is not so clear in this case, since management. The case for re-use is not so clear in this case, since
there is no compelling backward compatibility argument. there is no compelling backward compatibility argument.
2.11 Localized Mobility Management Independent of Global Mobility 3.10 Localized Mobility Management Independent of Global Mobility
Management Management (Goal #10)
Localized mobility management should be implementable and Localized mobility management should be implementable and
deployable independently of any global mobility management deployable independently of any global mobility management
protocol. This enables the choice of local and global mobility protocol. This enables the choice of local and global mobility
management to be made independently of particular protocols that management to be made independently of particular protocols that
are implemented and deployed to solve the two different sorts of are implemented and deployed to solve the two different sorts of
mobility management problems. The operator can choose a particular mobility management problems. The operator can choose a particular
localized mobility management protocol according to the specific localized mobility management protocol according to the specific
features of their access network. It can subsequently upgrade the features of their access network. It can subsequently upgrade the
localized mobility management protocol on its own, without even localized mobility management protocol on its own, without even
informing the mobile nodes. Similarly, the mobile nodes can use a informing the mobile nodes. Similarly, the mobile nodes can use a
global mobility management protocol that best suits their global mobility management protocol that best suits their
requirements, or even not use one at all. Also, a mobile node can 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 move into a new access network without having to check that it
understands the localized mobility management protocol being used understands the localized mobility management protocol being used
there. there.
The goal is that the implementation and deployment of the localized The goal is that the implementation and deployment of the localized
mobility management protocol should not restrict, or be restricted mobility management protocol should not restrict, or be restricted
by, the choice of global mobility management protocol. by, the choice of global mobility management protocol.
2.12 Configurable Data Plane Forwarding between Mobility Anchor and 3.11 Configurable Data Plane Forwarding between Local Mobility Anchor
Access Router and Mobile Access Gateway (Goal #11)
Different network operators may require different types of Different network operators may require different types of
forwarding options between the mobility anchor and the access forwarding options between the LMA and the MAGs for mobile node
routers for mobile node data plane traffic. An obvious forwarding data plane traffic. An obvious forwarding option that has been used
option that has been used in past IETF localized mobility in past IETF localized mobility management protocols is IP-IP
management protocols is IP-IP encapsulation for bidirectional encapsulation for bidirectional tunneling. The tunnel endpoints are
tunneling. The tunnel endpoints could be the mobility anchor and the LMA and the MAGs. But other options are possible. Some network
the access routers. But other options are possible. Some network
deployments may prefer routing-based solutions. Others may require deployments may prefer routing-based solutions. Others may require
security tunnels using IPsec ESP encapsulation if part of the security tunnels using IPsec ESP encapsulation if part of the
localized mobility management domain runs over a public access localized mobility management domain runs over a public access
network and the network operator wants to protect the traffic. network and the network operator wants to protect the traffic.
A goal of the NETLMM protocol is to allow the forwarding between A goal of the NETLMM protocol is to allow the forwarding between
the mobility anchor and access routers to be configurable depending the LMA and MAGs to be configurable depending on the particulars of
on the particulars of the network deployment. Configurability is the network deployment. Configurability is not expected to be
not expected to be dynamic as in controlled by the arrival of a dynamic as in controlled by the arrival of a mobile node; but
mobile node; but rather, configuration is expected to be similar in rather, configuration is expected to be similar in time scale to
time scale to configuration for routing. The NETLMM protocol may configuration for routing. The NETLMM protocol may designate a
designate a default forwarding mechanism. It is also possible that default forwarding mechanism. It is also possible that additional
additional work may be required to specify the interaction between work may be required to specify the interaction between a
a particular forwarding mechanism and the NETLMM protocol, but this particular forwarding mechanism and the NETLMM protocol, but this
work is not in scope of the NETLMM base protocol. work is not in scope of the NETLMM base protocol.
3.0 IANA Considerations 4.0 IANA Considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
4.0 Security Considerations 5.0 Security Considerations
There are two kinds of security issues involved in network-based There are two kinds of security issues involved in network-based
localized mobility management: security between the mobile node and localized mobility management: security between the mobile node and
the network, and security between network elements that participate the network, and security between network elements that participate
in the network-based localized mobility management protocol in the NETLMM protocol. The security-related goals in this
document, described in Section 3.3 and 3.5, focus on the former,
Security between the mobile node and the network itself consists of because those are unique to network-based mobility management. The
two parts: threats involved in localized mobility management in threat analysis document [2] contains a more detailed discussion of
general, and threats to the network-based localized mobility both kinds of threats, which the protocol design must address.
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 [20].
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 mutual 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 Acknowledgements 6.0 Acknowledgements
The authors would like to acknowledge the following for The authors would like to acknowledge the following for
particularly diligent reviewing: Vijay Devarapalli, Peter McCann, particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin. Templin.
6.0 Author's Addresses 7.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 12, line 4 skipping to change at page 11, line 53
USA USA
Email: phil.roberts@motorola.com Email: phil.roberts@motorola.com
Katsutoshi Nishida Katsutoshi Nishida
NTT DoCoMo Inc. NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi 3-5 Hikarino-oka, Yokosuka-shi
Kanagawa, Kanagawa,
Japan Japan
Phone: +81 46 840 3545 Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp Email: nishidak@nttdocomo.co.jp
Gerardo Giaretta Gerardo Giaretta
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
10148 Torino 10148 Torino
Italy Italy
Phone: +39 011 2286904 Phone: +39 011 2286904
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
7.0 Informative References 8.0 Normative References
[1] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure [1] Kempf, J., editor, "Problem Statement for IP Local Mobility,"
Internet Draft, Work in Progress.
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based
Localized Mobility Management", Internet Draft, Work in
Progress.
9.0 Informative References
[3] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March, 2005. Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[2] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., [4] Carpenter, B., "Architectural Principles of the Internet,"
"Design, Implementation and Evaluation of Cellular IP", IEEE
Personal Communications, June/July 2000.
[3] Carpenter, B., "Architectural Principles of the Internet,"
RFC 1958, June, 1996. RFC 1958, June, 1996.
[4] Choi, J, and Daley, G., "Goals of Detecting Network [5] Choi, J, and Daley, G., "Goals of Detecting Network
Attachment in IPv6", Internet Draft, Work in Progress. Attachment in IPv6", Internet Draft, Work in Progress.
[5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol [6] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical [7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999. Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard [8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
802.1x, June, 2001. 802.1x, June, 2001.
[8] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in [9] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6", RFC 3775. IPv6", RFC 3775, June, 2004.
[9] Kempf, J., editor, "Problem Statement for IP Local Mobility," [10] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
Internet Draft, Work in Progress.
[10] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6
Handover Key using SEND", Internet Draft, Work in Progress.
[11] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
4068, July, 2005.
[12] Koodli, R., " IP Address Location Privacy and Mobile IPv6:
Problem Statement", Internet Draft, Work in Progress.
[13] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004. 3753, June, 2004.
[14] Moskowitz, R., and Nikander, P., "Host Identity Protocol [11] Moskowitz, R., and Nikander, P., "Host Identity Protocol
(HIP) Architecture", RFC 4423, May, 2006. (HIP) Architecture", RFC 4423, May, 2006.
[15] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta, [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
G., and Bournelle, J., "Handover Keys Using AAA", Internet August, 2002.
Draft, Work in Progress. [13] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
[16] 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.
[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] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August, 2005. 4140, August, 2005.
[19] Vida, R., and Costa, L., " Multicast Listener Discovery [14] Vida, R., and Costa, L., " Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[20] Vogt, C., and Kempf, J., "Security Threats to Network-based
Localized Mobillity Management", Internet Draft, Work in
Progress.
8.0 Appendix: Gap Analysis
This section discusses a gap analysis between existing proposals
for solving localized mobility management and the goals in Section.
2.0.
8.1 Mobile IPv6 with Local Home Agent
One option is to deploy Mobile IPv6 with a locally assigned home
agent in the local network. This solution requires the mobile node
to somehow be assigned a home agent in the local network when it
boots up. This home agent is used instead of the home agent in the
home network. The advantage of this option is that no special
solution is required for edge mobility - the mobile node reuses the
global mobility management protocol for that purpose - if the
mobile node is using Mobile IPv6.
The analysis of this approach against the goals above is the
following.
Goal #1 Handover Performance Improvement: If the mobile node does
not perform route optimization, this solution reduces, but does not
eliminate, IP handover related performance problems.
Goal #2 Reduction in Handover-related Signaling Volume: Similarly
to Goal #1, signaling volume is reduced if no route optimization
signaling is done on handover.
Goal #3 Location privacy: Location privacy is preserved for
external correspondents as long as all of the mobile node's traffic
is routed through the local HA.
Goal #4 Efficient Use of Wireless Resources: If traffic is not
route optimized, the mobile node still pays for an over-the-air
tunnel to the locally assigned home agent. The overhead here is
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 Limit the Signaling Overhead in the Network: If the
localized mobility management domain is large, the mobile node may
suffer from unoptimzed routes. RFC 3775 [8] provides no support for
notifying a mobile node that another localized home agent is
available for a more optimized route, or for handing over between
home agents. A mobile node would have to perform the full home
agent bootstrap procedure, including establishing a new IPsec SA
with the new home agent.
Goal #6 No Extra Security Between Mobile Node and Network: A local
home agent in a roaming situation requires the guest mobile node to
have the proper credentials to authenticate with the local home
agent in the serving network. The credentials used for network
access authentication could also be used for mobile service
authentication and authorization if the local home agent uses EAP
over IKEv2 to authenticate the mobile node with its home AAA
server. This may require additional authorization between the home
and visited networks to use the same credentials for a different
service, however. In addition, as in Goal #3, if binding updates
are done in cleartext over the access network or the mobile node
has become infected with malware, the local home agent's address
could be revealed to attackers and the local home agent could
become the target of a DoS attack. So a local home agent would
provide no benefit for this goal.
Goal #7 Support for Heterogeneous Wireless Link Technologies: This
solution supports multiple wireless technologies with separate IP
subnets for different links. No special work is required to
interface a local home agent to different wireless technologies.
Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
support Mobile IPv6 in order for this option to work. So mobile
node changes are required and other IP mobility protocols are not
supported.
Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is
working on modifying the protocol to allow registration of IPv4
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 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, Mobile IPv6.
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.
8.2 Hierarchical Mobile IPv6 (HMIPv6)
HMIPv6 [18] provides the most complete localized mobility
management solution available today. In HMIPv6, a localized
mobility anchor called a MAP serves as a routing anchor for a
regional care of address. When a mobile node moves from one access
router to another, the mobile node changes the binding between its
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 8.1; however, HMIPv6
also allows a mobile node to hand over between MAPs.
Handover between MAPs and MAP discovery requires configuration on
the routers. MAP addresses are advertised by access routers.
Handover happens by overlapping MAP coverage areas so that, for
some number of access routers, more than one MAP may be advertised.
Mobile nodes need to switch MAPs in the transition area, and then
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.
Goal #1 Handover Performance Improvement: This solution shortens,
but does not eliminate, the latency associated with IP handover,
since it reduces the amount of signaling and the length of the
signaling paths.
Goal #2 Reduction in Handover-related Signaling Volume: Signaling
volume is reduced simply because no route optimization signaling is
done on handover within the coverage area of the MAP.
Goal #3 Location privacy: Location privacy is preserved for
external correspondents.
Goal #4 Use of Wireless Resources: The mobile node always pays for
an over-the-air tunnel to the MAP. If the mobile node is tunneling
through a global home agent or VPN gateway, the wired link
experiences double tunneling. Over-the-air tunnel overhead can be
removed by header compression, however.
Goal #5 Limit the Signaling Overhead in the Network: From Goal #1
and Goal #4, the signaling overhead is no more or less than for
mobile nodes whose global mobility management anchor is local.
However, because MAP handover is possible, forwarding across large
localized mobility management domains can be improved thereby
improving wired network resource utilization by using multiple MAPs
and handing over, at the expense of the configuration and
management overhead involved in maintaining multiple MAP coverage
areas.
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
addition, since the mobile node is required to have a unicast
address for the MAP that is either globally routed or routing
restricted to the local administrative domain, the MAP is
potentially a target for DoS attacks across a wide swath of network
topology.
Goal #7 Support for Heterogeneous Wireless Link Technologies: This
solution supports multiple wireless technologies with separate IP
subnets for different links.
Goal #8 Support for Unmodified Mobile Nodes: This solution requires
modification to the mobile nodes. In addition, the HMIPv6 design
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 is an expired Internet draft with a design for a
regional registration protocol for Mobile IPv4 that has similar
functionality. It is possible that the same IPv4 transition
solution as used for Mobile IPv6 could be used [17] above.
Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, HMIPv6.
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.
8.3 Combinations of Mobile IPv6 with Optimizations
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.
8.3.1 MIPv6 with local home agent + FMIPv6
As discussed in Section 8.1, the use of MIPv6 with a dynamically
assigned, local home agent cannot fulfill the goals. A fundamental
limitation is that Mobile IPv6 cannot provide seamless handover
(i.e. Goal #1). FMIPv6 [11] above 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.
Goal #1 Handover Performance Improvement: FMIPv6 provides a
solution for handover performance improvement that should fulfill
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.
Goal #2 Reduction in Handover-related Signaling Volume: FMIPv6
requires the mobile node to perform extra signaling with the access
router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
in standard MIPv6, whenever the mobile node moves to another link,
it must send a Binding Update to the home agent. If route
optimization is used, the mobile node also performs return
routability and sends a Binding Update to each correspondent node.
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 Location privacy: The mobile node maintains a local care of
address. If route optimization is not used, location privacy can be
achieved using bi-directional tunneling.
Goal #4 Use of Wireless Resources: As stated for Goal #2, the
combination of MIPv6 and FMIPv6 generates extra signaling overhead.
For data packets, in addition to the Mobile IPv6 over-the-air
tunnel, there is a further level of tunneling between the mobile
node and the previous access router during handover. This tunnel is
needed to forward incoming packets to the mobile node addressed to
the previous care of address. Another reason is that, even if the
mobile node has a valid new care of address, the mobile node cannot
use the new care of address directly with its correspondents
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 Limit the Signaling Overhead in the Network: FMIPv6
generates extra signaling overhead between the previous access
router and the new access router for the HI/HAck exchange.
Concerning data packets, the use of FMIPv6 for handover performance
improvement implies a tunnel between the previous access router and
the mobile node that adds some overhead in the wired network. This
overhead has more impact on star topology deployments, since
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 Extra Security Between Mobile Node and Network: In addition
to the analysis for Mobile IPv6 with local home agent in Section
8.1, FMIPv6 requires the mobile node and the previous access router
to share a security association in order to secure FBU/FBA
exchange. Two solutions have been proposed: a SEND-based solution
[10] above and an AAA-based solution [15]. Both solutions require
additional support on the mobile node and in the network beyond
what is required for network access authentication.
Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6
and FMIPv6 support multiple wireless technologies, so this goal is
fulfilled.
Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
support both MIPv6 and FMIPv6, so it is not possible to satisfy
this goal.
Goal #9 Support for IPv4 and IPv6: Work is underway to extend MIPv6
with the capability to run over both IPv6-enabled and IPv4-only
networks [17] above. FMIPv6 only supports IPv6. Even though an IPv4
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.
Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses existing protocols, Mobile IPv6 and 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.
8.3.2 HMIPv6 + FMIPv6
HMIPv6 provides several advantages in terms of local mobility
management. However, as seen in Section 8.2, it does not fulfill
all the goals identified in Section 2.0. In particular, HMIPv6 does
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.
Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both
shorten the latency associated with IP handovers. In particular,
FMIPv6 is expected to fulfill the goals on jitter, delay and packet
loss raised by real-time applications.
Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6
and HMIPv6 require extra signaling compared with Mobile IPv6. As a
whole the mobile node performs signaling message exchanges at each
handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA.
However, as mentioned in Section 8.2, the use of HMIPv6 reduces the
signaling overhead since no route optimization signaling is done
for intra-MAP handovers. In addition, naive 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 Location privacy: HMIPv6 may preserve location privacy,
depending on the dimension of the geographic area covered by the
MAP.
Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the
combination of HMIPv6 and FMIPv6 generates a lot of signaling
overhead in the network. Concerning payload data, in addition to
the over-the-air MIPv6 tunnel, a further level of 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 Limit the Signaling Overhead in the Network: The signaling
overhead in the network is not reduced by HMIPv6, as mentioned in
Section 8.2. Instead, FMIPv6 generates extra signaling overhead
between the previous access router and new access router for
HI/HAck exchange. For payload data, the same considerations as for
Goal #4 are applicable.
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 #8 Support for Unmodified Mobile Nodes: The mobile node must
support both HMIPv6 and FMIPv6 protocols, so this goal is not
fulfilled.
Goal #9 Support for IPv4 and IPv6: Currently there is no IPv4
version of HMIPv6. There is an IPv4 version of FMIP but it is not
clear how it could be used together with FMIPv6 in order to handle
fast handovers across any wired network.
Goal #10 Re-use of Existing Protocols Where Sensible: This
solution re-uses existing protocols, HMIPv6 and FMIPv6.
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.
8.4 Micromobility Protocols
Researchers have defined some protocols that are often
characterized as micromobility protocols. Two typical protocols in
this category are Cellular-IP [2] and HAWAII [16]. Researchers
defined these protocols before local mobility optimizations for
Mobile IP such as FMIP and HMIP were developed, in order to reduce
handover latency. Cellular-IP and HAWAII were proposed in the IETF
for standardization, but after some study in the IRTF, were
dropped. There are many micromobility protocols defined in the
academic literature, but in this document, the term is used
specifically to refer to Cellular-IP and HAWAII.
The micromobility approach to localized mobility management
requires host route propagation from the mobile node to a
collection of specialized routers in the localized mobility
management domain along a path back to a boundary router at the
edge of the localized mobility management domain. A boundary router
is a kind of localized mobility management domain gateway.
Localized mobility management is authorized with the access router,
but reauthorization with each new access router is necessary on
link movement, in addition to any reauthorization for basic network
access. The host routes allow the mobile node to maintain the same
IP address when it moves to a new link, and still continue to
receive packets on the new link.
Cellular IP and HAWAII have a few things in common. Both are
compatible with Mobile IP and are intended to provide a higher
level of handover performance in local networks than was previously
available with Mobile IP without such extensions as HMIP and FMIP.
Both use host routes installed in a number of routers within a
restricted routing domain. Both define specific messaging to update
those routes along the forwarding path and specify how the
messaging is to be used to update the routing tables and forwarding
tables along the path between the mobile and a micromobility domain
boundary router at which point Mobile IP is to used to handle
global mobility in a scalable way. Unlike the FMIP and HMIP
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 is conceptually withain the micromobility 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 10.0 IPR Statements
deployment and scalability standpoint. Both protocols involve every
routing element between the mobile device and the micromobility
domain boundary router in all packet forwarding decisions specific
to care of addresses for mobile nodes. Scalability is limited
because each care of address corresponding to a mobile node
generates a routing table entry, and perhaps multiple forwarding
table entries, in every router along the path. Since mobile nodes
can have multiple global care of addresses in IPv6, this can result
in a large expansion in router state throughout the micromobility
routing domain. Although the extent of the scalability for
micromobility protocols is still not clearly understood from a
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 goals in Section 2.0:
Goal #1 Handover Performance Improvement: The micromobility
protocols reduce handover latency by quickly fixing up routes
between the boundary router and the access router. While some
additional latency may be expected during host route propagation,
it is typically much less than experienced with standard Mobile IP.
Goal #2 Reduction in Handover-related Signaling Volume: The
micromobility protocols require 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 link.
Goal #3 Location privacy: No care of address changes are exposed to
correspondent nodes or the mobile node itself while the mobile node
is moving in the micromobility-managed network.
Goal #4 Use of Wireless Resources: The only additional over-the-air
signaling is involved in propagating host routes from the mobile
node to the network upon movement. Since this signaling would be
required for movement detection in any case, it is expected to be
minimal. Mobile node traffic experiences no overhead.
Goal #5 Limit the Signaling Overhead in the Network: 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 Security Between Mobile Node and Network: 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 Support for Heterogeneous Wireless Link Technologies:
HMIPv6 The micromobility protocols support multiple wireless
technologies, so this goal is satisfied.
Goal #8 Support for Unmodified Mobile Nodes: 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 require mobile
node software changes, however.
Goal #9 Re-use of Existing Protocols Where Sensible: Support for
IPv4 and IPv6: 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.
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.
8.5 Summary
The following table summarizes the discussion in Section 9.1
through 9.5. In the table, a "M" indicates that the protocol
completely meets the goal, a "P" indicates that it partially meets
the goal, and an "X" indicates that it does not meet the goal.
Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
-------- -- -- -- -- -- -- -- -- -- ---
MIPv6 P X X X X X M X M M
HMIPv6 P X X X P X M X X M
MIPv6 +
FMIPv6 M X X X P X M X P M
HMIPv6 +
FMIPv6 M X X X X X M X X M
Micro. M M M M P M M M P X
9.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 Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 23, line 38 skipping to change at page 13, line 29
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. 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 copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
10.0 Disclaimer of Validity 11.0 Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
11.0 Copyright Notice 12.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
 End of changes. 74 change blocks. 
850 lines changed or deleted 327 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/