idnits 2.17.1 draft-ietf-netlmm-nohost-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 70 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 23 has weird spacing: '... months and ...' == Line 28 has weird spacing: '... The list ...' == Line 70 has weird spacing: '... mobile node ...' == Line 75 has weird spacing: '...s, and also ...' == Line 114 has weird spacing: '...agement probl...' == (65 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '12') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '18') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '19') (Obsoleted by RFC 5380) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Kempf, 2 Editor 3 Document: draft-ietf-netlmm-nohost-req-02.txt 5 Expires: December, 2006 June, 2006 7 Goals for Network-based Localized Mobility Management (NETLMM) 8 (draft-ietf-netlmm-nohost-req-02.txt) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Contributors 36 Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and 37 Marco Liebsch all contributed major effort to this document. Their 38 names are not included in the authors' section due to the RFC 39 Editor's limit of 5 names. 41 Abstract 43 In this document, design goals for a network-based localized 44 mobility management protocol are discussed. 46 Table of Contents 48 1.0 Introduction.............................................2 49 2.0 Goals for Localized Mobility Management..................2 50 3.0 IANA Considerations.....................................10 51 4.0 Security Considerations.................................10 52 5.0 Author's Addresses......................................11 53 6.0 Informative References..................................12 54 7.0 IPR Statements..........................................13 55 8.0 Disclaimer of Validity..................................13 56 9.0 Copyright Notice........................................14 57 10.0 Appendix: Gap Analysis..................................14 59 1.0 Introduction 61 In [1], the basic problems that occur when a global mobility 62 protocol is used for managing local mobility are described, and two 63 basic approaches to localized mobility management - the host-based 64 approach that is used by most IETF protocols, and the proprietary 65 WLAN switch approach used between WLAN switches in different 66 subnets - are examined. The conclusion from the problem statement 67 document is that none of the approaches has a complete solution to 68 the problem. While the WLAN switch approach is most convenient for 69 network operators and users because it requires no software on the 70 mobile node other than the standard drivers for WiFi, the 71 proprietary nature limits interoperability and the restriction to a 72 single wireless link type and wired backhaul link type restricts 73 scalablity. The IETF host-based protocols require host software 74 stack changes that may not be compatible with all global mobility 75 protocols, and also require specialized and complex security 76 transactions with the network that may limit deployability. The use 77 of an IGP to distribute host routes has scalability and deployment 78 limitations. 80 This document develops more detailed goals for a network-based 81 localized mobility management protocol. In Section 2.0, we review a 82 list of goals that are desirable in a network-based localized 83 mobility management solution. Section 3.0 briefly outlines security 84 considerations. More discussion of security can be found in the 85 threat analysis document [2]. The architecture of the NETLMM 86 protocol for which the goals in this document have been formulated 87 is described in Section 4 of [1]. 89 1.1 Terminology 91 Mobility terminology in this draft follows that in RFC 3753 [3] and 92 in [1]. 94 2.0 Goals for Localized Mobility Management 96 Section 2 of [1] describes three problems with using a global 97 mobility management protocol for localized mobility management. Any 98 localized mobility management protocol must naturally address these 99 three problems. In addition, the side effects of introducing such a 100 solution into the network need to be limited. In this section, we 101 address goals on a localized mobility solution including both 102 solving the basic problems (Goals 1, 2, 3) and limiting the side 103 effects (Goals 4+). 105 Some basic goals of all IETF protocols are not discussed in detail 106 here, but any solution is expected to satisfy them. These goals are 107 fault tolerance, robustness, interoperability, scalability, and 108 minimal specialized network equipment. A good discussion of their 109 applicability to IETF protocols can be found in [4]. 111 Out of scope for the initial goals discussion are QoS, multicast, 112 and dormant mode/paging. While these are important functions for 113 mobile nodes, they are not part of the base localized mobility 114 management problem. In addition, mobility between localized 115 mobility management domains is not covered here. It is assumed that 116 this is covered by the global mobility management protocols. 118 2.1 Handover Performance Improvement (Goal #1) 120 Handover packet loss occurs because there is usually latency 121 between when the wireless link handover starts and when the IP 122 subnet configuration and global mobility management signaling 123 completes. During this time the mobile node is unreachable at its 124 former topological location on the old link where correspondents 125 are sending packets and to which they are being forwarded. Such 126 misrouted packets are dropped. This aspect of handover performance 127 optimization has been the subject of an enormous amount of work, 128 both in other SDOs, to reduce the latency of wireless link 129 handover, in the IETF and elsewhere, to reduce the latency in IP 130 handover. Many solutions to this problem have been proposed at the 131 wireless link layer and at the IP layer. One aspect of this goal 132 for localized mobility management is that the processing delay for 133 changing the forwarding after handover must approach as closely as 134 possible the sum of the delay associated with link layer handover 135 and the delay required for active IP layer movement detection, in 136 order to avoid excessive packet loss. Ideally, if network-side link 137 layer support is available for handling movement detection prior to 138 link handover or as part of the link handover process, the routing 139 update should complete within the time required for wireless link 140 handover. This delay is difficult to quantify, but for voice 141 traffic, the entire handover delay including Layer 2 handover time 142 and IP handover time should be between 40-70 ms to avoid any 143 degradation in call quality. 145 A goal of the protocol is to reduce the loss of accurate forwarding 146 to reduce interruptions which may cause user-perceptible service 147 degradation for real time traffic such as voice. 149 2.2 Reduction in Handover-related Signaling Volume (Goal #2) 151 Considering Mobile IPv6 as the global mobility protocol (other 152 mobility protocols require about the same or somewhat less), if a 153 mobile node is required to reconfigure on every move between links, 154 the following signaling must be performed: 156 1) Movement detection using DNA [6] or possibly a link specific 157 protocol, 158 2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or 159 PANA [8]. The mobile node may also or instead have to obtain a 160 router authorization certificate using SEND [9], if the 161 certificate is not already cached, 162 3) Router discovery which may be part of movement detection, 163 4) If stateless address autoconfiguration is used, address 164 configuration and Duplicate Address Detection (unless optimistic 165 Duplicate Address Detection [10] is used) including for link 166 local addresses. If stateful address configuration is used, then 167 DHCP is used for address configuration, 168 5) Binding Update to the home agent, 169 6) If route optimization is in effect, return routability to 170 establish the binding key, 171 7) Binding Update to correspondent nodes for route optimization. 173 Note that Steps 1-2 will always be necessary, even for intra-link 174 mobility. Step 3 will be necessary even if the mobile node's care- 175 of address can remain the same when it moves to a new access 176 router. Steps 5 through 7 are only necessary when Mobile IPv6 is 177 used. 179 The result is approximately 10 messages at the IP level before a 180 mobile node can be ensured that it is established on a link and has 181 full IP connectivity. Furthermore, in some cases, the mobile node 182 may need to engage in "heartbeat signaling" to keep the connection 183 with the correspondent or global mobility anchor fresh, for 184 example, return routability in Mobile IPv6 must be done at a 185 maximum every 7 minutes even if the mobile node is standing still. 187 The goal is that handover signaling volume from the mobile node to 188 the network should be no more than what is needed for the mobile 189 node to perform secure IP level movement detection, in cases where 190 no link layer support exists. If link layer support exists for IP 191 level movement detection, the mobile node may not need to perform 192 any additional IP level signaling after handover. 194 2.3 Location privacy (Goal #3) 196 Although general location privacy issues have been discussed in 197 [11], the location privacy referred to here focuses on the IP 198 layer. In most wireless IP network deployments, different IP 199 subnets are used to cover different geographical areas. It is 200 therefore possible to derive a topological to geographical map, in 201 which particular IPv6 subnet prefixes are mapped to particular 202 geographical locations. The precision of the map depends on the 203 size of the geographic area covered by a particular subnet: if the 204 area is large, then knowing the subnet prefix won't provide much 205 information about the precise geographical location of a mobile 206 node within the subnet. 208 When a mobile node moves geographically, it also moves 209 topologically between subnets. In order to maintain routability, 210 the mobile node must change its local IP address when it moves 211 between subnets. A correspondent node or eavesdropper can use the 212 topological to geographical map to deduce in real time where a 213 mobile node - and therefore its user - is located. Depending on how 214 precisely the geographical location can be deduced, this 215 information could be used to compromise the privacy or even cause 216 harm to the user. The geographical location information should not 217 be revealed to nor be deducible by the correspondent node or an 218 eavesdropper without the authorization of 219 the mobile node's owner. 221 The threats to location privacy come in a variety of forms. One is 222 a man in the middle attack in which traffic between a correspondent 223 and the mobile node is intercepted and the mobile node's location 224 is deduced from that. Others are attacks in which the correspondent 225 itself is the attacker, and the correspondent deliberately starts a 226 session with the mobile node in order to track its location by 227 noting the source address of packets originating from the mobile 228 node. Note that the location privacy referred to here is different 229 from the location privacy discussed in [14][15][16]. The location 230 privacy discussed in these drafts primarily concerns modifications 231 to the Mobile IPv6 protocol to eliminate places where an 232 eavesdropper could track the mobile node's movement by correlating 233 home address and care of address. 235 In order to reduce the risk from location privacy compromises as a 236 result of IP address changes, the goal for NETLMM is to remove the 237 need to change IP address as mobile node moves across links. 238 Keeping the IP address fixed removes any possibility for the 239 correspondent node to deduce the precise geographic location of the 240 mobile node without the user's authorization. Note that keeping the 241 address constant doesn't completely remove the possibility of 242 deducing the geographical location, since a local address still is 243 required. However, it does allow the network to be deployed such 244 that the mapping between the geographic and topological location is 245 considerably less precise. If the mapping is not precise, an 246 attacker can only deduce in real time that the mobile node is 247 somewhere in a large geographic area, like, for example, a 248 metropolitan region or even a small country, reducing reducing the 249 granularity of the location information. 251 2.4 Efficient Use of Wireless Resources (Goal #4) 253 Advances in wireless physical layer and medium access control layer 254 technology continue to increase the bandwidth available from 255 limited wireless spectrum, but even with technology increases, 256 wireless spectrum remains a limited resource. Unlike wired network 257 links, wireless links are constrained in the number of bits/Hertz 258 by their coding technology and use of physical spectrum, which is 259 fixed by the physical layer. It is not possible to lay an extra 260 cable if the link becomes increasingly congested as is the case 261 with wired links. 263 While header compression technology can remove header overhead, it 264 does not come without cost. Requiring header compression on the 265 wireless access points increases the cost and complexity of the 266 access points, and increases the amount of processing required for 267 traffic across the wireless link. Header compression also requires 268 special software on the host, which may or may not be present. 269 Since the access points tend to be a critical bottleneck in 270 wireless access networks for real time traffic (especially on the 271 downlink), reducing the amount of per-packet processing is 272 important. While header compression probably cannot be completely 273 eliminated, especially for real time media traffic, simplifying 274 compression to reduce processing cost is an important goal. 276 The goal is that the localized mobility management protocol should 277 not introduce any new signaling or increase existing signaling over 278 the air. 280 2.5 Limit the Signaling Overhead in the Network (Goal #5) 282 While bandwidth and router processing resources are typically not 283 as constrained in the wired network, access networks tend to have 284 somewhat stronger bandwidth and router processing constraints than 285 the backbone. These constraints are a function of the cost of 286 laying fiber or wiring to the wireless access points in a widely 287 dispersed geographic area. Therefore, any solutions for localized 288 mobility management should minimize signaling within the wired 289 network as well. 291 2.6 No Extra Security Between Mobile Node and Network (Goal #6) 293 Localized mobility management protocols that have signaling between 294 the mobile node and network require a security association between 295 the mobile node and the network entity that is the target of the 296 signaling. Establishing a security association specifically for 297 localized mobility service in a roaming situation may prove 298 difficult, because provisioning a mobile node with security 299 credentials for authenticating and authorizing localized mobility 300 service in each roaming partner's network may be unrealistic from a 301 deployment perspective. Reducing the complexity of mobile node to 302 network security for localized mobility management can therefore 303 reduce barriers to deployment. 305 If the access router deduces mobile node movement based on active 306 IP-level movement detection by the mobile node, then authentication 307 is required for the IP-level movement detection messages from the 308 mobile node to ensure that the mobile node is authorized to possess 309 the address used for the movement detection. The authorization may 310 be at the IP level or it may be tied to the original network access 311 authentication and wireless link layer authorization for handover. 312 Some wireless link layers, especially cellular protocols, feature 313 full support and strong security for handover at the link level, 314 and require no IP support for handover. If such wireless link 315 security is not available, however, then it must be provided at the 316 IP level. Security threats to the NETLMM protocol are discussed in 317 [2]. 319 In summary, ruling out mobile node involvement in local mobility 320 management simplifies security by removing the need for service- 321 specific credentials to authenticate and authorize the mobile node 322 for localized mobility management in the network. This puts 323 localized mobility management on the same level as basic IP 324 routing. Hosts obtain this service as part of their network access. 325 If the access network policy wants to deny localized mobility 326 management to a mobile node, it can do so at the time network 327 access authentication occurs, in a manner the reverse of how some 328 networks restrict routing to the Internet before network access 329 authentication and open it afterwards. 331 The goal is that support for localized mobility management should 332 not require security between the mobile node and the network other 333 than that required for network access or local link security (such 334 as SEND [9]). 336 2.7 Support for Heterogeneous Wireless Link Technologies (Goal #7) 338 The number of wireless link technologies available is growing, and 339 the growth seems unlikely to slow down. Since the standardization 340 of a wireless link physical and medium access control layers is a 341 time consuming process, reducing the amount of work necessary to 342 interface a particular wireless link technology to an IP network is 343 necessary. A localized mobility management solution should ideally 344 require minimal work to interface with a new wireless link 345 technology. 347 In addition, an edge mobility solution should provide support for 348 multiple wireless link technologies. It is not required that the 349 localized mobility management solution support handover from one 350 wireless link technology to another without change in IP address, 351 but this possibility should not be precluded. 353 The goal is that the localized mobility management protocol should 354 not use any wireless link specific information for basic routing 355 management, though it may be used for other purposes, such as 356 identifying a mobile node. 358 2.8 Support for Unmodified Mobile Nodes (Goal #8) 359 In the wireless LAN switching market, no modification of the 360 software on the mobile node is required to achieve localized 361 mobility management. Being able to accommodate unmodified mobile 362 nodes enables a service provider to offer service to as many 363 customers as possible, the only constraint being that the customer 364 is authorized for network access. 366 Another advantage of minimizing mobile node software for localized 367 mobility management is that multiple global mobility management 368 protocols can be supported. There are a variety of global mobility 369 management protocols that might also need support, including 370 proprietary or wireless link technology-specific protocols needing 371 support for backward compatibility reasons. Within the Internet, 372 both HIP [12] and Mobike [13] are likely to need support in 373 addition to Mobile IPv6, and Mobile IPv4 support may also be 374 necessary. 376 Note that this goal does NOT mean that the mobile node has no 377 software at all associated with mobility or wireless. The mobile 378 node must have some kind of global mobility protocol if it is to 379 move from one domain of edge mobility support to another and 380 maintain session continuity, although no global mobility protocol 381 is required if the mobile node only moves within the coverage area 382 of the localized mobility management protocol or no session 383 continuity is required during global movement. Also, every wireless 384 link protocol requires handover support on the mobile node in the 385 physical and medium access control layers, typically in the 386 wireless interface driver. Information passed from the medium 387 access control layer to the IP layer on the mobile node may be 388 necessary to trigger IP signaling for IP handover. Such movement 389 detection support at the IP level may be required in order to 390 determine whether the mobile node's default router is still 391 reachable after the move to a new access point has occurred at the 392 medium access control layer. Whether or not such support is 393 required depends on whether the medium access control layer can 394 completely hide link movement from the IP layer. For a wireless 395 link protocol such as the 3G protocols, the mobile node and network 396 undergo an extensive negotiation at the medium access control layer 397 prior to handover, so it may be possible to trigger routing update 398 without any IP protocol involvement. However, for a wireless link 399 protocol such as IEEE 802.11 in which the decision for handover is 400 entirely in the hands of the mobile node, IP layer movement 401 detection signaling from the mobile node may be required to trigger 402 a routing update. 404 The goal is that the localized mobility management solution should 405 be able to support any mobile node that joins the link and that has 406 a wireless interface that can communicate with the network, without 407 requiring localized mobility management software on the mobile 408 node. 410 2.9 Support for IPv4 and IPv6 (Goal #9) 412 While most of this document is written with IPv6 in mind, localized 413 mobility management is a problem in IPv4 networks as well. A 414 solution for localized mobility that works for both versions of IP 415 is desirable, though the actual protocol may be slightly different 416 due to the technical details of how each IP version works. From 417 Goal #8 (Section 2.8), minimizing mobile node support for localized 418 mobility means that ideally no IP version-specific changes would be 419 required on the mobile node for localized mobility, and that global 420 mobility protocols for both IPv4 and IPv6 should be supported. Any 421 IP version-specific features would be confined to the network 422 protocol. 424 2.10 Re-use of Existing Protocols Where Sensible (Goal #10) 426 Many existing protocols are available as Internet Standards upon 427 which the NETLMM protocol can be built. The design of the protocol 428 should have a goal to re-use existing protocols where it makes 429 architectural and engineering sense to do so. The design should 430 not, however, attempt to re-use existing protocols where there is 431 no real architectural or engineering reason. For example, the suite 432 of Internet Standards contains several good candidate protocols for 433 the transport layer, so there is no real need to develop a new 434 transport protocol specifically for NETLMM. Re-use is clearly a 435 good engineering decision in this case, since backward 436 compatibility with existing protocol stacks is important. On the 437 other hand, the network-based, localized mobility management 438 functionality being introduced by NETLMM is a new piece of 439 functionality, and therefore any decision about whether to re-use 440 an existing global mobility management protocol should carefully 441 consider whether re-using such a protocol really meets the needs of 442 the functional architecture for network-based localized mobility 443 management. The case for re-use is not so clear in this case, since 444 there is no compelling backward compatibility argument. 446 2.11 Localized Mobility Management Independent of Global Mobility 447 Management 449 Localized mobility management should be implementable and 450 deployable independently of any global mobility management 451 protocol. This enables the choice of local and global mobility 452 management to be made independently of particular protocols that 453 are implemented and deployed to solve the two different sorts of 454 mobility management problems. The operator can choose a particular 455 localized mobility management protocol according to the specific 456 features of their access network. It can subsequently upgrade the 457 localized mobility management protocol on its own, without even 458 informing the mobile nodes. Similarly, the mobile nodes can use a 459 global mobility management protocol that best suits their 460 requirements, or even not use one at all. Also, a mobile node can 461 move into a new access network without having to check that it 462 understands the localized mobility management protocol being used 463 there. 465 The goal is that the implementation and deployment of the localized 466 mobility management protocol should not restrict, or be restricted 467 by, the choice of global mobility management protocol. 469 2.12 Configurable Data Plane Forwarding between Mobility Anchor and 470 Access Router 472 Different network operators may require different types of 473 forwarding options between the mobility anchor and the access 474 routers for mobile node data plane traffic. An obvious forwarding 475 option that has been used in past IETF localized mobility 476 management protocols is IP-IP encapsulation for bidirectional 477 tunneling. The tunnel endpoints could be the mobility anchor and 478 the access routers. But other options are possible. Some network 479 deployments may prefer routing-based solutions. Others may require 480 security tunnels using IPsec ESP encapsulation if part of the 481 localized mobility management domain runs over a public access 482 network and the network operator wants to protect the traffic. 484 A goal of the NETLMM protocol is to allow the forwarding between 485 the mobility anchor and access routers to be configurable depending 486 on the particulars of the network deployment. Configurability is 487 not expected to be dynamic as in controlled by the arrival of a 488 mobile node; but rather, configuration is expected to be similar in 489 time scale to configuration for routing. The NETLMM protocol may 490 designate a default forwarding mechanism. It is also possible that 491 additional work may be required to specify the interaction between 492 a particular forwarding mechanism and the NETLMM protocol, but this 493 work is not in scope of the NETLMM base protocol. 495 3.0 IANA Considerations 497 There are no IANA considerations for this document. 499 4.0 Security Considerations 501 There are two kinds of security issues involved in network-based 502 localized mobility management: security between the mobile node and 503 the network, and security between network elements that participate 504 in the network-based localized mobility management protocol 506 Security between the mobile node and the network itself consists of 507 two parts: threats involved in localized mobility management in 508 general, and threats to the network-based localized mobility 509 management from the host. The first is discussed above in Sections 510 2.3 and 2.6. The second is discussed in the threat analysis 511 document [2]. 513 For threats to network-based localized mobility management, the 514 basic threat is an attempt by an unauthorized party to signal a 515 bogus mobility event. Such an event must be detectable. This 516 requires proper bidirectional authentication and authorization of 517 network elements that participate in the network-based localized 518 mobility management protocol, and data origin authentication on the 519 signaling traffic between network elements. 521 5.0 Author's Addresses 523 James Kempf 524 DoCoMo USA Labs 525 181 Metro Drive, Suite 300 526 San Jose, CA 95110 527 USA 528 Phone: +1 408 451 4711 529 Email: kempf@docomolabs-usa.com 531 Kent Leung 532 Cisco Systems, Inc. 533 170 West Tasman Drive 534 San Jose, CA 95134 535 USA 536 EMail: kleung@cisco.com 538 Phil Roberts 539 Motorola Labs 540 Schaumberg, IL 541 USA 542 Email: phil.roberts@motorola.com 544 Katsutoshi Nishida 545 NTT DoCoMo Inc. 546 3-5 Hikarino-oka, Yokosuka-shi 547 Kanagawa, 548 Japan 549 Phone: +81 46 840 3545 550 Email: nishidak@nttdocomo.co.jp 552 Gerardo Giaretta 553 Telecom Italia Lab 554 via G. Reiss Romoli, 274 555 10148 Torino 556 Italy 557 Phone: +39 011 2286904 558 Email: gerardo.giaretta@tilab.com 560 Marco Liebsch 561 NEC Network Laboratories 562 Kurfuersten-Anlage 36 563 69115 Heidelberg 564 Germany 565 Phone: +49 6221-90511-46 566 Email: marco.liebsch@ccrle.nec.de 568 6.0 Informative References 570 [1] Kempf, J., editor, "Problem Statement for IP Local Mobility," 571 Internet Draft, Work in Progress. 572 [2] Vogt, C., and Kempf, J., "Security Threats to Network-based 573 Localized Mobillity Management", Internet draft, Work in 574 Progress. 575 [3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 576 3753, June, 2004. 577 [4] Carpenter, B., "Architectural Principles of the Internet," 578 RFC 1958, June, 1996. 579 [5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 580 IPv6", RFC 3775. 581 [6] Choi, J, and Daley, G., "Goals of Detecting Network 582 Attachment in IPv6", Internet Draft, work in progress. 583 [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 584 802.1x, June, 2001. 585 [8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, 586 A., "Protocol for Carrying Authentication for Network Access 587 (PANA)", Internet Draft, work in progress. 588 [9] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure 589 Neighbor Discovery (SEND)", RFC 3971, March, 2005. 590 [10] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, 591 Work in Progress. 592 [11] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, 593 S.D., and Patil, B., "Privacy for Mobile and Multi-homed 594 Nodes: MoMiPriv Problem Statement", Internet Draft, work in 595 progress. 596 [12] Moskowitz, R., and Nikander, P., "Host Identity Protocol 597 (HIP) Architecture", RFC 4423, May, 2006. 598 [13] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol 599 (MOBIKE)", Internet Draft, Work in Progress. 600 [14] Koodli, R., "IP Address Location Privacy and IP Mobility", 601 Internet Draft, Work in Progress. 602 [15] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., 603 "Solutions for IP Address Location Privacy in the presence of 604 IP Mobility", Internet Draft, Work in Progress. 605 [16] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., 606 "Protocol for Protecting Movement of Mobile Nodes in Mobile 607 IPv6", Internet Draft, Work in Progress. 608 [17] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., 609 Levkowetz, H., Thubert, P, and Wakikawa, R. "Dual Stack 610 Mobile IPv6 (DSMIPv6) for Hosts and Routers", Internet Draft, 611 Work in Progress. 612 [18] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 613 4068, July, 2005. 615 [19] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., 616 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 617 4140, August, 2005. 618 [20] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6 619 Handover Key using SEND", Internet Draft, work in progress. 620 [21] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta, 621 G., and Bournelle, J., "Handover Keys Using AAA", Internet 622 Draft, Work in Progress. 623 [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., 624 "Design, Implementation and Evaluation of Cellular IP", IEEE 625 Personal Communications, June/July 2000. 626 [23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., 627 "HAWAII: A domain-based approach for supporting mobility in 628 wide-area wireless networks", in Proceedings of the 629 International Conference on Networking Protocols (ICNP), 630 1999. 632 7.0 IPR Statements 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed 636 to pertain to the implementation or use of the technology described 637 in this document or the extent to which any license under such 638 rights might or might not be available; nor does it represent that 639 it has made any independent effort to identify any such rights. 640 Information on the procedures with respect to rights in RFC 641 documents can be found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use 646 of such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository 648 at http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at ietf- 654 ipr@ietf.org. 656 8.0 Disclaimer of Validity 658 This document and the information contained herein are provided on 659 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 660 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 661 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 662 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 663 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 664 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 665 PARTICULAR PURPOSE. 667 9.0 Copyright Notice 669 Copyright (C) The Internet Society (2006). This document is 670 subject to the rights, licenses and restrictions contained in BCP 671 78, and except as set forth therein, the authors retain all their 672 rights. 674 10.0 Appendix: Gap Analysis 676 This section discusses a gap analysis between existing proposals 677 for solving localized mobility management and the goals in Section. 678 2.0. 680 10.1 Mobile IPv6 with Local Home Agent 682 One option is to deploy Mobile IPv6 with a locally assigned home 683 agent in the local network. This solution requires the mobile node 684 to somehow be assigned a home agent in the local network when it 685 boots up. This home agent is used instead of the home agent in the 686 home network. The advantage of this option is that no special 687 solution is required for edge mobility - the mobile node reuses the 688 global mobility management protocol for that purpose - if the 689 mobile node is using Mobile IPv6. 691 The analysis of this approach against the goals above is the 692 following. 694 Goal #1 Handover Performance Improvement: If the mobile node does 695 not perform route optimization, this solution reduces, but does not 696 eliminate, IP handover related performance problems. 698 Goal #2 Reduction in Handover-related Signaling Volume: Similarly 699 to Goal #1, signaling volume is reduced if no route optimization 700 signaling is done on handover. 702 Goal #3 Location privacy: Location privacy is preserved for 703 external correspondents, but the mobile node itself still maintains 704 a local care-of address. If the mobile node performs route 705 optimization, location privacy may be compromised, but not 706 performing route optimization is no better than having a remote 707 home agent. 709 Goal #4 Efficient Use of Wireless Resources: If traffic is not 710 route optimized, the mobile node still pays for an over-the-air 711 tunnel to the locally assigned home agent. The overhead here is 712 exactly the same as if the mobile node's home agent in the home 713 network is used and route optimization is not done. 715 Goal #5 Limit the Signaling Overhead in the Network: If the 716 localized mobility management domain is large, the mobile node may 717 suffer from unoptimzed routes. RFC 3775 [5] provides no support for 718 notifying a mobile node that another localized home agent is 719 available for a more optimized route, or for handing over between 720 home agents. A mobile node would have to perform the full home 721 agent bootstrap procedure, including establishing a new IPsec SA 722 with the new home agent. 724 Goal #6 No Extra Security Between Mobile Node and Network: A local 725 home agent in a roaming situation requires the guest mobile node to 726 have the proper credentials to authenticate with the local home 727 agent in the serving network. Although the credentials used for 728 network access authentication could also be used for mobile service 729 authentication and authorization if the local home agent uses EAP 730 over IKEv2 to authenticate the mobile node with its home AAA 731 server, the two sets of credentials are in principle different, and 732 could require additional credential provisioning. In addition, as 733 in Goal #3, if binding updates are done in cleartext over the 734 access network or the mobile node has become infected with malware, 735 the local home agent's address could be revealed to attackers and 736 the local home agent could become the target of a DoS attack. So a 737 local home agent would provide no benefit for this goal. 739 Goal #7 Support for Heterogeneous Wireless Link Technologies: This 740 solution supports multiple wireless technologies with separate IP 741 subnets for different links. No special work is required to 742 interface a local home agent to different wireless technologies. 744 Goal #8 Support for Unmodified Mobile Nodes: The mobile node must 745 support Mobile IPv6 in order for this option to work. So mobile 746 node changes are required and other IP mobility protocols are not 747 supported. 749 Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is 750 working on modifying the protocol to allow registration of IPv4 751 care-of addresses in an IPv6 home agent, and also to allow a mobile 752 node to have an IPv4 care of address [17]. 754 Goal #10 Re-use of Existing Protocols Where Sensible: This solution 755 re-uses an existing protocol, Mobile IPv6. 757 Goal #11 Localized Mobility Management Independent of Global 758 Mobility Management: This solution merges localized mobility 759 management and global mobility management, so it does not support 760 the goal. 762 10.2 Hierarchical Mobile IPv6 (HMIPv6) 764 HMIPv6 [19] provides the most complete localized mobility 765 management solution available today. In HMIPv6, a localized 766 mobility anchor called a MAP serves as a routing anchor for a 767 regional care-of address. When a mobile node moves from one access 768 router to another, the mobile node changes the binding between its 769 regional care-of address and local care-of address at the MAP. No 770 global mobility management signaling is required, since the care-of 771 address seen by correspondents does not change. This part of HMIPv6 772 is similar to the solution outlined in Section 10.1; however, 773 HMIPv6 also allows a mobile node to hand over between MAPs. 775 Handover between MAPs and MAP discovery requires configuration on 776 the routers. MAP addresses are advertised by access routers. 777 Handover happens by overlapping MAP coverage areas so that, for 778 some number of access routers, more than one MAP may be advertised. 779 Mobile nodes need to switch MAPs in the transition area, and then 780 must perform global mobility management update and route 781 optimization to the new regional care-of address, if appropriate. 783 The analysis of this approach against the goals above is the 784 following. 786 Goal #1 Handover Performance Improvement: This solution shortens, 787 but does not eliminate, the latency associated with IP handover, 788 since it reduces the amount of signaling and the length of the 789 signaling paths. 791 Goal #2 Reduction in Handover-related Signaling Volume: Signaling 792 volume is reduced simply because no route optimization signaling is 793 done on handover within the coverage area of the MAP. 795 Goal #3 Location privacy: Location privacy is preserved for 796 external correspondents. 798 Goal #4 Use of Wireless Resources: The mobile node always pays for 799 an over-the-air tunnel to the MAP. If the mobile node is tunneling 800 through a global home agent or VPN gateway, the wired link 801 experiences double tunneling. Over-the-air tunnel overhead can be 802 removed by header compression, however. 804 Goal #5 Limit the Signaling Overhead in the Network: From Goal #1 805 and Goal #4, the signaling overhead is no more or less than for 806 mobile nodes whose global mobility management anchor is local. 807 However, because MAP handover is possible, forwarding across large 808 localized mobility management domains can be improved thereby 809 improving wired network resource utilization by using multiple MAPs 810 and handing over, at the expense of the configuration and 811 management overhead involved in maintaining multiple MAP coverage 812 areas. 814 Goal #6 Extra Security Between Mobile Node and Network: In a 815 roaming situation, the guest mobile node must have the proper 816 credentials to authenticate with the MAP in the serving network. In 817 addition, since the mobile node is required to have a unicast 818 address for the MAP that is either globally routed or routing 819 restricted to the local administrative domain, the MAP is 820 potentially a target for DoS attacks across a wide swath of network 821 topology. 823 Goal #7 Support for Heterogeneous Wireless Link Technologies: This 824 solution supports multiple wireless technologies with separate IP 825 subnets for different links. 827 Goal #8 Support for Unmodified Mobile Nodes: This solution requires 828 modification to the mobile nodes. In addition, the HMIPv6 design 829 has been optimized for Mobile IPv6 mobile nodes, and is not a good 830 match for other global mobility management protocols. 832 Goal #9 Currently, there is no IPv4 version of this protocol; 833 although there is an expired Internet draft with a design for a 834 regional registration protocol for Mobile IPv4 that has similar 835 functionality. It is possible that the same IPv4 transition 836 solution as used for Mobile IPv6 could be used [17]. 838 Goal #10 Re-use of Existing Protocols Where Sensible: This solution 839 re-uses an existing protocol, HMIPv6. 841 Goal #11 Localized Mobility Management Independent of Global 842 Mobility Management: While HIMPv6 is technically a separate 843 protocol from MIPv6 and could in principle be implemented and 844 deployed without MIPv6, the design is very similar and 845 implementation and deployment would be easier if the mobile nodes 846 supported MIPv6. 848 10.3 Combinations of Mobile IPv6 with Optimizations 850 One approach to local mobility that has received much attention in 851 the past and has been thought to provide a solution is combinations 852 of protocols. The general approach is to try to cover gaps in the 853 solution provided by MIPv6 by using other protocols. In this 854 section, gap analyses for MIPv6 + FMIPv6 and HMIPv6 + FMIPv6 are 855 discussed. 857 10.3.1 MIPv6 with local home agent + FMIPv6 859 As discussed in Section 10.1, the use of MIPv6 with a dynamically 860 assigned, local home agent cannot fulfill the goals. A fundamental 861 limitation is that Mobile IPv6 cannot provide seamless handover 862 (i.e. Goal #1). FMIPv6 [18] has been defined with the intent to 863 improve the handover performance of MIPv6. For this reason, the 864 combined usage of FMIPv6 and MIPv6 with a dynamically assigned 865 local home agent has been proposed to handle local mobility. 867 Note that this gap analysis only applies to localized mobility 868 management, and it is possible that MIPv6 and FMIPv6 might still be 869 acceptable for global mobility management. 871 The analysis of this combined approach against the goals follows. 873 Goal #1 Handover Performance Improvement: FMIPv6 provides a 874 solution for handover performance improvement that should fulfill 875 the goals raised by real-time applications in terms of jitter, 876 delay and packet loss. The location of the home agent (in local or 877 home domain) does not affect the handover latency. 879 Goal #2 Reduction in Handover-related Signaling Volume: FMIPv6 880 requires the mobile node to perform extra signaling with the access 881 router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as 882 in standard MIPv6, whenever the mobile node moves to another link, 883 it must send a Binding Update to the home agent. If route 884 optimization is used, the mobile node also performs return 885 routability and sends a Binding Update to each correspondent node. 886 Nonetheless, it is worth noting that FMIPv6 should result in a 887 reduction of the amount of IPv6 Neighbor Discovery signaling on the 888 new link. 890 Goal #3 Location privacy: The mobile node mantains a local care-of 891 address. If route optimization is not used, location privacy can be 892 achieved using bi-directional tunneling. 894 Goal #4 Use of Wireless Resources: As stated for Goal #2, the 895 combination of MIPv6 and FMIPv6 generates extra signaling overhead. 896 For data packets, in addition to the Mobile IPv6 over-the-air 897 tunnel, there is a further level of tunneling between the mobile 898 node and the previous access router during handover. This tunnel is 899 needed to forward incoming packets to the mobile node addressed to 900 the previous care-of address. Another reason is that, even if the 901 mobile node has a valid new care-of address, the mobile node cannot 902 use the new care of address directly with its correspondents 903 without performing route optimization to the new care of address. 904 This implies that the transient tunnel overhead is in place even 905 for route optimized traffic. 907 Goal #5 Limit the Signaling Overhead in the Network: FMIPv6 908 generates extra signaling overhead between the previous access 909 router and the new access router for the HI/HAck exchange. 910 Concerning data packets, the use of FMIPv6 for handover performance 911 improvement implies a tunnel between the previous access router and 912 the mobile node that adds some overhead in the wired network. This 913 overhead has more impact on star topology deployments, since 914 packets are routed down to the old access router, then back up to 915 the aggregation router and then back down to the new access router. 917 Goal #6 Extra Security Between Mobile Node and Network: In addition 918 to the analysis for Mobile IPv6 with local home agent in Section 919 10.1, FMIPv6 requires the mobile node and the previous access 920 router to share a security association in order to secure FBU/FBA 921 exchange. Two solutions have been proposed: a SEND-based solution 922 [20] and an AAA-based solution [21]. Both solutions require 923 additional support on the mobile node and in the network beyond 924 what is required for network access authentication. 926 Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6 927 and FMIPv6 support multiple wireless technologies, so this goal is 928 fufilled. 930 Goal #8 Support for Unmodified Mobile Nodes: The mobile node must 931 support both MIPv6 and FMIPv6, so it is not possible to satisfy 932 this goal. 934 Goal #9 Support for IPv4 and IPv6: Work is underway to extend MIPv6 935 with the capability to run over both IPv6-enabled and IPv4-only 936 networks [17]. FMIPv6 only supports IPv6. Even though an IPv4 937 version of FMIP has been recently proposed, it is not clear how it 938 could be used together with FMIPv6 in order to handle fast 939 handovers across any wired network. 941 Goal #10 Re-use of Existing Protocols Where Sensible: This solution 942 re-uses existing protocols, Mobile IPv6 and FMIPv6. 944 Goal #11 Localized Mobility Management Independent of Global 945 Mobility Management: This solution merges localized mobility 946 management and global mobility management, so it does not support 947 the goal. 949 10.3.2 HMIPv6 + FMIPv6 951 HMIPv6 provides several advantages in terms of local mobility 952 management. However, as seen in Section 10.2, it does not fulfill 953 all the goals identified in Section 2.0. In particular, HMIPv6 does 954 not completely eliminate the IP handover latency. For this reason, 955 FMIPv6 could be used together with HMIPv6 in order to cover the 956 gap. 958 Note that even if this solution is used, the mobile node is likely 959 to need MIPv6 for global mobility management, in contrast with the 960 MIPv6 with dynamically assigned local home agent + FMIPv6 solution. 961 Thus, this solution should really be considered MIPv6 + HMIPv6 + 962 FMIPv6. 964 The analysis of this combined approach against the goals follows. 966 Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both 967 shorten the latency associated with IP handovers. In particular, 968 FMIPv6 is expected to fulfill the goals on jitter, delay and packet 969 loss raised by real-time applications. 971 Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6 972 and HMIPv6 require extra signaling compared with Mobile IPv6. As a 973 whole the mobile node performs signaling message exchanges at each 974 handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. 976 However, as mentioned in Section 10.2, the use of HMIPv6 reduces 977 the signaling overhead since no route optimization signaling is 978 done for intra-MAP handovers. In addition, naive combinations of 979 FMIPv6 and HMIPv6 often result in redundant signaling. There is 980 much work in the academic literature and the IETF on more refined 981 ways of combining signaling from the two protocols to avoid 982 redundant signaling. 984 Goal #3 Location privacy: HMIPv6 may preserve location privacy, 985 depending on the dimension of the geographic area covered by the 986 MAP. 988 Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the 989 combination of HMIPv6 and FMIPv6 generates a lot of signaling 990 overhead in the network. Concerning payload data, in addition to 991 the over-the-air MIPv6 tunnel, a further level of tunneling is 992 established between mobile node and MAP. Notice that this tunnel is 993 in place even for route optimized traffic. Moreover, if FMIPv6 is 994 directly applied to HMIPv6 networks, there is a third temporary 995 handover-related tunnel between the mobile node and previous access 996 router. Again, there is much work in the academic literature and 997 IETF on ways to reduce the extra tunnel overhead on handover by 998 combining HMIP and FMIP tunneling. 1000 Goal #5 Limit the Signaling Overhead in the Network: The signaling 1001 overhead in the network is not reduced by HMIPv6, as mentioned in 1002 Section 10.2. Instead, FMIPv6 generates extra signaling overhead 1003 between the previous access router and new access router for 1004 HI/HAck exchange. For payload data, the same considerations as for 1005 Goal #4 are applicable. 1007 Goal #6 Security Between Mobile Node and Network: FMIPv6 requires 1008 the mobile node and the previous access router to share a security 1009 association in order to secure the FBU/FBA exchange. In addition, 1010 HMIPv6 requires that the mobile node and MAP share an IPsec 1011 security association in order to secure LBU/LBA exchange. The only 1012 well understood approach to set up an IPsec security association is 1013 the use of certificates, but this may raise deployment issues. 1014 Thus, the combination of FMIPv6 and HMIPv6 doubles the amount of 1015 mobile node to network security protocol required, since security 1016 for both FMIP and HMIP must be deployed. 1018 Goal #7 Support for Heterogeneous Wireless Link Technologies: 1019 HMIPv6 and FMIPv6 support multiple wireless technologies, so this 1020 goal is fufilled. 1022 Goal #8 Support for Unmodified Mobile Nodes: The mobile node must 1023 support both HMIPv6 and FMIPv6 protocols, so this goal is not 1024 fulfilled. 1026 Goal #9 Support for IPv4 and IPv6: Currently there is no IPv4 1027 version of HMIPv6. There is an IPv4 version of FMIP but it is not 1028 clear how it could be used together with FMIPv6 in order to handle 1029 fast handovers across any wired network. 1031 Goal #10 Re-use of Existing Protocols Where Sensible: This 1032 solution re-uses existing protocols, HMIPv6 and FMIPv6. 1034 Goal #11 Localized Mobility Management Independent of Global 1035 Mobility Management: While HIMPv6 is technically a separate 1036 protocol from MIPv6 and could in principle be implemented and 1037 deployed without MIPv6, the design is very similar and 1038 implementation and deployment would be easier if the mobile nodes 1039 supported MIPv6. 1041 10.4 Micromobility Protocols 1043 Researchers have defined some protocols that are often 1044 characterized as micromobility protocols. Two typical protocols in 1045 this category are Cellular-IP [22] and HAWAII [23]. Researchers 1046 defined these protocols before local mobility optimizations for 1047 Mobile IP such as FMIP and HMIP were developed, in order to reduce 1048 handover latency. Cellular-IP and HAWAII were proposed in the IETF 1049 for standardization, but after some study in the IRTF, were 1050 dropped. There are many micromobility protocols defined in the 1051 academic literature, but in this document, the term is used 1052 specifically to refer to Cellular-IP and HAWAII. 1054 The micromobility approach to localized mobility management 1055 requires host route propagation from the mobile node to a 1056 collection of specialized routers in the localized mobility 1057 management domain along a path back to a boundary router at the 1058 edge of the localized mobility management domain. A boundary router 1059 is a kind of localized mobility management domain gateway. 1060 Localized mobility management is authorized with the access router, 1061 but reauthorization with each new access router is necessary on 1062 link movement, in addition to any reauthorization for basic network 1063 access. The host routes allow the mobile node to maintain the same 1064 IP address when it moves to a new link, and still continue to 1065 receive packets on the new link. 1067 Cellular IP and HAWAII have a few things in common. Both are 1068 compatible with Mobile IP and are intended to provide a higher 1069 level of handover performance in local networks than was previously 1070 available with Mobile IP without such extensions as HMIP and FMIP. 1071 Both use host routes installed in a number of routers within a 1072 restricted routing domain. Both define specific messaging to update 1073 those routes along the forwarding path and specify how the 1074 messaging is to be used to update the routing tables and forwarding 1075 tables along the path between the mobile and a micromobility domain 1076 boundary router at which point Mobile IP is to used to handle 1077 global mobility in a scalable way. Unlike the FMIP and HMIP 1078 protocols, however, these protocols do not require the mobile node 1079 to obtain a new care of address on each access router as it moves; 1080 but rather, the mobile node maintains the same care of address 1081 across the micromobility domain. From outside the micromobility 1082 domain, the care of address is routed using traditional longest 1083 prefix matching IP routing to the domain's boundary router, so the 1084 care of address conceptually is within the micromobiity domain 1085 boundary router's subnet. Within the micromobility domain, the care 1086 of address is routed to the correct access router using host 1087 routes. 1089 Micromobility protocols have some potential drawbacks from a 1090 deployment and scalability standpoint. Both protocols involve every 1091 routing element between the mobile device and the micromobility 1092 domain boundary router in all packet forwarding decisions specific 1093 to care of addresses for mobile nodes. Scalability is limited 1094 because each care of address corresponding to a mobile node 1095 generates a routing table entry, and perhaps multiple forwarding 1096 table entries, in every router along the path. Since mobile nodes 1097 can have multiple global care of addresses in IPv6, this can result 1098 in a large expansion in router state throughout the micromobility 1099 routing domain. Although the extent of the scalability for 1100 micromobility protocols is still not clearly understood from a 1101 research standpoint, it seems certain that they will be less 1102 scalable than the Mobile IP optimization enhancements, and will 1103 require more specialized gear in the wired network. 1105 The following is a gap analysis of the micromobility protocols 1106 against the goals in Section 2.0: 1108 Goal #1 Handover Performance Improvement: The micromobility 1109 protocols reduce handover latency by quickly fixing up routes 1110 between the boundary router and the access router. While some 1111 additional latency may be expected during host route propagation, 1112 it is typically much less than experienced with standard Mobile IP. 1114 Goal #2 Reduction in Handover-related Signaling Volume: The 1115 micromobility protocols require signaling from the mobile node to 1116 the access router to initiate the host route propagation, but that 1117 is a considerable reduction over the amount of signaling required 1118 to configure to a new link. 1120 Goal #3 Location privacy: No care-of address changes are exposed to 1121 correspondent nodes or the mobile node itself while the mobile node 1122 is moving in the micromobility-managed network. 1124 Goal #4 Use of Wireless Resources: The only additional over-the-air 1125 signaling is involved in propagating host routes from the mobile 1126 node to the network upon movement. Since this signaling would be 1127 required for movement detection in any case, it is expected to be 1128 minimal. Mobile node traffic experiences no overhead. 1130 Goal #5 Limit the Signaling Overhead in the Network: Host route 1131 propagation is required throughout the wired network. The volume of 1132 signaling could be more or less depending on the speed of mobile 1133 node movement and the size of the wired network. 1135 Goal #6 Security Between Mobile Node and Network: The mobile node 1136 only requires a security association of some type with the access 1137 router. Because the signaling is causing routes to the mobile 1138 node's care-of address to change, the signaling must prove 1139 authorization to hold the address. 1141 Goal #7 Support for Heterogeneous Wireless Link Technologies: 1142 HMIPv6 The micromobility protocols support multiple wireless 1143 technologies, so this goal is satisfied. 1145 Goal #8 Support for Unmodified Mobile Nodes: The mobile node must 1146 support some way of signaling the access router on link handover, 1147 but this is required for movement detection anyway. The nature of 1148 the signaling for the micromobility protocols may require mobile 1149 node software changes, however. 1151 Goal #9 Re-use of Existing Protocols Where Sensible: Support for 1152 IPv4 and IPv6: Most of the work on the micromobility protocols was 1153 done in IPv4, but little difference could be expected for IPv6. 1155 Goal #10 This solution does not reuse an existing protocol because 1156 there is currently no Internet Standard protocol for micromobility. 1158 Goal #11 Localized Mobility Management Independent of Global 1159 Mobility Management: This solution separates global and local 1160 mobility management, since the micromobility protocols only support 1161 localized mobility management. 1163 10.5 Summary 1165 The following table summarizes the discussion in Section 9.1 1166 through 9.5. In the table, a "M" indicates that the protocol 1167 completely meets the goal, a "P" indicates that it partially meets 1168 the goal, and an "X" indicates that it does not meet the goal. 1170 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 1171 -------- -- -- -- -- -- -- -- -- -- --- 1173 MIPv6 P X X X X X M X M M 1175 HMIPv6 P X X X P X M X X M 1177 MIPv6 + 1178 FMIPv6 M X X X P X M X P M 1180 HMIPv6 + 1181 FMIPv6 M X X X X X M X X M 1182 Micro. M M M M P M M M P X