draft-ietf-netlmm-nohost-req-05.txt   rfc4831.txt 
Internet Draft J. Kempf, Editor Network Working Group J. Kempf, Ed.
Document: draft-ietf-netlmm-nohost-req-05.txt October, 2006 Request for Comments: 4831 DoCoMo USA Labs
Expires: April, 2007 Goals for Network-Based Localized Mobility Management (NETLMM)
Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-05.txt)
Status of this Memo
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 or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Contributors Copyright Notice
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and Copyright (C) The IETF Trust (2007).
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 In this document, design goals for a network-based localized mobility
mobility management (NETLMM) protocol are discussed. management (NETLMM) protocol are discussed.
Table of Contents Table of Contents
1.0 Introduction............................................2 1. Introduction ....................................................2
2.0 NETLMM Functional Architecture..........................3 1.1. Terminology ................................................2
3.0 Goals for the NETLMM Protocol...........................3 2. NETLMM Functional Architecture ..................................3
4.0 IANA Considerations....................................10 3. Goals for the NETLMM Protocol ...................................3
5.0 Security Considerations................................11 3.1. Goal 1: Handover Performance Improvement ...................4
6.0 Acknowledgements.......................................11 3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
7.0 Author's Addresses.....................................11 3.3. Goal 3: Location Privacy ...................................6
8.0 Normative References...................................12 3.4. Goal 4: Limit Overhead in the Network ......................7
9.0 Informative References.................................12 3.5. Goal 5: Simplify Mobile Node Mobility Management
10.0 IPR Statements.........................................13 Security by Deriving from IP Network Access and/or IP
11.0 Disclaimer of Validity.................................13 Movement Detection Security ................................7
12.0 Copyright Notice.......................................13 3.6. Goal 6: Link Technology Agnostic ...........................8
3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
3.10. Goal 10: Localized Mobility Management
Independent of Global Mobility Management ................10
3.11. Goal 11: Configurable Data Plane Forwarding
between Local Mobility Anchor and Mobile Access Gateway ..11
4. Security Considerations ........................................11
5. Acknowledgements ...............................................11
6. Normative References ...........................................12
7. Informative References .........................................12
8. Contributors ...................................................13
1.0 Introduction 1. Introduction
In [1], the basic problems that occur when a global mobility In [1], the basic problems that occur when a global mobility protocol
protocol is used for managing local mobility are described, and two is used for managing local mobility are described, and two currently
currently used approaches to localized mobility management - the used approaches to localized mobility management -- the host-based
host-based approach that is used by most IETF protocols, and the approach that is used by most IETF protocols, and the proprietary
proprietary WLAN switch approach used between WLAN switches in Wireless LAN (WLAN) switch approach used between WLAN switches in
different subnets - are examined. The conclusion from the problem different subnets -- are examined. The conclusion from the problem
statement document is that none of the approaches has a complete statement document is that none of the approaches has a complete
solution to the problem. While the WLAN switch approach is most solution to the problem. While the WLAN switch approach is most
convenient for network operators and users because it requires no convenient for network operators and users because it requires no
software on the mobile node other than the standard drivers for software on the mobile node other than the standard drivers for WiFi,
WiFi, the proprietary nature limits interoperability and the the proprietary nature limits interoperability, and the restriction
restriction to a single last hop link type and wired backhaul link to a single last-hop link type and wired backhaul link type restricts
type restricts scalability. The IETF host-based protocols require scalability. The IETF host-based protocols require host software
host software stack changes that may not be compatible with all stack changes that may not be compatible with all global mobility
global mobility protocols, and also require specialized and complex protocols. They also require specialized and complex security
security transactions with the network that may limit transactions with the network that may limit deployability. The
deployability. The conclusion was that a localized mobility conclusion is that a localized mobility management protocol that is
management protocol that was network based and required no software network based and requires no software on the host for localized
on the host for localized mobility management is desirable. mobility management is desirable.
This document develops a brief functional architecture and detailed This document develops a brief functional architecture and detailed
goals for a network-based localized mobility management protocol goals for a network-based localized mobility management protocol
(NETLMM). Section 2.0 describes the functional architecture of (NETLMM). Section 2 describes the functional architecture of NETLMM.
NETLMM. In Section 3.0, a list of goals that are desirable in the In Section 3, a list of goals that is desirable in the NETLMM
NETLMM protocol is presented. Section 4.0 concerns IANA protocol is presented. Section 4 briefly outlines Security
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 [2]. threat analysis document [2].
1.1 Terminology 1.1. Terminology
Mobility terminology in this draft follows that in RFC 3753 [10] Mobility terminology in this document follows that in RFC 3753 [10]
and in [1]. In addition, the following terms are related to the and in [1]. In addition, the following terms are related to the
functional architecture described in Section 2.0: functional architecture described in Section 2:
Localized Mobility Management Domain Localized Mobility Management Domain
An Access Network in the sense defined in [1] in which An Access Network in the sense defined in [1] in which mobility is
mobility is handled by the NETLMM protocol. handled by the NETLMM protocol.
Mobile Access Gateway Mobile Access Gateway
A Mobile Access Gateway (MAG) is a functional network
element that terminates a specific edge link and tracks A Mobile Access Gateway (MAG) is a functional network element that
mobile node IP level mobility between edge links, through terminates a specific edge link and tracks mobile node IP-level
NETLMM signaling with the Localized Mobility Anchor. The MAG mobility between edge links, through NETLMM signaling with the
also terminates host routed data traffic from the Localized Localized Mobility Anchor. The MAG also terminates host routed
Mobility Anchor for mobile nodes currently located within data traffic from the Localized Mobility Anchor for mobile nodes
the edge link under the MAG's control, and forwards data currently located within the edge link under the MAG's control,
traffic from mobile nodes on the edge link under its control and forwards data traffic from mobile nodes on the edge link under
to the Localized Mobility Anchor. its control to the Localized Mobility Anchor.
Local Mobility Anchor Local Mobility Anchor
A Local Mobility Anchor (LMA) is a router that maintains a A Local Mobility Anchor (LMA) is a router that maintains a
collection of host routes and associated forwarding collection of host routes and associated forwarding information
information for mobile nodes within a localized mobility for mobile nodes within a localized mobility management domain
management domain under its control. Together with the MAGs under its control. Together with the MAGs associated with it, the
associated with it, the LMA uses the NETLMM protocol to LMA uses the NETLMM protocol to manage IP node mobility within the
manage IP node mobility within the localized mobility localized mobility management domain. Routing of mobile node data
management domain. Routing of mobile node data traffic is traffic is anchored at the LMA as the mobile node moves around
anchored at the LMA as the mobile node moves around within within the localized mobility management domain.
the localized mobility management domain.
2.0 NETLMM Functional Architecture 2. NETLMM Functional Architecture
The NETLMM architecture consists of the following components. The NETLMM architecture consists of the following components.
Localized Mobility Anchors (LMAs) within the backbone network Localized Mobility Anchors (LMAs) within the backbone network
maintain a collection of routes for individual mobile nodes within maintain a collection of routes for individual mobile nodes within
the localized mobility management domain. The routes point to the the localized mobility management domain. The routes point to the
Mobile Access Gateways (MAGs) managing the links on which the Mobile Access Gateways (MAGs) managing the links on which the mobile
mobile nodes currently are located. Packets for a mobile node are nodes currently are located. Packets for a mobile node are routed to
routed to and from the mobile node through tunnels between the LMA and from the mobile node through tunnels between the LMA and MAG.
and MAG. When a mobile node moves from one link to another, the MAG When a mobile node moves from one link to another, the MAG sends a
sends a route update to the LMA. While some mobile node involvement route update to the LMA. While some mobile node involvement is
is necessary and expected for generic mobility functions such as necessary and expected for generic mobility functions such as
movement detection and to inform the MAG about mobile node movement detection and to inform the MAG about mobile node movement,
movement, no specific mobile node to network protocol will be no specific mobile-node-to-network protocol will be required for
required for localized mobility management itself. Host stack localized mobility management itself. Host stack involvement in
involvement in mobility management is thereby limited to generic mobility management is thereby limited to generic mobility functions
mobility functions at the IP layer, and no specialized localized at the IP layer, and no specialized localized mobility management
mobility management software is required. software is required.
3.0 Goals for the NETLMM Protocol 3. Goals for the NETLMM Protocol
Section 2 of [1] describes three problems with using a global 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 for NETLMM including both solving the basic problems address goals for NETLMM, including both solving the basic problems
(Goals 1, 2, 3) and limiting the side effects (Goals 4+). (Goals 1, 2, and 3) and limiting the side 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 [4]. applicability to IETF protocols can be found in [4].
Out of scope for the initial goals discussion are QoS and dormant Out of scope for the initial goals discussion are Quality of Service
mode/paging. While these are important functions for mobile nodes, (QoS) and dormant mode/paging. While these are important functions
they are not part of the base localized mobility management for mobile nodes, they are not part of the base localized mobility
problem. In addition, mobility between localized mobility management problem. In addition, mobility between localized mobility
management domains is not covered here. It is assumed that this is management domains is not covered here. It is assumed that this is
covered by the global mobility management protocols. covered by the global mobility management protocols.
3.1 Handover Performance Improvement (Goal #1) 3.1. Goal 1: Handover Performance Improvement
Handover packet loss occurs because there is usually latency Handover packet loss occurs because there is usually latency between
between when the link handover starts and when the IP subnet when the link handover starts and when the IP subnet configuration
configuration and global mobility management signaling completes. and global mobility management signaling completes. During this
During this time the mobile node is unreachable at its former time, the mobile node is unreachable at its former topological
topological location on the old link where correspondents are location on the old link where correspondents are sending packets.
sending packets. Such misrouted packets are dropped. This aspect of Such misrouted packets are dropped. This aspect of handover
handover performance optimization has been the subject of much performance optimization has been the subject of much work, both in
work, both in other SDOs and in the IETF, in order to reduce the other Standards Development Organizations (SDOs) and in the IETF, in
latency in IP handover. Many solutions to this problem have been order to reduce the latency in IP handover. Many solutions to this
proposed at the link layer and at the IP layer. One aspect of this problem have been proposed at the link layer and at the IP layer.
goal for localized mobility management is that the processing delay One aspect of this goal for localized mobility management is that the
for changing the forwarding after handover must approach as closely processing delay for changing the forwarding after handover must
as possible the sum of the delay associated with link layer approach as closely as possible the sum of the delay associated with
handover and the delay required for active IP layer movement link-layer handover and the delay required for active IP-layer
detection, in order to avoid excessive packet loss. Ideally, if movement detection, in order to avoid excessive packet loss.
network-side link layer support is available for handling movement Ideally, if network-side link-layer support is available for handling
detection prior to link handover or as part of the link handover movement detection prior to link handover or as part of the link
process, the routing update should complete within the time handover process, the routing update should complete within the time
required for link handover. This delay is difficult to quantify, required for link handover. This delay is difficult to quantify, but
but for voice traffic, the entire handover delay including Layer 2 for voice traffic, the entire handover delay, including Layer 2
handover time and IP handover time should be between 40-70 ms to handover time and IP handover time should be between 40-70 ms to
avoid any degradation in call quality. Of course, if the link layer avoid any degradation in call quality. Of course, if the link-layer
handover latency is too high, sufficient IP layer handover handover latency is too high, sufficient IP-layer handover
performance for good real time service cannot be matched. performance for good real-time service cannot be matched.
A goal of the NETLMM protocol - in networks where the link layer A goal of the NETLMM protocol -- in networks where the link-layer
handover latency allows it - is to reduce the amount of latency in handover latency allows it -- is to reduce the amount of latency in
IP handover, so that the combined IP and link layer handover IP handover, so that the combined IP-layer and link-layer handover
latency is less than 70 ms. latency is less than 70 ms.
3.2 Reduction in Handover-related Signaling Volume (Goal #2) 3.2. Goal 2: Reduction in Handover-Related Signaling Volume
Considering Mobile IPv6 [9] 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
must be performed: 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 [7] this is the Reassociate message For example, in 802.11 [7], this is the Reassociate message
together with 802.1x [8] reauthentication using EAP. together with 802.1x [8] reauthentication using EAP.
2) Active IP level movement detection, including router
reachability. The DNA protocol [5] uses Router 2) Active IP-level movement detection, including router reachability.
The Detecting Network Attachment (DNA) protocol [5] uses Router
Solicitation/Router Advertisement for this purpose. In addition, Solicitation/Router Advertisement for this purpose. In addition,
if SEND [3] is used and the mobile node does not have a if SEcure Neighbor Discovery (SEND) [3] is used and the mobile
certificate cached for the router, the mobile node must use node does not have a certificate cached for the router, the mobile
Certification Path Solicitation/Certification Path Advertisement node must use Certification Path Solicitation/Certification Path
to obtain a certification path. Advertisement to obtain a certification path.
3) Two Multicast Listener Discovery (MLD) [14] 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
link local and global addresses, and two Neighbor Advertisement 5) Two NS messages from the router for address resolution of the link
messages in response from the mobile node, local and global addresses, and two Neighbor Advertisement
6) Binding Update/Binding Acknowledgement between the mobile node messages in response from the mobile node.
and home agent to update the care of address binding,
6) Binding Update/Binding Acknowledgement between the mobile node 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 last hop 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. Steps 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
is used. The result is approximately 18 messages at the IP level, used. The result is approximately 18 messages at the IP level, where
where the exact number depends on various specific factors such as the exact number depends on various specific factors, such as whether
whether the mobile node has a router certificate cached or not, or not the mobile node has a router certificate cached before a
before a mobile node can be ensured that it is established on a mobile node can be ensured that it is established on a link and has
link and has full IP connectivity. In addition to handover related full IP connectivity. In addition to handover related signaling, if
signaling, if the mobile node performs Mobile IPv6 route the mobile node performs Mobile IPv6 route optimization, it may be
optimization, it may be required to renew its return routability required to renew its return routability key periodically (on the
key periodically (on the order of every 7 minutes) even if it is order of every 7 minutes), even if it is not moving, resulting in
not moving, resulting in additional signaling. additional signaling.
The signaling required has a large impact on the performance of The signaling required has a large impact on the performance of
handover, impacting Goal #1. Perhaps more importantly, the handover, impacting Goal 1. Perhaps more importantly, the aggregate
aggregate impact from many mobile nodes of such signaling on impact from many mobile nodes of such signaling on expensive shared
expensive shared links (such as wireless where the capacity of the links (such as wireless where the capacity of the link cannot easily
link cannot easily be expanded) can result in reduced last hop link be expanded) can result in reduced last-hop link capacity for data
capacity for data traffic. Additoinally, in links where the end traffic. Additionally, in links where the end user is charged for IP
user is charged for IP traffic, IP signaling is not without cost. traffic, IP signaling is not without cost.
To address the issue of signaling impact described above, the goal To address the issue of signaling impact described above, the goal is
is that handover signaling volume from the mobile node to the that handover signaling volume from the mobile node to the network
network should be no more than what is needed for the mobile node should be no more than what is needed for the mobile node to perform
to perform secure IP level movement detection, in cases where no secure IP-level movement detection, in cases where no link-layer
link layer support exists. Furthermore, NETLMM should not introduce support exists. Furthermore, NETLMM should not introduce any
any additional signaling during handover beyond what is required additional signaling during handover beyond what is required for IP-
for IP level movement detection. If link layer support exists for level movement detection. If link-layer support exists for IP-level
IP level movement detection, the mobile node may not need to movement detection, the mobile node may not need to perform any
perform any additional IP level signaling after link layer additional IP-level signaling after link-layer handover.
handover.
3.3 Location Privacy (Goal #3) 3.3. Goal 3: Location Privacy
In any IP network, there is a threat that an attacker can determine In any IP network, there is a threat that an attacker can determine
the physical location of a network node from the node's topological the physical location of a network node from the node's topological
location. Depending on how an operator deploys their network, an location. Depending on how an operator deploys their network, an
operator may choose to assign subnet coverage in a way that is operator may choose to assign subnet coverage in a way that is
tightly bound to geography at some timescale or it may choose to tightly bound to geography at some timescale, or it may choose to
assign it in ways in which the threat of someone finding a node assign it in ways in which the threat of someone finding a node
physically based on its IP address is smaller. Allowing physically based on its IP address is smaller. Allowing the L2
the L2 attachment and L3 address to be less tightly bound is one attachment and L3 address to be less tightly bound is one tool for
tool for reducing this threat to location privacy. reducing this threat to location privacy.
Mobility introduces an additional threat. An attacker can track a Mobility introduces an additional threat. An attacker can track a
mobile node's geographical location in real time, if the victim mobile node's geographical location in real-time, if the victim
mobile node must change its IP address as it moves from one subnet mobile node must change its IP address as it moves from one subnet to
to another through the covered geographical area. If the another through the covered geographical area. If the granularity of
granularity of the mapping between the IP subnets and geographical the mapping between the IP subnets and geographical area is small for
area is small for the particular link type in use, the attacker can the particular link type in use, the attacker can potentially
potentially assemble enough information to find the victim in real assemble enough information to find the victim in real time.
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 a mobile node moves across links in an need to change IP address as a mobile node moves across links in an
access network. Keeping the IP address fixed over a large access network. Keeping the IP address fixed over a large
geographical region fuzzes out the resolution of the mapping geographical region fuzzes out the resolution of the mapping between
between the IP subnets and geographical area, regardless of how the IP subnets and geographical area, regardless of how small the
small the natural deployment granularity may be. This reduces the natural deployment granularity may be. This reduces the chance that
chance that the attacker can deduce the precise geographic location the attacker can deduce the precise geographic location of the mobile
of the mobile node. node.
3.4 Limit Overhead in the Network (Goal #4) 3.4. Goal 4: Limit Overhead in the Network
Access networks, including both the wired and wireless parts, tend Access networks, including both the wired and wireless parts, tend to
to have somewhat stronger bandwidth and router processing have somewhat stronger bandwidth and router processing constraints
constraints than the backbone. In the wired part of the network, than the backbone. In the wired part of the network, these
these constraints are a function of the cost of laying fiber or constraints are a function of the cost of laying fiber or wiring to
wiring to the wireless access points in a widely dispersed the wireless access points in a widely dispersed geographic area. In
geographic area. In the wireless part of the network, these the wireless part of the network, these constraints are due to the
constraints are due to the limitation on the number of bits per limitation on the number of bits per Hertz imposed by the physical
Hertz imposed by the physical layer protocol. Therefore, any layer protocol. Therefore, any solutions for localized mobility
solutions for localized mobility management should minimize management should minimize overhead within the access network.
overhead within the access network.
3.5 Simplify Mobile Node Mobility Management Security by Deriving from 3.5. Goal 5: Simplify Mobile Node Mobility Management Security by
IP Network Access and/or IP Movement Detection Security (Goal #5) Deriving from IP Network Access and/or IP Movement Detection
Security
Localized mobility management protocols that have host involvement Localized mobility management protocols that have host involvement
may require an additional security association between the mobile may require an additional security association between the mobile
node and the mobility anchor, and establishing this security node and the mobility anchor, and establishing this security
association may require additional signaling between the mobile association may require additional signaling between the mobile node
node and the mobility anchor (see [13] for an example). The and the mobility anchor (see [13] for an example). The additional
additional security association requires extra signaling and security association requires extra signaling and therefore extra
therefore extra time to negotiate. Reducing the complexity of time to negotiate. Reducing the complexity of mobile-node-to-network
mobile node to network security for localized mobility management security for localized mobility management can therefore reduce
can therefore reduce barriers to deployment and improve barriers to deployment and improve responsiveness. Naturally, such
responsiveness. Naturally, such simplification must not come at the simplification must not come at the expense of maintaining strong
expense of maintaining strong security guarantees for both the security guarantees for both the network and mobile node.
network and mobile node.
In NETLMM, the network (specifically the MAG) derives the In NETLMM, the network (specifically, the MAG) derives the occurrence
occurrence of a mobility event requiring a routing update for a of a mobility event, requiring a routing update for a mobile node
mobile node from link layer handover signaling or IP layer movement from link-layer handover signaling, or IP-layer movement detection
detection signaling from the mobile node. This information is used signaling from the mobile node. This information is used to update
to update routing for the mobile node at the LMA. The handover or routing for the mobile node at the LMA. The handover, or movement
movement detection signaling must provide the network with proper detection signaling, must provide the network with proper
authentication and authorization so that the network can authentication and authorization so that the network can definitively
definitively identify the mobile node and determine its identify the mobile node and determine its authorization. The
authorization. The authorization may be at the IP level, for authorization may be at the IP level -- for example, using something
example, using something like SEND [3] to secure IP movement like SEND [3] to secure IP movement detection signaling -- or it at
detection signaling, or it may be at the link level. Proper the link level. Proper authentication and authorization must be
authentication and authorization must be implemeted on link layer implemented on link-layer handover signaling and/or IP-level movement
handover signaling and/or IP level movement detection signaling in detection signaling in order for the MAG to securely deduce mobile
order for the MAG to securely deduce mobile node movement events. node movement events. Security threats to the NETLMM protocol are
Security threats to the NETLMM protocol are discussed in [2]. discussed in [2].
The goal is that security for NETLMM mobile node mobility The goal is that security for NETLMM mobile node mobility management
management should derive from IP network access and/or IP movement should derive from IP network access and/or IP movement detection
detection security, such as SEND or network access authentication, security, such as SEND or network access authentication, and not
and not require any additional security associations or additional require any additional security associations or additional signaling
signaling between the mobile node and the network. between the mobile node and the network.
3.6 Link Technology Agnostic (Goal #6) 3.6. Goal 6: Link Technology Agnostic
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
of a wireless link physical and medium access control layers is a a wireless link physical and medium access control layers is a time-
time consuming process, reducing the amount of work necessary to consuming process, reducing the amount of work necessary to interface
interface a particular wireless link technology to an IP network is a particular wireless link technology to an IP network is necessary.
necessary. When the last hop link is a wireless link, a localized When the last-hop link is a wireless link, a localized mobility
mobility management solution should ideally require minimal work to management solution should ideally require minimal work to interface
interface with a new wireless link technology. 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 a change in the IP
but this possibility should not be precluded. address, 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
securely identifying a mobile node. securely identifying a mobile node.
3.7 Support for Unmodified Mobile Nodes (Goal #7) 3.7. Goal 7: Support for Unmodified Mobile Nodes
In the wireless LAN switching market, no modification of the In the WLAN switching market, no modification of the software on the
software on the mobile node is required to achieve localized mobile node is required to achieve localized mobility management.
mobility management. Being able to accommodate unmodified mobile Being able to accommodate unmodified mobile nodes enables a service
nodes enables a service provider to offer service to as many provider to offer service to as many customers as possible, the only
customers as possible, the only constraint being that the customer 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 link technology-specific protocols needing support proprietary or link technology-specific protocols needing support for
for backward compatibility reasons. Within the Internet, both HIP backward compatibility reasons. Within the Internet, both Host
[11] and Mobike [6] are likely to need support in addition to Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming
Mobile IPv6 [9], and Mobile IPv4 [12] support may also be (MOBIKE) [6] are likely to need support in addition to Mobile IPv6
necessary. [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. The mobile node must have software at all associated with mobility. The mobile node must have
some kind of global mobility protocol if it is to move from one some kind of global mobility protocol if it is to move from one
domain of edge mobility support to another and maintain session domain of edge mobility support to another and maintain session
continuity, although no global mobility protocol is required if the continuity, although no global mobility protocol is required if the
mobile node only moves within the coverage area of the localized mobile node only moves within the coverage area of the localized
mobility management protocol or no session continuity is required mobility management protocol or no session continuity is required
during global movement. Also, if the last hop link is a wireless during global movement. Also, if the last-hop link is a wireless
link, every wireless link protocol requires handover support on the link, every wireless link protocol requires handover support on the
mobile node in the physical and medium access control layers, mobile node in the physical and medium access control layers,
typically in the wireless interface driver. Information passed from typically in the wireless interface driver. Information passed from
the medium access control layer to the IP layer on the mobile node the medium access control layer to the IP layer on the mobile node
may be necessary to trigger IP signaling for IP handover. Such may be necessary to trigger IP signaling for IP handover. Such
movement detection support at the IP level may be required in order movement detection support at the IP level may be required in order
to 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
required depends on whether the medium access control layer can depends on whether the medium access control layer can completely
completely hide link movement from the IP layer. For cellular type hide link movement from the IP layer. For cellular type wireless
wireless link protocols, the mobile node and network undergo an link protocols, the mobile node and network undergo an extensive
extensive negotiation at the medium access control layer prior to negotiation at the medium access control layer prior to handover, so
handover, so it may be possible to trigger routing update without it may be possible to trigger a routing update without any IP
any IP protocol involvement. However, for a wireless link protocol protocol involvement. However, for a wireless link protocol such as
such as IEEE 802.11 [7] in which the decision for handover is IEEE 802.11 [7] in which the decision for handover is entirely in the
entirely in the hands of the mobile node, IP layer movement hands of the mobile node, IP-layer movement detection signaling from
detection signaling from the mobile node may be required to trigger 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
be able to support any mobile node that joins the link and that has able to support any mobile node that joins the link and that has an
a interface that can communicate with the network, without interface that can communicate with the network, without requiring
requiring localized mobility management software on the mobile localized mobility management software on the mobile node.
node.
3.8 Support for IPv4 and IPv6 (Goal #8) 3.8. Goal 8: Support for IPv4 and IPv6
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
is desirable, though the actual protocol may be slightly different desirable, though the actual protocol may be slightly different due
due to the technical details of how each IP version works. From to the technical details of how each IP version works. From Goal 7
Goal #7 (Section 3.7), minimizing mobile node support for localized (Section 3.7), minimizing mobile node support for localized mobility
mobility means that ideally no IP version-specific changes should means that ideally no IP version-specific changes should be required
be required on the mobile node for localized mobility, and that on the mobile node for localized mobility, and that global mobility
global mobility protocols for both IPv4 and IPv6 should be protocols for both IPv4 and IPv6 should be supported. Any IP
supported. Any IP version-specific features should be confined to version-specific features should be confined to the network protocol.
the network protocol.
3.9 Re-use of Existing Protocols Where Sensible (Goal #9) 3.9. Goal 9: Reuse of Existing Protocols Where Sensible
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 reuse existing protocols where it makes
architectural and engineering sense to do so. The design should architectural and engineering sense to do so. However, the design
not, however, attempt to re-use existing protocols where there is should not attempt to reuse existing protocols where there is no real
no real architectural or engineering reason. For example, the suite architectural or engineering reason. For example, the suite of
of Internet Standards contains several good candidate protocols for Internet Standards contains several good candidate protocols for the
the transport layer, so there is no real need to develop a new transport layer, so there is no real need to develop a new transport
transport protocol specifically for NETLMM. Re-use is clearly a protocol specifically for NETLMM. Reuse is clearly a good
good engineering decision in this case, since backward engineering decision in this case, since backward compatibility with
compatibility with existing protocol stacks is important. On the existing protocol stacks is important. On the other hand, the
other hand, the network-based, localized mobility management network-based, localized mobility management functionality being
functionality being introduced by NETLMM is a new piece of introduced by NETLMM is a new piece of functionality, and therefore
functionality, and therefore any decision about whether to re-use any decision about whether to reuse an existing global mobility
an existing global mobility management protocol should carefully management protocol should carefully consider whether reusing such a
consider whether re-using such a protocol really meets the needs of protocol really meets the needs of the functional architecture for
the functional architecture for network-based localized mobility network-based localized mobility management. The case for reuse is
management. The case for re-use is not so clear in this case, since not so clear in this case, since there is no compelling backward
there is no compelling backward compatibility argument. compatibility argument.
3.10 Localized Mobility Management Independent of Global Mobility 3.10. Goal 10: Localized Mobility Management Independent of Global
Management (Goal #10) Mobility Management
Localized mobility management should be implementable and Localized mobility management should be implementable and deployable
deployable independently of any global mobility management independently of any global mobility management protocol. This
protocol. This enables the choice of local and global mobility enables the choice of local and global mobility management to be made
management to be made independently of particular protocols that independently of particular protocols that are implemented and
are implemented and deployed to solve the two different sorts of deployed to solve the two different sorts of mobility management
mobility management problems. The operator can choose a particular problems. The operator can choose a particular localized mobility
localized mobility management protocol according to the specific management protocol according to the specific features of their
features of their access network. It can subsequently upgrade the access network. It can subsequently upgrade the localized mobility
localized mobility management protocol on its own, without even management protocol on its own, without even informing the mobile
informing the mobile nodes. Similarly, the mobile nodes can use a nodes. Similarly, the mobile nodes can use a global mobility
global mobility management protocol that best suits their management protocol that best suits their requirements, or not use
requirements, or even not use one at all. Also, a mobile node can one at all. Also, a mobile node can move into a new access network
move into a new access network without having to check that it without having to check that it understands the localized mobility
understands the localized mobility management protocol being used 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.
3.11 Configurable Data Plane Forwarding between Local Mobility Anchor 3.11. Goal 11: Configurable Data Plane Forwarding between Local
and Mobile Access Gateway (Goal #11) Mobility Anchor and Mobile Access Gateway
Different network operators may require different types of
forwarding options between the LMA and the MAGs 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 are
the LMA and the MAGs. 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 LMA and MAGs 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.
4.0 IANA Considerations Different network operators may require different types of forwarding
options between the LMA and the MAGs 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 are the LMA and
the MAGs. But other options are possible. Some network deployments
may prefer routing-based solutions. Others may require security
tunnels using IPsec Encapsulating Security Payload (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.
There are no IANA considerations for this document. A goal of the NETLMM protocol is to allow the forwarding between the
LMA and MAGs 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 timescale 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.
5.0 Security Considerations 4. 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 NETLMM protocol. The security-related goals in this in the NETLMM protocol. The security-related goals in this document,
document, described in Section 3.3 and 3.5, focus on the former, described in Section 3.3 and 3.5, focus on the former, because those
because those are unique to network-based mobility management. The are unique to network-based mobility management. The threat analysis
threat analysis document [2] contains a more detailed discussion of document [2] contains a more detailed discussion of both kinds of
both kinds of threats, which the protocol design must address. threats, which the protocol design must address.
6.0 Acknowledgements 5. Acknowledgements
The authors would like to acknowledge the following for The authors would like to acknowledge the following people 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.
7.0 Author's Addresses 6. Normative References
James Kempf [1] Kempf, J., Ed., "Problem Statement for Network-Based Localized
DoCoMo USA Labs Mobility Management (NETLMM)", RFC 4830, April 2007.
181 Metro Drive, Suite 300
San Jose, CA 95110 [2] Vogt, C., and Kempf, J., "Security Threats to Network-Based
USA Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com 7. Informative References
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[4] Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996.
[5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005.
[6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x,
June, 2001.
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
8. Contributors
Kent Leung Kent Leung
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: kleung@cisco.com EMail: kleung@cisco.com
Phil Roberts Phil Roberts
Motorola Labs Motorola Labs
Schaumberg, IL Schaumberg, IL
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
8.0 Normative References Editor's Address
[1] Kempf, J., editor, "Problem Statement for IP Local Mobility," James Kempf
Internet Draft, Work in Progress. DoCoMo USA Labs
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based 181 Metro Drive, Suite 300
Localized Mobility Management", Internet Draft, Work in San Jose, CA 95110
Progress. USA
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
9.0 Informative References Full Copyright Statement
[3] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Copyright (C) The IETF Trust (2007).
Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[4] Carpenter, B., "Architectural Principles of the Internet,"
RFC 1958, June, 1996.
[5] Choi, J, and Daley, G., "Goals of Detecting Network
Attachment in IPv6", Internet Draft, Work in Progress.
[6] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
802.1x, June, 2001.
[9] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6", RFC 3775, June, 2004.
[10] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004.
[11] Moskowitz, R., and Nikander, P., "Host Identity Protocol
(HIP) Architecture", RFC 4423, May, 2006.
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August, 2002.
[13] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August, 2005.
[14] Vida, R., and Costa, L., " Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
10.0 IPR Statements This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this 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
at http://www.ietf.org/ipr. 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
ipr@ietf.org. ietf-ipr@ietf.org.
11.0 Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
12.0 Copyright Notice Acknowledgement
Copyright (C) The Internet Society (2006). This document is Funding for the RFC Editor function is currently provided by the
subject to the rights, licenses and restrictions contained in BCP Internet Society.
78, and except as set forth therein, the authors retain all their
rights.
 End of changes. 88 change blocks. 
434 lines changed or deleted 433 lines changed or added

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