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