draft-ietf-netlmm-nohost-req-02.txt   draft-ietf-netlmm-nohost-req-03.txt 
Internet Draft J. Kempf, Internet Draft J. Kempf,
Editor Editor
Document: draft-ietf-netlmm-nohost-req-02.txt Document: draft-ietf-netlmm-nohost-req-03.txt
Expires: December, 2006 June, 2006 Expires: December, 2006 June, 2006
Goals for Network-based Localized Mobility Management (NETLMM) Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-02.txt) (draft-ietf-netlmm-nohost-req-03.txt)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 50 skipping to change at page 1, line 50
names are not included in the authors' section due to the RFC names are not included in the authors' section due to the RFC
Editor's limit of 5 names. Editor's limit of 5 names.
Abstract Abstract
In this document, design goals for a network-based localized In this document, design goals for a network-based localized
mobility management protocol are discussed. mobility management protocol are discussed.
Table of Contents Table of Contents
1.0 Introduction.............................................2 1.0 Introduction............................................2
2.0 Goals for Localized Mobility Management..................2 2.0 Goals for Localized Mobility Management.................2
3.0 IANA Considerations.....................................10 3.0 IANA Considerations....................................10
4.0 Security Considerations.................................10 4.0 Security Considerations................................10
5.0 Author's Addresses......................................11 5.0 Acknowledgements.......................................11
6.0 Informative References..................................12 6.0 Author's Addresses.....................................11
7.0 IPR Statements..........................................13 7.0 Informative References.................................12
8.0 Disclaimer of Validity..................................13 8.0 IPR Statements.........................................13
9.0 Copyright Notice........................................14 9.0 Disclaimer of Validity.................................14
10.0 Appendix: Gap Analysis..................................14 10.0 Copyright Notice.......................................14
11.0 Appendix: Gap Analysis.................................14
1.0 Introduction 1.0 Introduction
In [1], the basic problems that occur when a global mobility In [1], the basic problems that occur when a global mobility
protocol is used for managing local mobility are described, and two protocol is used for managing local mobility are described, and two
basic approaches to localized mobility management - the host-based 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
skipping to change at page 7, line 31 skipping to change at page 7, line 31
management to a mobile node, it can do so at the time network management to a mobile node, it can do so at the time network
access authentication occurs, in a manner the reverse of how some access authentication occurs, in a manner the reverse of how some
networks restrict routing to the Internet before network access networks restrict routing to the Internet before network access
authentication and open it afterwards. 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 [9]).
2.7 Support for Heterogeneous Wireless Link Technologies (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
technology. technology.
skipping to change at page 11, line 13 skipping to change at page 11, line 13
document [2]. document [2].
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 bidirectional authentication and authorization of
network elements that participate in the network-based localized network elements that participate in the network-based localized
mobility management protocol, and data origin authentication on the mobility management protocol, and data origin authentication on the
signaling traffic between network elements. signaling traffic between network elements.
5.0 Author's Addresses 5.0 Acknowledgements
The authors would like to acknowledge the following for
particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin.
6.0 Author's Addresses
James Kempf James Kempf
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: +1 408 451 4711 Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
Kent Leung Kent Leung
skipping to change at page 12, line 9 skipping to change at page 12, line 17
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
6.0 Informative References 7.0 Informative References
[1] Kempf, J., editor, "Problem Statement for IP Local Mobility," [1] Kempf, J., editor, "Problem Statement for IP Local Mobility,"
Internet Draft, Work in Progress. Internet Draft, Work in Progress.
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based [2] Vogt, C., and Kempf, J., "Security Threats to Network-based
Localized Mobillity Management", Internet draft, Work in Localized Mobillity Management", Internet draft, Work in
Progress. Progress.
[3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC [3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004. 3753, June, 2004.
[4] Carpenter, B., "Architectural Principles of the Internet," [4] Carpenter, B., "Architectural Principles of the Internet,"
RFC 1958, June, 1996. RFC 1958, June, 1996.
skipping to change at page 13, line 22 skipping to change at page 13, line 31
Draft, Work in Progress. Draft, Work in Progress.
[22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
"Design, Implementation and Evaluation of Cellular IP", IEEE "Design, Implementation and Evaluation of Cellular IP", IEEE
Personal Communications, June/July 2000. Personal Communications, June/July 2000.
[23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., [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.
7.0 IPR Statements 8.0 IPR Statements
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 13, line 46 skipping to change at page 14, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
8.0 Disclaimer of Validity 9.0 Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
9.0 Copyright Notice 10.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
10.0 Appendix: Gap Analysis 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.
10.1 Mobile IPv6 with Local Home Agent 11.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 15, line 49 skipping to change at page 16, line 10
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.
10.2 Hierarchical Mobile IPv6 (HMIPv6) 11.2 Hierarchical Mobile IPv6 (HMIPv6)
HMIPv6 [19] provides the most complete localized mobility HMIPv6 [19] 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 10.1; however, is similar to the solution outlined in Section 11.1; however,
HMIPv6 also allows a mobile node to hand over between MAPs. HMIPv6 also allows a mobile node to hand over between MAPs.
Handover between MAPs and MAP discovery requires configuration on 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.
skipping to change at page 17, line 32 skipping to change at page 17, line 43
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.
10.3 Combinations of Mobile IPv6 with Optimizations 11.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.
10.3.1 MIPv6 with local home agent + FMIPv6 11.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 10.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 [18] has been defined with the intent to
improve the handover performance of MIPv6. For this reason, the 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.
skipping to change at page 18, line 53 skipping to change at page 19, line 12
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
10.1, FMIPv6 requires the mobile node and the previous access 11.1, FMIPv6 requires the mobile node and the previous access
router to share a security association in order to secure FBU/FBA router 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 [20] and an AAA-based solution [21]. 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. fufilled.
skipping to change at page 19, line 30 skipping to change at page 19, line 42
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.
10.3.2 HMIPv6 + FMIPv6 11.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 10.2, it does not fulfill management. However, as seen in Section 11.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 4 skipping to change at page 20, line 16
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 10.2, the use of HMIPv6 reduces
the signaling overhead since no route optimization signaling is the signaling overhead since no route optimization signaling is
done for intra-MAP handovers. In addition, naive combinations of done for intra-MAP handovers. In addition, naive combinations of
FMIPv6 and HMIPv6 often result in redundant signaling. There is FMIPv6 and HMIPv6 often result in redundant signaling. There is
much work in the academic literature and the IETF on more refined much work in the academic literature and the IETF on more refined
ways of combining signaling from the two protocols to avoid ways of combining signaling from the two protocols to avoid
redundant signaling. redundant 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.
skipping to change at page 20, line 31 skipping to change at page 20, line 42
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 10.2. Instead, FMIPv6 generates extra signaling overhead Section 11.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 17 skipping to change at page 21, line 30
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.
10.4 Micromobility Protocols 11.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 [22] and HAWAII [23]. 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
skipping to change at page 23, line 35 skipping to change at page 23, line 48
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.
10.5 Summary 11.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
 End of changes. 22 change blocks. 
34 lines changed or deleted 40 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/