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