idnits 2.17.1 draft-soliman-mipshop-4140bis-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1271. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 -- 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: '1' is mentioned on line 1033, but not defined == Missing Reference: '3' is mentioned on line 1039, but not defined == Missing Reference: '2' is mentioned on line 1036, but not defined -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '4') (Obsoleted by RFC 5268) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 H. Soliman 3 INTERNET-DRAFT Qualcomm-Flarion 4 Expires: April 2006 C. Castelluccia 5 INRIA 6 K. ElMalki 7 L. Bellier 8 INRIA 9 October, 2006 11 Hierarchical Mobile IPv6 Mobility Management (HMIPv6) 12 draft-soliman-mipshop-4140bis-01.txt 14 Status of this memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document introduces extensions to Mobile IPv6 and IPv6 Neighbour 39 Discovery to allow for local mobility handling. Hierarchical 40 mobility management for Mobile IPv6 is designed to reduce the amount 41 of signalling between the Mobile Node, its Correspondent Nodes, and 42 its Home Agent. The Mobility Anchor Point (MAP) described in this 43 document can also be used to improve the performance of Mobile IPv6 44 in terms of handover speed. 46 Table of Contents 48 1. Introduction.....................................................3 49 2. Terminology......................................................4 50 3. Overview of HMIPv6...............................................5 51 3.1. HMIPv6 Operations...........................................5 52 4. Mobile IPv6 Extension - Local Binding Update.....................7 53 5. Neighbour Discovery Extension: The MAP Option Message Format.....8 54 6. Protocol Operation...............................................9 55 6.1. Mobile Node Operation.......................................9 56 6.1.1 Sending Packets to Correspondent Nodes.................11 57 6.2. MAP Operations.............................................11 58 6.3. Home Agent Operations......................................12 59 6.4. Correspondent Node Operations..............................12 60 6.5. Local Mobility Management Optimisation within a MAP Domain.12 61 6.6. Location Privacy...........................................13 62 7. MAP Discovery...................................................13 63 7.1. Dynamic MAP Discovery......................................13 64 7.1.1. Router Operation for Dynamic MAP Discovery............14 65 7.1.2. MAP Operation for Dynamic MAP Disovery................14 66 7.2. Mobile Node Operation......................................14 67 8. Updating Previous MAPs..........................................15 68 9. Note on MAP Selection by the Mobile Node........................16 69 9.1. MAP Selection in a Distributed MAP Environment.............16 70 9.2. MAP Selection in a Flat Mobility Architecture..............17 71 10. Detection and Recovery from MAP Failures.......................17 72 11. IANA Considerations............................................18 73 12. Security Considerations........................................18 74 12.1. Mobile Node-MAP Security..................................19 75 12.2. Mobile Node-Correspondent Node Security...................21 76 12.3. Mobile Node-Home Agent Security...........................21 77 13. Acknowledgements...............................................21 78 14. References.....................................................21 79 14.1. Normative References......................................21 80 14.2. Informative References....................................22 81 Authors' Addresses.................................................25 83 1. Introduction 85 This specification introduces the concept of a Hierarchical Mobile 86 IPv6 network, utilising a new node called the Mobility Anchor Point 87 (MAP). 89 Mobile IPv6 [1] allows nodes to move within the Internet topology 90 while maintaining reachability and on-going connections between 91 mobile and correspondent nodes. To do this a mobile node sends 92 Binding Updates (BUs) to its Home Agent (HA) and all Correspondent 93 Nodes (CNs) it communicates with, every time it moves. Authenticating 94 binding updates requires approximately 1.5 round-trip times between 95 the mobile node and each correspondent node (for the entire return 96 routability procedure in a best case scenario, i.e., no packet loss). 97 In addition, one round-trip time is needed to update the Home Agent; 98 this can be done simultaneously while updating correspondent nodes. 99 The re-use of the home cookie (i.e., eliminating HOTI/HOT) will not 100 reduce the number of round trip times needed to update correspondent 101 nodes. These round trip delays will disrupt active connections every 102 time a handoff to a new AR is performed. Eliminating this additional 103 delay element from the time-critical handover period will 104 significantly improve the performance of Mobile IPv6. Moreover, in 105 the case of wireless links, such a solution reduces the number of 106 messages sent over the air interface to all correspondent nodes and 107 the Home Agent. A local anchor point will also allow Mobile IPv6 to 108 benefit from reduced mobility signalling with external networks. 110 For these reasons a new Mobile IPv6 node, called the Mobility Anchor 111 Point, is used and can be located at any level in a hierarchical 112 network of routers, including the Access Router (AR). The MAP will 113 limit the amount of Mobile IPv6 signalling outside the local domain. 114 The introduction of the MAP provides a solution to the issues 115 outlined earlier in the following way: 117 - The mobile node sends Binding Updates to the local MAP rather than 118 the HA (which is typically further away) and CNs 120 - Only one Binding Update message needs to be transmitted by the MN 121 before traffic from the HA and all CNs is re-routed to its new 122 location. This is independent of the number of CNs that the MN is 123 communicating with. 125 A MAP is essentially a local Home Agent. The aim of introducing the 126 hierarchical mobility management model in Mobile IPv6 is to enhance 127 the performance of Mobile IPv6 while minimising the impact on Mobile 128 IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile 129 nodes to hide their location from correspondent nodes and Home Agents 130 while using Mobile IPv6 route optimisation. 132 It is pertinent to note that the use of the MAP does not imply or 133 assume that a permanent Home Agent is present. In other words, a 134 mobile node need not have a permanent Home address or Home Agent in 135 order to be HMIPv6-aware or use the features in this specification. A 136 MAP may be used by a mobile node in a nomadic manner to achieve 137 mobility management within a local domain. Section 6.5 describes such 138 scenario. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [3]. 146 In addition, new terms are defined below: 148 Access Router (AR) The AR is the Mobile Node's default router. 149 The AR aggregates the outbound traffic of 150 mobile nodes. 152 Mobility Anchor Point A Mobility Anchor Point is a router located 153 (MAP) in a network visited by the mobile node. 154 The MAP is used by the MN as a local HA. 155 One or more MAPs can exist within a visited 156 network. 158 Regional Care-of An RCoA is an address obtained by the 159 Address (RCoA) mobile node from the visited network. An 160 RCoA is an address on the MAP's subnet. It 161 is auto-configured by the mobile node when 162 receiving the MAP option. 164 HMIPv6-aware An HMIPv6-aware mobile node is a mobile 165 Mobile Node node that can receive and process the MAP 166 option received from its default router. 167 An HMIPv6-aware Mobile Node must also be 168 able to send local binding updates (Binding 169 Update with the M flag set). 171 On-link Care-of The LCoA is the on-link CoA configured on 172 Address (LCoA) a mobile node's interface based on the 173 prefix advertised by its default router. 174 In [1], this is simply referred to as the 175 Care-of- address. However, in this memo 176 LCoA is used to distinguish it from the 177 RCoA. 179 Local Binding Update The MN sends a Local Binding Update to the 180 MAP in order to establish a binding between 181 the RCoA and LCoA. 183 3. Overview of HMIPv6 185 This Hierarchical Mobile IPv6 scheme introduces a new function, the 186 MAP, and minor extensions to the mobile node operation. The 187 correspondent node and Home Agent operation will not be affected. 189 Just like Mobile IPv6, this solution is independent of the underlying 190 access technology, allowing mobility within or between different 191 types of access networks. 193 A mobile node entering a MAP domain will receive Router 194 Advertisements containing information about one or more local MAPs. 195 The MN can bind its current location (on-link CoA) with an address on 196 the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive 197 all packets on behalf of the mobile node it is serving and will 198 encapsulate and forward them directly to the mobile node's current 199 address. If the mobile node changes its current address within a 200 local MAP domain (LCoA), it only needs to register the new address 201 with the MAP. Hence, only the Regional CoA (RCoA) needs to be 202 registered with correspondent nodes and the HA. The RCoA does not 203 change as long as the MN moves within a MAP domain (see below for 204 definition). This makes the mobile node's mobility transparent to 205 correspondent nodes it communicates with. 207 A MAP domain's boundaries are defined by the Access Routers (ARs) 208 advertising the MAP information to the attached Mobile Nodes. The 209 detailed extensions to Mobile IPv6 and operations of the different 210 nodes will be explained later in this document. 212 It should be noted that the HMIPv6 concept is simply an extension to 213 the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an 214 implementation of Mobile IPv6 SHOULD choose to use the MAP when 215 discovering such capability in a visited network. However, in some 216 cases the mobile node may prefer to simply use the standard Mobile 217 IPv6 implementation. For instance, the mobile node may be located in 218 a visited network within its home site. In this case, the HA is 219 located near the visited network and could be used instead of a MAP. 220 In this scenario, the mobile node would only update the HA whenever 221 it moves. The method to determine whether the HA is in the vicinity 222 of the MN (e.g., same site) is outside the scope of this document. 224 3.1. HMIPv6 Operations 226 The network architecture shown in Figure 1 illustrates an example of 227 the use of the MAP in a visited network. 229 In Figure 1, the MAP can help in providing seamless mobility for the 230 mobile node as it moves from Access Router 1 (AR1) to Access Router 2 231 (AR2), while communicating with the correspondent node. A multi- 232 level hierarchy is not required for a higher handover performance. 233 Hence, it is sufficient to locate one or more MAPs (possibly covering 234 the same domain) at any position in the operator's network. 236 +-------+ 237 | HA | 238 +-------+ +----+ 239 | | CN | 240 | +----+ 241 | | 242 +-------+-----+ 243 | 244 |RCoA 245 +-------+ 246 | MAP | 247 +-------+ 248 | | 249 | +--------+ 250 | | 251 | | 252 +-----+ +-----+ 253 | AR1 | | AR2 | 254 +-----+ +-----+ 255 LCoA1 LCoA2 257 +----+ 258 | MN | 259 +----+ ------------> 260 Movement 262 Figure 1: Hierarchical Mobile IPv6 domain 264 Upon arrival in a visited network, the mobile node will discover the 265 global address of the MAP. This address is stored in the Access 266 Routers and communicated to the mobile node via Router Advertisements 267 (RAs). A new option for RAs is defined later in this specification. 268 This is needed to inform mobile nodes about the presence of the MAP 269 (MAP discovery). The discovery phase will also inform the mobile 270 node of the distance of the MAP from the mobile node. For example, 271 the MAP function could be implemented as shown in Figure 1, and, at 272 the same time, also be implemented in AR1 and AR2. In this case the 273 mobile node can choose the first hop MAP or one further up in the 274 hierarchy of routers. The details on how to choose a MAP are 275 provided in section 10. 277 The process of MAP discovery continues as the mobile node moves from 278 one subnet to the next. Every time the mobile node detects movement, 279 it will also detect whether it is still in the same MAP domain. The 280 router advertisement used to detect movement will also inform the 281 mobile node, through the MAP option, whether it is still in the same 282 MAP domain. As the mobile node roams within a MAP domain, it will 283 continue to receive the same MAP option included in router 284 advertisements from its AR. If a change in the advertised MAP's 285 address is received, the mobile node MUST act on the change by 286 sending Binding Updates to its HA and correspondent nodes. 288 If the mobile node is not HMIPv6-aware, then no MAP Discovery will be 289 performed, resulting in the mobile node using the Mobile IPv6 [1] 290 protocol for its mobility management. On the other hand, if the 291 mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 292 implementation. If so, the mobile node will first need to register 293 with a MAP by sending it a BU containing its Home Address and on-link 294 address (LCoA). The Home address used in the BU is the RCoA. The 295 MAP MUST store this information in its Binding Cache to be able to 296 forward packets to their final destination when received from the 297 different correspondent nodes or HAs. 299 The mobile node will always need to know the original sender of any 300 received packets to determine if route optimisation is required. 301 This information will be available to the mobile node because the MAP 302 does not modify the contents of the original packet. Normal 303 processing of the received packets (as described in [1]) will give 304 the mobile node the necessary information. 306 To use the network bandwidth in a more efficient manner, a mobile 307 node may decide to register with more than one MAP simultaneously and 308 to use each MAP address for a specific group of correspondent nodes. 309 For example, in Fig 1, if the correspondent node happens to exist on 310 the same link as the mobile node, it would be more efficient to use 311 the first hop MAP (in this case assume it is AR1) for communication 312 between them. This will avoid sending all packets via the "highest" 313 MAP in the hierarchy and thus will result in more efficient usage of 314 network bandwidth. The mobile node can also use its current on-link 315 address (LCoA) as a CoA, as specified in [1]. Note that the mobile 316 node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a 317 binding update sent to another MAP. The LCoA included in the binding 318 update MUST be the mobile node's address derived from the prefix 319 advertised on its link. 321 4. Mobile IPv6 Extension - Local Binding Update 323 This section outlines the extensions proposed to the binding update 324 specified in [1]. 326 A new flag is added: the M flag, which indicates MAP registration. 327 When a mobile node registers with the MAP, the M and A flags MUST be 328 set to distinguish this registration from a BU being sent to the HA 329 or a correspondent node. 331 0 1 2 3 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Sequence # | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |A|H|L|K|M| Reserved | Lifetime | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Description of extensions to the binding update: 344 M If set to 1 it indicates a MAP registration. 346 It should be noted that this is an extension to the Binding update 347 specified in [1]. 349 5. Neighbour Discovery Extension: The MAP Option Message Format 351 0 1 2 3 352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Dist | Pref |R| Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Valid Lifetime | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 + + 360 | | 361 + Global IP Address for MAP + 362 | | 363 + + 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Fields: 369 Type IPv6 Neighbor Discovery option. 23. 371 Length 8-bit unsigned integer. The length of the option 372 and MUST be set to 3. 374 Dist A 4-bit unsigned integer identifying the Distance 375 Between MAP and the receiver of the advertisement. 376 Its default value SHOULD be set to 1 if Dynamic 377 MAP discovery is used. The Distance MUST be set 378 to 1 if the MAP is on the same link as the mobile 379 node. This field need not be interpreted as the 380 number of hops between MAP and the mobile node. 381 The only requirement is that the meaning of the 382 Distance field is consistently interpreted within 383 one Domain. A Distance value of Zero MUST NOT be 384 used. 386 Pref The preference of a MAP. A 4-bit unsigned 387 integer. A decimal value of 15 indicates the 388 highest availability. 390 R When set to 1, it indicates that the mobile node 391 MUST form an RCoA based on the prefix in the MAP 392 option. 394 Valid Lifetime The minimum value (in seconds) of both the 395 preferred and valid lifetimes of the prefix 396 assigned to the MAP's subnet. This value 397 indicates the validity of the MAP's address and 398 consequently the time for which the RCoA is valid. 400 Global Address One of the MAP's global addresses. The 64-bit 401 prefix extracted from this address MUST be 402 configured in the MAP to be used for RCoA 403 construction by the mobile node. 405 Although not explicitly included in the MAP option, the prefix length 406 of the MAP's Global IP address MUST be 64. This prefix is the one 407 used by the mobile node to form an RCoA, by appending a 64-bit 408 identifier to the prefix. Thus, it necessitates a static prefix 409 length for the MAP's subnet. 411 6. Protocol Operation 413 This section describes the HMIPv6 protocol. In HMIPv6, the mobile 414 node has two addresses, an RCoA on the MAP's link and an on-link CoA 415 (LCoA). This RCoA is formed in a stateless manner by combining the 416 mobile node's interface identifier and the subnet prefix received in 417 the MAP option. 419 As illustrated in this section, this protocol requires updating the 420 mobile nodes' implementation only. The HA and correspondent node are 421 unchanged. The MAP performs the function of a "local" HA that binds 422 the mobile node's RCoA to an LCoA. 424 6.1. Mobile Node Operation 426 When a mobile node moves into a new MAP domain (i.e., its MAP 427 changes), it needs to configure two CoAs: an RCoA on the MAP's link 428 and an on-link CoA (LCoA). The RCoA is formed in a stateless manner. 429 After forming the RCoA based on the prefix received in the MAP 430 option, the mobile node sends a local BU to the MAP with the A and M 431 flags set. The local BU is a BU defined in [1] and includes the 432 mobile node's RCoA in the Home Address Option. No alternate-CoA 433 option is needed in this message. The LCoA is used as the source 434 address of the BU. This BU will bind the mobile node's RCoA (similar 435 to a Home Address) to its LCoA. The MAP (acting as a HA) will then 436 perform DAD (when a new binding is being created) for the mobile 437 node's RCoA on its link and return a Binding Acknowledgement to the 438 MN. This acknowledgement identifies the binding as successful or 439 contains the appropriate fault code. No new error codes need to be 440 supported by the mobile node for this operation. The mobile node 441 MUST silently ignore binding acknowledgements that do not contain a 442 routing header type 2, which includes the mobile node's RCoA. 444 Following a successful registration with the MAP, a bi-directional 445 tunnel between the mobile node and the MAP is established. All 446 packets sent by the mobile node are tunnelled to the MAP. The outer 447 header contains the mobile node's LCoA in the source address field 448 and the MAP's address in the destination address field. The inner 449 header contains the mobile node's RCoA in the source address field 450 and the peer's address in the destination address field. Similarly, 451 all packets addressed to the mobile node's RCoA are intercepted by 452 the MAP and tunnelled to the mobile node's LCoA. 454 This specification allows a mobile node to use more than one RCoA if 455 it received more than one MAP option. In this case, the mobile node 456 MUST perform the binding update procedure for each RCoA. In 457 addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived 458 from a MAP's prefix (e.g., MAP1) as a care-of address in its binding 459 update to another MAP (e.g., MAP2). This would force packets to be 460 encapsulated several times (twice in this example) on their path to 461 the mobile node. This form of multi-level hierarchy will reduce the 462 protocol's efficiency and performance. 464 After registering with the MAP, the mobile node MUST register its new 465 RCoA with its HA by sending a BU that specifies the binding (RCoA, 466 Home Address) as in Mobile IPv6. The mobile node's Home Address is 467 used in the home address option and the RCoA is used as the care-of 468 address in the source address field. The mobile node may also send a 469 similar BU (i.e., that specifies the binding between the Home Address 470 and the RCoA) to its current correspondent nodes. 472 The mobile node SHOULD wait for the binding acknowledgement from the 473 MAP before registering the RCoA with other nodes (e.g. CN or HA, if 474 available). It should be noted that when binding the RCoA with the HA 475 and correspondent nodes, the binding lifetime MUST NOT be larger than 476 the mobile node's binding lifetime with the MAP, which is received in 477 the Binding Acknowledgement. 479 In order to speed up the handover between MAPs and reduce packet 480 loss, a mobile node SHOULD send a local BU to its previous MAP, 481 specifying its new LCoA. Packets in transit that reach the previous 482 MAP are then forwarded to the new LCoA. 484 The MAP will receive packets addressed to the mobile node's RCoA 485 (from the HA or correspondent nodes). Packets will be tunnelled from 486 the MAP to the mobile node's LCoA. The mobile node will de-capsulate 487 the packets and process them in the normal manner. 489 When the mobile node moves within the same MAP domain, it should only 490 register its new LCoA with its MAP. In this case, the RCoA remains 491 unchanged. 493 Note that a mobile node may send a BU containing its LCoA (instead of 494 its RCoA) to correspondent nodes, which are connected to its same 495 link. Packets will then be routed directly without going through the 496 MAP. 498 6.1.1 Sending Packets to Correspondent Nodes 500 The mobile node can communicate with a correspondent node through the 501 HA, or in a route-optimised manner, as described in [1]. When 502 communicating through the HA, the message formats in [1] can be re- 503 used. 505 If the mobile node communicates directly with the correspondent node 506 (i.e., the CN has a binding cache entry for the mobile node), the 507 mobile node MUST use the same care-of address used to create a 508 binding cache entry in the correspondent node (RCoA) as a source 509 address. According to [1], the mobile node MUST also include a Home 510 Address option in outgoing packets. The Home address option MUST 511 contain the mobile node's home address. 513 6.2. MAP Operations 515 The MAP acts like an HA; it intercepts all packets addressed to 516 registered mobile nodes and tunnels them to the corresponding LCoA, 517 which is stored in its binding cache. 519 A MAP has no knowledge of the mobile node's Home address. The mobile 520 node will send a local BU to the MAP with the M and A flags set. The 521 aim of this BU is to inform the MAP that the mobile node has formed 522 an RCoA (contained in the BU as a Home address). If successful, the 523 MAP MUST return a binding acknowledgement to the mobile node, 524 indicating a successful registration. This is identical to the HA 525 operation in [1]. No new error codes are introduced for HMIPv6. The 526 binding acknowledgement MUST include a routing header type 2 that 527 contains the mobile node's RCoA. 529 The MAP MUST be able to accept packets tunnelled from the mobile 530 node, with the mobile node being the tunnel entry point and the MAP 531 being the tunnel exit point. 533 The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are 534 intercepted by the MAP, using proxy Neighbour Advertisement, and then 535 encapsulated and routed to the mobile node's LCoA. This operation is 536 identical to that of the HA described in [1]. 538 A MAP MAY be configured with the list of valid on-link prefixes that 539 mobile nodes can use to derive LCoAs. This is useful for network 540 operators that need to stop mobile nodes from continuing to use the 541 MAP after moving to a different administrative domain. If a mobile 542 node sent a binding update containing an LCoA that is not in the 543 MAP's "valid on-link prefixes" list, the MAP could reject the binding 544 update using existing error code 129 (administratively prohibited). 546 6.3. Home Agent Operations 548 The support of HMIPv6 is completely transparent to the HA's 549 operation. Packets addressed to a mobile node's Home Address will be 550 forwarded by the HA to its RCoA, as described in [1]. 552 6.4. Correspondent Node Operations 554 HMIPv6 is completely transparent to correspondent nodes. 556 6.5. Local Mobility Management Optimisation within a MAP Domain 558 In [1], it is stated that for short-term communication, particularly 559 communication that may easily be retried upon failure, the mobile 560 node MAY choose to directly use one of its care-of addresses as the 561 source of the packet, thus not requiring the use of a Home Address 562 option in the packet. Such use of the CoA will reduce the overhead 563 of sending each packet due to the absence of additional options. In 564 addition, it will provide an optimal route between the mobile node 565 and correspondent node. 567 HMIPv6-aware mobile nodes can use their RCoA as the source address 568 without using a Home Address option. In other words, the RCoA can be 569 used as a source address for upper layers. Using this feature, the 570 mobile node will be seen by the correspondent node as a fixed node 571 while moving within a MAP domain. 573 This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., 574 no bindings or home address options are sent over the Internet), but 575 still provides local mobility management to the mobile nodes with 576 near-optimal routing. Although such use of RCoA does not provide 577 global mobility (i.e. communication is broken when a mobile node 578 changes its RCoA), it would be useful for several applications (e.g., 579 web browsing). The validity of the RCoA as a source address used by 580 applications will depend on the size of a MAP domain and the speed of 581 the mobile node. Furthermore, because the support for BU processing 582 in correspondent nodes is not mandated in [1], this mechanism can 583 provide a way of obtaining route optimisation without sending BUs to 584 the correspondent nodes. 586 Enabling this mechanism can be done by presenting the RCoA as a 587 temporary home address for the mobile node. This may require an 588 implementation to augment its source address selection algorithm with 589 the knowledge of the RCoA in order to use it for the appropriate 590 applications. 592 6.6. Location Privacy 594 In HMIPv6, a mobile node hides its LCoA from its corresponding nodes 595 and its home agent by using its RCoA in the source field of the 596 packets that it sends. As a result, address-based location tracking 597 of a mobile node by its corresponding nodes or its home agent is more 598 difficult because they only know its RCoA and not its LCoA. 600 7. MAP Discovery 602 This section describes how a mobile node obtains the MAP address and 603 subnet prefix, and how ARs in a domain discover MAPs. Two different 604 methods for MAP discovery are defined below. 606 Dynamic MAP Discovery is based on propagating the MAP option in 607 Router Advertisements from the MAP to the mobile node through certain 608 (configured) router interfaces within the routers in an operator's 609 network. This requires manual configuration of the MAP and also that 610 the routers receiving the MAP option allow them to propagate the 611 option on certain interfaces. To ensure a secure communication 612 between routers, router advertisements that are sent between routers 613 for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, 614 ESP, or SEND). In the case where this authentication is not possible 615 (e.g., third party routers exist between the MAP and ARs), a network 616 operator may prefer to manually configure all the ARs to send the MAP 617 option, as described in this document. 619 Manual configuration of the MAP option information in ARs and other 620 MAPs in the same domain is the default mechanism. It should also be 621 possible to configure ARs and MAPs to enable dynamic mechanisms for 622 MAP Discovery. 624 7.1. Dynamic MAP Discovery 626 The process of MAP discovery can be performed in different ways. 627 Router advertisements are used for Dynamic MAP Discovery by 628 introducing a new option. The access router is required to send the 629 MAP option in its router advertisements. This option includes the 630 distance vector from the mobile node (which may not imply the real 631 distance in terms of the number of hops), the preference for this 632 particular MAP, the MAP's global IP address and subnet prefix 634 7.1.1. Router Operation for Dynamic MAP Discovery 636 The ARs within a MAP domain may be configured dynamically with the 637 information related to the MAP options. ARs may obtain this 638 information by listening for RAs with MAP options. Each MAP in the 639 network needs to be configured with a default preference, the right 640 interfaces to send this option on, and the IP address to be sent. 641 The initial value of the "Distance" field MAY be set to a default 642 value of 1 and MUST NOT be set to zero. Routers in the MAP domain 643 should be configured to re-send the MAP option on certain interfaces. 645 Upon reception of a router advertisement with the MAP option, the 646 receiving router MUST copy the option and re-send it after 647 incrementing the Distance field by one. If the receiving router was 648 also a MAP, it MUST send its own option, together with the received 649 option, in the same advertisement. If a router receives more than 650 one MAP option for the same MAP (i.e., the same IP address in the MAP 651 option), from two different interfaces, it MUST choose the option 652 with the smallest distance field. 654 In this manner, information about one or more MAPs can be dynamically 655 passed to a mobile node. Furthermore, by performing the discovery 656 phase in this way, different MAP nodes are able to change their 657 preferences dynamically based on the local policies, node overload or 658 other load-sharing protocols being used. 660 7.1.2. MAP Operation for Dynamic MAP Disovery 662 A MAP will be configured to send its option or relay MAP options 663 belonging to other MAPs onto certain interfaces. The choice of 664 interfaces is done by the network administrator (i.e., manual 665 configuration) and depends on the network topology. A default 666 preference value of 10 may be assigned to each MAP. It should be 667 noted that a MAP can change its preference value at any time due to 668 various reasons (e.g., node overload or load sharing). A preference 669 value of zero means the MAP SHOULD NOT be chosen by new mobile nodes. 670 This value could be reached in cases of node overload or partial node 671 failures. 673 The MAP option is propagated towards ARs in its domain. Each router 674 along the path to an AR will increment the Distance field by one. If 675 a router that is also a MAP receives advertisements from other MAPs, 676 it MUST add its own MAP option and propagate both options to the next 677 router or to the AR (if it has direct connectivity with the AR). 679 7.2. Mobile Node Operation 681 When an HMIPv6-aware mobile node receives a router advertisement, it 682 should search for the MAP option. One or more options may be found 683 for different MAP IP addresses. 685 A mobile node SHOULD register with the MAP having the highest 686 preference value. A MAP with a preference value of zero SHOULD NOT 687 be used for new local BUs (i.e., the mobile node can refresh existing 688 bindings but cannot create new ones). However, a mobile node MAY 689 choose to register with one MAP over another, depending on the value 690 received in the Distance field, provided that the preference value is 691 above zero. 693 A MAP option containing a valid lifetime value of zero means that 694 this MAP MUST NOT be selected by the MN. A valid lifetime of zero 695 indicates a MAP failure. When this option is received, a mobile node 696 MUST choose another MAP and create new bindings. Any existing 697 bindings with this MAP can be assumed to be lost. If no other MAP is 698 available, the mobile node MUST revert to using the Mobile IPv6 699 protocol, as specified in [1]. 701 If a multihomed mobile node has access to several ARs simultaneously 702 (on different interfaces), it SHOULD use an LCoA on the link defined 703 by the AR that advertises its current MAP. 705 A mobile node MUST store the received option(s) in order to choose at 706 least one MAP to register with. Storing the options is essential, as 707 they will be compared to other options received later for the purpose 708 of the movement detection algorithm. 710 If no MAP options are found in the router advertisement, the mobile 711 node MUST use the Mobile IPv6 protocol, as specified in [1]. 713 If the R flag is set, the mobile node MUST use its RCoA as the Home 714 Address when performing the MAP registration. RCoA is then bound to 715 the LCoA in the MAP's Binding Cache. 717 A mobile node MAY choose to register with more than one MAP 718 simultaneously, or use both the RCoA and its LCoA as care-of 719 addresses simultaneously with different correspondent nodes. 721 8. Updating Previous MAPs 723 When a mobile node moves into a new MAP domain, the mobile node may 724 send a BU to the previous MAP requesting it to forward packets 725 addressed to the mobile node's new CoA. An administrator MAY 726 restrict the MAP from forwarding packets to LCoAs outside the MAP's 727 domain. However, it is RECOMMENDED that MAPs be allowed to forward 728 packets to LCoAs associated with some of the ARs in neighbouring MAP 729 domains, provided that they are located within the same 730 administrative domain. 732 For instance, a MAP could be configured to forward packets to LCoAs 733 associated with ARs that are geographically adjacent to ARs on the 734 boundary of its domain. This will allow for a smooth inter-MAP 735 handover as it allows the mobile node to continue to receive packets 736 while updating the new MAP, its HA and, potentially, correspondent 737 nodes. 739 9. Note on MAP Selection by the Mobile Node 741 HMIPv6 provides a flexible mechanism for local mobility management 742 within a visited network. As explained earlier, a MAP can exist 743 anywhere in the operator's network (including the AR). Several MAPs 744 can be located within the same domain independently of each other. 745 In addition, overlapping MAP domains are also allowed and 746 recommended. Both static and dynamic hierarchies are supported. 748 When the mobile node receives a router advertisement including a MAP 749 option, it should perform actions according to the following movement 750 detection mechanisms. In a Hierarchical Mobile IP network such as 751 the one described in this document, the mobile node should be: 753 - "Eager" to perform new bindings 754 - "Lazy" in releasing existing bindings 756 The above means that the mobile node should register with any "new" 757 MAP advertised by the AR (Eager). The method by which the mobile 758 node determines whether the MAP is a "new" MAP is described in 759 section 9.1. The mobile node should not release existing bindings 760 until it no longer receives the MAP option (or receives it with a 761 lifetime of zero) or the lifetime of its existing binding expires 762 (Lazy). This Eager-Lazy approach, described above, will assist in 763 providing a fallback mechanism in case of the failure of one of the 764 MAP routers, as it will reduce the time it takes for a mobile node to 765 inform its correspondent nodes and HA about its new care-of address. 767 9.1. MAP Selection in a Distributed MAP Environment 769 The mobile node needs to consider several factors to optimally select 770 one or more MAPs, where several MAPs are available in the same 771 domain. 773 There are no benefits foreseen in selecting more than one MAP and 774 forcing packets to be sent from the higher MAP down through a 775 hierarchy of MAPs. This approach may add forwarding delays and 776 eliminate the robustness of IP routing between the highest MAP and 777 the mobile node; therefore, it is prohibited by this specification. 778 Allowing more than one MAP ("above" the AR) within a network should 779 not imply that the mobile node forces packets to be routed down the 780 hierarchy of MAPs. However, placing more than one MAP "above" the AR 781 can be used for redundancy and as an optimisation for the different 782 mobility scenarios experienced by mobile nodes. The MAPs are used 783 independently of each other by the MN (e.g., each MAP is used for 784 communication to a certain set of CNs). 786 In terms of the Distance-based selection in a network with several 787 MAPs, a mobile node may choose to register with the furthest MAP to 788 avoid frequent re-registrations. This is particularly important for 789 fast mobile nodes that will perform frequent handoffs. In this 790 scenario, the choice of a more distant MAP would reduce the 791 probability of having to change a MAP and informing all correspondent 792 nodes and the HA. This specification does not provide an algorithm 793 for the distance-based MAP selection. However, such an algorithm may 794 be introduced in future extensions utilising information about the 795 speed of mobility from lower layers. 797 In a scenario where several MAPs are discovered by the mobile node in 798 one domain, the mobile node may need sophisticated algorithms to be 799 able to select the appropriate MAP. These algorithms would have the 800 mobile node speed as an input (for distance based selection) combined 801 with the preference field in the MAP option. However, this 802 specification proposes that the mobile node uses the following 803 algorithm as a default, where other optimised algorithms are not 804 available. The following algorithm is simply based on selecting the 805 MAP that is most distant, provided that its preference value did not 806 reach a value of zero. The mobile node operation is shown below: 808 1. Receive and parse all MAP options 809 2. Arrange MAPs in a descending order, starting with the furthest 810 MAP (i.e., MAP option having largest Dist field) 811 3. Select first MAP in list 812 4. If either the preference value or the valid lifetime fields are 813 set to zero, select the following MAP in the list. 814 5. Repeat step (4) while new MAP options still exist, until a MAP is 815 found with a non-zero preference value and a non-zero valid 816 lifetime. 818 Implementing the steps above would result in mobile nodes selecting, 819 by default, the most distant or furthest available MAP. This will 820 continue until the preference value reduces to zero. Following this, 821 mobile nodes will start selecting another MAP. 823 9.2. MAP Selection in a Flat Mobility Architecture. 825 Network operators may choose a flat architecture in some cases where 826 a Mobile IPv6 handover may be considered a rare event. In these 827 scenarios, operators may choose to include the MAP function in ARs 828 only. The inclusion of the MAP function in ARs can still be useful 829 to reduce the time required to update all correspondent nodes and the 830 HA. In this scenario, a mobile node may choose a MAP (in the AR) as 831 an anchor point when performing a handoff. This kind of dynamic 832 hierarchy (or anchoring) is only recommended for cases where inter-AR 833 movement is not frequent. 835 10. Detection and Recovery from MAP Failures. 837 This specification introduces a MAP that can be seen as a local Home 838 Agent in a visited network. A MAP, like a Home Agent, is a single 839 point of failure. If a MAP fails, its binding cache content will be 840 lost, resulting in loss of communication between mobile and 841 correspondent nodes. This situation may be avoided by using more 842 than one MAP on the same link and by utilising some form of context 843 transfer protocol between them. Alternatively, future versions of 844 the Virtual Router Redundancy Protocol [4] or HA redundancy protocols 845 may allow networks to recover from MAP failures. 847 In cases where such protocols are not supported, the mobile node 848 would need to detect MAP failures. The mobile node can detect this 849 situation when it receives a router advertisement containing a MAP 850 option with a lifetime of zero. The mobile node should start the MAP 851 discovery process and attempt to register with another MAP. After it 852 has selected and registered with another MAP, it will also need to 853 inform correspondent nodes and the Home Agent if its RCoA has 854 changed. Note that in the presence of a protocol that transfers 855 binding cache entries between MAPs for redundancy purposes, a new MAP 856 may be able to provide the same RCoA to the mobile node (e.g., if 857 both MAPs advertise the same prefix in the MAP option). This would 858 save the mobile node from updating correspondent nodes and the Home 859 Agent. 861 Access routers can be triggered to advertise a MAP option with a 862 lifetime of zero (indicating MAP failure) in different ways: 864 - By manual intervention. 865 - In a dynamic manner. 867 ARs can perform Dynamic detection of MAP failure by sending ICMP Echo 868 request messages to the MAP regularly (e.g., every ten seconds). If 869 no response is received, an AR may try to aggressively send echo 870 requests to the MAP for a short period of time (e.g., once every 5 871 seconds for 15 seconds); if no reply is received, a MAP option may be 872 sent with a valid lifetime value of zero. 874 This specification does not mandate a particular recovery mechanism. 875 However, any similar mechanism between the MAP and an AR SHOULD be 876 secure to allow for message authentication, integrity protection, and 877 protection against replay attacks. 879 11. IANA Considerations 881 TBD. 883 12. Security Considerations 885 This specification introduces a new concept to Mobile IPv6, namely, a 886 Mobility Anchor Point that acts as a local Home Agent. It is crucial 887 that the security relationship between the mobile node and the MAP is 888 strong; it MUST involve mutual authentication, integrity protection, 889 and protection against replay attacks. Confidentiality may be needed 890 for payload traffic, but is not required for binding updates to the 891 MAP. The absence of any of these protections may lead to malicious 892 mobile nodes impersonating other legitimate ones or impersonating a 893 MAP. Any of these attacks will undoubtedly cause undesirable impacts 894 to the mobile node's communication with all correspondent nodes 895 having knowledge of the mobile node's RCoA. 897 Three different relationships (related to securing binding updates) 898 need to be considered: 900 1) The mobile node - MAP 901 2) The mobile node - Home Agent 902 3) The mobile node - correspondent node 904 12.1. Mobile Node-MAP Security 906 In order to allow a mobile node to use the MAP's forwarding service, 907 initial authorisation (specifically for the service, not for the 908 RCoA) MAY be needed. Authorising a mobile node to use the MAP 909 service can be done based on the identity of the mobile node 910 exchanged during the SA negotiation process. The authorisation may 911 be granted based on the mobile node's identity, or based on the 912 identity of a Certificate Authority (CA) that the MAP trusts. For 913 instance, if the mobile node presents a certificate signed by a 914 trusted entity (e.g., a CA that belongs to the same administrative 915 domain, or another trusted roaming partner), it would be sufficient 916 for the MAP to authorise the use of its service. Note that this 917 level of authorisation is independent of authorising the use of a 918 particular RCoA. Similarly, the mobile node would trust the MAP if 919 it presents a certificate signed by the same CA or by another CA that 920 the mobile node is configured to trust (e.g., a roaming partner). 922 HMIPv6 uses an additional registration between the mobile node and 923 its current MAP. As explained in this document, when a mobile node 924 moves into a new domain (i.e., served by a new MAP), it obtains an 925 RCoA, an LCoA and registers the binding between these two addresses 926 with the new MAP. The MAP then verifies whether the RCoA has not 927 been registered yet and, if so, it creates a binding cache entry with 928 the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it 929 needs to send a new BU that specifies the binding between RCoA and 930 its new LCoA. This BU needs to be authenticated, otherwise any host 931 could send a BU for the mobile node's RCoA and hijack the mobile 932 node's packets. However, because the RCoA is temporary and is not 933 bound to a particular node, a mobile node does not have to initially 934 (before the first binding update) prove that it owns its RCoA (unlike 935 the requirement on home addresses in Mobile IPv6) when it establishes 936 a Security Association with its MAP. A MAP only needs to ensure that 937 a BU for a particular RCoA was issued by the same mobile node that 938 established the Security Association for that RCoA. 940 The MAP does not need to have prior knowledge of the identity of the 941 mobile node nor its Home Address. As a result the SA between the 942 mobile node and the MAP can be established using any key 943 establishment protocols such as IKE. A return routability test is 944 not necessary. 946 The MAP needs to set the SA for the RCoA (not the LCoA). This can be 947 performed with IKE [2]. The mobile node uses its LCoA as the source 948 address, but specifies that the RCoA should be used in the SA. This 949 is achieved by using the RCoA as the identity in IKE Phase 2 950 negotiation. This step is identical to the use of the home address 951 in IKE phase 2. 953 If a binding cache entry exists for a given RCoA, the MAP's IKE 954 policy check MUST point to the SA used to install the entry. If the 955 mobile node's credentials stored in the existing SA do not match the 956 ones provided in the current negotiation, the MAP MUST reject the new 957 SA establishment request for such RCoA with an INVALID-ID-INFORMATION 958 notification [2]. This is to prevent two different mobile nodes from 959 registering (intentionally or not) the same RCoA. Upon receiving this 960 notification, the mobile node SHOULD generate a new RCoA and restart 961 the IKE negotiation. Alternatively, a MAP may decide that, if a 962 binding cache entry already exists for a particular RCoA, no new 963 security association should be established for such RCoA; this is 964 independent of the mobile node credentials. This prevents the mobile 965 node from being able to re-establish a security association for the 966 same RCoA (i.e., to change session keys). However, this is not a 967 major problem because the SA will typically only be used to protect 968 signalling traffic when a MN moves, and not for the actual data 969 traffic sent to arbitrary nodes. Binding updates between the MAP and 970 the mobile node MUST be protected with either AH or ESP in transport 971 mode. When ESP is used, a non- null authentication algorithm MUST be 972 used. 974 IKEv2 allows the use of EAP as a mechanism to bootstrap the security 975 association between the communicating peers. Hence, in the absence of 976 Certificates or PKI-based trust models, EAP can be used with IKEv2 to 977 leverage the AAA infrastructure to bootstrap the SA between the 978 mobile node and the MAP. Such mechanism is useful in scenarios where 979 an administrator wishes to avoid the configuration and management of 980 certificates on mobile nodes. 982 If EAP is used with IKEv2, the EAP method runs between the mobile 983 node and a AAA server. Following a successful authentication, the 984 resulting keying material can be used to bootstrap IKEv2 between the 985 MAP and the mobile node. The specification of which EAP methods 986 should be used, or how keys are transported between the MAP and the 987 AAA server is outside the scope of this document. 989 12.2. Mobile Node-Correspondent Node Security 991 Mobile IPv6 [1] defines a return routability procedure that allows 992 mobile and correspondent nodes to authenticate binding updates and 993 acknowledgements. This specification does not impact the return 994 routability test defined in [1]. However, it is important to note 995 that mobile node implementers need to be careful when selecting the 996 source address of the HOTI and COTI messages, defined in [1]. The 997 source address used in HOTI messages MUST be the mobile node's home 998 address. The packet containing the HOTI message is encapsulated 999 twice. The inner encapsulating header contains the RCoA in the 1000 source address field and the home agent's address in the destination 1001 address field. The outer encapsulating header contains the mobile 1002 node's LCoA in the source address field and the MAP's address in the 1003 destination field. 1005 12.3. Mobile Node-Home Agent Security 1007 The security relationship between the mobile node and its Home Agent, 1008 as discussed in [1], is not impacted by this specification. 1010 13. Acknowledgements 1012 The authors would like to thank Conny Larsson (Ericsson) and Mattias 1013 Pettersson (Ericsson) for their valuable input to this document. The 1014 authors would also like to thank the members of the French RNRT 1015 MobiSecV6 project (BULL, France Telecom and INRIA) for testing the 1016 first implementation and for their valuable feedback. The INRIA 1017 HMIPv6 project is partially funded by the French Government. 1019 In addition, the authors would like to thank the following members of 1020 the working group in alphabetical order: Samita Chakrabarti (Sun), 1021 Gregory Daley (Monash University), Francis Dupont (GET/Enst 1022 Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave 1023 Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf 1024 (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel 1025 Montenegro (Microsoft), Nick "Sharkey" Moore, Erik Nordmark (Sun), 1026 Basavaraj Patil (Nokia), Brett Pentland (Siemens), and Alper Yegin 1027 (Samsung) for their comments on the document. 1029 14. References 1031 14.1. Normative References. 1033 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1034 IPv6", RFC 3775, June 2004. 1036 [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1037 November 1998. 1039 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1040 Levels", BCP 14, RFC 2119, March 1997. 1042 14.2. Informative References 1044 [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 1045 2005. 1047 [5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 1048 Denial of Service Attacks which employ IP Source Address 1049 Spoofing", BCP 38, RFC 2827, May 2000. 1051 [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1052 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1054 Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 1056 Fast Handovers are required to ensure that the layer 3 (Mobile IP) 1057 handover delay is minimised, thus also minimising, and possibly 1058 eliminating, the period of service disruption which normally occurs 1059 when a mobile node moves between two ARs. This period of service 1060 disruption usually occurs due to the time required by the mobile node 1061 to update its HA using Binding Updates after it moves between ARs. 1062 During this time period the mobile node cannot resume or continue 1063 communications. The mechanism to achieve Fast Handovers with Mobile 1064 IPv6 is described in [5] and is briefly summarised here. This 1065 mechanism allows the anticipation of the layer 3 handover, such that 1066 data traffic can be redirected to the mobile node's new location 1067 before it moves there. 1069 While the mobile node is connected to its previous Access Router 1070 (PAR) and is about to move to a new Access Router (NAR), the Fast 1071 Handovers in Mobile IPv6 requires in sequence: 1073 1) The mobile node to obtain a new care-of address at the NAR while 1074 connected to the PAR. 1076 2) New CoA to be used at NAR case: the mobile node to send a F-BU 1077 (Fast BU) to its previous anchor point (i.e., PAR) to update its 1078 binding cache with the mobile node's new CoA while still attached 1079 to PAR. 1081 3) The previous anchor point (i.e., PAR) to start forwarding packets 1082 destined for the mobile node to the mobile node's new CoA at NAR 1083 (or old CoA tunnelled to NAR, if new CoA is not applicable). 1085 4) Old CoA to be used at NAR case: the mobile node to send a F-BU 1086 (Fast BU) to its previous anchor point (i.e., PAR), after it has 1087 moved and attached to NAR, in order to update its binding cache 1088 with the mobile node's new CoA. 1090 The mobile node or PAR may initiate the Fast Handover procedure by 1091 using wireless link-layer information or link-layer triggers that 1092 inform that the mobile node will soon be handed off between two 1093 wireless access points respectively attached to PAR and NAR. If the 1094 "trigger" is received at the mobile node, the mobile node will 1095 initiate the layer-3 handover process by sending a Proxy Router 1096 Solicitation message to PAR. Instead, if the "trigger" is received 1097 at PAR, then it will transmit a Proxy Router Advertisement to the 1098 appropriate mobile node, without the need for solicitations. The 1099 basic Fast Handover message exchanges are illustrated in Figure A.1. 1101 +-----------+ 1a. HI +-----+ 1102 | | ---------------->| NAR | 1103 | PAR | 1b. HAck | | 1104 +-----------+ <--------------- +-----+ 1105 ^ | ^ 1106 (2a. RtSolPr) | | 2b | 1107 | | Pr | 3. Fast BU (F-BU) 1108 | | RtAdv | 4. Fast BA (F-BACK) 1109 | v v 1110 +------------+ 1111 | MN | 1112 +------------+ - - - - - -> 1113 Movement 1115 Figure A.1: Fast Mobile IPv6 Handover Protocol 1117 The mobile node obtains a new care-of address while connected to PAR 1118 by means of router advertisements containing information from the NAR 1119 (Proxy Router Advertisement, which may be sent due to a Proxy Router 1120 Solicitation). The PAR will validate the mobile node's new CoA by 1121 sending a Handover Initiate (HI) message to the NAR. The new CoA 1122 sent in the HI message is formed by appending the mobile node's 1123 current interface identifier to the NAR's prefix. Based on the 1124 response generated in the Handover Acknowledge (HAck) message, the 1125 PAR will either generate a tunnel to the mobile node's new CoA (if 1126 the address was valid) or generate a tunnel to the NAR's address (if 1127 the address was already in use on the new subnet). If the address 1128 was already in use on the new subnet, it is assumed that there will 1129 be no time to perform another attempt to configure the mobile node 1130 with a CoA on the new link. Therefore, the NAR will generate a host 1131 route for the mobile node using its old CoA. Note that message 1a 1132 may precede message 2b or occur at the same time. 1134 In [5], the ARs act as local Home Agents, which hold binding caches 1135 for the mobile nodes and receive Binding Updates. This makes these 1136 ARs function like the MAP specified in this document. Also, it is 1137 quite possible that the ARs are not directly connected, but 1138 communicate through an aggregation router. Therefore, such an 1139 aggregation router is also an ideal position for the MAP 1140 functionality. These are two ways of integrating the HMIPv6 and ast 1141 Handover mechanisms. The first involves placing MAPs in place of the 1142 ARs, which is a natural step. The second scenario involves placing 1143 the MAP in an aggregation router "above" the ARs. In this case, [5] 1144 specifies forwarding of packets between PAR and NAR. This could be 1145 inefficient in terms of delay and bandwidth efficiency because 1146 packets will traverse the MAP-PAR link twice and packets will arrive 1147 out of order at the mobile node. Using the MAP in the aggregation 1148 router would improve the efficiency of Fast Handovers, which could 1149 make use of the MAP to redirect traffic, thus saving delay and 1150 bandwidth between the aggregation router and the PAR. 1152 +---------+ 1153 | MAP | 1154 +-------------->| | 1155 | +---------+ 1156 | | ^ 1157 | 1a. HI | | 1158 | | | 1159 | | | 1b. HAck 1160 | v | 1161 +---------+ | +---------+ 1162 | | | | NAR | 1163 | PAR | | | | 1164 +---------+ | +---------+ 1165 ^ | | 1166 (2a. RtSolPr) | | 2b | 1167 | | Pr | 3. Fast BU (F-BU) from mobile node to 1168 | | MAP 1169 | | RtAdv | 4. Fast BA (F-BACK) from MAP to 1170 | | | mobile node 1171 | v v 1172 +------------+ 1173 | MN | Movement 1174 +------------+ - - - - - -> 1176 Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6 1178 In Figure A.2, the HI/HAck messages now occur between the MAP and NAR 1179 in order to check the validity of the newly requested care-of address 1180 and to establish a temporary tunnel should the new care-of address 1181 not be valid. Therefore, the same functionality of the Fast Handover 1182 procedure is kept, but the anchor point is moved from the PAR to the 1183 MAP. 1185 As in the previous Fast Handover procedure, in the network-determined 1186 case the layer-2 "triggers" at the PAR will cause the PAR to send a 1187 Proxy Router Advertisement to the mobile node with the MAP option. 1188 In the mobile-determined case, this is preceded by a Proxy Router 1189 Solicitation from the mobile node. The same layer-2 trigger at PAR 1190 in the network-determined case could be used to independently 1191 initiate Context Transfer (e.g., QoS) between PAR and NAR. In the 1192 mobile-determined case, the trigger at PAR could be replaced by the 1193 reception of a Proxy Router Solicitation or F-BU. Context Transfer 1194 is being worked on in the IETF Seamoby WG. 1196 The combination of Fast Handover and HMIPv6 allows the anticipation 1197 of the layer 3 handoff, such that data traffic can be efficiently 1198 redirected to the mobile node's new location before it moves there. 1199 However, it is not easy to determine the correct time to start 1200 forwarding traffic from the MAP to the mobile node's new location, 1201 which has an impact on how smooth the handoff will be. The same 1202 issues arise in [5] with respect to when to start forwarding between 1203 PAR and NAR. Packet loss will occur if this is performed too late or 1204 too early with respect to the time in which the mobile node detaches 1205 from PAR and attaches to NAR. Such packet loss is likely to occur if 1206 the MAP updates its binding cache upon receiving the anticipated 1207 F-BU, because it is not known exactly when the mobile node will 1208 perform or complete the layer-2 handover to NAR, relative to when the 1209 mobile node transmits the F-BU. Also, some measure is needed to 1210 support the case in which the mobile node's layer-2 handover 1211 unexpectedly fails (after Fast Handover has been initiated) or when 1212 the mobile node moves quickly back-and-forth between ARs (ping-pong). 1213 Simultaneous bindings [6] provide a solution to these issues. In 1214 [6], a new Simultaneous Bindings Flag is added to the Fast Binding 1215 Update (F-BU) message and a new Simultaneous Bindings suboption is 1216 defined for the Fast Binding Acknowledgement (F-BAck) message. Using 1217 this enhanced mechanism, upon layer-3 handover, traffic for the 1218 mobile node will be sent from the MAP to both PAR and NAR for a 1219 certain period, thus isolating the mobile node from layer-2 effects 1220 such as handover timing, ping-pong, or handover failure and providing 1221 the mobile node with uninterrupted layer-3 connectivity. 1223 Authors' Addresses 1225 Hesham Soliman 1226 Qualcomm-Flarion Technologies 1227 E-mail: Hesham@Qualcomm.com 1229 Claude Castelluccia 1230 INRIA Rhone-Alpes 1231 655 avenue de l'Europe 1232 38330 Montbonnot Saint-Martin 1233 France 1235 EMail: claude.castelluccia@inria.fr 1236 Phone: +33 4 76 61 52 15 1238 Karim El Malki 1239 EMail: karim@elmalki.homeip.net 1241 Ludovic Bellier 1242 INRIA Rhone-Alpes 1243 655 avenue de l'Europe 1244 38330 Montbonnot Saint-Martin 1245 France 1247 EMail: ludovic.bellier@inria.fr 1249 Intellectual Property Statement 1251 The IETF takes no position regarding the validity or scope of any 1252 Intellectual Property Rights or other rights that might be claimed to 1253 pertain to the implementation or use of the technology described in 1254 this document or the extent to which any license under such rights 1255 might or might not be available; nor does it represent that it has 1256 made any independent effort to identify any such rights. Information 1257 on the IETF's procedures with respect to rights in IETF Documents can 1258 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1260 Copies of IPR disclosures made to the IETF Secretariat and any 1261 assurances of licenses to be made available, or the result of an 1262 attempt made to obtain a general license or permission for the use of 1263 such proprietary rights by implementers or users of this 1264 specification can be obtained from the IETF on-line IPR repository at 1265 http://www.ietf.org/ipr. 1267 The IETF invites any interested party to bring to its attention any 1268 copyrights, patents or patent applications, or other proprietary 1269 rights that may cover technology that may be required to implement 1270 this standard. Please address the information to the IETF at ietf- 1271 ipr@ietf.org. 1273 Full Copyright Statement 1275 Copyright (C) The Internet Society (2006). This document is subject 1276 to the rights, licenses and restrictions contained in BCP 78, and 1277 except as set forth therein, the authors retain all their rights. 1279 Disclaimer of Validity 1281 This document and the information contained herein are provided on an 1282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1284 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1285 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1289 This Internet-Draft expires April, 2007.