idnits 2.17.1 draft-kempf-netlmm-nohost-req-00.txt: -(598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(862): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(895): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(897): 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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 929. ** 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 are 5 instances 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: ' 4.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.) ** The document seems to lack an Authors' Addresses Section. ** There are 589 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 30 has weird spacing: '... The list...' == Line 33 has weird spacing: '... The list ...' == Line 75 has weird spacing: '...agement proto...' == Line 137 has weird spacing: '...y, and minim...' == Line 138 has weird spacing: '...network equip...' == (32 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 855 looks like a reference -- Missing reference section? '2' on line 858 looks like a reference -- Missing reference section? '19' on line 897 looks like a reference -- Missing reference section? '3' on line 860 looks like a reference -- Missing reference section? '4' on line 862 looks like a reference -- Missing reference section? '5' on line 864 looks like a reference -- Missing reference section? '6' on line 866 looks like a reference -- Missing reference section? '7' on line 868 looks like a reference -- Missing reference section? '8' on line 870 looks like a reference -- Missing reference section? '9' on line 873 looks like a reference -- Missing reference section? '10' on line 875 looks like a reference -- Missing reference section? '12' on line 880 looks like a reference -- Missing reference section? '14' on line 885 looks like a reference -- Missing reference section? '15' on line 887 looks like a reference -- Missing reference section? '16' on line 890 looks like a reference -- Missing reference section? '17' on line 893 looks like a reference -- Missing reference section? '20' on line 900 looks like a reference -- Missing reference section? '21' on line 902 looks like a reference -- Missing reference section? '22' on line 905 looks like a reference -- Missing reference section? '11' on line 877 looks like a reference -- Missing reference section? '13' on line 883 looks like a reference -- Missing reference section? '18' on line 895 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Kempf 3 Internet Draft K. Leung 4 Document: draft-kempf-netlmm-nohost-req-00.txt P. Roberts 5 K. Nishida 6 G. Giaretta 7 M. Liebsch 9 Expires: January, 2006 July, 2005 11 Requirements and Gap Analysis for IP Local Mobility 12 (draft-kempf-netlmm-nohost-req-00.txt) 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any applicable 17 patent or other IPR claims of which he or she is aware have been or will be 18 disclosed, and any of which he or she becomes aware will be disclosed, in 19 accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task Force 22 (IETF), its areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months and 26 may be updated, replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet-Drafts as reference material or to cite them 28 other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In draft-kempf-netlmm-nohost-ps, the problems with using global IP mobility 39 management protocols for local mobility and some problems with existing 40 localized mobility management protocols are described. In this document, we 41 explore requirements for localized mobility management in more detail. An 42 extensive gap analysis against the protocols illustrates where existing 43 protocols are able to fulfill the requirements and where they are lacking. 45 Table of Contents 47 1.0 Introduction.....................................................2 48 2.0 Requirements for Localized Mobility Management...................3 49 3.0 Gap Analysis.....................................................7 50 4.0 Security Considerations.........................................14 51 5.0 Recommendation..................................................15 52 6.0 Author Information..............................................16 53 7.0 Informative References..........................................17 54 8.0 IPR Statements..................................................18 55 9.0 Disclaimer of Validity..........................................18 56 10.0 Copyright Notice................................................18 58 1.0 Introduction 60 In draft-kempf-netlmm-nohost-ps [1], the basic problems that occur when a 61 global mobility protocol is used for managing local mobility are described, 62 and two basic approaches to localized mobility management - the host-based 63 approach that is used by most IETF protocols and the WLAN switch approach 64 are examined. The conclusion from the problem statement document is that 65 neither approach has a complete solution to the problem. While the WLAN 66 switch approach is most convenient for network operators and users because 67 it requires no host support, the proprietary nature limits interoperability 68 and the restriction to a single wireless link type and wired backhaul link 69 type restricts scalablity. The IETF host-based protocols require host 70 software stack changes that may not be compatible with all global mobility 71 protocols, and also require specialized and complex security transactions 72 with the network that may limit deployability. 74 This document develops more detailed requirements for a localized mobility 75 management protocol and analyzes existing protocols against those 76 requirements. In Section 2.0, we review a list of requirements that are 77 desirable in a localized mobility management solution. Section 3.0 performs 78 a gap analysis against the requirements of proposed solutions to localized 79 mobility management. Section 4.0 briefly outlines security considerations. 80 Finally, in Section 5.0, a recommendation is made for the development of a 81 network-based approach to localized mobility management. 83 1.1 Terminology 85 Mobility terminology in this draft follows that in RFC 3753 [2] and in [1]. 86 In addition, the following terms are used here: 88 Host-Based Approach 89 A host-based approach to localized mobility management requires binding 90 between a local care-of address and a regional care-of address at a 91 mobility anchor within the localized mobility management domain. The 92 binding is maintained by the mobile node and requires software in the 93 mobile node's stack to perform the binding. The localized mobility 94 service is authorized with the mobility anchor point separately from 95 network access. An example is HMIPv6 [19]. A mobility anchor is a kind 96 of localized mobility management domain gateway. The regional care-of 97 address is fixed at the mobility anchor while the local care-of address 98 on the access router changes when the mobile node moves to a new IP 99 link. 101 Micromobility Approach 102 A micromobility approach to localized mobility management requires host 103 route propagation from the mobile node to a collection of specialized 104 routers in the localized mobility management domain along a path back 105 to a boundary router at the edge of the localized mobility management 106 domain. A boundary router is a kind of localized mobility management 107 domain gateway. Localized mobility management is authorized with the 108 access router, but reauthorization with each new access router is 109 necessary on IP link movement, in addition to any reauthorization for 110 basic network access. The host routes allow the mobile node to maintain 111 the same IP address when it moves to a new IP link, and still continue 112 to receive packets on the new IP link. 114 Edge Mobility Approach 115 In the edge mobility approach to localized mobility management, the 116 access routers update bindings between the mobile node's care-of 117 address and the mobile node's current IP link. The bindings are 118 maintained at an edge mobility anchor point. No host involvement is 119 required beyond movement detection. The mobile node requires no special 120 authorization for localized mobility management service beyond the 121 authorization required for basic network access. A mobile node's IP 122 address does not change when the mobile node moves from one access 123 router to another within the coverage area of the edge mobility anchor 124 point, because the mobility anchor and access routers take care of 125 changing the routing. 127 2.0 Requirements for Localized Mobility Management 129 Any localized mobility solution must naturally address the three problems 130 described in [1]. In addition, the side effects of introducing such a 131 solution into the network need to be limited. In this section, we address 132 requirements on a localized mobility solution including both solving the 133 basic problems and limiting the side effects. 135 Some basic requirements of all IETF protocols are not discussed in detail 136 here, but any solution is expected to satisfy them. These requirements are 137 interoperability, scalability, and minimal requirement for specialized 138 network equipment. A good discussion of their applicability to IETF 139 protocols can be found in [3]. 141 Out of scope for the initial requirements discussion are QoS, multicast, and 142 dormant mode/paging. While these are important functions for mobile hosts, 143 they are not part of the base localized mobility management problem. In 144 addition, mobility between localized mobility management domains is not 145 covered here. It is assumed that this is covered by the global mobility 146 management protocols. 148 2.1 Handover Performance Improvement (Requirement #1) 150 Handover packet loss occurs because there is usually latency between when 151 the wireless link handover starts and when the IP link handover completes. 152 During this time the mobile node is unreachable at its former topological 153 location on the old IP link where correspondents are sending packets and to 154 which the routing system is routing them. Such misrouted packets are 155 dropped. This aspect of handover performance optimization has been the 156 subject of an enormous amount of work, both in other SDOs, to reduce the 157 latency of wireless link handover, and in the IETF and elsewhere, to reduce 158 the latency in IP link handover. Many solutions to this problem have been 159 proposed at the wireless link layer and at the IP layer. 161 Note that a related problem occurs when traffic packets are not routed 162 through a global mobility anchor such as a Mobile IP home agent. Route 163 optimized Mobile IPv6 [4] and HIP [5] are examples. A loss of connectivity 164 can occur when both sides of the IP conversation are mobile and they both 165 hand over at the same time. The two sides must use a global mobility anchor 166 point, like a home agent or rendezvous server, to re-establish the 167 connection, but there may be substantial packet loss until the problem is 168 discovered. 170 In both cases, the loss of accurate routing caused the connection to 171 experience an interruption which may cause service degradation for real time 172 traffic such as voice 174 2.2 Reduction in Handover-related Signaling Volume (Requirement #2) 176 Considering Mobile IPv6 as the global mobility protocol (other mobility 177 protocols require about the same or somewhat less), if a mobile node is 178 required to reconfigure on every move between IP links, the following set of 179 signaling messages must be done: 181 1) Movement detection using DNA [6] or possibly a link specific protocol, 182 2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or PANA [8]. 183 The mobile node may also or instead have to obtain a router certificate 184 using SEND [9], if the certificate is not already cached, 185 3) Router discovery which may be part of movement detection, 186 4) If stateless address autoconfiguration is used, address configuration and 187 Duplicate Address Detection (unless optimistic Duplicate Address 188 Detection [10] is used). If stateful address configuration is used, then 189 DHCP is used for address configuration, 190 5) Binding Update to the home agent, 191 6) If route optimization is in effect, return routability to establish the 192 binding key, 193 7) Binding Update to correspondent nodes for route optimization. 195 Note that Steps 1-2 will always be necessary, even for intra-link mobility, 196 and Step 3 will be necessary even if the mobile node's care-of address can 197 remain the same when it moves to a new access router. 199 This is a lot of signaling just to get up on a new IP link. Furthermore, in 200 some cases, the mobile node may need to engage in "heartbeat signaling" to 201 keep the connection with the correspondent or global mobility anchor fresh, 202 for example, return routability in Mobile IPv6 must be done at a maximum 203 every 7 minutes even if the mobile node is standing still. 205 2.3 Location privacy (Requirement #3) 207 Location privacy in the context of IP mobility refers to hiding the 208 geographic location of mobile users. Although general location privacy 209 issues have been discussed in [12], the location privacy referred to here 210 focuses on the IP layer and involves the basic property of the IP address 211 that may change due to the mobility. The location information should not be 212 revealed to nor deduced by the correspondent node without the authorization 213 of the mobile node's owner. Since the localized mobility management protocol 214 is responsible for the MN mobility within the local mobility management 215 domain, it should conceal geographical movement of the mobile node. 217 The threats to location privacy come in a variety of forms. Perhaps least 218 likely is a man in the middle attack in which traffic between a 219 correspondent and the mobile node is intercepted and the mobile node's 220 location is deduced from that, since man in the middle attacks in the 221 Internet tend to be fairly rare. More likely are attacks in which the 222 correspondent is the attacker or the correspondent or even mobile node 223 itself are relaying information on the care-of address change to someone. 224 The owner of the correspondent or mobile node might not even be aware of the 225 problem if an attacker has installed spyware or some other kind of exploit 226 on the mobile node and the malware is relaying the change in care-of address 227 to an attacker. 229 Note that the location privacy referred to here is different from the 230 location privacy discussed in [14][15][16]. The location privacy discussed 231 in these drafts primarily concerns modifications to the Mobile IPv6 protocol 232 to eliminate places where an eavesdropper could track the mobile node's 233 movement by correlating home address and care of address. 235 2.4 Efficient Use of Wireless Resources (Requirement #4) 237 Advances in wireless PHY and MAC technology continue to increase the 238 bandwidth available from limited wireless spectrum, but even with technology 239 increases, wireless spectrum remains a limited resource. Unlike wired 240 network links, wireless links are constrained in the number of bits/Hertz by 241 their coding technology and use of physical spectrum, which is fixed by the 242 PHY. It is not possible to lay an extra cable if the link becomes 243 increasingly congested as is the case with wired links. 245 Some existing localized mobility management solutions increase packet size 246 over the wireless link by adding tunneling or other per packet overhead. 247 While header compression technology can remove header overhead, header 248 compression does not come without cost. Requiring header compression on the 249 wireless access points increases the cost and complexity of the access 250 points, and increases the amount of processing required for traffic across 251 the wireless link. Since the access points tend to be a critical bottleneck 252 in wireless access networks for real time traffic (especially on the 253 downlink), reducing the amount of per-packet processing is important. While 254 header compression probably cannot be completely eliminated, especially for 255 real time media traffic, simplifying compression to reduce processing cost 256 is an important requirement. 258 2.5 Reduction of Signaling Overhead in the Network (Requirement #5) 260 While bandwidth and router processing resources are typically not as 261 constrained in the wired network, wired networks tend to have higher 262 bandwidth and router processing constraints than the backbone. These 263 constraints are a function of the cost of laying fiber or wiring to the 264 wireless access points in a widely dispersed geographic area. Therefore, any 265 solutions for localized mobility management should minimize signaling within 266 the wired network as well. 268 2.6 No Extra Security Between Mobile Node and Network (Requirement #6) 270 Localized mobility management protocols that have signaling between the host 271 and network require a security association between the host and the network 272 entity that is the target of the signaling. Establishing a security 273 association specifically for localized mobility service in a roaming 274 situation may prove difficult, because provisioning a mobile node with 275 security credentials for authenticating and authorizing localized mobility 276 service in each roaming partner's network may be unrealistic from a 277 deployment perspective. Reducing the complexity of host to network security 278 for localized mobility management can therefore reduce barriers to 279 deployment. 281 Removing host involvement in localized mobility management also limits the 282 possibility of DoS attacks on network infrastructural elements. In a host 283 based approach, the host is required to have a global or restricted routing 284 local IP address for a network infrastructure element, the mobility anchor 285 point. The network infrastructural element therefore becomes a possible 286 target for DoS attacks, even if hosts are properly authenticated. A properly 287 authenticated host can either willfully or inadvertently give the network 288 infrastructural element address to an attacker. 290 In summary, ruling out host involvement in local mobility management 291 simplifies security by removing the need for service-specific credentials to 292 authenticate and authorize the host for localized mobility management in the 293 network and by limiting the possibility of DoS attacks on network 294 infrastructural elements. 296 2.7 Support for Heterogeneous Wireless Link Technologies (Requirement #7) 298 The number of wireless link technologies available is growing, and the 299 growth seems unlikely to slow down. Since the standardization of a wireless 300 link PHY and MAC is a time consuming process, reducing the amount of work 301 necessary to interface a particular wireless link technology to an IP 302 network is necessary. A localized mobility management solution should 303 ideally require minimal work to interface with a new wireless link 304 technology. 306 In addition, an edge mobility solution should provide support for multiple 307 wireless link technologies within the network in separate subnets. The edge 308 mobility solution should also support handover between different wireless 309 link technologies. 311 2.8 Support for Unmodified Hosts (Requirement #8) 313 A localized mobility management solution should be able to support any host 314 that walks up to the link and has a wireless interface that can communicate 315 with the network, without requiring localized mobility management software 316 on the host. This approach has been extremely successful in the wireless LAN 317 switching market, because it reduces the burden of host software 318 installation on the user. In addition, being able to accommodate unmodified 319 hosts enables a service provider to offer service to as many customers as 320 possible, the only constraint being that the customer is authorized for 321 network access. 323 As a practical matter, there may be some constraints that require some 324 configuration on the host. The host must have some kind of global mobility 325 protocol if it is to move from one domain of edge mobility support to 326 another, although no global mobility protocol is required if the host only 327 moves within the coverage area of the localized mobility management 328 protocol. Also, every wireless link protocol requires handover support on 329 the host in the physical and MAC layers. Information from the MAC layer to 330 the IP layer on the host may be necessary to trigger signaling for IP link 331 handover. The localized mobility solution should be able to accommodate 332 wireless link protocols with host handover support. 334 Another advantage of minimizing host changes for localized mobility 335 management is that multiple global mobility management protocols can be 336 supported with a localized mobility management solution that does not have 337 host involvement. While Mobile IPv6 is clearly the global mobility 338 management protocol of primary interest going forward, there are a variety 339 of global mobility management protocols that might also need support, 340 including proprietary protocols needing support for backward compatibility 341 reasons. Within IETF, both HIP and Mobike are likely to need support in 342 addition to Mobile IPv6, and Mobile IPv4 support may also be necessary. 344 2.9 Support for IPv4 and IPv6 (Requirement #9) 346 While most of this document is written with IPv6 in mind, localized mobility 347 management is a problem in IPv4 networks as well. A solution for localized 348 mobility that works for both versions of IP is desirable, though the actual 349 protocol may be slightly different due to the technical details of how each 350 IP version works. From Requirement #8 (Section 2.8), minimizing host support 351 for localized mobility means that ideally no IP version-specific changes 352 would be required on the host for localized mobility, and that global 353 mobility protocols for both IPv4 and IPv6 should be supported. Any IP 354 version-specific features would be confined to the network protocol. 356 3.0 Gap Analysis 358 This section discusses a gap analysis between existing proposals for solving 359 localized mobility management and the requirement sin Section. 2.0. 361 3.1 Mobile IPv6 with Local Home Agent 363 One option is to deploy Mobile IPv6 with a locally assigned home agent in 364 the local network. This solution requires the mobile node to somehow be 365 assigned a home agent in the local network when it boots up. This home agent 366 is used instead of the home agent in the home network. The advantage of this 367 option is that the no special solution is required for edge mobility - the 368 mobile node reuses the global mobility management protocol for that purpose 369 - if the mobile node is using Mobile IPv6. One disadvantage is that Mobile 370 IP has no provision for handover between home agents. Although such handover 371 should be infrequent, it could be quite lengthy and complex. 373 The analysis of this approach against the requirements above is the 374 following. 376 Requirement #1: If the mobile node does not perform route optimization, this 377 solution reduces, but does not eliminate, IP link handover related 378 performance problems. 380 Requirement #2: Similarly to Requirement #1, signaling volume is reduced if 381 no route optimization signaling is done on handover. 383 Requirement #3: Location privacy is preserved for external correspondents, 384 but the mobile node itself still maintains a local care-of address which a 385 worm or other exploit could misuse. If the mobile node does perform route 386 optimization, location privacy may be compromised, and this solution is no 387 better than having a remote home agent. 389 Requirement #4: If traffic is not route optimized, the mobile node still 390 pays for an over-the-air tunnel to the locally assigned home agent. The 391 overhead here is exactly the same as if the mobile node's home agent in the 392 home network is used and route optimization is not done. 394 Requirement #5: If the localized mobility management domain is large, the 395 mobile node may suffer from unoptimzed routes since handover and mobility 396 between home agents is not supported. 398 Requirement #6: A local home agent in a roaming situation requires the guest 399 mobile node to have the proper credentials to authenticate with the local 400 home agent in the serving network. In addition, as in Requirement #3, the 401 local home agent's address could become the target of a DoS attack if 402 revealed to an attacker. So a local home agent would provide no benefit for 403 this requirement. 405 Requirement #7: This solution supports multiple wireless technologies in 406 separate IP link subnets. No special work is required to interface a local 407 home agent to different wireless technologies. 409 Requirement #8: The host must support Mobile IPv6 in order for this option 410 to work. So host stack changes are required and other IP mobility protocols 411 are not supported. 413 Requirement #9: This solution requires separate locally assigned home agents 414 for Mobile IPv4 and Mobile IPv6 since the local home agent should have MIP 415 functions or IPv4 or IPv6 in conjunction with IP version of global mobility 416 protocol, or some way to register an IPv4 care of address to home address 417 mapping in an Mobile IPv6 home agent. While there are a couple of proposals 418 currently active in the IETF for this (see [17] for one), it is not clear at 419 this point whether they will be adopted for standards track development. 421 3.2 Hierarchical Mobile IPv6 (HMIPv6) 423 HMIPv6 [19] provides the most complete localized mobility management 424 solution available today as an Internet RFC. In HMIPv6, a localized mobility 425 anchor called a MAP serves as a routing anchor for a regional care-of 426 address. When a mobile node moves from one access router to another, the 427 mobile node changes the binding between its regional care-of address and 428 local care-of address at the MAP. No global mobility management signaling is 429 required, since the care-of address seen by correspondents does not change. 430 This part of HMIPv6 is similar to the solution outlined in Section 3.1; 431 however, HMIPv6 also allows a mobile node to hand over between MAPs. 433 Handover between MAPs and MAP discovery requires configuration on the 434 routers. MAP addresses are advertised by access routers. Handover happens by 435 overlapping MAP coverage areas so that, for some number of access routers, 436 more than one MAP may be advertised. Mobile nodes need to switch MAPs in the 437 transition area, and then must perform global mobility management update and 438 route optimization to the new regional care-of address, if appropriate. 440 The analysis of this approach against the requirements above is the 441 following. 443 Requirement #1 This solution shortens, but does not eliminate, the latency 444 associated with IP link handover, since it reduces the amount of signaling 445 and the length of the signaling paths. 447 Requirement #2 Signaling volume is reduced simply because no route 448 optimization signaling is done on handover within the coverage area of the 449 MAP. 451 Requirement #3 Location privacy is preserved for external correspondents, 452 but the mobile node itself still maintains a local care-of address which a 453 worm or other exploit could access by sending the local care-of address to 454 third malicious node to enable it to track the MN�s location. 456 Requirement #4 The mobile node always pays for an over-the-air tunnel to the 457 MAP. If the mobile node is tunneling through a global home agent or VPN 458 gateway, the wired link experiences double tunneling. Over-the-air tunnel 459 overhead can be removed by header compression, however. 461 Requirement #5 From Requirement #1 and Requirement #4, the signaling 462 overhead is no more or less than for mobile nodes whose global mobility 463 management anchor is local. However, because MAP handover is possible, 464 routes across large localized mobility management domains can be improved 465 thereby improving wired network resource utilization by using multiple MAPs 466 and handing over, at the expense of the configuration and management 467 overhead involved in maintaining multiple MAP coverage areas. 469 Requirement #6 In a roaming situation, the guest mobile node must have the 470 proper credentials to authenticate with the MAP in the serving network. In 471 addition, since the mobile node is required to have a unicast address for 472 the MAP that is either globally routed or routing restricted to the local 473 administrative domain, the MAP is potentially a target for DoS attacks 474 across a wide swath of network topology. 476 Requirement #7 This solution supports multiple wireless technologies in 477 separate IP link subnets. 479 Requirement #8 This solution requires modification to the hosts. In 480 addition, the HMIPv6 design has been optimized for Mobile IPv6 hosts, and is 481 not a good match for other global mobility management protocols. 483 Requirement #9 Currently, there is no IPv4 version of this protocol; 484 although there is an expired Internet draft with a design for a regional 485 registration protocol for Mobile IPv4 that has similar functionality. 487 3.3 Combinations of Mobile IPv6 with Optimizations 489 One approach to local mobility that has received much attention in the past 490 and has been thought to provide a solution is combinations of protocols. The 491 general approach is to try to cover gaps in the solution provided by MIPv6 492 by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6 493 and HMIPv6 + FMIPv6 are discussed. 495 3.3.1 MIPv6 + FMIPv6 497 As discussed in Section 3.1, the use of MIPv6 with a dynamically assigned, 498 local home agent cannot fulfill the requirements. A fundamental limitation 499 is that Mobile IPv6 cannot provide seamless handover (i.e. Requirement #1). 500 FMIPv6 has been defined with the intent to improve the handover performance 501 of MIPv6. For this reason, the combined usage of FMIPv6 and MIPv6 with a 502 dynamically assigned local home agent has been proposed to handle local 503 mobility. 505 Note that this gap analysis only applies to localized mobility management, 506 and it is possible that MIPv6 and FMIPv6 might still be acceptable for 507 global mobility management. 509 The analysis of this combined approach against the requirements follows. 511 Requirement #1 FMIPv6 provides a solution for handover performance 512 improvement that should fulfill the requirements raised by real-time 513 applications in terms of jitter, delay and packet loss. The location of the 514 home agent (in local or home domain) does not affect the handover latency. 516 Requirement #2 FMIPv6 requires the MN to perform extra signaling with the 517 access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as 518 in standard MIPv6, whenever the mobile node moves to another IP link, it 519 must send a Binding Update to the home agent. If route optimization is used, 520 the mobile node also performs return routability and sends a Binding Update 521 to each correspondent node. Nonetheless, it is worth noting that FMIPv6 522 should result in a reduction of the amount of IPv6 Neighbor Discovery 523 signaling on the new link. 525 Requirement #3 The mobile node mantains a local care-of address. If route 526 optimization is not used, location privacy can be achieved using bi- 527 directional tunneling. However, as mentioned in Section 3.1, a worm or other 528 malware can exploit this care of address by sending it to a third malicious 529 node. 531 Requirement #4 As stated for Requirement #2, the combination of MIPv6 and 532 FMIPv6 generates extra signaling overhead. For data packets, in addition to 533 the Mobile IPv6 over-the-air tunnel, there is a further level of tunneling 534 between the mobile node and the previous access router during handover. This 535 tunnel is needed to forward incoming packets to the mobile node addressed to 536 the previous care-of address. Another reason is that, even if the mobile 537 node has a valid new care-of address, the mobile node cannot use the new 538 care of address directly with its correspondents without performing route 539 optimization to the new care of address. This implies that the transient 540 tunnel overhead is in place even for route optimized traffic. 542 Requirement #5 FMIPv6 generates extra signaling overhead between previous 543 the access router and the new access router for the HI/HAck exchange. 544 Concerning data packets, the use of FMIPv6 for handover performance 545 improvement implies a tunnel between the previous access router and the 546 mobile node that adds some overhead in the wired network. This overhead has 547 more impact on star topology deployments, since packets are routed down to 548 the old access router, then back up to the aggregation router and then back 549 down to the new access router. 551 Requirement #6 In addition to the analysis for Mobile IPv6 with local home 552 agent in Section 3.1, FMIPv6 requires the mobile node and the previous 553 access router to share a security association in order to secure FBU/FBA 554 exchange. So far, only a SEND-based solution has been proposed and this 555 requires the MN to use autoconfigured Cryptographically Generated Addresses 556 (CGAs)[20]. This precludes stateful address allocation using DHCP, which 557 might be a necessary deployment in certain circumstances. Another solution 558 based on AAA is under study but it could require extra signaling overhead 559 over the air and in the wired network and it could raise performance issues. 561 Requirement #7 MIPv6 and FMIPv6 support multiple wireless technologies, so 562 this requirement is fufilled. 564 Requirement #8 The host must support both MIPv6 and FMIPv6, so it is not 565 possible to satisfy this requirement. 567 Requirement #9 Work is underway to extend MIPv6 with the capability to run 568 over both IPv6-enabled and IPv4-only networks [17]. FMIPv6 only supports 569 IPv6. Even though an IPv4 version of FMIP has been recently proposed, it is 570 not clear how it could be used together with FMIPv6 in order to handle fast 571 handovers across any wired network. 573 3.3.2 HMIPv6 + FMIPv6 575 HMIPv6 provides several advantages in terms of local mobility management. 576 However, as seen in Section 3.2, it does not fulfill all the requirements 577 identified in Section 2.0. In particular, HMIPv6 does not completely 578 eliminate the IP link handover latency. For this reason, FMIPv6 could be 579 used together with HMIPv6 in order to cover the gap. 581 Note that even if this solution is used, the mobile node is likely to need 582 MIPv6 for global mobility management, in contrast with the MIPv6 with 583 dynamically assigned local home agent + FMIPv6 solution. Thus, this solution 584 should really be considered MIPv6 + HMIPv6 + FMIPv6. 586 The analysis of this combined approach against the requirements follows. 588 Requirement #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP 589 link handovers. In particular, FMIPv6 is expected to fulfill the 590 requirements on jitter, delay and packet loss raised by real-time 591 applications. 593 Requirement #2 Both FMIPv6 and HMIPv6 require extra signaling compared with 594 Mobile IPv6. As a whole the mobile node performs signaling message exchanges 595 at each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. 596 However, as mentioned in Section 3.2, the use of HMIPv6 reduces the 597 signaling overhead since no route optimization signaling is done for intra- 598 MAP handovers. In addition, na�ve combinations of FMIPv6 and HMIPv6 often 599 result in redundant signaling. There is much work in the academic literature 600 and the IETF on more refined ways of combining signaling from the two 601 protocols to avoid redundant signaling. 603 Requirement #3 HMIPv6 may preserve location privacy, depending on the 604 dimension of the geographic area covered by the MAP. As discussed in Section 605 3.2, the mobile node still maintains a local care-of address that can be 606 exploited by worms or other malware. 608 Requirement #4 As mentioned for Requirement #2, the combination of HMIPv6 609 and FMIPv6 generates a lot of signaling overhead in the network. Concerning 610 payload data, in addition to the over-the-air MIPv6 tunnel, a further level 611 of tunneling is established between mobile node and MAP. Notice that this 612 tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is 613 directly applied to HMIPv6 networks, there is a third temporary handover- 614 related tunnel between the mobile node and previous access router. Again, 615 there is much work in the academic literature and IETF on ways to reduce the 616 extra tunnel overhead on handover by combining HMIP and FMIP tunneling. 618 Requirement #5 The signaling overhead in the network is not reduced by 619 HMIPv6, as mentioned in Section 3.2. Instead, FMIPv6 generates extra 620 signaling overhead between the previous access router and new access router 621 for HI/HAck exchange. For payload data, the same considerations as for 622 Requirement #4 are applicable. 624 Requirement #6 FMIPv6 requires the mobile node and the previous access 625 router to share a security association in order to secure the FBU/FBA 626 exchange. In addition, HMIPv6 requires that the mobile node and MAP share an 627 IPsec security association in order to secure LBU/LBA exchange. The only 628 well understood approach to set up an IPsec security association using of 629 certificates, but this may raise deployment issues. Thus, the combination of 630 FMIPv6 and HMIPv6 doubles the amount of host to network security protocol 631 required, since security for both FMIP and HMIP must be deployed. 633 Requirement #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so 634 this requirement is fufilled. 636 Requirement #8 The host must support both HMIPv6 and FMIPv6 protocols, so 637 this requirement is not fulfilled. 639 Requirement #9 Currently there is no IPv4 version of HMIPv6. There is an 640 IPv4 version of FMIP but it is not clear how it could be used together with 641 FMIPv6 in order to handle fast handovers across any wired network. 643 3.4 Micromobility Protocols 645 Researchers have defined some protocols that are often characterized as 646 micromobility protocols. Two typical protocols in this category are 647 Cellular-IP [21] and HAWAII [22]. Researchers defined these protocols before 648 local mobility optimizations for Mobile IP such as FMIP and HMIP were 649 developed, in order to reduce handover latency. 651 Cellular IP and HAWAII have a few things in common. Both are compatible 652 with Mobile IP and are intended to provide a higher level of handover 653 performance in local networks than was previously available with Mobile IP 654 without such extensions as HMIP and FMIP. Both use host routes installed in 655 a number of routers within a restricted routing domain. Both define specific 656 messaging to update those routes along the forwarding path and specify how 657 the messaging is to be used to update the routing tables and forwarding 658 tables along the path between the mobile and a micromobility domain boundary 659 router at which point Mobile IP is to used to handle scalable global 660 mobility. Unlike the FMIP and HMIP protocols, however, these protocols do 661 not require the host to obtain a new care of address on each access router 662 as it moves; but rather, the host maintains the same care of address across 663 the micromobility domain. From outside the micromobility domain, the care of 664 address is routed using traditional longest prefix matching IP routing to 665 the domain's boundary router, so the care of address conceptually is within 666 the micromobiity domain boundary router's subnet. Within the micromobility 667 domain, the care of address is routed to the correct access router using 668 host routes. 670 Cellular IP and HAWAII differ in a few aspects. Cellular IP seems to be 671 restricted, based on the nature of the protocol, to tree-based network 672 topologies. HAWAII claims to be applicable in both tree-based and more 673 complete network topologies. HAWAII documents more functionality in the 674 realm of reliability and QoS interworking. Both protocols involve the 675 mobile node itself in mobility operations, although this is also true of the 676 Mobile IP based optimizations, so both protocols raise the same security 677 concerns with respect to authorizing address update as the Mobile IP based 678 optimizations. HAWAII provides some analysis of network deployment 679 scenarios including scale, density, and efficiency, but some of these 680 assumptions seem very conservative compared to realistic cellular type 681 deployments. 683 Micromobility protocols have some potential drawbacks from a deployment and 684 scalability standpoint. Both protocols involve every routing element between 685 the mobile device and the micromobility domain boundary router in all packet 686 forwarding decisions specific to care of addresses for mobile nodes. 687 Scalability is limited because each care of address corresponding to a 688 mobile node generates a routing table entry, and perhaps multiple forwarding 689 table entries, in every router along the path. Since mobile nodes can have 690 multiple global care of addresses in IPv6, this can result in a large 691 expansion in router state throughout the micromobility routing domain. 692 Although the extent of the scalability for micromobility protocols is still 693 not clearly understood from a research standpoint, it seems certain that 694 they will be less scalable than the Mobile IP optimization enhancements, and 695 will require more specialized gear in the wired network. 697 The following is a gap analysis of the micromobility protocols against the 698 requirements in Section 2.0: 700 Requirement #1 The micromobility protocols reduce handover latency by 701 quickly fixing up routes between the boundary router and the access router. 702 While some additional latency may be expected during host route propagation, 703 it is typically much less than experienced with standard Mobile IP. 705 Requirement #2 The micromobility protocols require signaling from the host 706 to the access router to initiate the host route propagation, but that is a 707 considerable reduction over the amount of signaling required to configure to 708 a new IP link. 710 Requirement #3 No care-of address changes are exposed to correspondent nodes 711 or the mobile node itself while the mobile node is moving in the 712 micromobility-managed network. Because there is no local care-of address, 713 there is no threat from malware that exposes the location by sending the 714 care-of address to an adversary. 716 Requirement #4 The only additional over-the-air signaling is involved in 717 propagating host routes from the mobile node to the network upon movement. 718 Since this signaling would be required for movement detection in any case, 719 it is expected to be minimal. Mobile node traffic experiences no overhead. 721 Requirement #5 Host route propagation is required throughout the wired 722 network. The volume of signaling could be more or less depending on the 723 speed of mobile node movement and the size of the wired network. 725 Requirement #6 The mobile node only requires a security association of some 726 type with the access router. Because the signaling is causing routes to the 727 mobile node's care-of address to change, the signaling must prove 728 authorization to hold the address. 730 Requirement #7 The micromobility protocols support multiple wireless 731 technologies, so this requirement is satisfied. 733 Requirement #8 The host must support some way of signaling the access router 734 on link handover, but this is required for movement detection anyway. The 735 nature of the signaling for the micromobility protocols may require host 736 software changes, however. 738 Requirement #9 Most of the work on the micromobility protocols was done in 739 IPv4, but little difference could be expected for IPv6. 741 4.0 Security Considerations 743 Sections 2.3 and 2.6 discuss security considerations for edge mobility. 744 Ideally, a single authentication and authorization of the host for entry 745 into a serving network should be sufficient to authorize the host for 746 receiving edge mobility service as well as normal IP routing to and from the 747 Internet. In the other direction, authentication and authorization of the 748 access routers through RFC 3971 [9] should be sufficient for the host to 749 trust the routing infrastructure, including for edge mobility. This limits 750 the serving network's exposure to the host and the host's exposure to the 751 serving network to two points: the NAS (which, in a wireless network is 752 typically built into the wireless access points) and the access routers. Any 753 additional network elements required to implement edge mobility are not 754 directly accessible to the host. 756 Sections 2.3 and 2.6 also discuss how involving the host in localized 757 mobility management can increase the probability of DoS attacks or expose 758 location privacy information. Global mobility protocols such as Mobile IPv6 759 that require host to network signaling have the same vulnerability, however, 760 the difference with localized mobility management is that the number of 761 network entities involved and their management is expected to be minimal. In 762 addition, while it would certainly be preferable if global IP mobility could 763 be designed in a way to eliminate any global mobility anchor, the nature of 764 IP routing seems to preclude such an option. Any doubts about the dangers 765 spyware, viruses, and other malware could pose to a design that didn't seek 766 to mitigate such threats can be assuaged by checking the volume of spam that 767 comes through zombies and other compromised hosts. 769 5.0 Recommendation 771 In view of the gap analysis in Section 3.0, none of the existing solutions 772 provide complete coverage of the requirements. FMIPv6 provides a complete 773 solution to Requirement 3.1 but to no other requirement. FMIP, HMIP and 774 micromobility protocols require that the MN is modified to support the 775 additional functionality. But as analyzed above, the functionality provided 776 by each protocol is does not fully support the set of requirements discussed 777 in Section 2.0. 779 We therefore recommend that a new, network based localized mobility 780 management protocol be developed that minimizes or eliminates host 781 involvement. Such a localized mobility management protocol can be treated as 782 part of the network infrastructure. This kind of architecture is required to 783 address the gaps with existing protocols described in Section 3.0. The new 784 localized mobility management protocol can be paired with a link layer 785 specific IP link handover optimization protocol, such as are provided by 786 wireless LAN switches, or an IP link handover optimization protocol, such as 787 FMIPv6, to eliminate handover related packet latency. The protocol should 788 minimize the number of specialized routers in the localized mobility 789 management domain to reduce the amount of state update needed upon movement 790 and to allow standardized network equipment to be used where mobility 791 support is not required. 793 With the edge mobility approach, a mobile node has a single IP address that 794 does not change when the mobile node moves from one access router to 795 another, because the mobility anchor and access routers take care of 796 changing the routing. An edge mobility approach does not require a separate 797 security association with a network element, reducing the amount of overhead 798 required to get a connection up on the network. In an edge mobility approach, 799 hosts only have link local addresses for access routers, so it is much more 800 difficult to mount off-link DoS attacks, and on-link attacks are easier to 801 trace and stop. With the edge mobility approach, no authentication and 802 authorization is necessary beyond that necessary for initial network access 803 and whatever additional authentication and authorization is required by the 804 wireless link layer upon movement between access points. 806 6.0 Author Information 808 James Kempf 809 DoCoMo USA Labs 810 181 Metro Drive, Suite 300 811 San Jose, CA 95110 812 USA 813 Phone: +1 408 451 4711 814 Email: kempf@docomolabs-usa.com 816 Kent Leung 817 Cisco Systems, Inc. 818 170 West Tasman Drive 819 San Jose, CA 95134 820 USA 821 EMail: kleung@cisco.com 823 Phil Roberts 824 Motorola Labs 825 Schaumberg, IL 826 USA 827 Email: phil.roberts@motorola.com 829 Katsutoshi Nishida 830 NTT DoCoMo Inc. 831 3-5 Hikarino-oka, Yokosuka-shi 832 Kanagawa, 833 Japan 834 Phone: +81 46 840 3545 835 Email: nishidak@nttdocomo.co.jp 837 Gerardo Giaretta 838 Telecom Italia Lab 839 via G. Reiss Romoli, 274 840 10148 Torino 841 Italy 842 Phone: +39 011 2286904 843 Email: gerardo.giaretta@tilab.com 845 Marco Liebsch 846 NEC Network Laboratories 847 Kurfuersten-Anlage 36 848 69115 Heidelberg 849 Germany 850 Phone: +49 6221-90511-46 851 Email: marco.liebsch@ccrle.nec.de 853 7.0 Informative References 855 [1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch, 856 M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet 857 Draft, work in progress. 858 [2] Manner, J., and Kojo, M., " Mobility Related Terminology", RFC 3753, 859 June, 2004. 860 [3] Carpenter, B., "Architectural Principles of the Internet," RFC 1958, 861 June, 1996. 862 [4] Johnson, D., Perkins, C., and Arkko, J., �Mobility Support in IPv6,� 863 RFC 3775. 864 [5] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host 865 Identity Protocol", Internet Draft, work in progress. 866 [6] Choi, J, and Daley, G., " Goals of Detecting Network Attachment in 867 IPv6", Internet Draft, work in progress. 868 [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 869 2001. 870 [8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A., 871 "Protocol for Carrying Authentication for Network Access (PANA)", 872 Internet Draft, work in progress. 873 [9] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor 874 Discovery (SEND)", RFC 3971, March, 2005. 875 [10] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work in 876 Progress. 877 [11] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law 878 and Policy in the US, EU, and Japan", ISOC Member Briefing #15, 879 http://www.isoc.org/briefings/015/index.shtml 880 [12] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and 881 Patil, B., " Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem 882 Statement", Internet Draft, work in progress. 883 [13] Kivinen, T., and Tschopfening, H., " Design of the MOBIKE Protocol", 884 Internet Draft, work in progress. 885 [14] Koodli, R., " IP Address Location Privacy and IP Mobility", Internet 886 Draft, work in progress. 887 [15] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., " Solutions 888 for IP Address Location Privacy in the presence of IP Mobility", 889 Internet Draft, work in progress. 890 [16] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., " Protocol for 891 Protecting Movement of Mobile Nodes in Mobile IPv6", Internet Draft, 892 work in progress. 893 [17] Wakikawa, R., Devarapalli, V., and Williams, C., " IPv4 Care-of Address 894 Registration", Internet Draft, work in progress. 895 [18] Koodli, R., editor, �Fast Handovers for Mobile IPv6,� Internet Draft, a 896 work in progress. 897 [19] Soliman, H., editor, �Hierarchical Mobile IPv6 Mobility Management,� 898 Internet Draft, a work in progress. 900 [20] Kempf, J., and Koodli, R., " Bootstrapping a Symmetric IPv6 Handover Key 901 from SEND", Internet Draft, work in progress. 902 [21] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design, 903 Implementation and Evaluation of Cellular IP", IEEE Personal 904 Communications, June/July 2000. 905 [22] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A 906 domain-based approach for supporting mobility in wide-area wireless 907 networks", in Proceedings of the International Conference on Networking 908 Protocols (ICNP), 1999. 910 8.0 IPR Statements 912 The IETF takes no position regarding the validity or scope of any 913 Intellectual Property Rights or other rights that might be claimed to 914 pertain to the implementation or use of the technology described in this 915 document or the extent to which any license under such rights might or might 916 not be available; nor does it represent that it has made any independent 917 effort to identify any such rights. Information on the procedures with 918 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 920 Copies of IPR disclosures made to the IETF Secretariat and any assurances of 921 licenses to be made available, or the result of an attempt made to obtain a 922 general license or permission for the use of such proprietary rights by 923 implementers or users of this specification can be obtained from the IETF 924 on-line IPR repository at http://www.ietf.org/ipr. 926 The IETF invites any interested party to bring to its attention any 927 copyrights, patents or patent applications, or other proprietary rights that 928 may cover technology that may be required to implement this standard. 929 Please address the information to the IETF at ietf-ipr@ietf.org. 931 9.0 Disclaimer of Validity 933 This document and the information contained herein are provided on an "AS 934 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 935 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 936 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 937 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 938 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 939 FOR A PARTICULAR PURPOSE. 941 10.0 Copyright Notice 943 Copyright (C) The Internet Society (2005). This document is subject to the 944 rights, licenses and restrictions contained in BCP 78, and except as set 945 forth therein, the authors retain all their rights.