draft-ietf-netlmm-nohost-req-03.txt   draft-ietf-netlmm-nohost-req-04.txt 
Internet Draft J. Kempf, Internet Draft J. Kempf, Editor
Editor Document: draft-ietf-netlmm-nohost-req-04.txt August, 2006
Document: draft-ietf-netlmm-nohost-req-03.txt
Expires: December, 2006 June, 2006 Expires: Feburary, 2007
Goals for Network-based Localized Mobility Management (NETLMM) Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-03.txt) (draft-ietf-netlmm-nohost-req-04.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 2, line 7 skipping to change at page 2, line 6
Table of Contents Table of Contents
1.0 Introduction............................................2 1.0 Introduction............................................2
2.0 Goals for Localized Mobility Management.................2 2.0 Goals for Localized Mobility Management.................2
3.0 IANA Considerations....................................10 3.0 IANA Considerations....................................10
4.0 Security Considerations................................10 4.0 Security Considerations................................10
5.0 Acknowledgements.......................................11 5.0 Acknowledgements.......................................11
6.0 Author's Addresses.....................................11 6.0 Author's Addresses.....................................11
7.0 Informative References.................................12 7.0 Informative References.................................12
8.0 IPR Statements.........................................13 8.0 Appendix: Gap Analysis.................................13
9.0 Disclaimer of Validity.................................14 9.0 IPR Statements.........................................23
10.0 Copyright Notice.......................................14 10.0 Disclaimer of Validity.................................23
11.0 Appendix: Gap Analysis.................................14 11.0 Copyright Notice.......................................23
1.0 Introduction 1.0 Introduction
In [1], the basic problems that occur when a global mobility In [9], 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 basic approaches to localized mobility management - the host-based
approach that is used by most IETF protocols, and the proprietary approach that is used by most IETF protocols, and the proprietary
WLAN switch approach used between WLAN switches in different WLAN switch approach used between WLAN switches in different
subnets - are examined. The conclusion from the problem statement subnets - are examined. The conclusion from the problem statement
document is that none of the approaches has a complete solution to document is that none of the approaches has a complete solution to
the problem. While the WLAN switch approach is most convenient for the problem. While the WLAN switch approach is most convenient for
network operators and users because it requires no software on the network operators and users because it requires no software on the
mobile node other than the standard drivers for WiFi, the mobile node other than the standard drivers for WiFi, the
proprietary nature limits interoperability and the restriction to a proprietary nature limits interoperability and the restriction to a
single wireless link type and wired backhaul link type restricts single wireless link type and wired backhaul link type restricts
scalablity. The IETF host-based protocols require host software scalability. The IETF host-based protocols require host software
stack changes that may not be compatible with all global mobility stack changes that may not be compatible with all global mobility
protocols, and also require specialized and complex security protocols, and also require specialized and complex security
transactions with the network that may limit deployability. The use transactions with the network that may limit deployability. The use
of an IGP to distribute host routes has scalability and deployment of an IGP to distribute host routes has scalability and deployment
limitations. limitations.
This document develops more detailed goals for a network-based This document develops more detailed goals for a network-based
localized mobility management protocol. In Section 2.0, we review a localized mobility management protocol. In Section 2.0, we review a
list of goals that are desirable in a network-based localized list of goals that are desirable in a network-based localized
mobility management solution. Section 3.0 briefly outlines security mobility management solution. Section 3.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]. The architecture of the NETLMM threat analysis document [20]. The architecture of the NETLMM
protocol for which the goals in this document have been formulated protocol for which the goals in this document have been formulated
is described in Section 4 of [1]. is described in Section 5 of [9].
1.1 Terminology 1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753 [3] and Mobility terminology in this draft follows that in RFC 3753 [13]
in [1]. and in [9].
2.0 Goals for Localized Mobility Management 2.0 Goals for Localized Mobility Management
Section 2 of [1] describes three problems with using a global Section 2 of [9] 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 on a localized mobility solution including both
solving the basic problems (Goals 1, 2, 3) and limiting the side solving the basic problems (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 [4]. applicability to IETF protocols can be found in [3].
Out of scope for the initial goals discussion are QoS, multicast, Out of scope for the initial goals discussion are QoS, multicast,
and dormant mode/paging. While these are important functions for and dormant mode/paging. While these are important functions for
mobile nodes, they are not part of the base localized mobility mobile nodes, they are not part of the base localized mobility
management problem. In addition, mobility between localized management problem. In addition, mobility between localized
mobility management domains is not covered here. It is assumed that mobility management domains is not covered here. It is assumed that
this is covered by the global mobility management protocols. this is covered by the global mobility management protocols.
2.1 Handover Performance Improvement (Goal #1) 2.1 Handover Performance Improvement (Goal #1)
skipping to change at page 4, line 4 skipping to change at page 3, line 55
degradation in call quality. degradation in call quality.
A goal of the protocol is to reduce the loss of accurate forwarding A goal of the protocol is to reduce the loss of accurate forwarding
to reduce interruptions which may cause user-perceptible service to reduce interruptions which may cause user-perceptible service
degradation for real time traffic such as voice. degradation for real time traffic such as voice.
2.2 Reduction in Handover-related Signaling Volume (Goal #2) 2.2 Reduction in Handover-related Signaling Volume (Goal #2)
Considering Mobile IPv6 as the global mobility protocol (other Considering Mobile IPv6 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 is required to reconfigure on every move between links, mobile node using address autoconfiguration is required to
the following signaling must be performed: reconfigure on every move between links, the following signaling
must be performed:
1) Movement detection using DNA [6] or possibly a link specific
protocol,
2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or
PANA [8]. The mobile node may also or instead have to obtain a
router authorization certificate using SEND [9], if the
certificate is not already cached,
3) Router discovery which may be part of movement detection,
4) If stateless address autoconfiguration is used, address
configuration and Duplicate Address Detection (unless optimistic
Duplicate Address Detection [10] is used) including for link
local addresses. If stateful address configuration is used, then
DHCP is used for address configuration,
5) Binding Update to the home agent,
6) If route optimization is in effect, return routability to
establish the binding key,
7) Binding Update to correspondent nodes for route optimization.
Note that Steps 1-2 will always be necessary, even for intra-link 1) Link layer signaling required for handover and reauthentication.
mobility. Step 3 will be necessary even if the mobile node's care- For example, in 802.11 [6] this is the Reassociate message
of address can remain the same when it moves to a new access together with 802.1x [7] reauthentication using EAP.
router. Steps 5 through 7 are only necessary when Mobile IPv6 is 2) Active IP level movement detection, including router
used. reachability. The DNA protocol [4] uses Router
Solicitation/Router Advertisement for this purpose. In addition,
if SEND [1] is used and the mobile node does not have a
certificate cached for the router, the mobile node must use
Certification Path Solicitation/Certification Path Advertisement
to obtain a certification path.
3) Two Multicast Listener Discovery (MLD) [19] REPORT messages, one
for each of the solicited node multicast addresses corresponding
to the link local address and the global address,
4) Two Neighbor Solicitation (NS) messages for duplicate address
detection, one for the link local address and one for the global
address. If the addresses are unique, no response will be
forthcoming.
5) Two NS messages from the router for address resolution of the
link local and global addresses, and two Neighbor Advertisement
messages in response from the mobile node,
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
mobile node to establish the binding key, consisting of one Home
Test Init/Home Test and Care of Test Init/Care of Test,
8) Binding Update/Binding Acknowledgement between the correspondent
node and mobile node for route optimization.
The result is approximately 10 messages at the IP level before a Note that Steps 1-2 may be necessary, even for intra-link mobility,
mobile node can be ensured that it is established on a link and has if the wireless link protocol doesn't provide much help for IP
full IP connectivity. Furthermore, in some cases, the mobile node handover. Step 3-5 will be different if stateful address
may need to engage in "heartbeat signaling" to keep the connection configuration is used, since additional messages are required to
with the correspondent or global mobility anchor fresh, for obtain the address. Steps 6-8 are only necessary when Mobile IPv6
example, return routability in Mobile IPv6 must be done at a is used. The result is approximately 18 messages at the IP level,
maximum every 7 minutes even if the mobile node is standing still. where the exact number depends on various specific factors such as
whether the mobile node has a router certificate cached or not,
before a mobile node can be ensured that it is established on a
link and has full IP connectivity.
The goal is that handover signaling volume from the mobile node to The goal is that handover signaling volume from the mobile node to
the network should be no more than what is needed for the mobile the network should be no more than what is needed for the mobile
node to perform secure IP level movement detection, in cases where node to perform secure IP level movement detection, in cases where
no link layer support exists. If link layer support exists for IP no link layer support exists. If link layer support exists for IP
level movement detection, the mobile node may not need to perform level movement detection, the mobile node may not need to perform
any additional IP level signaling after handover. any additional IP level signaling after handover.
2.3 Location privacy (Goal #3) 2.3 Location privacy (Goal #3)
Although location privacy issues for Mobile IPv6 have been
Although general location privacy issues have been discussed in discussed in [12], the location privacy referred to here focuses on
[11], the location privacy referred to here focuses on the IP the IP layer. In most wireless IP network deployments, different IP
layer. In most wireless IP network deployments, different IP
subnets are used to cover different geographical areas. It is subnets are used to cover different geographical areas. It is
therefore possible to derive a topological to geographical map, in therefore possible to derive a topological to geographical map, in
which particular IPv6 subnet prefixes are mapped to particular which particular IPv6 subnet prefixes are mapped to particular
geographical locations. The precision of the map depends on the geographical locations. The precision of the map depends on the
size of the geographic area covered by a particular subnet: if the size of the geographic area covered by a particular subnet: if the
area is large, then knowing the subnet prefix won't provide much area is large, then knowing the subnet prefix won't provide much
information about the precise geographical location of a mobile information about the precise geographical location of a mobile
node within the subnet. node within the subnet.
When a mobile node moves geographically, it also moves When a mobile node moves geographically, it also moves
topologically between subnets. In order to maintain routability, topologically between subnets. In order to maintain routability,
the mobile node must change its local IP address when it moves the mobile node must change its local IP address when it moves
between subnets. A correspondent node or eavesdropper can use the 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 topological to geographical map to deduce in real time where a
mobile node - and therefore its user - is located. Depending on how mobile node - and therefore its user - is located. Depending on how
precisely the geographical location can be deduced, this precisely the geographical location can be deduced, this
information could be used to compromise the privacy or even cause information could be used to compromise the privacy or even cause
harm to the user. The geographical location information should not harm to the user. The geographical location information should not
be revealed to nor be deducible by the correspondent node or an be revealed to nor be deducible by the correspondent node or an
eavesdropper without the authorization of eavesdropper without the authorization of the mobile node's owner.
the mobile node's owner.
The threats to location privacy come in a variety of forms. One is The threats to location privacy come in a variety of forms. One is
a man in the middle attack in which traffic between a correspondent a man in the middle attack in which traffic between a correspondent
and the mobile node is intercepted and the mobile node's location and the mobile node is intercepted and the mobile node's location
is deduced from that. Others are attacks in which the correspondent is deduced from that. Others are attacks in which the correspondent
itself is the attacker, and the correspondent deliberately starts a itself is the attacker, and the correspondent deliberately starts a
session with the mobile node in order to track its location by session with the mobile node in order to track its location by
noting the source address of packets originating from the mobile noting the source address of packets originating from the mobile
node. Note that the location privacy referred to here is different node. Note that the location privacy referred to here is different
from the location privacy discussed in [14][15][16]. The location from the location privacy discussed in [12]. The location privacy
privacy discussed in these drafts primarily concerns modifications discussed in these drafts primarily concerns modifications to the
to the Mobile IPv6 protocol to eliminate places where an Mobile IPv6 protocol to eliminate places where an eavesdropper
eavesdropper could track the mobile node's movement by correlating could track the mobile node's movement by correlating home address
home address and care of address. and care of address.
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 mobile node moves across links.
Keeping the IP address fixed removes any possibility for the Keeping the IP address fixed removes any possibility for the
correspondent node to deduce the precise geographic location of the correspondent node to deduce the precise geographic location of the
mobile node without the user's authorization. Note that keeping the mobile node without the user's authorization. Note that keeping the
address constant doesn't completely remove the possibility of address constant doesn't completely remove the possibility of
deducing the geographical location, since a local address still is deducing the geographical location, since a local address still is
required. However, it does allow the network to be deployed such required. However, it does allow the network to be deployed such
skipping to change at page 7, line 12 skipping to change at page 7, line 22
is required for the IP-level movement detection messages from the is required for the IP-level movement detection messages from the
mobile node to ensure that the mobile node is authorized to possess mobile node to ensure that the mobile node is authorized to possess
the address used for the movement detection. The authorization may the address used for the movement detection. The authorization may
be at the IP level or it may be tied to the original network access be at the IP level or it may be tied to the original network access
authentication and wireless link layer authorization for handover. authentication and wireless link layer authorization for handover.
Some wireless link layers, especially cellular protocols, feature Some wireless link layers, especially cellular protocols, feature
full support and strong security for handover at the link level, full support and strong security for handover at the link level,
and require no IP support for handover. If such wireless link and require no IP support for handover. If such wireless link
security is not available, however, then it must be provided at the security is not available, however, then it must be provided at the
IP level. Security threats to the NETLMM protocol are discussed in IP level. Security threats to the NETLMM protocol are discussed in
[2]. [20].
In summary, ruling out mobile node involvement in local mobility In summary, ruling out mobile node involvement in local mobility
management simplifies security by removing the need for service- management simplifies security by removing the need for service-
specific credentials to authenticate and authorize the mobile node specific credentials to authenticate and authorize the mobile node
for localized mobility management in the network. This puts for localized mobility management in the network. This puts
localized mobility management on the same level as basic IP localized mobility management on the same level as basic IP
routing. Hosts obtain this service as part of their network access. routing. Hosts obtain this service as part of their network access.
If the access network policy wants to deny localized mobility
management to a mobile node, it can do so at the time network
access authentication occurs, in a manner the reverse of how some
networks restrict routing to the Internet before network access
authentication and open it afterwards.
The goal is that support for localized mobility management should The goal is that support for localized mobility management should
not require security between the mobile node and the network other not require security between the mobile node and the network other
than that required for network access or local link security (such than that required for network access or local link security (such
as SEND [9]). as SEND [1]).
2.7 Wireless Link Technology Agnostic (Goal #7) 2.7 Wireless Link Technology Agnostic (Goal #7)
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. A localized mobility management solution should ideally
require minimal work to interface with a new wireless link require minimal work to interface with a new wireless link
skipping to change at page 8, line 17 skipping to change at page 8, line 22
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 wireless link technology-specific protocols needing
support for backward compatibility reasons. Within the Internet, support for backward compatibility reasons. Within the Internet,
both HIP [12] and Mobike [13] are likely to need support in both HIP [14] and Mobike [5] are likely to need support in addition
addition to Mobile IPv6, and Mobile IPv4 support may also be to Mobile IPv6, and Mobile IPv4 support may also be necessary.
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 or wireless. The mobile
node must have some kind of global mobility protocol if it is to node must have some kind of global mobility protocol if it is to
move from one domain of edge mobility support to another and move from one domain of edge mobility support to another and
maintain session continuity, although no global mobility protocol maintain session continuity, although no global mobility protocol
is required if the mobile node only moves within the coverage area is required if the mobile node only moves within the coverage area
of the localized mobility management protocol or no session of the localized mobility management protocol or no session
continuity is required during global movement. Also, every wireless continuity is required during global movement. Also, every wireless
link protocol requires handover support on the mobile node in the link protocol requires handover support on the mobile node in the
skipping to change at page 10, line 53 skipping to change at page 11, line 7
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 network-based localized mobility management protocol
Security between the mobile node and the network itself consists of Security between the mobile node and the network itself consists of
two parts: threats involved in localized mobility management in two parts: threats involved in localized mobility management in
general, and threats to the network-based localized mobility general, and threats to the network-based localized mobility
management from the host. The first is discussed above in Sections management from the host. The first is discussed above in Sections
2.3 and 2.6. The second is discussed in the threat analysis 2.3 and 2.6. The second is discussed in the threat analysis
document [2]. document [20].
For threats to network-based localized mobility management, the For threats to network-based localized mobility management, the
basic threat is an attempt by an unauthorized party to signal a basic threat is an attempt by an unauthorized party to signal a
bogus mobility event. Such an event must be detectable. This bogus mobility event. Such an event must be detectable. This
requires proper bidirectional authentication and authorization of requires proper mutual authentication and authorization of network
network elements that participate in the network-based localized elements that participate in the network-based localized mobility
mobility management protocol, and data origin authentication on the management protocol, and data origin authentication on the
signaling traffic between network elements. signaling traffic between network elements.
5.0 Acknowledgements 5.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 6.0 Author's Addresses
skipping to change at page 12, line 19 skipping to change at page 12, line 22
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 7.0 Informative References
[1] Kempf, J., editor, "Problem Statement for IP Local Mobility," [1] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Internet Draft, Work in Progress. Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based [2] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
Localized Mobillity Management", Internet draft, Work in "Design, Implementation and Evaluation of Cellular IP", IEEE
Progress. Personal Communications, June/July 2000.
[3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC [3] Carpenter, B., "Architectural Principles of the Internet,"
3753, June, 2004.
[4] Carpenter, B., "Architectural Principles of the Internet,"
RFC 1958, June, 1996. RFC 1958, June, 1996.
[5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in [4] Choi, J, and Daley, G., "Goals of Detecting Network
IPv6", RFC 3775. Attachment in IPv6", Internet Draft, Work in Progress.
[6] Choi, J, and Daley, G., "Goals of Detecting Network [5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
Attachment in IPv6", Internet Draft, work in progress. (MOBIKE)", RFC 4555, June 2006.
[6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
802.1x, June, 2001. 802.1x, June, 2001.
[8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, [8] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
A., "Protocol for Carrying Authentication for Network Access IPv6", RFC 3775.
(PANA)", Internet Draft, work in progress. [9] Kempf, J., editor, "Problem Statement for IP Local Mobility,"
[9] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[10] Moore, N., "Optimistic Neighbor Discovery", Internet Draft,
Work in Progress.
[11] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park,
S.D., and Patil, B., "Privacy for Mobile and Multi-homed
Nodes: MoMiPriv Problem Statement", Internet Draft, work in
progress.
[12] Moskowitz, R., and Nikander, P., "Host Identity Protocol
(HIP) Architecture", RFC 4423, May, 2006.
[13] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", Internet Draft, Work in Progress.
[14] Koodli, R., "IP Address Location Privacy and IP Mobility",
Internet Draft, Work in Progress. Internet Draft, Work in Progress.
[15] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., [10] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6
"Solutions for IP Address Location Privacy in the presence of Handover Key using SEND", Internet Draft, Work in Progress.
IP Mobility", Internet Draft, Work in Progress. [11] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
[16] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J.,
"Protocol for Protecting Movement of Mobile Nodes in Mobile
IPv6", Internet Draft, Work in Progress.
[17] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J.,
Levkowetz, H., Thubert, P, and Wakikawa, R. "Dual Stack
Mobile IPv6 (DSMIPv6) for Hosts and Routers", Internet Draft,
Work in Progress.
[18] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
4068, July, 2005. 4068, July, 2005.
[19] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., [12] Koodli, R., " IP Address Location Privacy and Mobile IPv6:
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC Problem Statement", Internet Draft, Work in Progress.
4140, August, 2005. [13] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
[20] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6 3753, June, 2004.
Handover Key using SEND", Internet Draft, work in progress. [14] Moskowitz, R., and Nikander, P., "Host Identity Protocol
[21] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta, (HIP) Architecture", RFC 4423, May, 2006.
[15] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta,
G., and Bournelle, J., "Handover Keys Using AAA", Internet G., and Bournelle, J., "Handover Keys Using AAA", Internet
Draft, Work in Progress. Draft, Work in Progress.
[22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
"Design, Implementation and Evaluation of Cellular IP", IEEE [16] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K.,
Personal Communications, June/July 2000.
[23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K.,
"HAWAII: A domain-based approach for supporting mobility in "HAWAII: A domain-based approach for supporting mobility in
wide-area wireless networks", in Proceedings of the wide-area wireless networks", in Proceedings of the
International Conference on Networking Protocols (ICNP), International Conference on Networking Protocols (ICNP),
1999. 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
4140, August, 2005.
[19] Vida, R., and Costa, L., " Multicast Listener Discovery
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 IPR Statements 8.0 Appendix: Gap Analysis
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9.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.
10.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
11.0 Appendix: Gap Analysis
This section discusses a gap analysis between existing proposals This section discusses a gap analysis between existing proposals
for solving localized mobility management and the goals in Section. for solving localized mobility management and the goals in Section.
2.0. 2.0.
11.1 Mobile IPv6 with Local Home Agent 8.1 Mobile IPv6 with Local Home Agent
One option is to deploy Mobile IPv6 with a locally assigned home One option is to deploy Mobile IPv6 with a locally assigned home
agent in the local network. This solution requires the mobile node agent in the local network. This solution requires the mobile node
to somehow be assigned a home agent in the local network when it 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 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 home network. The advantage of this option is that no special
solution is required for edge mobility - the mobile node reuses the solution is required for edge mobility - the mobile node reuses the
global mobility management protocol for that purpose - if the global mobility management protocol for that purpose - if the
mobile node is using Mobile IPv6. mobile node is using Mobile IPv6.
skipping to change at page 14, line 52 skipping to change at page 13, line 52
Goal #1 Handover Performance Improvement: If the mobile node does Goal #1 Handover Performance Improvement: If the mobile node does
not perform route optimization, this solution reduces, but does not not perform route optimization, this solution reduces, but does not
eliminate, IP handover related performance problems. eliminate, IP handover related performance problems.
Goal #2 Reduction in Handover-related Signaling Volume: Similarly Goal #2 Reduction in Handover-related Signaling Volume: Similarly
to Goal #1, signaling volume is reduced if no route optimization to Goal #1, signaling volume is reduced if no route optimization
signaling is done on handover. signaling is done on handover.
Goal #3 Location privacy: Location privacy is preserved for Goal #3 Location privacy: Location privacy is preserved for
external correspondents, but the mobile node itself still maintains external correspondents as long as all of the mobile node's traffic
a local care-of address. If the mobile node performs route is routed through the local HA.
optimization, location privacy may be compromised, but not
performing route optimization is no better than having a remote
home agent.
Goal #4 Efficient Use of Wireless Resources: If traffic is not Goal #4 Efficient Use of Wireless Resources: If traffic is not
route optimized, the mobile node still pays for an over-the-air route optimized, the mobile node still pays for an over-the-air
tunnel to the locally assigned home agent. The overhead here is 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 exactly the same as if the mobile node's home agent in the home
network is used and route optimization is not done. network is used and route optimization is not done.
Goal #5 Limit the Signaling Overhead in the Network: If the Goal #5 Limit the Signaling Overhead in the Network: If the
localized mobility management domain is large, the mobile node may localized mobility management domain is large, the mobile node may
suffer from unoptimzed routes. RFC 3775 [5] provides no support for suffer from unoptimzed routes. RFC 3775 [8] provides no support for
notifying a mobile node that another localized home agent is notifying a mobile node that another localized home agent is
available for a more optimized route, or for handing over between available for a more optimized route, or for handing over between
home agents. A mobile node would have to perform the full home home agents. A mobile node would have to perform the full home
agent bootstrap procedure, including establishing a new IPsec SA agent bootstrap procedure, including establishing a new IPsec SA
with the new home agent. with the new home agent.
Goal #6 No Extra Security Between Mobile Node and Network: A local Goal #6 No Extra Security Between Mobile Node and Network: A local
home agent in a roaming situation requires the guest mobile node to home agent in a roaming situation requires the guest mobile node to
have the proper credentials to authenticate with the local home have the proper credentials to authenticate with the local home
agent in the serving network. Although the credentials used for agent in the serving network. The credentials used for network
network access authentication could also be used for mobile service access authentication could also be used for mobile service
authentication and authorization if the local home agent uses EAP authentication and authorization if the local home agent uses EAP
over IKEv2 to authenticate the mobile node with its home AAA over IKEv2 to authenticate the mobile node with its home AAA
server, the two sets of credentials are in principle different, and server. This may require additional authorization between the home
could require additional credential provisioning. In addition, as and visited networks to use the same credentials for a different
in Goal #3, if binding updates are done in cleartext over the service, however. In addition, as in Goal #3, if binding updates
access network or the mobile node has become infected with malware, are done in cleartext over the access network or the mobile node
the local home agent's address could be revealed to attackers and has become infected with malware, the local home agent's address
the local home agent could become the target of a DoS attack. So a could be revealed to attackers and the local home agent could
local home agent would provide no benefit for this goal. 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 Goal #7 Support for Heterogeneous Wireless Link Technologies: This
solution supports multiple wireless technologies with separate IP solution supports multiple wireless technologies with separate IP
subnets for different links. No special work is required to subnets for different links. No special work is required to
interface a local home agent to different wireless technologies. interface a local home agent to different wireless technologies.
Goal #8 Support for Unmodified Mobile Nodes: The mobile node must Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
support Mobile IPv6 in order for this option to work. So mobile support Mobile IPv6 in order for this option to work. So mobile
node changes are required and other IP mobility protocols are not node changes are required and other IP mobility protocols are not
supported. supported.
Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is
working on modifying the protocol to allow registration of IPv4 working on modifying the protocol to allow registration of IPv4
care-of addresses in an IPv6 home agent, and also to allow a mobile care of addresses in an IPv6 home agent, and also to allow a mobile
node to have an IPv4 care of address [17]. node to have an IPv4 care of address [17].
Goal #10 Re-use of Existing Protocols Where Sensible: This solution Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, Mobile IPv6. re-uses an existing protocol, Mobile IPv6.
Goal #11 Localized Mobility Management Independent of Global Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution merges localized mobility Mobility Management: This solution merges localized mobility
management and global mobility management, so it does not support management and global mobility management, so it does not support
the goal. the goal.
11.2 Hierarchical Mobile IPv6 (HMIPv6) 8.2 Hierarchical Mobile IPv6 (HMIPv6)
HMIPv6 [19] provides the most complete localized mobility HMIPv6 [18] provides the most complete localized mobility
management solution available today. In HMIPv6, a localized management solution available today. In HMIPv6, a localized
mobility anchor called a MAP serves as a routing anchor for a mobility anchor called a MAP serves as a routing anchor for a
regional care-of address. When a mobile node moves from one access regional care of address. When a mobile node moves from one access
router to another, the mobile node changes the binding between its router to another, the mobile node changes the binding between its
regional care-of address and local care-of address at the MAP. No regional care of address and local care of address at the MAP. No
global mobility management signaling is required, since the care-of global mobility management signaling is required, since the care of
address seen by correspondents does not change. This part of HMIPv6 address seen by correspondents does not change. This part of HMIPv6
is similar to the solution outlined in Section 11.1; however, is similar to the solution outlined in Section 8.1; however, HMIPv6
HMIPv6 also allows a mobile node to hand over between MAPs. also allows a mobile node to hand over between MAPs.
Handover between MAPs and MAP discovery requires configuration on Handover between MAPs and MAP discovery requires configuration on
the routers. MAP addresses are advertised by access routers. the routers. MAP addresses are advertised by access routers.
Handover happens by overlapping MAP coverage areas so that, for Handover happens by overlapping MAP coverage areas so that, for
some number of access routers, more than one MAP may be advertised. some number of access routers, more than one MAP may be advertised.
Mobile nodes need to switch MAPs in the transition area, and then Mobile nodes need to switch MAPs in the transition area, and then
must perform global mobility management update and route must perform global mobility management update and route
optimization to the new regional care-of address, if appropriate. optimization to the new regional care of address, if appropriate.
The analysis of this approach against the goals above is the The analysis of this approach against the goals above is the
following. following.
Goal #1 Handover Performance Improvement: This solution shortens, Goal #1 Handover Performance Improvement: This solution shortens,
but does not eliminate, the latency associated with IP handover, but does not eliminate, the latency associated with IP handover,
since it reduces the amount of signaling and the length of the since it reduces the amount of signaling and the length of the
signaling paths. signaling paths.
Goal #2 Reduction in Handover-related Signaling Volume: Signaling Goal #2 Reduction in Handover-related Signaling Volume: Signaling
skipping to change at page 17, line 31 skipping to change at page 16, line 27
Goal #8 Support for Unmodified Mobile Nodes: This solution requires Goal #8 Support for Unmodified Mobile Nodes: This solution requires
modification to the mobile nodes. In addition, the HMIPv6 design modification to the mobile nodes. In addition, the HMIPv6 design
has been optimized for Mobile IPv6 mobile nodes, and is not a good has been optimized for Mobile IPv6 mobile nodes, and is not a good
match for other global mobility management protocols. match for other global mobility management protocols.
Goal #9 Currently, there is no IPv4 version of this protocol; Goal #9 Currently, there is no IPv4 version of this protocol;
although there is an expired Internet draft with a design for a although there is an expired Internet draft with a design for a
regional registration protocol for Mobile IPv4 that has similar regional registration protocol for Mobile IPv4 that has similar
functionality. It is possible that the same IPv4 transition functionality. It is possible that the same IPv4 transition
solution as used for Mobile IPv6 could be used [17]. solution as used for Mobile IPv6 could be used [17] above.
Goal #10 Re-use of Existing Protocols Where Sensible: This solution Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses an existing protocol, HMIPv6. re-uses an existing protocol, HMIPv6.
Goal #11 Localized Mobility Management Independent of Global Goal #11 Localized Mobility Management Independent of Global
Mobility Management: While HIMPv6 is technically a separate Mobility Management: While HIMPv6 is technically a separate
protocol from MIPv6 and could in principle be implemented and protocol from MIPv6 and could in principle be implemented and
deployed without MIPv6, the design is very similar and deployed without MIPv6, the design is very similar and
implementation and deployment would be easier if the mobile nodes implementation and deployment would be easier if the mobile nodes
supported MIPv6. supported MIPv6.
11.3 Combinations of Mobile IPv6 with Optimizations 8.3 Combinations of Mobile IPv6 with Optimizations
One approach to local mobility that has received much attention in One approach to local mobility that has received much attention in
the past and has been thought to provide a solution is combinations 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 of protocols. The general approach is to try to cover gaps in the
solution provided by MIPv6 by using other protocols. In this solution provided by MIPv6 by using other protocols. In this
section, gap analyses for MIPv6 + FMIPv6 and HMIPv6 + FMIPv6 are section, gap analyses for MIPv6 + FMIPv6 and HMIPv6 + FMIPv6 are
discussed. discussed.
11.3.1 MIPv6 with local home agent + FMIPv6 8.3.1 MIPv6 with local home agent + FMIPv6
As discussed in Section 11.1, the use of MIPv6 with a dynamically
As discussed in Section 8.1, the use of MIPv6 with a dynamically
assigned, local home agent cannot fulfill the goals. A fundamental assigned, local home agent cannot fulfill the goals. A fundamental
limitation is that Mobile IPv6 cannot provide seamless handover limitation is that Mobile IPv6 cannot provide seamless handover
(i.e. Goal #1). FMIPv6 [18] has been defined with the intent to (i.e. Goal #1). FMIPv6 [11] above has been defined with the intent
improve the handover performance of MIPv6. For this reason, the to improve the handover performance of MIPv6. For this reason, the
combined usage of FMIPv6 and MIPv6 with a dynamically assigned combined usage of FMIPv6 and MIPv6 with a dynamically assigned
local home agent has been proposed to handle local mobility. local home agent has been proposed to handle local mobility.
Note that this gap analysis only applies to localized mobility Note that this gap analysis only applies to localized mobility
management, and it is possible that MIPv6 and FMIPv6 might still be management, and it is possible that MIPv6 and FMIPv6 might still be
acceptable for global mobility management. acceptable for global mobility management.
The analysis of this combined approach against the goals follows. The analysis of this combined approach against the goals follows.
Goal #1 Handover Performance Improvement: FMIPv6 provides a Goal #1 Handover Performance Improvement: FMIPv6 provides a
skipping to change at page 18, line 35 skipping to change at page 17, line 30
requires the mobile node to perform extra signaling with the access requires the mobile node to perform extra signaling with the access
router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
in standard MIPv6, whenever the mobile node moves to another link, in standard MIPv6, whenever the mobile node moves to another link,
it must send a Binding Update to the home agent. If route it must send a Binding Update to the home agent. If route
optimization is used, the mobile node also performs return optimization is used, the mobile node also performs return
routability and sends a Binding Update to each correspondent node. routability and sends a Binding Update to each correspondent node.
Nonetheless, it is worth noting that FMIPv6 should result in a Nonetheless, it is worth noting that FMIPv6 should result in a
reduction of the amount of IPv6 Neighbor Discovery signaling on the reduction of the amount of IPv6 Neighbor Discovery signaling on the
new link. new link.
Goal #3 Location privacy: The mobile node mantains a local care-of Goal #3 Location privacy: The mobile node maintains a local care of
address. If route optimization is not used, location privacy can be address. If route optimization is not used, location privacy can be
achieved using bi-directional tunneling. achieved using bi-directional tunneling.
Goal #4 Use of Wireless Resources: As stated for Goal #2, the Goal #4 Use of Wireless Resources: As stated for Goal #2, the
combination of MIPv6 and FMIPv6 generates extra signaling overhead. combination of MIPv6 and FMIPv6 generates extra signaling overhead.
For data packets, in addition to the Mobile IPv6 over-the-air For data packets, in addition to the Mobile IPv6 over-the-air
tunnel, there is a further level of tunneling between the mobile tunnel, there is a further level of tunneling between the mobile
node and the previous access router during handover. This tunnel is node and the previous access router during handover. This tunnel is
needed to forward incoming packets to the mobile node addressed to needed to forward incoming packets to the mobile node addressed to
the previous care-of address. Another reason is that, even if the 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 mobile node has a valid new care of address, the mobile node cannot
use the new care of address directly with its correspondents use the new care of address directly with its correspondents
without performing route optimization to the new care of address. without performing route optimization to the new care of address.
This implies that the transient tunnel overhead is in place even This implies that the transient tunnel overhead is in place even
for route optimized traffic. for route optimized traffic.
Goal #5 Limit the Signaling Overhead in the Network: FMIPv6 Goal #5 Limit the Signaling Overhead in the Network: FMIPv6
generates extra signaling overhead between the previous access generates extra signaling overhead between the previous access
router and the new access router for the HI/HAck exchange. router and the new access router for the HI/HAck exchange.
Concerning data packets, the use of FMIPv6 for handover performance Concerning data packets, the use of FMIPv6 for handover performance
improvement implies a tunnel between the previous access router and improvement implies a tunnel between the previous access router and
the mobile node that adds some overhead in the wired network. This the mobile node that adds some overhead in the wired network. This
overhead has more impact on star topology deployments, since overhead has more impact on star topology deployments, since
packets are routed down to the old access router, then back up to 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. the aggregation router and then back down to the new access router.
Goal #6 Extra Security Between Mobile Node and Network: In addition Goal #6 Extra Security Between Mobile Node and Network: In addition
to the analysis for Mobile IPv6 with local home agent in Section to the analysis for Mobile IPv6 with local home agent in Section
11.1, FMIPv6 requires the mobile node and the previous access 8.1, FMIPv6 requires the mobile node and the previous access router
router to share a security association in order to secure FBU/FBA to share a security association in order to secure FBU/FBA
exchange. Two solutions have been proposed: a SEND-based solution exchange. Two solutions have been proposed: a SEND-based solution
[20] and an AAA-based solution [21]. Both solutions require [10] above and an AAA-based solution [15]. Both solutions require
additional support on the mobile node and in the network beyond additional support on the mobile node and in the network beyond
what is required for network access authentication. what is required for network access authentication.
Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6 Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6
and FMIPv6 support multiple wireless technologies, so this goal is and FMIPv6 support multiple wireless technologies, so this goal is
fufilled. fulfilled.
Goal #8 Support for Unmodified Mobile Nodes: The mobile node must Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
support both MIPv6 and FMIPv6, so it is not possible to satisfy support both MIPv6 and FMIPv6, so it is not possible to satisfy
this goal. this goal.
Goal #9 Support for IPv4 and IPv6: Work is underway to extend MIPv6 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 with the capability to run over both IPv6-enabled and IPv4-only
networks [17]. FMIPv6 only supports IPv6. Even though an IPv4 networks [17] above. FMIPv6 only supports IPv6. Even though an IPv4
version of FMIP has been recently proposed, it is not clear how it version of FMIP has been recently proposed, it is not clear how it
could be used together with FMIPv6 in order to handle fast could be used together with FMIPv6 in order to handle fast
handovers across any wired network. handovers across any wired network.
Goal #10 Re-use of Existing Protocols Where Sensible: This solution Goal #10 Re-use of Existing Protocols Where Sensible: This solution
re-uses existing protocols, Mobile IPv6 and FMIPv6. re-uses existing protocols, Mobile IPv6 and FMIPv6.
Goal #11 Localized Mobility Management Independent of Global Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution merges localized mobility Mobility Management: This solution merges localized mobility
management and global mobility management, so it does not support management and global mobility management, so it does not support
the goal. the goal.
11.3.2 HMIPv6 + FMIPv6 8.3.2 HMIPv6 + FMIPv6
HMIPv6 provides several advantages in terms of local mobility HMIPv6 provides several advantages in terms of local mobility
management. However, as seen in Section 11.2, it does not fulfill management. However, as seen in Section 8.2, it does not fulfill
all the goals identified in Section 2.0. In particular, HMIPv6 does all the goals identified in Section 2.0. In particular, HMIPv6 does
not completely eliminate the IP handover latency. For this reason, not completely eliminate the IP handover latency. For this reason,
FMIPv6 could be used together with HMIPv6 in order to cover the FMIPv6 could be used together with HMIPv6 in order to cover the
gap. gap.
Note that even if this solution is used, the mobile node is likely Note that even if this solution is used, the mobile node is likely
to need MIPv6 for global mobility management, in contrast with the to need MIPv6 for global mobility management, in contrast with the
MIPv6 with dynamically assigned local home agent + FMIPv6 solution. MIPv6 with dynamically assigned local home agent + FMIPv6 solution.
Thus, this solution should really be considered MIPv6 + HMIPv6 + Thus, this solution should really be considered MIPv6 + HMIPv6 +
FMIPv6. FMIPv6.
skipping to change at page 20, line 16 skipping to change at page 19, line 11
Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both
shorten the latency associated with IP handovers. In particular, shorten the latency associated with IP handovers. In particular,
FMIPv6 is expected to fulfill the goals on jitter, delay and packet FMIPv6 is expected to fulfill the goals on jitter, delay and packet
loss raised by real-time applications. loss raised by real-time applications.
Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6 Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6
and HMIPv6 require extra signaling compared with Mobile IPv6. As a and HMIPv6 require extra signaling compared with Mobile IPv6. As a
whole the mobile node performs signaling message exchanges at each whole the mobile node performs signaling message exchanges at each
handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA.
However, as mentioned in Section 11.2, the use of HMIPv6 reduces However, as mentioned in Section 8.2, the use of HMIPv6 reduces the
the signaling overhead since no route optimization signaling is signaling overhead since no route optimization signaling is done
done for intra-MAP handovers. In addition, naive combinations of for intra-MAP handovers. In addition, naive combinations of FMIPv6
FMIPv6 and HMIPv6 often result in redundant signaling. There is and HMIPv6 often result in redundant signaling. There is much work
much work in the academic literature and the IETF on more refined in the academic literature and the IETF on more refined ways of
ways of combining signaling from the two protocols to avoid combining signaling from the two protocols to avoid redundant
redundant signaling. signaling.
Goal #3 Location privacy: HMIPv6 may preserve location privacy, Goal #3 Location privacy: HMIPv6 may preserve location privacy,
depending on the dimension of the geographic area covered by the depending on the dimension of the geographic area covered by the
MAP. MAP.
Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the
combination of HMIPv6 and FMIPv6 generates a lot of signaling combination of HMIPv6 and FMIPv6 generates a lot of signaling
overhead in the network. Concerning payload data, in addition to overhead in the network. Concerning payload data, in addition to
the over-the-air MIPv6 tunnel, a further level of tunneling is the over-the-air MIPv6 tunnel, a further level of tunneling is
established between mobile node and MAP. Notice that this tunnel is established between mobile node and MAP. Notice that this tunnel is
in place even for route optimized traffic. Moreover, if FMIPv6 is in place even for route optimized traffic. Moreover, if FMIPv6 is
directly applied to HMIPv6 networks, there is a third temporary directly applied to HMIPv6 networks, there is a third temporary
handover-related tunnel between the mobile node and previous access handover-related tunnel between the mobile node and previous access
router. Again, there is much work in the academic literature and router. Again, there is much work in the academic literature and
IETF on ways to reduce the extra tunnel overhead on handover by IETF on ways to reduce the extra tunnel overhead on handover by
combining HMIP and FMIP tunneling. combining HMIP and FMIP tunneling.
Goal #5 Limit the Signaling Overhead in the Network: The signaling Goal #5 Limit the Signaling Overhead in the Network: The signaling
overhead in the network is not reduced by HMIPv6, as mentioned in overhead in the network is not reduced by HMIPv6, as mentioned in
Section 11.2. Instead, FMIPv6 generates extra signaling overhead Section 8.2. Instead, FMIPv6 generates extra signaling overhead
between the previous access router and new access router for between the previous access router and new access router for
HI/HAck exchange. For payload data, the same considerations as for HI/HAck exchange. For payload data, the same considerations as for
Goal #4 are applicable. Goal #4 are applicable.
Goal #6 Security Between Mobile Node and Network: FMIPv6 requires Goal #6 Security Between Mobile Node and Network: FMIPv6 requires
the mobile node and the previous access router to share a security the mobile node and the previous access router to share a security
association in order to secure the FBU/FBA exchange. In addition, association in order to secure the FBU/FBA exchange. In addition,
HMIPv6 requires that the mobile node and MAP share an IPsec HMIPv6 requires that the mobile node and MAP share an IPsec
security association in order to secure LBU/LBA exchange. The only security association in order to secure LBU/LBA exchange. The only
well understood approach to set up an IPsec security association is well understood approach to set up an IPsec security association is
skipping to change at page 21, line 30 skipping to change at page 20, line 24
Goal #10 Re-use of Existing Protocols Where Sensible: This Goal #10 Re-use of Existing Protocols Where Sensible: This
solution re-uses existing protocols, HMIPv6 and FMIPv6. solution re-uses existing protocols, HMIPv6 and FMIPv6.
Goal #11 Localized Mobility Management Independent of Global Goal #11 Localized Mobility Management Independent of Global
Mobility Management: While HIMPv6 is technically a separate Mobility Management: While HIMPv6 is technically a separate
protocol from MIPv6 and could in principle be implemented and protocol from MIPv6 and could in principle be implemented and
deployed without MIPv6, the design is very similar and deployed without MIPv6, the design is very similar and
implementation and deployment would be easier if the mobile nodes implementation and deployment would be easier if the mobile nodes
supported MIPv6. supported MIPv6.
11.4 Micromobility Protocols 8.4 Micromobility Protocols
Researchers have defined some protocols that are often Researchers have defined some protocols that are often
characterized as micromobility protocols. Two typical protocols in characterized as micromobility protocols. Two typical protocols in
this category are Cellular-IP [22] and HAWAII [23]. Researchers this category are Cellular-IP [2] and HAWAII [16]. Researchers
defined these protocols before local mobility optimizations for defined these protocols before local mobility optimizations for
Mobile IP such as FMIP and HMIP were developed, in order to reduce Mobile IP such as FMIP and HMIP were developed, in order to reduce
handover latency. Cellular-IP and HAWAII were proposed in the IETF handover latency. Cellular-IP and HAWAII were proposed in the IETF
for standardization, but after some study in the IRTF, were for standardization, but after some study in the IRTF, were
dropped. There are many micromobility protocols defined in the dropped. There are many micromobility protocols defined in the
academic literature, but in this document, the term is used academic literature, but in this document, the term is used
specifically to refer to Cellular-IP and HAWAII. specifically to refer to Cellular-IP and HAWAII.
The micromobility approach to localized mobility management The micromobility approach to localized mobility management
requires host route propagation from the mobile node to a requires host route propagation from the mobile node to a
skipping to change at page 22, line 22 skipping to change at page 21, line 15
messaging is to be used to update the routing tables and forwarding messaging is to be used to update the routing tables and forwarding
tables along the path between the mobile and a micromobility domain tables along the path between the mobile and a micromobility domain
boundary router at which point Mobile IP is to used to handle boundary router at which point Mobile IP is to used to handle
global mobility in a scalable way. Unlike the FMIP and HMIP global mobility in a scalable way. Unlike the FMIP and HMIP
protocols, however, these protocols do not require the mobile node protocols, however, these protocols do not require the mobile node
to obtain a new care of address on each access router as it moves; 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 but rather, the mobile node maintains the same care of address
across the micromobility domain. From outside the micromobility across the micromobility domain. From outside the micromobility
domain, the care of address is routed using traditional longest domain, the care of address is routed using traditional longest
prefix matching IP routing to the domain's boundary router, so the prefix matching IP routing to the domain's boundary router, so the
care of address conceptually is within the micromobiity domain care of address is conceptually withain the micromobility domain
boundary router's subnet. Within the micromobility domain, the care boundary router's subnet. Within the micromobility domain, the care
of address is routed to the correct access router using host of address is routed to the correct access router using host
routes. routes.
Micromobility protocols have some potential drawbacks from a Micromobility protocols have some potential drawbacks from a
deployment and scalability standpoint. Both protocols involve every deployment and scalability standpoint. Both protocols involve every
routing element between the mobile device and the micromobility routing element between the mobile device and the micromobility
domain boundary router in all packet forwarding decisions specific domain boundary router in all packet forwarding decisions specific
to care of addresses for mobile nodes. Scalability is limited to care of addresses for mobile nodes. Scalability is limited
because each care of address corresponding to a mobile node because each care of address corresponding to a mobile node
skipping to change at page 23, line 5 skipping to change at page 21, line 51
between the boundary router and the access router. While some between the boundary router and the access router. While some
additional latency may be expected during host route propagation, additional latency may be expected during host route propagation,
it is typically much less than experienced with standard Mobile IP. it is typically much less than experienced with standard Mobile IP.
Goal #2 Reduction in Handover-related Signaling Volume: The Goal #2 Reduction in Handover-related Signaling Volume: The
micromobility protocols require signaling from the mobile node to micromobility protocols require signaling from the mobile node to
the access router to initiate the host route propagation, but that the access router to initiate the host route propagation, but that
is a considerable reduction over the amount of signaling required is a considerable reduction over the amount of signaling required
to configure to a new link. to configure to a new link.
Goal #3 Location privacy: No care-of address changes are exposed to Goal #3 Location privacy: No care of address changes are exposed to
correspondent nodes or the mobile node itself while the mobile node correspondent nodes or the mobile node itself while the mobile node
is moving in the micromobility-managed network. is moving in the micromobility-managed network.
Goal #4 Use of Wireless Resources: The only additional over-the-air Goal #4 Use of Wireless Resources: The only additional over-the-air
signaling is involved in propagating host routes from the mobile signaling is involved in propagating host routes from the mobile
node to the network upon movement. Since this signaling would be node to the network upon movement. Since this signaling would be
required for movement detection in any case, it is expected to be required for movement detection in any case, it is expected to be
minimal. Mobile node traffic experiences no overhead. minimal. Mobile node traffic experiences no overhead.
Goal #5 Limit the Signaling Overhead in the Network: Host route Goal #5 Limit the Signaling Overhead in the Network: Host route
propagation is required throughout the wired network. The volume of propagation is required throughout the wired network. The volume of
signaling could be more or less depending on the speed of mobile signaling could be more or less depending on the speed of mobile
node movement and the size of the wired network. node movement and the size of the wired network.
Goal #6 Security Between Mobile Node and Network: The mobile node Goal #6 Security Between Mobile Node and Network: The mobile node
only requires a security association of some type with the access only requires a security association of some type with the access
router. Because the signaling is causing routes to the mobile router. Because the signaling is causing routes to the mobile
node's care-of address to change, the signaling must prove node's care of address to change, the signaling must prove
authorization to hold the address. authorization to hold the address.
Goal #7 Support for Heterogeneous Wireless Link Technologies: Goal #7 Support for Heterogeneous Wireless Link Technologies:
HMIPv6 The micromobility protocols support multiple wireless HMIPv6 The micromobility protocols support multiple wireless
technologies, so this goal is satisfied. technologies, so this goal is satisfied.
Goal #8 Support for Unmodified Mobile Nodes: The mobile node must Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
support some way of signaling the access router on link handover, support some way of signaling the access router on link handover,
but this is required for movement detection anyway. The nature of but this is required for movement detection anyway. The nature of
the signaling for the micromobility protocols may require mobile the signaling for the micromobility protocols may require mobile
skipping to change at page 23, line 48 skipping to change at page 22, line 44
done in IPv4, but little difference could be expected for IPv6. done in IPv4, but little difference could be expected for IPv6.
Goal #10 This solution does not reuse an existing protocol because Goal #10 This solution does not reuse an existing protocol because
there is currently no Internet Standard protocol for micromobility. there is currently no Internet Standard protocol for micromobility.
Goal #11 Localized Mobility Management Independent of Global Goal #11 Localized Mobility Management Independent of Global
Mobility Management: This solution separates global and local Mobility Management: This solution separates global and local
mobility management, since the micromobility protocols only support mobility management, since the micromobility protocols only support
localized mobility management. localized mobility management.
11.5 Summary 8.5 Summary
The following table summarizes the discussion in Section 9.1 The following table summarizes the discussion in Section 9.1
through 9.5. In the table, a "M" indicates that the protocol through 9.5. In the table, a "M" indicates that the protocol
completely meets the goal, a "P" indicates that it partially meets completely meets the goal, a "P" indicates that it partially meets
the goal, and an "X" indicates that it does not meet the goal. the goal, and an "X" indicates that it does not meet the goal.
Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
-------- -- -- -- -- -- -- -- -- -- --- -------- -- -- -- -- -- -- -- -- -- ---
MIPv6 P X X X X X M X M M MIPv6 P X X X X X M X M M
skipping to change at page 24, line 9 skipping to change at page 23, line 4
The following table summarizes the discussion in Section 9.1 The following table summarizes the discussion in Section 9.1
through 9.5. In the table, a "M" indicates that the protocol through 9.5. In the table, a "M" indicates that the protocol
completely meets the goal, a "P" indicates that it partially meets completely meets the goal, a "P" indicates that it partially meets
the goal, and an "X" indicates that it does not meet the goal. the goal, and an "X" indicates that it does not meet the goal.
Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
-------- -- -- -- -- -- -- -- -- -- --- -------- -- -- -- -- -- -- -- -- -- ---
MIPv6 P X X X X X M X M M MIPv6 P X X X X X M X M M
HMIPv6 P X X X P X M X X M HMIPv6 P X X X P X M X X M
MIPv6 + MIPv6 +
FMIPv6 M X X X P X M X P M FMIPv6 M X X X P X M X P M
HMIPv6 + HMIPv6 +
FMIPv6 M X X X X X M X X M FMIPv6 M X X X X X M X X M
Micro. M M M M P M M M P X Micro. M M M M P M M M P X
9.0 IPR Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10.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.
11.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
 End of changes. 66 change blocks. 
223 lines changed or deleted 170 lines changed or added

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