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