idnits 2.17.1 draft-ietf-netlmm-nohost-req-01.txt: -(834): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 701 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 17 has weird spacing: '... By submi...' == Line 31 has weird spacing: '... The list...' == Line 34 has weird spacing: '... The list ...' == Line 130 has weird spacing: '..., like a ho...' == Line 153 has weird spacing: '...(unless optim...' == (27 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) -- Missing reference section? '1' on line 480 looks like a reference -- Missing reference section? '2' on line 483 looks like a reference -- Missing reference section? '3' on line 485 looks like a reference -- Missing reference section? '5' on line 489 looks like a reference -- Missing reference section? '6' on line 622 looks like a reference -- Missing reference section? '7' on line 493 looks like a reference -- Missing reference section? '8' on line 495 looks like a reference -- Missing reference section? '9' on line 497 looks like a reference -- Missing reference section? '10' on line 499 looks like a reference -- Missing reference section? '11' on line 502 looks like a reference -- Missing reference section? '12' on line 504 looks like a reference -- Missing reference section? '14' on line 509 looks like a reference -- Missing reference section? '16' on line 514 looks like a reference -- Missing reference section? '17' on line 517 looks like a reference -- Missing reference section? '18' on line 520 looks like a reference -- Missing reference section? '28' on line 545 looks like a reference -- Missing reference section? '4' on line 487 looks like a reference -- Missing reference section? '13' on line 506 looks like a reference -- Missing reference section? '15' on line 512 looks like a reference -- Missing reference section? '19' on line 803 looks like a reference -- Missing reference section? '20' on line 526 looks like a reference -- Missing reference section? '21' on line 657 looks like a reference -- Missing reference section? '22' on line 790 looks like a reference -- Missing reference section? '23' on line 885 looks like a reference -- Missing reference section? '24' on line 885 looks like a reference -- Missing reference section? '25' on line 1026 looks like a reference -- Missing reference section? '26' on line 998 looks like a reference -- Missing reference section? '27' on line 999 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Kempf, 3 Editor 4 Internet Draft K. Leung 5 Document: draft-ietf-netlmm-nohost-req-01.txt P. Roberts 6 K. Nishida 7 G. Giaretta 8 M. Liebsch 10 Expires: October, 2006 April, 2006 12 Goals for Network-based Localized Mobility Management (NETLMM) 13 (draft-ietf-netlmm-nohost-req-01.txt) 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware have been 19 or will be disclosed, and any of which he or she becomes aware will be 20 disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering Task Force 23 (IETF), its areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months and 27 may be updated, replaced, or obsoleted by other documents at any time. It is 28 inappropriate to use Internet-Drafts as reference material or to cite them 29 other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In this document, design goals for a network-based localized mobility 40 management protocol are discussed. 42 Table of Contents 44 1.0 Introduction.....................................................2 45 2.0 Goals for Localized Mobility Management..........................2 46 3.0 Security Considerations..........................................8 47 4.0 Author Information...............................................9 48 5.0 Informative References..........................................10 49 6.0 IPR Statements..................................................11 50 7.0 Disclaimer of Validity..........................................12 51 8.0 Copyright Notice................................................12 52 9.0 Appendix: Gap Analysis..........................................12 54 1.0 Introduction 56 In [1], the basic problems that occur when a global mobility protocol is 57 used for managing local mobility are described, and three basic approaches 58 to localized mobility management - the host-based approach that is used by 59 most IETF protocols, the WLAN switch approach, and using a standard routing 60 IGP to distribute host routes - are examined. The conclusion from the 61 problem statement document is that none of the approaches has a complete 62 solution to the problem. While the WLAN switch approach is most convenient 63 for network operators and users because it requires no mobile node support, 64 the proprietary nature limits interoperability and the restriction to a 65 single wireless link type and wired backhaul link type restricts scalablity. 66 The IETF host-based protocols require host software stack changes that may 67 not be compatible with all global mobility protocols, and also require 68 specialized and complex security transactions with the network that may 69 limit deployability. The use of an IGP to distribute host routes has 70 scalability and deployment limitations. 72 This document develops more detailed goals for a network-based localized 73 mobility management protocol. In Section 2.0, we review a list of goals that 74 are desirable in a network-based localized mobility management solution. 75 Section 3.0 briefly outlines security considerations. More discussion of 76 security can be found in the threat analysis document [2]. The architecture 77 of the NETLMM protocol for which the goals in this document have been 78 formulated is described in Section 4 of [1]. 80 1.1 Terminology 82 Mobility terminology in this draft follows that in RFC 3753 [3] and in [1]. 84 2.0 Goals for Localized Mobility Management 86 Any localized mobility solution must naturally address the three problems 87 described in [1]. In addition, the side effects of introducing such a 88 solution into the network need to be limited. In this section, we address 89 goals on a localized mobility solution including both solving the basic 90 problems and limiting the side effects. 92 Some basic goals of all IETF protocols are not discussed in detail here, but 93 any solution is expected to satisfy them. These goals are interoperability, 94 scalability, and minimal goal for specialized network equipment. A good 95 discussion of their applicability to IETF protocols can be found in [5]. 97 Out of scope for the initial goals discussion are QoS, multicast, and 98 dormant mode/paging. While these are important functions for mobile nodes, 99 they are not part of the base localized mobility management problem. In 100 addition, mobility between localized mobility management domains is not 101 covered here. It is assumed that this is covered by the global mobility 102 management protocols. 104 2.1 Handover Performance Improvement (Goal #1) 106 Handover packet loss occurs because there is usually latency between when 107 the wireless link handover starts and when the IP link handover completes. 108 During this time the mobile node is unreachable at its former topological 109 location on the old IP link where correspondents are sending packets and to 110 which the routing system is routing them. Such misrouted packets are 111 dropped. This aspect of handover performance optimization has been the 112 subject of an enormous amount of work, both in other SDOs, to reduce the 113 latency of wireless link handover, and in the IETF and elsewhere, to reduce 114 the latency in IP link handover. Many solutions to this problem have been 115 proposed at the wireless link layer and at the IP layer. One aspect of this 116 goal for localized mobility management is that the processing delay for 117 changing the routing after handover must approach as closely as possible the 118 sum of the delay associated with link layer handover and the delay required 119 for active IP layer movement detection, in order to avoid excessive packet 120 loss. Ideally, if network-side link layer support is available for handling 121 movement detection prior to link handover or as part of the link handover 122 process, the routing update should complete within the time required for 123 wireless link handover. 125 Note that a related problem occurs when traffic packets are not routed 126 through a global mobility anchor such as a Mobile IP home agent. Route 127 optimized Mobile IPv6 [6] and HIP [7] are examples. A loss of connectivity 128 can occur when both sides of the IP conversation are mobile and they both 129 hand over at the same time. The two sides must use a global mobility anchor 130 point, like a home agent or rendezvous server, to re-establish the 131 connection, but there may be substantial packet loss until the problem is 132 discovered. Another aspect of this goal is that the solution must ensure 133 that connectivity is not lost when both ends are mobile and move at the same 134 time. 136 In both cases, the loss of accurate routing causes the connection to 137 experience an interruption which may cause service degradation for real time 138 traffic such as voice 140 2.2 Reduction in Handover-related Signaling Volume (Goal #2) 142 Considering Mobile IPv6 as the global mobility protocol (other mobility 143 protocols require about the same or somewhat less), if a mobile node is 144 required to reconfigure on every move between IP links, the following set of 145 signaling messages must be done: 147 1) Movement detection using DNA [8] or possibly a link specific protocol, 148 2) Any link layer or IP layer AAA signaling, such as 802.1x [9] or PANA 149 [10]. The mobile node may also or instead have to obtain a router 150 certificate using SEND [11], if the certificate is not already cached, 151 3) Router discovery which may be part of movement detection, 152 4) If stateless address autoconfiguration is used, address configuration and 153 Duplicate Address Detection (unless optimistic Duplicate Address 154 Detection [12] is used). If stateful address configuration is used, then 155 DHCP is used for address configuration, 157 5) Binding Update to the home agent, 158 6) If route optimization is in effect, return routability to establish the 159 binding key, 160 7) Binding Update to correspondent nodes for route optimization. 162 Note that Steps 1-2 will always be necessary, even for intra-link mobility, 163 and Step 3 will be necessary even if the mobile node's care-of address can 164 remain the same when it moves to a new access router. 166 The result is approximately 10 messages at the IP level before a mobile node 167 can be ensured that it is established on a link and has full IP 168 connectivity. Furthermore, in some cases, the mobile node may need to engage 169 in "heartbeat signaling" to keep the connection with the correspondent or 170 global mobility anchor fresh, for example, return routability in Mobile IPv6 171 must be done at a maximum every 7 minutes even if the mobile node is 172 standing still. 174 The goal is that handover signaling volume from the mobile node to the 175 network should be no more than what is needed for the mobile node to perform 176 secure IP level movement detection, in cases where no link layer support 177 exists. If link layer support exists for IP level movement detection, the 178 mobile node may not need to perform any additional IP level signaling after 179 handover. 181 2.3 Location privacy (Goal #3) 183 Although general location privacy issues have been discussed in [14], the 184 location privacy referred to here focuses on the IP layer. In most wireless 185 IP network deployments, different IP subnets are used to cover different 186 geographical areas. It is therefore possible to derive a topological to 187 geographical map, in which particular IPv6 subnet prefixes are mapped to 188 particular geographical locations. The precision of the map depends on the 189 size of the geographic area covered by a particular subnet: if the area is 190 large, then knowing the subnet prefix won't provide much information about 191 the precise geographical location of a mobile node within the subnet. 193 When a mobile node moves geographically, it also moves topologically between 194 subnets. In order to maintain routability, the mobile node must change its 195 local IP address when it moves between subnets. A correspondent node or 196 eavesdropper can use the topological to geographical map to deduce in real 197 time where a mobile node - and therefore its user - is located. Depending on 198 how precisely the geographical location can be deduced, this information 199 could be used to compromise the privacy or even cause harm to the user. The 200 geographical location information should not be revealed to nor be deducible 201 by the correspondent node or an eavesdropper without the authorization of 202 the mobile node's owner. 204 The threats to location privacy come in a variety of forms. Perhaps least 205 likely is a man in the middle attack in which traffic between a 206 correspondent and the mobile node is intercepted and the mobile node's 207 location is deduced from that, since man in the middle attacks in the 208 Internet tend to be fairly rare. More likely are attacks in which the 209 correspondent is the attacker or the correspondent or even the mobile node 210 itself is relaying information on the local address change to an attacker. 211 The owner of the correspondent or mobile node might not even be aware of the 212 problem if an attacker has installed spyware or some other kind of exploit 213 and the malware is relaying the change in local address to the attacker. 214 Host-based localized mobility management solutions in which the 215 correspondent only sees a regional address but the host still maintains a 216 local address are unsatisfactory because they still have a potential for 217 malware on the mobile node itself to reveal a change in the local address. 219 Note that the location privacy referred to here is different from the 220 location privacy discussed in [16][17][18]. The location privacy discussed 221 in these drafts primarily concerns modifications to the Mobile IPv6 protocol 222 to eliminate places where an eavesdropper could track the mobile node's 223 movement by correlating home address and care of address. 225 In order to reduce the risk from location privacy compromises as a result of 226 IP address changes, the goal for NETLMM is to remove the need to change IP 227 address as mobile node moves across IP links. Keeping the IP address fixed 228 removes any possibility for the correspondent node to deduce the precise 229 geographic location of the mobile node without the user's authorization, as 230 well as any possibility that malware on the mobile node could inadvertently 231 reveal the mobile node's location to an attacker. Note that keeping the 232 address constant doesn't completely remove the possibility of deducing the 233 geographical location, since a local address still is required. However, it 234 does allow the network to be deployed such that the mapping between the 235 geographic and topological location is considerably less precise. If the 236 mapping is not precise, an attacker can only deduce in real time that the 237 mobile node is somewhere in a large geographic area, like, for example, a 238 metropolitan region or even a small country, reducing the possibility that 239 the attacker can cause harm to the user. 241 2.4 Efficient Use of Wireless Resources (Goal #4) 243 Advances in wireless PHY and MAC technology continue to increase the 244 bandwidth available from limited wireless spectrum, but even with technology 245 increases, wireless spectrum remains a limited resource. Unlike wired 246 network links, wireless links are constrained in the number of bits/Hertz by 247 their coding technology and use of physical spectrum, which is fixed by the 248 PHY. It is not possible to lay an extra cable if the link becomes 249 increasingly congested as is the case with wired links. 251 Some existing localized mobility management solutions increase packet size 252 over the wireless link by adding tunneling or other per packet overhead. 253 While header compression technology can remove header overhead, header 254 compression does not come without cost. Requiring header compression on the 255 wireless access points increases the cost and complexity of the access 256 points, and increases the amount of processing required for traffic across 257 the wireless link. Since the access points tend to be a critical bottleneck 258 in wireless access networks for real time traffic (especially on the 259 downlink), reducing the amount of per-packet processing is important. While 260 header compression probably cannot be completely eliminated, especially for 261 real time media traffic, simplifying compression to reduce processing cost 262 is an important goal. 264 The goal is that the localized mobility management protocol should not 265 introduce any new signaling or increase existing signaling over the air. 267 2.5 Reduction of Signaling Overhead in the Network (Goal #5) 269 While bandwidth and router processing resources are typically not as 270 constrained in the wired network, wired networks tend to have higher 271 bandwidth and router processing constraints than the backbone. These 272 constraints are a function of the cost of laying fiber or wiring to the 273 wireless access points in a widely dispersed geographic area. Therefore, any 274 solutions for localized mobility management should minimize signaling within 275 the wired network as well. 277 2.6 No Extra Security Between Mobile Node and Network (Goal #6) 279 Localized mobility management protocols that have signaling between the 280 mobile node and network require a security association between the mobile 281 node and the network entity that is the target of the signaling. 282 Establishing a security association specifically for localized mobility 283 service in a roaming situation may prove difficult, because provisioning a 284 mobile node with security credentials for authenticating and authorizing 285 localized mobility service in each roaming partner's network may be 286 unrealistic from a deployment perspective. Reducing the complexity of mobile 287 node to network security for localized mobility management can therefore 288 reduce barriers to deployment. 290 Removing mobile node involvement in localized mobility management also 291 limits the possibility of DoS attacks on network infrastructural elements. 292 In a host based approach, the mobile node is required to have a global or 293 restricted routing local IP address for a network infrastructure element, 294 the mobility anchor point. The network infrastructural element therefore 295 becomes a possible target for DoS attacks, even if mobile nodes are properly 296 authenticated. A properly authenticated mobile node can either willfully or 297 inadvertently give the network infrastructural element address to an 298 attacker. 300 In summary, ruling out mobile node involvement in local mobility management 301 simplifies security by removing the need for service-specific credentials to 302 authenticate and authorize the mobile node for localized mobility management 303 in the network and by limiting the possibility of DoS attacks on network 304 infrastructural elements. The goal is that support for localized mobility 305 management should not require additional security between the mobile node 306 and the network. 308 2.7 Support for Heterogeneous Wireless Link Technologies (Goal #7) 310 The number of wireless link technologies available is growing, and the 311 growth seems unlikely to slow down. Since the standardization of a wireless 312 link PHY and MAC is a time consuming process, reducing the amount of work 313 necessary to interface a particular wireless link technology to an IP 314 network is necessary. A localized mobility management solution should 315 ideally require minimal work to interface with a new wireless link 316 technology. 318 In addition, an edge mobility solution should provide support for multiple 319 wireless link technologies within the network in separate subnets. It is not 320 required that the localized mobility management solution support handover 321 from one wireless link technology to another without change in IP address. 322 The reason is because a change in network interface typically requires that 323 the hardware interface associated with one wireless link technology be 324 brought up and configured, and this process typically requires that the IP 325 stack for the new interface card be configured on the mobile node from the 326 driver up. Requiring that the mobile node IP stack circumvent this process 327 to keep the IP address constant would be a major change in the way the IP 328 stack software is implemented. 330 The goal is that the localized mobility management protocol should not use 331 any wireless link specific information for basic routing management, though 332 it may be used for other purposes, such as identifying a mobile node. 334 2.8 Support for Unmodified Mobile Nodes (Goal #8) 336 In the wireless LAN switching market, no modification of the software on the 337 mobile node is required to achieve "IP mobility" (which means localized 338 mobility management). Being able to accommodate unmodified mobile nodes 339 enables a service provider to offer service to as many customers as 340 possible, the only constraint being that the customer is authorized for 341 network access. 343 Another advantage of minimizing mobile node software for localized mobility 344 management is that multiple global mobility management protocols can be 345 supported with a localized mobility management solution that does not have 346 mobile node involvement. While Mobile IPv6 is clearly the global mobility 347 management protocol of primary interest going forward, there are a variety 348 of global mobility management protocols that might also need support, 349 including proprietary protocols needing support for backward compatibility 350 reasons. Within IETF, both HIP and Mobike are likely to need support in 351 addition to Mobile IPv6, and Mobile IPv4 support may also be necessary. 353 Note that this goal does NOT mean that the mobile node has no software at 354 all associated with mobility or wireless. The mobile node must have some 355 kind of global mobility protocol if it is to move from one domain of edge 356 mobility support to another, although no global mobility protocol is 357 required if the mobile node only moves within the coverage area of the 358 localized mobility management protocol. Also, every wireless link protocol 359 requires handover support on the mobile node in the physical and MAC layers, 360 typically in the wireless interface driver. Information passed from the MAC 361 layer to the IP layer on the mobile node may be necessary to trigger IP 362 signaling for IP link handover. Such movement detection support at the IP 363 level may be required in order to determine whether the mobile node's 364 default router is still reachable after the move to a new access point has 365 occurred at the MAC layer. Whether or not such support is required depends 366 on whether the MAC layer can completely hide link movement from the IP 367 layer. For a wireless link protocol such as the 3G protocols, the mobile 368 node and network undergo an extensive negotiation at the MAC layer prior to 369 handover, so it may be possible to trigger routing update without any IP 370 protocol involvement. However, for a wireless link protocol such as IEEE 371 802.11 in which there is no network involvement in handover, IP layer 372 movement detection signaling from the mobile node may be required to trigger 373 routing update. 375 The goal is that the localized mobility management solution should be able 376 to support any mobile node that walks up to the link and has a wireless 377 interface that can communicate with the network, without requiring localized 378 mobility management software on the mobile node. 380 2.9 Support for IPv4 and IPv6 (Goal #9) 382 While most of this document is written with IPv6 in mind, localized mobility 383 management is a problem in IPv4 networks as well. A solution for localized 384 mobility that works for both versions of IP is desirable, though the actual 385 protocol may be slightly different due to the technical details of how each 386 IP version works. From Goal #8 (Section 2.8), minimizing mobile node support 387 for localized mobility means that ideally no IP version-specific changes 388 would be required on the mobile node for localized mobility, and that global 389 mobility protocols for both IPv4 and IPv6 should be supported. Any IP 390 version-specific features would be confined to the network protocol. 392 2.10 Re-use of Existing Protocols Where Sensible (Goal #10) 394 Many existing protocols are available as Internet Standards upon which the 395 NETLMM protocol can be built. The design of the protocol should have a goal 396 to re-use existing protocols where it makes architectural and engineering 397 sense to do so. The design should not, however, attempt to re-use existing 398 protocols where there is no real architectural or engineering reason. For 399 example, the suite of Internet Standards contains several good candidate 400 protocols for the transport layer, so there is no real need to develop a new 401 transport protocol specifically for NETLMM. Re-use is clearly a good 402 engineering decision in this case, since backward compatibility with 403 existing protocol stacks is important. On the other hand, the network-based, 404 localized mobility management functionality being introduced by NETLMM is a 405 new piece of functionality, and therefore any decision about whether to re- 406 use an existing global mobility management protocol should carefully 407 consider whether re-using such a protocol really meets the needs of the 408 functional architecture for network-based localized mobility management. The 409 case for re-use is not so clear in this case, since there is no compelling 410 backward compatibility argument. 412 3.0 Security Considerations 413 There are two kinds of security issues involved in network-based localized 414 mobility management: security between the mobile node and the network, and 415 security between network elements that participate in the network-based 416 localized mobility management protocol 418 Security between the mobile node and the network itself consists of two 419 parts: threats involved in localized mobility management in general, and 420 threats to the network-based localized mobility management from the host. 421 The first is discussed above in Sections 2.3 and 2.6. The second is 422 discussed in the threat analysis document [28]. 424 For threats to network-based localized mobility management, the basic threat 425 is an attempt by an unauthorized party to signal a bogus mobility event. 426 Such an event must be detectable. This requires proper bidirectional 427 authentication and authorization of network elements that participate in the 428 network-based localized mobility management protocol, and data origin 429 authentication on the signaling traffic between network elements. 431 4.0 Author Information 433 James Kempf 434 DoCoMo USA Labs 435 181 Metro Drive, Suite 300 436 San Jose, CA 95110 437 USA 438 Phone: +1 408 451 4711 439 Email: kempf@docomolabs-usa.com 441 Kent Leung 442 Cisco Systems, Inc. 443 170 West Tasman Drive 444 San Jose, CA 95134 445 USA 446 EMail: kleung@cisco.com 448 Phil Roberts 449 Motorola Labs 450 Schaumberg, IL 451 USA 452 Email: phil.roberts@motorola.com 454 Katsutoshi Nishida 455 NTT DoCoMo Inc. 456 3-5 Hikarino-oka, Yokosuka-shi 457 Kanagawa, 458 Japan 459 Phone: +81 46 840 3545 460 Email: nishidak@nttdocomo.co.jp 462 Gerardo Giaretta 463 Telecom Italia Lab 464 via G. Reiss Romoli, 274 465 10148 Torino 466 Italy 467 Phone: +39 011 2286904 468 Email: gerardo.giaretta@tilab.com 470 Marco Liebsch 471 NEC Network Laboratories 472 Kurfuersten-Anlage 36 473 69115 Heidelberg 474 Germany 475 Phone: +49 6221-90511-46 476 Email: marco.liebsch@ccrle.nec.de 478 5.0 Informative References 480 [1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch, 481 M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet 482 Draft, work in progress. 483 [2] Vogt, C., and Kempf, J., "Security Threats to Network-based Localized 484 Mobillity Management", Internet draft, work in progress. 485 [3] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753, 486 June, 2004. 487 [4] Devarapalli,V., Wakikawa, R., Petrescu, A., Thubert, P., "Network 488 Mobility (NEMO) Basic Support Protocol", RFC 3963, January, 2005. 489 [5] Carpenter, B., "Architectural Principles of the Internet," RFC 1958, 490 June, 1996. 491 [6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", 492 RFC 3775. 493 [7] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host 494 Identity Protocol", Internet Draft, work in progress. 495 [8] Choi, J, and Daley, G., "Goals of Detecting Network Attachment in 496 IPv6", Internet Draft, work in progress. 497 [9] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 498 2001. 499 [10] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A., 500 "Protocol for Carrying Authentication for Network Access (PANA)", 501 Internet Draft, work in progress. 502 [11] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor 503 Discovery (SEND)", RFC 3971, March, 2005. 504 [12] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work in 505 Progress. 506 [13] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law 507 and Policy in the US, EU, and Japan", ISOC Member Briefing #15, 508 http://www.isoc.org/briefings/015/index.shtml 509 [14] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and 510 Patil, B., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem 511 Statement", Internet Draft, work in progress. 512 [15] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol", 513 Internet Draft, work in progress. 514 [16] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet 515 Draft, work in progress. 517 [17] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., "Solutions 518 for IP Address Location Privacy in the presence of IP Mobility", 519 Internet Draft, work in progress. 520 [18] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol for 521 Protecting Movement of Mobile Nodes in Mobile IPv6", Internet Draft, 522 work in progress. 523 [19] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H., 524 Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for 525 Hosts and Routers", Internet Draft, work in progress. 526 [20] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July, 527 2005. 528 [21] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., 529 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, 530 August, 2005. 531 [22] Kempf, J., and Koodli, R., "Bootstrapping a Symmetric IPv6 Handover Key 532 from SEND", Internet Draft, work in progress. 533 [23] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design, 534 Implementation and Evaluation of Cellular IP", IEEE Personal 535 Communications, June/July 2000. 536 [24] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A 537 domain-based approach for supporting mobility in wide-area wireless 538 networks", in Proceedings of the International Conference on Networking 539 Protocols (ICNP), 1999. 540 [25] "Mobile VPN Network Configuration Alternatives", IP Unplugged, 541 http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf. 542 [26] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, 543 Feburary, 1990. 544 [27] Moy, J., "OSPF Version 2", STD 54, April, 1998. 545 [28] Threat analysis draft, TBD 547 6.0 IPR Statements 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in this 552 document or the extent to which any license under such rights might or might 553 not be available; nor does it represent that it has made any independent 554 effort to identify any such rights. Information on the procedures with 555 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any assurances of 558 licenses to be made available, or the result of an attempt made to obtain a 559 general license or permission for the use of such proprietary rights by 560 implementers or users of this specification can be obtained from the IETF 561 on-line IPR repository at http://www.ietf.org/ipr. 563 The IETF invites any interested party to bring to its attention any 564 copyrights, patents or patent applications, or other proprietary rights that 565 may cover technology that may be required to implement this standard. 566 Please address the information to the IETF at ietf-ipr@ietf.org. 568 7.0 Disclaimer of Validity 570 This document and the information contained herein are provided on an "AS 571 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 572 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 573 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 574 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 575 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 576 FOR A PARTICULAR PURPOSE. 578 8.0 Copyright Notice 580 Copyright (C) The Internet Society (2006). This document is subject to the 581 rights, licenses and restrictions contained in BCP 78, and except as set 582 forth therein, the authors retain all their rights. 584 9.0 Appendix: Gap Analysis 586 This section discusses a gap analysis between existing proposals for solving 587 localized mobility management and the goals in Section. 2.0. 589 9.1 Mobile IPv6 with Local Home Agent 591 One option is to deploy Mobile IPv6 with a locally assigned home agent in 592 the local network. This solution requires the mobile node to somehow be 593 assigned a home agent in the local network when it boots up. This home agent 594 is used instead of the home agent in the home network. The advantage of this 595 option is that no special solution is required for edge mobility - the 596 mobile node reuses the global mobility management protocol for that purpose 597 - if the mobile node is using Mobile IPv6. One disadvantage is that Mobile 598 IP has no provision for handover between home agents. Although such handover 599 should be infrequent, it could be quite lengthy and complex. 601 The analysis of this approach against the goals above is the following. 603 Goal #1: If the mobile node does not perform route optimization, this 604 solution reduces, but does not eliminate, IP link handover related 605 performance problems. 607 Goal #2: Similarly to Goal #1, signaling volume is reduced if no route 608 optimization signaling is done on handover. 610 Goal #3: Location privacy is preserved for external correspondents, but the 611 mobile node itself still maintains a local care-of address which a worm or 612 other exploit could misuse. If the mobile node does perform route 613 optimization, location privacy may be compromised, and this solution is no 614 better than having a remote home agent. 616 Goal #4: If traffic is not route optimized, the mobile node still pays for 617 an over-the-air tunnel to the locally assigned home agent. The overhead here 618 is exactly the same as if the mobile node's home agent in the home network 619 is used and route optimization is not done. 621 Goal #5: If the localized mobility management domain is large, the mobile 622 node may suffer from unoptimzed routes. RFC 3775 [6] provides no support for 623 notifying a mobile node that another localized home agent is available for a 624 more optimized route, or for handing over between home agents. A mobile node 625 would have to perform the full home agent bootstrap procedure, including 626 establishing a new IPsec SA with the new home agent. 628 Goal #6: A local home agent in a roaming situation requires the guest mobile 629 node to have the proper credentials to authenticate with the local home 630 agent in the serving network. Although the credentials used for network 631 access authentication could also be used for mobile service authentication 632 and authorization if the local home agent uses EAP over IKEv2 to 633 authenticate the mobile node with its home AAA server, the two sets of 634 credentials are in principle different, and could require additional 635 credential provisioning. In addition, as in Goal #3, if binding updates are 636 done in cleartext over the access network or the mobile node has become 637 infected with malware, the local home agent's address could be revealed to 638 attackers and the local home agent could become the target of a DoS attack. 639 So a local home agent would provide no benefit for this goal. 641 Goal #7: This solution supports multiple wireless technologies in separate 642 IP link subnets. No special work is required to interface a local home agent 643 to different wireless technologies. 645 Goal #8: The mobile node must support Mobile IPv6 in order for this option 646 to work. So mobile node changes are required and other IP mobility protocols 647 are not supported. 649 Goal #9: The Mobile IPv6 working group is working on modifying the protocol 650 to allow registration of IPv4 care-of addresses in an IPv6 home agent, and 651 also to allow a mobile node to have an IPv4 care of address [19]. 653 Goal #10 This solution re-uses an existing protocol, Mobile IPv6. 655 9.2 Hierarchical Mobile IPv6 (HMIPv6) 657 HMIPv6 [21] provides the most complete localized mobility management 658 solution available today as an RFC. In HMIPv6, a localized mobility anchor 659 called a MAP serves as a routing anchor for a regional care-of address. When 660 a mobile node moves from one access router to another, the mobile node 661 changes the binding between its regional care-of address and local care-of 662 address at the MAP. No global mobility management signaling is required, 663 since the care-of address seen by correspondents does not change. This part 664 of HMIPv6 is similar to the solution outlined in Section 9.1; however, 665 HMIPv6 also allows a mobile node to hand over between MAPs. 667 Handover between MAPs and MAP discovery requires configuration on the 668 routers. MAP addresses are advertised by access routers. Handover happens by 669 overlapping MAP coverage areas so that, for some number of access routers, 670 more than one MAP may be advertised. Mobile nodes need to switch MAPs in the 671 transition area, and then must perform global mobility management update and 672 route optimization to the new regional care-of address, if appropriate. 674 The analysis of this approach against the goals above is the following. 676 Goal #1 This solution shortens, but does not eliminate, the latency 677 associated with IP link handover, since it reduces the amount of signaling 678 and the length of the signaling paths. 680 Goal #2 Signaling volume is reduced simply because no route optimization 681 signaling is done on handover within the coverage area of the MAP. 683 Goal #3 Location privacy is preserved for external correspondents, but the 684 mobile node itself still maintains a local care-of address which a worm or 685 other exploit could access by sending the local care-of address to third 686 malicious node to enable it to track the mobile node's location. 688 Goal #4 The mobile node always pays for an over-the-air tunnel to the MAP. 689 If the mobile node is tunneling through a global home agent or VPN gateway, 690 the wired link experiences double tunneling. Over-the-air tunnel overhead 691 can be removed by header compression, however. 693 Goal #5 From Goal #1 and Goal #4, the signaling overhead is no more or less 694 than for mobile nodes whose global mobility management anchor is local. 695 However, because MAP handover is possible, routes across large localized 696 mobility management domains can be improved thereby improving wired network 697 resource utilization by using multiple MAPs and handing over, at the expense 698 of the configuration and management overhead involved in maintaining 699 multiple MAP coverage areas. 701 Goal #6 In a roaming situation, the guest mobile node must have the proper 702 credentials to authenticate with the MAP in the serving network. In 703 addition, since the mobile node is required to have a unicast address for 704 the MAP that is either globally routed or routing restricted to the local 705 administrative domain, the MAP is potentially a target for DoS attacks 706 across a wide swath of network topology. 708 Goal #7 This solution supports multiple wireless technologies in separate IP 709 link subnets. 711 Goal #8 This solution requires modification to the mobile nodes. In 712 addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, 713 and is not a good match for other global mobility management protocols. 715 Goal #9 Currently, there is no IPv4 version of this protocol; although there 716 is an expired Internet draft with a design for a regional registration 717 protocol for Mobile IPv4 that has similar functionality. It is possible that 718 the same IPv4 transition solution as used for Mobile IPv6 could be used 719 [19]. 721 Goal #10 This solution re-uses an existing protocol, HMIPv6. 723 9.3 Combinations of Mobile IPv6 with Optimizations 725 One approach to local mobility that has received much attention in the past 726 and has been thought to provide a solution is combinations of protocols. The 727 general approach is to try to cover gaps in the solution provided by MIPv6 728 by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6 729 and HMIPv6 + FMIPv6 are discussed. 731 9.3.1 MIPv6 + FMIPv6 733 As discussed in Section 9.1, the use of MIPv6 with a dynamically assigned, 734 local home agent cannot fulfill the goals. A fundamental limitation is that 735 Mobile IPv6 cannot provide seamless handover (i.e. Goal #1). FMIPv6 has been 736 defined with the intent to improve the handover performance of MIPv6. For 737 this reason, the combined usage of FMIPv6 and MIPv6 with a dynamically 738 assigned local home agent has been proposed to handle local mobility. 740 Note that this gap analysis only applies to localized mobility management, 741 and it is possible that MIPv6 and FMIPv6 might still be acceptable for 742 global mobility management. 744 The analysis of this combined approach against the goals follows. 746 Goal #1 FMIPv6 provides a solution for handover performance improvement that 747 should fulfill the goals raised by real-time applications in terms of 748 jitter, delay and packet loss. The location of the home agent (in local or 749 home domain) does not affect the handover latency. 751 Goal #2 FMIPv6 requires the mobile node to perform extra signaling with the 752 access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as 753 in standard MIPv6, whenever the mobile node moves to another IP link, it 754 must send a Binding Update to the home agent. If route optimization is used, 755 the mobile node also performs return routability and sends a Binding Update 756 to each correspondent node. Nonetheless, it is worth noting that FMIPv6 757 should result in a reduction of the amount of IPv6 Neighbor Discovery 758 signaling on the new link. 760 Goal #3 The mobile node mantains a local care-of address. If route 761 optimization is not used, location privacy can be achieved using bi- 762 directional tunneling. However, as mentioned in Section 9.1, a worm or other 763 malware can exploit this care of address by sending it to a third malicious 764 node. 766 Goal #4 As stated for Goal #2, the combination of MIPv6 and FMIPv6 generates 767 extra signaling overhead. For data packets, in addition to the Mobile IPv6 768 over-the-air tunnel, there is a further level of tunneling between the 769 mobile node and the previous access router during handover. This tunnel is 770 needed to forward incoming packets to the mobile node addressed to the 771 previous care-of address. Another reason is that, even if the mobile node 772 has a valid new care-of address, the mobile node cannot use the new care of 773 address directly with its correspondents without performing route 774 optimization to the new care of address. This implies that the transient 775 tunnel overhead is in place even for route optimized traffic. 777 Goal #5 FMIPv6 generates extra signaling overhead between the previous 778 access router and the new access router for the HI/HAck exchange. Concerning 779 data packets, the use of FMIPv6 for handover performance improvement implies 780 a tunnel between the previous access router and the mobile node that adds 781 some overhead in the wired network. This overhead has more impact on star 782 topology deployments, since packets are routed down to the old access 783 router, then back up to the aggregation router and then back down to the new 784 access router. 786 Goal #6 In addition to the analysis for Mobile IPv6 with local home agent in 787 Section 9.1, FMIPv6 requires the mobile node and the previous access router 788 to share a security association in order to secure FBU/FBA exchange. So far, 789 only a SEND-based solution has been proposed and this requires the mobile 790 node to use autoconfigured Cryptographically Generated Addresses (CGAs)[22]. 791 This precludes stateful address allocation using DHCP, which might be a 792 necessary deployment in certain circumstances. Another solution based on AAA 793 is under study but it could require extra signaling overhead over the air 794 and in the wired network and it could raise performance issues. 796 Goal #7 MIPv6 and FMIPv6 support multiple wireless technologies, so this 797 goal is fufilled. 799 Goal #8 The mobile node must support both MIPv6 and FMIPv6, so it is not 800 possible to satisfy this goal. 802 Goal #9 Work is underway to extend MIPv6 with the capability to run over 803 both IPv6-enabled and IPv4-only networks [19]. FMIPv6 only supports IPv6. 804 Even though an IPv4 version of FMIP has been recently proposed, it is not 805 clear how it could be used together with FMIPv6 in order to handle fast 806 handovers across any wired network. 808 Goal #10 This solution re-uses existing protocols, Mobile IPv6 and FMIPv6. 810 9.3.2 HMIPv6 + FMIPv6 812 HMIPv6 provides several advantages in terms of local mobility management. 813 However, as seen in Section 9.2, it does not fulfill all the goals 814 identified in Section 2.0. In particular, HMIPv6 does not completely 815 eliminate the IP link handover latency. For this reason, FMIPv6 could be 816 used together with HMIPv6 in order to cover the gap. 818 Note that even if this solution is used, the mobile node is likely to need 819 MIPv6 for global mobility management, in contrast with the MIPv6 with 820 dynamically assigned local home agent + FMIPv6 solution. Thus, this solution 821 should really be considered MIPv6 + HMIPv6 + FMIPv6. 823 The analysis of this combined approach against the goals follows. 825 Goal #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP link 826 handovers. In particular, FMIPv6 is expected to fulfill the goals on jitter, 827 delay and packet loss raised by real-time applications. 829 Goal #2 Both FMIPv6 and HMIPv6 require extra signaling compared with Mobile 830 IPv6. As a whole the mobile node performs signaling message exchanges at 831 each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. However, 832 as mentioned in Section 9.2, the use of HMIPv6 reduces the signaling 833 overhead since no route optimization signaling is done for intra-MAP 834 handovers. In addition, na�ve combinations of FMIPv6 and HMIPv6 often result 835 in redundant signaling. There is much work in the academic literature and 836 the IETF on more refined ways of combining signaling from the two protocols 837 to avoid redundant signaling. 839 Goal #3 HMIPv6 may preserve location privacy, depending on the dimension of 840 the geographic area covered by the MAP. As discussed in Section 9.2, the 841 mobile node still maintains a local care-of address that can be exploited by 842 worms or other malware. 844 Goal #4 As mentioned for Goal #2, the combination of HMIPv6 and FMIPv6 845 generates a lot of signaling overhead in the network. Concerning payload 846 data, in addition to the over-the-air MIPv6 tunnel, a further level of 847 tunneling is established between mobile node and MAP. Notice that this 848 tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is 849 directly applied to HMIPv6 networks, there is a third temporary handover- 850 related tunnel between the mobile node and previous access router. Again, 851 there is much work in the academic literature and IETF on ways to reduce the 852 extra tunnel overhead on handover by combining HMIP and FMIP tunneling. 854 Goal #5 The signaling overhead in the network is not reduced by HMIPv6, as 855 mentioned in Section 9.2. Instead, FMIPv6 generates extra signaling overhead 856 between the previous access router and new access router for HI/HAck 857 exchange. For payload data, the same considerations as for Goal #4 are 858 applicable. 860 Goal #6 FMIPv6 requires the mobile node and the previous access router to 861 share a security association in order to secure the FBU/FBA exchange. In 862 addition, HMIPv6 requires that the mobile node and MAP share an IPsec 863 security association in order to secure LBU/LBA exchange. The only well 864 understood approach to set up an IPsec security association using of 865 certificates, but this may raise deployment issues. Thus, the combination of 866 FMIPv6 and HMIPv6 doubles the amount of mobile node to network security 867 protocol required, since security for both FMIP and HMIP must be deployed. 869 Goal #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so this 870 goal is fufilled. 872 Goal #8 The mobile node must support both HMIPv6 and FMIPv6 protocols, so 873 this goal is not fulfilled. 875 Goal #9 Currently there is no IPv4 version of HMIPv6. There is an IPv4 876 version of FMIP but it is not clear how it could be used together with 877 FMIPv6 in order to handle fast handovers across any wired network. 879 Goal #10 This solution re-uses existing protocols, HMIPv6 and FMIPv6. 881 9.4 Micromobility Protocols 883 Researchers have defined some protocols that are often characterized as 884 micromobility protocols. Two typical protocols in this category are 885 Cellular-IP [23] and HAWAII [24]. Researchers defined these protocols before 886 local mobility optimizations for Mobile IP such as FMIP and HMIP were 887 developed, in order to reduce handover latency. 889 The micromobility approach to localized mobility management requires host 890 route propagation from the mobile node to a collection of specialized 891 routers in the localized mobility management domain along a path back to a 892 boundary router at the edge of the localized mobility management domain. A 893 boundary router is a kind of localized mobility management domain gateway. 894 Localized mobility management is authorized with the access router, but 895 reauthorization with each new access router is necessary on IP link 896 movement, in addition to any reauthorization for basic network access. The 897 host routes allow the mobile node to maintain the same IP address when it 898 moves to a new IP link, and still continue to receive packets on the new IP 899 link. 901 Cellular IP and HAWAII have a few things in common. Both are compatible 902 with Mobile IP and are intended to provide a higher level of handover 903 performance in local networks than was previously available with Mobile IP 904 without such extensions as HMIP and FMIP. Both use host routes installed in 905 a number of routers within a restricted routing domain. Both define specific 906 messaging to update those routes along the forwarding path and specify how 907 the messaging is to be used to update the routing tables and forwarding 908 tables along the path between the mobile and a micromobility domain boundary 909 router at which point Mobile IP is to used to handle scalable global 910 mobility. Unlike the FMIP and HMIP protocols, however, these protocols do 911 not require the mobile node to obtain a new care of address on each access 912 router as it moves; but rather, the mobile node maintains the same care of 913 address across the micromobility domain. From outside the micromobility 914 domain, the care of address is routed using traditional longest prefix 915 matching IP routing to the domain's boundary router, so the care of address 916 conceptually is within the micromobiity domain boundary router's subnet. 917 Within the micromobility domain, the care of address is routed to the 918 correct access router using host routes. 920 Cellular IP and HAWAII differ in a few aspects. Cellular IP seems to be 921 restricted, based on the nature of the protocol, to tree-based network 922 topologies. HAWAII claims to be applicable in both tree-based and more 923 complete network topologies. HAWAII documents more functionality in the 924 realm of reliability and QoS interworking. Both protocols involve the 925 mobile node itself in mobility operations, although this is also true of the 926 Mobile IP based optimizations, so both protocols raise the same security 927 concerns with respect to authorizing address update as the Mobile IP based 928 optimizations. HAWAII provides some analysis of network deployment 929 scenarios including scale, density, and efficiency, but some of these 930 assumptions seem very conservative compared to realistic cellular type 931 deployments. 933 Micromobility protocols have some potential drawbacks from a deployment and 934 scalability standpoint. Both protocols involve every routing element between 935 the mobile device and the micromobility domain boundary router in all packet 936 forwarding decisions specific to care of addresses for mobile nodes. 937 Scalability is limited because each care of address corresponding to a 938 mobile node generates a routing table entry, and perhaps multiple forwarding 939 table entries, in every router along the path. Since mobile nodes can have 940 multiple global care of addresses in IPv6, this can result in a large 941 expansion in router state throughout the micromobility routing domain. 942 Although the extent of the scalability for micromobility protocols is still 943 not clearly understood from a research standpoint, it seems certain that 944 they will be less scalable than the Mobile IP optimization enhancements, and 945 will require more specialized gear in the wired network. 947 The following is a gap analysis of the micromobility protocols against the 948 goals in Section 2.0: 950 Goal #1 The micromobility protocols reduce handover latency by quickly 951 fixing up routes between the boundary router and the access router. While 952 some additional latency may be expected during host route propagation, it is 953 typically much less than experienced with standard Mobile IP. 955 Goal #2 The micromobility protocols require signaling from the mobile node 956 to the access router to initiate the host route propagation, but that is a 957 considerable reduction over the amount of signaling required to configure to 958 a new IP link. 960 Goal #3 No care-of address changes are exposed to correspondent nodes or the 961 mobile node itself while the mobile node is moving in the micromobility- 962 managed network. Because there is no local care-of address, there is no 963 threat from malware that exposes the location by sending the care-of address 964 to an adversary. 966 Goal #4 The only additional over-the-air signaling is involved in 967 propagating host routes from the mobile node to the network upon movement. 968 Since this signaling would be required for movement detection in any case, 969 it is expected to be minimal. Mobile node traffic experiences no overhead. 971 Goal #5 Host route propagation is required throughout the wired network. The 972 volume of signaling could be more or less depending on the speed of mobile 973 node movement and the size of the wired network. 975 Goal #6 The mobile node only requires a security association of some type 976 with the access router. Because the signaling is causing routes to the 977 mobile node's care-of address to change, the signaling must prove 978 authorization to hold the address. 980 Goal #7 The micromobility protocols support multiple wireless technologies, 981 so this goal is satisfied. 983 Goal #8 The mobile node must support some way of signaling the access router 984 on link handover, but this is required for movement detection anyway. The 985 nature of the signaling for the micromobility protocols may mobile node 986 software changes, however. 988 Goal #9 Most of the work on the micromobility protocols was done in IPv4, 989 but little difference could be expected for IPv6. 991 Goal #10 This solution does not reuse an existing protocol because there is 992 currently no Internet Standard protocol for micromobility. 994 9.5 Standard Internal Gateway Route Distribution Protocols (OSPF and IS-IS) 996 It has also been suggested that instead of using a specialized 997 micromobility routing protocol in the access network, a standardized 998 Internal Gateway route distribution Protocol (IGP) such as IS-IS [26] or 999 OSPF [27] should be used to distribute host routes. Host route messages are 1000 formatted in the IGPs by including a subnet mask in the route information 1001 update, indicating that the address is a /32 for IPv4 or a /128 for IPv6 1002 instead of a subnet prefix. Since IGPs typically distribute route 1003 information by flooding, every router in the domain obtains a copy of the 1004 host route eventually. Using an IGP instead of a micromobility protocol has 1005 the advantage that standardized routing equipment can be used for all 1006 routers in the access network, and, if a particular router goes down, the 1007 host routes maintained along alternate routes should be sufficient to 1008 continue routing, unlike micromobility protocols where only targeted routers 1009 have the host routes. 1011 Distributing host routes with an IGP has some significant disadvantages 1012 however. One is that flooding requires a certain amount of time to converge; 1013 so for some period after the link handover blackout, delivery to a mobile 1014 node that has moved will be disrupted until convergence along the routes 1015 traveled by the mobile node's traffic has occurred. Because micromobility 1016 protocols target host routes back to the micromobility domain border router, 1017 convergence can potentially be achieved more quickly. Tunnel-based solutions 1018 such as HMIP don't suffer from convergence latency because only the two 1019 endpoints need to know the routing. As a result, the internal routing 1020 tables updated by the IGP remain stable when a mobile node moves. The 1021 movement does not affect routing of traffic to other mobile nodes due to 1022 intensive path computation. 1024 Another disadvantage of using an IGP is that each router in the domain must 1025 maintain a full host route table for all hosts. This goal raises a 1026 scalability issue. For example, an experiment [25] using OSPF to distribute 1027 host routes through an access network consisting of a collection of rather 1028 smallish enterprise routers indicated that about 25,000 routes could be 1029 supported in 22 Mb of memory before performance started to degrade. This 1030 works out to about 0.88 kb/host. Scaling this up to, say, 10 million hosts 1031 (what one might expect in a large metropolitan area such as Tokyo or San 1032 Francisco) would require about 8.8 Gb of memory per router. While memory 1033 costs continue to drop, the amount of processing power for searching a 1034 routing database of that size essentially means that each router in the 1035 domain must have the same processing power as a high end, border router. 1036 Micromobility and tunnel- based solutions don't suffer from this problem, 1037 because the host route is local to the tunnel endpoints. Other routers in 1038 the domain route based on highly scalable shortest matching network prefix 1039 method. 1041 The following is a gap analysis of host route distribution using a 1042 standardized IGP against the goals in Section 2.0: 1044 Goal #1 Host route distribution using an IGP is likely to suffer from 1045 increased handover latency due to a lag time as routes converge over the 1046 access network. The exact amount of latency depends on the convergence 1047 characteristics of the particular IGP and the topology of the access 1048 network, i.e. how fast convergence occurs along routes taken by the mobile 1049 node's traffic. 1051 Goal #2 Host route distribution using an IGP requires signaling from the 1052 mobile node to the access router to initiate the host route propagation, but 1053 that is a considerable reduction over the amount of signaling required to 1054 configure to a new IP link. However, if a mobile node is moving quickly, the 1055 flooding traffic necessary to propagate a host route may not converge before 1056 the mobile node hands over again. This could result in a cacscading series 1057 of host route updates that never converge. Whether or not this effect occurs 1058 depends on the size of the localized mobility domain, and so the need to 1059 ensure convergence places an upper bound on the size of the domain or 1060 expected movement speed of the mobile nodes. 1062 Goal #3 No care-of address changes are exposed to correspondent nodes or the 1063 mobile node itself while the mobile node is moving in the localized mobility 1064 management domain. Because there is no local care-of address, there is no 1065 threat from malware that exposes the location by sending the care-of address 1066 to an adversary. 1068 Goal #4 The only additional over-the-air signaling involved is signaling 1069 from the mobile node to the access router indicating that the mobile node 1070 has moved. Mobile node traffic experiences no overhead. 1072 Goal #5 Host route propagation is required throughout the wired network. The 1073 volume of signaling could be more or less depending on the speed of mobile 1074 node movement and the size of the wired network. 1076 Goal #6 The mobile node only requires a security association of some type 1077 with the access router. Because the signaling is causing routes to the 1078 mobile node's care-of address to change, the signaling must prove 1079 authorization to hold the address. 1081 Goal #7 This goal is satisfied by default, since the IGPs are used over the 1082 wired backbone. 1084 Goal #8 The mobile node needs to perform some kind of active movement 1085 detection with proof of identity to trigger the host route distribution, but 1086 this kind of signaling is needed for movement regardless of whether 1087 localized mobility management is deployed. Depending on the wireless link 1088 type, this may be handled by the wireless link layer. 1090 Goal #9 Since the IGPs support both IPv4 and IPv6, both are supported by 1091 this technique. 1093 Goal #10 This solution re-uses existing protocols, OSPF or IS-IS. 1095 9.6 Summary 1097 The following table summarizes the discussion in Section 9.1 through 9.5. In 1098 the table, a "M" indicates that the protocol completely meets the goal, a 1099 "P" indicates that it partially meets the goal, and an "X" indicates that it 1100 does not meet the goal. 1102 Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 1103 -------- -- -- -- -- -- -- -- -- -- --- 1105 MIPv6 P X X X X X M X M M 1107 HMIPv6 P X X X P X M X X M 1109 MIPv6 + 1110 FMIPv6 M X X X P X M X P M 1112 HMIPv6 + 1113 FMIPv6 M X X X X X M X X M 1115 Micro. M M M M P M M M P X 1117 IGP X M M M X M M M M M