idnits 2.17.1 draft-ietf-netlmm-nohost-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 22 has weird spacing: '... months and ...' == Line 27 has weird spacing: '... The list ...' == Line 72 has weird spacing: '...i, the propr...' == Line 77 has weird spacing: '...ecurity tran...' == Line 78 has weird spacing: '...y. The concl...' == (40 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '9') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '11') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '12') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '13') (Obsoleted by RFC 5380) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Kempf, Editor 3 Document: draft-ietf-netlmm-nohost-req-05.txt October, 2006 4 Expires: April, 2007 6 Goals for Network-based Localized Mobility Management (NETLMM) 7 (draft-ietf-netlmm-nohost-req-05.txt) 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Contributors 35 Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and 36 Marco Liebsch all contributed major effort to this document. Their 37 names are not included in the authors' section due to the RFC 38 Editor's limit of 5 names. 40 Abstract 42 In this document, design goals for a network-based localized 43 mobility management (NETLMM) protocol are discussed. 45 Table of Contents 47 1.0 Introduction............................................2 48 2.0 NETLMM Functional Architecture..........................3 49 3.0 Goals for the NETLMM Protocol...........................3 50 4.0 IANA Considerations....................................10 51 5.0 Security Considerations................................11 52 6.0 Acknowledgements.......................................11 53 7.0 Author's Addresses.....................................11 54 8.0 Normative References...................................12 55 9.0 Informative References.................................12 56 10.0 IPR Statements.........................................13 57 11.0 Disclaimer of Validity.................................13 58 12.0 Copyright Notice.......................................13 60 1.0 Introduction 62 In [1], the basic problems that occur when a global mobility 63 protocol is used for managing local mobility are described, and two 64 currently used approaches to localized mobility management - the 65 host-based approach that is used by most IETF protocols, and the 66 proprietary WLAN switch approach used between WLAN switches in 67 different subnets - are examined. The conclusion from the problem 68 statement document is that none of the approaches has a complete 69 solution to the problem. While the WLAN switch approach is most 70 convenient for network operators and users because it requires no 71 software on the mobile node other than the standard drivers for 72 WiFi, the proprietary nature limits interoperability and the 73 restriction to a single last hop link type and wired backhaul link 74 type restricts scalability. The IETF host-based protocols require 75 host software stack changes that may not be compatible with all 76 global mobility protocols, and also require specialized and complex 77 security transactions with the network that may limit 78 deployability. The conclusion was that a localized mobility 79 management protocol that was network based and required no software 80 on the host for localized mobility management is desirable. 82 This document develops a brief functional architecture and detailed 83 goals for a network-based localized mobility management protocol 84 (NETLMM). Section 2.0 describes the functional architecture of 85 NETLMM. In Section 3.0, a list of goals that are desirable in the 86 NETLMM protocol is presented. Section 4.0 concerns IANA 87 considerations. Section 5.0 briefly outlines security 88 considerations. More discussion of security can be found in the 89 threat analysis document [2]. 91 1.1 Terminology 93 Mobility terminology in this draft follows that in RFC 3753 [10] 94 and in [1]. In addition, the following terms are related to the 95 functional architecture described in Section 2.0: 97 Localized Mobility Management Domain 99 An Access Network in the sense defined in [1] in which 100 mobility is handled by the NETLMM protocol. 102 Mobile Access Gateway 103 A Mobile Access Gateway (MAG) is a functional network 104 element that terminates a specific edge link and tracks 105 mobile node IP level mobility between edge links, through 106 NETLMM signaling with the Localized Mobility Anchor. The MAG 107 also terminates host routed data traffic from the Localized 108 Mobility Anchor for mobile nodes currently located within 109 the edge link under the MAG's control, and forwards data 110 traffic from mobile nodes on the edge link under its control 111 to the Localized Mobility Anchor. 113 Local Mobility Anchor 115 A Local Mobility Anchor (LMA) is a router that maintains a 116 collection of host routes and associated forwarding 117 information for mobile nodes within a localized mobility 118 management domain under its control. Together with the MAGs 119 associated with it, the LMA uses the NETLMM protocol to 120 manage IP node mobility within the localized mobility 121 management domain. Routing of mobile node data traffic is 122 anchored at the LMA as the mobile node moves around within 123 the localized mobility management domain. 125 2.0 NETLMM Functional Architecture 127 The NETLMM architecture consists of the following components. 128 Localized Mobility Anchors (LMAs) within the backbone network 129 maintain a collection of routes for individual mobile nodes within 130 the localized mobility management domain. The routes point to the 131 Mobile Access Gateways (MAGs) managing the links on which the 132 mobile nodes currently are located. Packets for a mobile node are 133 routed to and from the mobile node through tunnels between the LMA 134 and MAG. When a mobile node moves from one link to another, the MAG 135 sends a route update to the LMA. While some mobile node involvement 136 is necessary and expected for generic mobility functions such as 137 movement detection and to inform the MAG about mobile node 138 movement, no specific mobile node to network protocol will be 139 required for localized mobility management itself. Host stack 140 involvement in mobility management is thereby limited to generic 141 mobility functions at the IP layer, and no specialized localized 142 mobility management software is required. 144 3.0 Goals for the NETLMM Protocol 146 Section 2 of [1] describes three problems with using a global 147 mobility management protocol for localized mobility management. Any 148 localized mobility management protocol must naturally address these 149 three problems. In addition, the side effects of introducing such a 150 solution into the network need to be limited. In this section, we 151 address goals for NETLMM including both solving the basic problems 152 (Goals 1, 2, 3) and limiting the side effects (Goals 4+). 154 Some basic goals of all IETF protocols are not discussed in detail 155 here, but any solution is expected to satisfy them. These goals are 156 fault tolerance, robustness, interoperability, scalability, and 157 minimal specialized network equipment. A good discussion of their 158 applicability to IETF protocols can be found in [4]. 160 Out of scope for the initial goals discussion are QoS and dormant 161 mode/paging. While these are important functions for mobile nodes, 162 they are not part of the base localized mobility management 163 problem. In addition, mobility between localized mobility 164 management domains is not covered here. It is assumed that this is 165 covered by the global mobility management protocols. 167 3.1 Handover Performance Improvement (Goal #1) 169 Handover packet loss occurs because there is usually latency 170 between when the link handover starts and when the IP subnet 171 configuration and global mobility management signaling completes. 172 During this time the mobile node is unreachable at its former 173 topological location on the old link where correspondents are 174 sending packets. Such misrouted packets are dropped. This aspect of 175 handover performance optimization has been the subject of much 176 work, both in other SDOs and in the IETF, in order to reduce the 177 latency in IP handover. Many solutions to this problem have been 178 proposed at the link layer and at the IP layer. One aspect of this 179 goal for localized mobility management is that the processing delay 180 for changing the forwarding after handover must approach as closely 181 as possible the sum of the delay associated with link layer 182 handover and the delay required for active IP layer movement 183 detection, in order to avoid excessive packet loss. Ideally, if 184 network-side link layer support is available for handling movement 185 detection prior to link handover or as part of the link handover 186 process, the routing update should complete within the time 187 required for link handover. This delay is difficult to quantify, 188 but for voice traffic, the entire handover delay including Layer 2 189 handover time and IP handover time should be between 40-70 ms to 190 avoid any degradation in call quality. Of course, if the link layer 191 handover latency is too high, sufficient IP layer handover 192 performance for good real time service cannot be matched. 194 A goal of the NETLMM protocol - in networks where the link layer 195 handover latency allows it - is to reduce the amount of latency in 196 IP handover, so that the combined IP and link layer handover 197 latency is less than 70 ms. 199 3.2 Reduction in Handover-related Signaling Volume (Goal #2) 201 Considering Mobile IPv6 [9] as the global mobility protocol (other 202 mobility protocols require about the same or somewhat less), if a 203 mobile node using address autoconfiguration is required to 204 reconfigure on every move between links, the following signaling 205 must be performed: 207 1) Link layer signaling required for handover and reauthentication. 208 For example, in 802.11 [7] this is the Reassociate message 209 together with 802.1x [8] reauthentication using EAP. 210 2) Active IP level movement detection, including router 211 reachability. The DNA protocol [5] uses Router 212 Solicitation/Router Advertisement for this purpose. In addition, 213 if SEND [3] is used and the mobile node does not have a 214 certificate cached for the router, the mobile node must use 215 Certification Path Solicitation/Certification Path Advertisement 216 to obtain a certification path. 217 3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one 218 for each of the solicited node multicast addresses corresponding 219 to the link local address and the global address, 220 4) Two Neighbor Solicitation (NS) messages for duplicate address 221 detection, one for the link local address and one for the global 222 address. If the addresses are unique, no response will be 223 forthcoming. 224 5) Two NS messages from the router for address resolution of the 225 link local and global addresses, and two Neighbor Advertisement 226 messages in response from the mobile node, 227 6) Binding Update/Binding Acknowledgement between the mobile node 228 and home agent to update the care of address binding, 229 7) Return routability signaling between the correspondent node and 230 mobile node to establish the binding key, consisting of one Home 231 Test Init/Home Test and Care of Test Init/Care of Test, 232 8) Binding Update/Binding Acknowledgement between the correspondent 233 node and mobile node for route optimization. 235 Note that Steps 1-2 may be necessary even for intra-link mobility, 236 if the last hop link protocol doesn't provide much help for IP 237 handover. Step 3-5 will be different if stateful address 238 configuration is used, since additional messages are required to 239 obtain the address. Steps 6-8 are only necessary when Mobile IPv6 240 is used. The result is approximately 18 messages at the IP level, 241 where the exact number depends on various specific factors such as 242 whether the mobile node has a router certificate cached or not, 243 before a mobile node can be ensured that it is established on a 244 link and has full IP connectivity. In addition to handover related 245 signaling, if the mobile node performs Mobile IPv6 route 246 optimization, it may be required to renew its return routability 247 key periodically (on the order of every 7 minutes) even if it is 248 not moving, resulting in additional signaling. 250 The signaling required has a large impact on the performance of 251 handover, impacting Goal #1. Perhaps more importantly, the 252 aggregate impact from many mobile nodes of such signaling on 253 expensive shared links (such as wireless where the capacity of the 254 link cannot easily be expanded) can result in reduced last hop link 255 capacity for data traffic. Additoinally, in links where the end 256 user is charged for IP traffic, IP signaling is not without cost. 258 To address the issue of signaling impact described above, the goal 259 is that handover signaling volume from the mobile node to the 260 network should be no more than what is needed for the mobile node 261 to perform secure IP level movement detection, in cases where no 262 link layer support exists. Furthermore, NETLMM should not introduce 263 any additional signaling during handover beyond what is required 264 for IP level movement detection. If link layer support exists for 265 IP level movement detection, the mobile node may not need to 266 perform any additional IP level signaling after link layer 267 handover. 269 3.3 Location Privacy (Goal #3) 271 In any IP network, there is a threat that an attacker can determine 272 the physical location of a network node from the node's topological 273 location. Depending on how an operator deploys their network, an 274 operator may choose to assign subnet coverage in a way that is 275 tightly bound to geography at some timescale or it may choose to 276 assign it in ways in which the threat of someone finding a node 277 physically based on its IP address is smaller. Allowing 278 the L2 attachment and L3 address to be less tightly bound is one 279 tool for reducing this threat to location privacy. 281 Mobility introduces an additional threat. An attacker can track a 282 mobile node's geographical location in real time, if the victim 283 mobile node must change its IP address as it moves from one subnet 284 to another through the covered geographical area. If the 285 granularity of the mapping between the IP subnets and geographical 286 area is small for the particular link type in use, the attacker can 287 potentially assemble enough information to find the victim in real 288 time. 290 In order to reduce the risk from location privacy compromises as a 291 result of IP address changes, the goal for NETLMM is to remove the 292 need to change IP address as a mobile node moves across links in an 293 access network. Keeping the IP address fixed over a large 294 geographical region fuzzes out the resolution of the mapping 295 between the IP subnets and geographical area, regardless of how 296 small the natural deployment granularity may be. This reduces the 297 chance that the attacker can deduce the precise geographic location 298 of the mobile node. 300 3.4 Limit Overhead in the Network (Goal #4) 302 Access networks, including both the wired and wireless parts, tend 303 to have somewhat stronger bandwidth and router processing 304 constraints than the backbone. In the wired part of the network, 305 these constraints are a function of the cost of laying fiber or 306 wiring to the wireless access points in a widely dispersed 307 geographic area. In the wireless part of the network, these 308 constraints are due to the limitation on the number of bits per 309 Hertz imposed by the physical layer protocol. Therefore, any 310 solutions for localized mobility management should minimize 311 overhead within the access network. 313 3.5 Simplify Mobile Node Mobility Management Security by Deriving from 314 IP Network Access and/or IP Movement Detection Security (Goal #5) 316 Localized mobility management protocols that have host involvement 317 may require an additional security association between the mobile 318 node and the mobility anchor, and establishing this security 319 association may require additional signaling between the mobile 320 node and the mobility anchor (see [13] for an example). The 321 additional security association requires extra signaling and 322 therefore extra time to negotiate. Reducing the complexity of 323 mobile node to network security for localized mobility management 324 can therefore reduce barriers to deployment and improve 325 responsiveness. Naturally, such simplification must not come at the 326 expense of maintaining strong security guarantees for both the 327 network and mobile node. 329 In NETLMM, the network (specifically the MAG) derives the 330 occurrence of a mobility event requiring a routing update for a 331 mobile node from link layer handover signaling or IP layer movement 332 detection signaling from the mobile node. This information is used 333 to update routing for the mobile node at the LMA. The handover or 334 movement detection signaling must provide the network with proper 335 authentication and authorization so that the network can 336 definitively identify the mobile node and determine its 337 authorization. The authorization may be at the IP level, for 338 example, using something like SEND [3] to secure IP movement 339 detection signaling, or it may be at the link level. Proper 340 authentication and authorization must be implemeted on link layer 341 handover signaling and/or IP level movement detection signaling in 342 order for the MAG to securely deduce mobile node movement events. 343 Security threats to the NETLMM protocol are discussed in [2]. 345 The goal is that security for NETLMM mobile node mobility 346 management should derive from IP network access and/or IP movement 347 detection security, such as SEND or network access authentication, 348 and not require any additional security associations or additional 349 signaling between the mobile node and the network. 351 3.6 Link Technology Agnostic (Goal #6) 353 The number of wireless link technologies available is growing, and 354 the growth seems unlikely to slow down. Since the standardization 355 of a wireless link physical and medium access control layers is a 356 time consuming process, reducing the amount of work necessary to 357 interface a particular wireless link technology to an IP network is 358 necessary. When the last hop link is a wireless link, a localized 359 mobility management solution should ideally require minimal work to 360 interface with a new wireless link technology. 362 In addition, an edge mobility solution should provide support for 363 multiple wireless link technologies. It is not required that the 364 localized mobility management solution support handover from one 365 wireless link technology to another without change in IP address, 366 but this possibility should not be precluded. 368 The goal is that the localized mobility management protocol should 369 not use any wireless link specific information for basic routing 370 management, though it may be used for other purposes, such as 371 securely identifying a mobile node. 373 3.7 Support for Unmodified Mobile Nodes (Goal #7) 375 In the wireless LAN switching market, no modification of the 376 software on the mobile node is required to achieve localized 377 mobility management. Being able to accommodate unmodified mobile 378 nodes enables a service provider to offer service to as many 379 customers as possible, the only constraint being that the customer 380 is authorized for network access. 382 Another advantage of minimizing mobile node software for localized 383 mobility management is that multiple global mobility management 384 protocols can be supported. There are a variety of global mobility 385 management protocols that might also need support, including 386 proprietary or link technology-specific protocols needing support 387 for backward compatibility reasons. Within the Internet, both HIP 388 [11] and Mobike [6] are likely to need support in addition to 389 Mobile IPv6 [9], and Mobile IPv4 [12] support may also be 390 necessary. 392 Note that this goal does NOT mean that the mobile node has no 393 software at all associated with mobility. The mobile node must have 394 some kind of global mobility protocol if it is to move from one 395 domain of edge mobility support to another and maintain session 396 continuity, although no global mobility protocol is required if the 397 mobile node only moves within the coverage area of the localized 398 mobility management protocol or no session continuity is required 399 during global movement. Also, if the last hop link is a wireless 400 link, every wireless link protocol requires handover support on the 401 mobile node in the physical and medium access control layers, 402 typically in the wireless interface driver. Information passed from 403 the medium access control layer to the IP layer on the mobile node 404 may be necessary to trigger IP signaling for IP handover. Such 405 movement detection support at the IP level may be required in order 406 to determine whether the mobile node's default router is still 407 reachable after the move to a new access point has occurred at the 408 medium access control layer. Whether or not such support is 409 required depends on whether the medium access control layer can 410 completely hide link movement from the IP layer. For cellular type 411 wireless link protocols, the mobile node and network undergo an 412 extensive negotiation at the medium access control layer prior to 413 handover, so it may be possible to trigger routing update without 414 any IP protocol involvement. However, for a wireless link protocol 415 such as IEEE 802.11 [7] in which the decision for handover is 416 entirely in the hands of the mobile node, IP layer movement 417 detection signaling from the mobile node may be required to trigger 418 a routing update. 420 The goal is that the localized mobility management solution should 421 be able to support any mobile node that joins the link and that has 422 a interface that can communicate with the network, without 423 requiring localized mobility management software on the mobile 424 node. 426 3.8 Support for IPv4 and IPv6 (Goal #8) 428 While most of this document is written with IPv6 in mind, localized 429 mobility management is a problem in IPv4 networks as well. A 430 solution for localized mobility that works for both versions of IP 431 is desirable, though the actual protocol may be slightly different 432 due to the technical details of how each IP version works. From 433 Goal #7 (Section 3.7), minimizing mobile node support for localized 434 mobility means that ideally no IP version-specific changes should 435 be required on the mobile node for localized mobility, and that 436 global mobility protocols for both IPv4 and IPv6 should be 437 supported. Any IP version-specific features should be confined to 438 the network protocol. 440 3.9 Re-use of Existing Protocols Where Sensible (Goal #9) 442 Many existing protocols are available as Internet Standards upon 443 which the NETLMM protocol can be built. The design of the protocol 444 should have a goal to re-use existing protocols where it makes 445 architectural and engineering sense to do so. The design should 446 not, however, attempt to re-use existing protocols where there is 447 no real architectural or engineering reason. For example, the suite 448 of Internet Standards contains several good candidate protocols for 449 the transport layer, so there is no real need to develop a new 450 transport protocol specifically for NETLMM. Re-use is clearly a 451 good engineering decision in this case, since backward 452 compatibility with existing protocol stacks is important. On the 453 other hand, the network-based, localized mobility management 454 functionality being introduced by NETLMM is a new piece of 455 functionality, and therefore any decision about whether to re-use 456 an existing global mobility management protocol should carefully 457 consider whether re-using such a protocol really meets the needs of 458 the functional architecture for network-based localized mobility 459 management. The case for re-use is not so clear in this case, since 460 there is no compelling backward compatibility argument. 462 3.10 Localized Mobility Management Independent of Global Mobility 463 Management (Goal #10) 465 Localized mobility management should be implementable and 466 deployable independently of any global mobility management 467 protocol. This enables the choice of local and global mobility 468 management to be made independently of particular protocols that 469 are implemented and deployed to solve the two different sorts of 470 mobility management problems. The operator can choose a particular 471 localized mobility management protocol according to the specific 472 features of their access network. It can subsequently upgrade the 473 localized mobility management protocol on its own, without even 474 informing the mobile nodes. Similarly, the mobile nodes can use a 475 global mobility management protocol that best suits their 476 requirements, or even not use one at all. Also, a mobile node can 477 move into a new access network without having to check that it 478 understands the localized mobility management protocol being used 479 there. 481 The goal is that the implementation and deployment of the localized 482 mobility management protocol should not restrict, or be restricted 483 by, the choice of global mobility management protocol. 485 3.11 Configurable Data Plane Forwarding between Local Mobility Anchor 486 and Mobile Access Gateway (Goal #11) 488 Different network operators may require different types of 489 forwarding options between the LMA and the MAGs for mobile node 490 data plane traffic. An obvious forwarding option that has been used 491 in past IETF localized mobility management protocols is IP-IP 492 encapsulation for bidirectional tunneling. The tunnel endpoints are 493 the LMA and the MAGs. But other options are possible. Some network 494 deployments may prefer routing-based solutions. Others may require 495 security tunnels using IPsec ESP encapsulation if part of the 496 localized mobility management domain runs over a public access 497 network and the network operator wants to protect the traffic. 499 A goal of the NETLMM protocol is to allow the forwarding between 500 the LMA and MAGs to be configurable depending on the particulars of 501 the network deployment. Configurability is not expected to be 502 dynamic as in controlled by the arrival of a mobile node; but 503 rather, configuration is expected to be similar in time scale to 504 configuration for routing. The NETLMM protocol may designate a 505 default forwarding mechanism. It is also possible that additional 506 work may be required to specify the interaction between a 507 particular forwarding mechanism and the NETLMM protocol, but this 508 work is not in scope of the NETLMM base protocol. 510 4.0 IANA Considerations 512 There are no IANA considerations for this document. 514 5.0 Security Considerations 516 There are two kinds of security issues involved in network-based 517 localized mobility management: security between the mobile node and 518 the network, and security between network elements that participate 519 in the NETLMM protocol. The security-related goals in this 520 document, described in Section 3.3 and 3.5, focus on the former, 521 because those are unique to network-based mobility management. The 522 threat analysis document [2] contains a more detailed discussion of 523 both kinds of threats, which the protocol design must address. 525 6.0 Acknowledgements 527 The authors would like to acknowledge the following for 528 particularly diligent reviewing: Vijay Devarapalli, Peter McCann, 529 Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred 530 Templin. 532 7.0 Author's Addresses 534 James Kempf 535 DoCoMo USA Labs 536 181 Metro Drive, Suite 300 537 San Jose, CA 95110 538 USA 539 Phone: +1 408 451 4711 540 Email: kempf@docomolabs-usa.com 542 Kent Leung 543 Cisco Systems, Inc. 544 170 West Tasman Drive 545 San Jose, CA 95134 546 USA 547 EMail: kleung@cisco.com 549 Phil Roberts 550 Motorola Labs 551 Schaumberg, IL 552 USA 553 Email: phil.roberts@motorola.com 555 Katsutoshi Nishida 556 NTT DoCoMo Inc. 557 3-5 Hikarino-oka, Yokosuka-shi 558 Kanagawa, 559 Japan 560 Phone: +81 46 840 3545 561 Email: nishidak@nttdocomo.co.jp 563 Gerardo Giaretta 564 Telecom Italia Lab 565 via G. Reiss Romoli, 274 566 10148 Torino 567 Italy 568 Phone: +39 011 2286904 569 Email: gerardo.giaretta@tilab.com 571 Marco Liebsch 572 NEC Network Laboratories 573 Kurfuersten-Anlage 36 574 69115 Heidelberg 575 Germany 576 Phone: +49 6221-90511-46 577 Email: marco.liebsch@ccrle.nec.de 579 8.0 Normative References 581 [1] Kempf, J., editor, "Problem Statement for IP Local Mobility," 582 Internet Draft, Work in Progress. 583 [2] Vogt, C., and Kempf, J., "Security Threats to Network-based 584 Localized Mobility Management", Internet Draft, Work in 585 Progress. 587 9.0 Informative References 589 [3] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure 590 Neighbor Discovery (SEND)", RFC 3971, March, 2005. 591 [4] Carpenter, B., "Architectural Principles of the Internet," 592 RFC 1958, June, 1996. 593 [5] Choi, J, and Daley, G., "Goals of Detecting Network 594 Attachment in IPv6", Internet Draft, Work in Progress. 595 [6] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol 596 (MOBIKE)", RFC 4555, June 2006. 597 [7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical 598 Layer (PHY) specifications", IEEE Std. 802.11, 1999. 599 [8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 600 802.1x, June, 2001. 601 [9] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 602 IPv6", RFC 3775, June, 2004. 603 [10] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 604 3753, June, 2004. 605 [11] Moskowitz, R., and Nikander, P., "Host Identity Protocol 606 (HIP) Architecture", RFC 4423, May, 2006. 607 [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 608 August, 2002. 609 [13] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., 610 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 611 4140, August, 2005. 612 [14] Vida, R., and Costa, L., " Multicast Listener Discovery 613 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 615 10.0 IPR Statements 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed 619 to pertain to the implementation or use of the technology described 620 in this document or the extent to which any license under such 621 rights might or might not be available; nor does it represent that 622 it has made any independent effort to identify any such rights. 623 Information on the procedures with respect to rights in RFC 624 documents can be found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use 629 of such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository 631 at http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at ietf- 637 ipr@ietf.org. 639 11.0 Disclaimer of Validity 641 This document and the information contained herein are provided on 642 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 643 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 644 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 645 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 646 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 647 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 648 PARTICULAR PURPOSE. 650 12.0 Copyright Notice 652 Copyright (C) The Internet Society (2006). This document is 653 subject to the rights, licenses and restrictions contained in BCP 654 78, and except as set forth therein, the authors retain all their 655 rights.