idnits 2.17.1 draft-ietf-mipshop-hmipv6-04.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.5 on line 1315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1299. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: '2' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1099, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-08 == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-01 == Outdated reference: A later version (-06) exists of draft-elmalki-mobileip-bicasting-v6-03 -- Obsolete informational reference (is this intentional?): RFC 2267 (ref. '14') (Obsoleted by RFC 2827) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-04 Summary: 15 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hesham Soliman, Flarion 3 INTERNET-DRAFT Claude Catelluccia, INRIA 4 Expires: June 2005 Karim El Malki, Ericsson 5 Ludovic Bellier, INRIA 6 December, 2004 8 Hierarchical Mobile IPv6 mobility management (HMIPv6) 9 11 Status of this memo 13 By submitting this Internet-Draft, we certify that any applicable 14 patent or other IPR claims of which I am (we are) aware have been 15 disclosed, and any of which we become aware will be disclosed, in 16 accordance with RFC 3668 (BCP 79). 18 By submitting this Internet-Draft, we accept the provisions of 19 Section 4 of RFC 3667 (BCP 78). 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 This document is a submission of the IETF MIPSHOP WG. Comments should 37 be directed to the MIPSHOP WG mailing list, mipshop@ietf.org. 39 Abstract 41 This document introduces extensions to Mobile IPv6 and IPv6 Neighbour 42 Discovery to allow for local mobility handling. Hierarchical mobility 43 management for Mobile IPv6 is designed to reduce the amount of 44 signalling between the Mobile Node, its Correspondent Nodes and its 45 Home Agent. The Mobility Anchor Point described in this document can 46 also be used to improve the performance of Mobile IPv6 in terms of 47 handover speed. 49 Table of Contents 51 1. Introduction.....................................................3 52 2. Terminology......................................................4 53 3. Overview of HMIPv6...............................................4 54 3.1. HMIPv6 Operation............................................5 55 4. Mobile IPv6 extensions...........................................7 56 4.1. Local Binding Update........................................7 57 5. Neighbour Discovery extension - The MAP option message format....8 58 6. Protocol operation...............................................9 59 6.1. Mobile node Operation.......................................9 60 6.1.1. Sending packets to correspondent nodes................11 61 6.2. MAP Operations.............................................11 62 6.3. Home Agent Operations......................................12 63 6.4. Correspondent node Operations..............................12 64 6.5. Local Mobility Management optimisation within a MAP domain.12 65 6.6. Location Privacy...........................................13 66 7. MAP discovery...................................................13 67 7.1. Dynamic MAP Discovery......................................13 68 7.1.1. Router Operation for Dynamic MAP Discovery............14 69 7.1.2. MAP Operation for Dynamic MAP Discovery...............14 70 7.2. Mobile node Operation......................................15 71 8. Updating previous MAPs..........................................15 72 9. Notes on MAP selection by the mobile node.......................16 73 9.1. MAP selection in a distributed-MAP environment.............16 74 9.2. MAP selection in a flat mobility management architecture...17 75 10. Detection and recovery from MAP failures.......................18 76 11. IANA Considerations............................................18 77 12. Security considerations........................................19 78 12.1. Mobile node-MAP security..................................19 79 12.2. Mobile node-correspondent node security...................20 80 12.3. Mobile node-Home Agent security...........................21 81 13. Acknowledgments................................................21 82 14. Authors' Addresses.............................................21 83 15. References.....................................................22 84 15.1. Normative references......................................22 85 15.2. Informative References....................................23 86 Appendix A - Fast Mobile IPv6 Handovers and HMIPv6.................24 88 1. Introduction 90 This memo introduces the concept of a Hierarchical Mobile IPv6 91 network, utilising a new node called the Mobility Anchor Point (MAP). 93 Mobile IPv6 [1] allows nodes to move within the Internet topology 94 while maintaining reachability and on-going connections between 95 mobile and correspondent nodes. To do this a mobile node sends 96 Binding Updates (BUs) to its Home Agent (HA) and all Correspondent 97 Nodes (CNs) it communicates with, every time it moves. Authenticating 98 binding updates requires approximately 1.5 round trip times between 99 the mobile node and each correspondent node (for the entire return 100 routability procedure in a best case scenario, i.e. no packet 101 losses). In addition, one round trip time is needed to update the 102 Home Agent, this can be done simultaneously while updating 103 correspondent nodes. The re-use of the home cookie (i.e. eliminating 104 HOTI/HOT) will not reduce the number of round trip times needed to 105 update correspondent nodes. These round trip delays will disrupt 106 active connections every time a handoff to a new AR is performed. 107 Eliminating this additional delay element from the time-critical 108 handover period will significantly improve the performance of Mobile 109 IPv6. Moreover, in the case of wireless links, such solution reduces 110 the number of messages sent over the air interface to all 111 correspondent nodes and the Home Agent. A local anchor point will 112 also allow Mobile IPv6 to benefit from reduced mobility signalling 113 with external networks. 115 For these reasons a new Mobile IPv6 node, called the Mobility Anchor 116 Point is used and can be located at any level in a hierarchical 117 network of routers, including the Access Router (AR). Unlike Foreign 118 Agents in IPv4, a MAP is not required on each subnet. The MAP will 119 limit the amount of Mobile IPv6 signalling outside the local domain. 120 The introduction of the MAP provides a solution to the issues 121 outlined earlier in the following way: 123 - The mobile node sends Binding Updates to the local MAP rather than 124 the HA (that is typically further away) and CNs 126 - Only one Binding Update message needs to be transmitted by the MN 127 before traffic from the HA and all CNs is re-routed to its new 128 location. This is independent of the number of CNs that the MN is 129 communicating with. 131 A MAP is essentially a local Home Agent. The aim of introducing the 132 hierarchical mobility management model in Mobile IPv6 is to enhance 133 the performance of Mobile IPv6 while minimising the impact on Mobile 134 IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6 135 Handovers to help Mobile Nodes in achieving seamless mobility (see 136 Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their 137 location from correspondent nodes and Home Agents while using Mobile 138 IPv6 route optimisation. 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 [10]. 146 In addition, new terms are defined below: 148 Access Router (AR) The Mobile Node's default router. The AR 149 aggregates the outbound traffic of mobile 150 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 169 (Binding Update with the M flag set). 171 On-link CoA (LCoA) The LCoA is the on-link CoA configured on 172 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 LCoA 176 is used to distinguish it from the RCoA. 178 Local Binding Update The MN sends a Local Binding Update to the 179 MAP in order to establish a binding 180 between the RCoA and LCoA. 182 3. Overview of HMIPv6 184 This Hierarchical Mobile IPv6 scheme introduces a new function, the 185 MAP, and minor extensions to the mobile node operation. The 186 correspondent node and Home Agent operation will not be affected. 188 Just like Mobile IPv6, this solution is independent of the underlying 189 access technology, allowing mobility within or between different 190 types of access networks. 192 A mobile node entering a MAP domain will receive Router 193 Advertisements containing information on one or more local MAPs. The 194 MN can bind its current location (on-link CoA) with an address on the 195 MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all 196 packets on behalf of the mobile node it is serving and will 197 encapsulate and forward them directly to the mobile node's current 198 address. If the mobile node changes its current address within a 199 local MAP domain (LCoA), it only needs to register the new address 200 with the MAP. Hence, only the Regional CoA (RCoA) needs to be 201 registered with correspondent nodes and the HA. The RCoA does not 202 change as long as the MN moves within a MAP domain (see below for 203 definition). This makes the mobile node's mobility transparent to the 204 correspondent nodes it is communicating with. 206 A MAP domain's boundaries are defined by the Access Routers (ARs) 207 advertising the MAP information to the attached Mobile Nodes. 208 The detailed extensions to Mobile IPv6 and operations of the 209 different nodes will be explained later in this document. 211 It should be noted that the HMIPv6 concept is simply an extension to 212 the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an 213 implementation of Mobile IPv6 SHOULD choose to use the MAP when 214 discovering such capability in a visited network. However, in some 215 cases the mobile node may prefer to simply use the standard Mobile 216 IPv6 implementation. For instance, the mobile node may be located in 217 a visited network within its home site. In this case, the HA is 218 located near the visited network and could be used instead of a MAP. 219 In this scenario, the mobile node would only update the HA whenever 220 it moves. The method to determine whether the HA is in the vicinity 221 of the MN (e.g. same site) is outside the scope of this document. 223 3.1. HMIPv6 Operation 225 The network architecture shown in Figure 1 illustrates an example of 226 the use of the MAP in a visited network. 228 In Figure 1, the MAP can help in providing seamless mobility for the 229 mobile node as it moves from Access Router 1 (AR1) to Access Router 2 230 (AR2), while communicating with the correspondent node. A multi-level 231 hierarchy is not required for a higher handover performance. Hence, 232 it is sufficient to locate one or more MAPs (possibly covering the 233 same domain) at any position in the operator's network. 235 +-------+ 236 | HA | 237 +-------+ +----+ 238 | | CN | 239 | +----+ 240 | | 241 +-------+-----+ 242 | 243 |RCoA 244 +-------+ 245 | MAP | 246 +-------+ 247 | | 248 | +--------+ 249 | | 250 | | 251 +-----+ +-----+ 252 | AR1 | | AR2 | 253 +-----+ +-----+ 254 LCoA1 LCoA2 256 +----+ 257 | MN | 258 +----+ ------------> 259 Movement 261 Figure 1: Hierarchical Mobile IPv6 domain 263 Upon arrival in a visited network, the mobile node will discover the 264 global address of the MAP. This address is stored in the Access 265 Routers and communicated to the mobile node via Router Advertisements 266 (RAs). A new option for RAs is defined later in this specification. 267 This is needed to inform mobile nodes about the presence of the MAP 268 (MAP discovery). The discovery phase will also inform the mobile node 269 of the distance of the MAP from the mobile node. For example, the MAP 270 function could be implemented as shown in Figure 1 and at the same 271 time also in AR1 and AR2. In this case the mobile node can choose the 272 first hop MAP or one further up in the hierarchy of routers. The 273 details on how to choose a MAP are provided in section 10. 275 The process of MAP discovery continues as the mobile node moves from 276 one subnet to the next. Every time the mobile node detects movement, 277 it will also detect whether it is still in the same MAP domain. The 278 router advertisement used to detect movement will also inform the 279 mobile node, through the MAP option, whether it is still in the same 280 MAP domain. As the mobile node roams within a MAP domain, it will 281 continue to receive the same MAP option included in router 282 advertisements from its AR. If a change in the advertised MAP's 283 address is received, the mobile node MUST act on the change by 284 sending Binding Updates to its HA and correspondent nodes. 286 If the mobile node is not HMIPv6-aware then no MAP Discovery will be 287 performed, resulting in the mobile node using the Mobile IPv6 [1] 288 protocol for its mobility management. On the other hand, if the 289 mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 290 implementation. If so, the mobile node will first need to register 291 with a MAP by sending it a BU containing its Home Address and on-link 292 address (LCoA). The Home address used in the BU is the RCoA. The MAP 293 MUST store this information in its Binding Cache to be able to 294 forward packets to their final destination when received from the 295 different correspondent nodes or HAs. 297 The mobile node will always need to know the original sender of any 298 received packets to determine if route optimisation is required. This 299 information will be available to the mobile node since the MAP does 300 not modify the contents of the original packet. Normal processing of 301 the received packets (as described in [1]) will give the mobile node 302 the necessary information. 304 To use the network bandwidth in a more efficient manner, a mobile 305 node may decide to register with more than one MAP simultaneously and 306 use each MAP address for a specific group of correspondent nodes. For 307 example, in Fig 1, if the correspondent node happens to exist on the 308 same link as the mobile node, it would be more efficient to use the 309 first hop MAP (in this case assume it is AR1) for communication 310 between them. This will avoid sending all packets via the "highest" 311 MAP in the hierarchy and hence result in a more efficient usage of 312 network bandwidth. The mobile node can also use its current on-link 313 address (LCoA) as a CoA as specified in [1]. Note that the mobile 314 node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a 315 binding update sent to another MAP. The LCoA included in the binding 316 update MUST be the mobile node's address derived from the prefix 317 advertised on its link. 319 If a router advertisement is used for MAP discovery, as described in 320 this document, all ARs belonging to the MAP domain MUST advertise the 321 MAP's IP address. The same concept (of advertising the MAP's presence 322 within its domain) should be used if other methods of MAP discovery 323 are introduced in future. 325 4. Mobile IPv6 extensions 327 This section outlines the extensions proposed to the binding update 328 specified in [1]. 330 4.1. Local Binding Update 332 A new flag is added; the M flag that indicates MAP registration. When 333 a mobile node registers with the MAP, the M and A flags MUST be set 334 to distinguish this registration from a BU being sent to the HA or a 335 correspondent node. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Sequence # | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |A|H|L|K|M| Reserved | Lifetime | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 . . 346 . Mobility Options . 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Description of extensions to the binding update: 352 M If set to 1 it indicates a MAP registration. 354 It should be noted that this is an extension to the Binding update 355 specified in [1]. 357 5. Neighbour Discovery extension - The MAP option message format 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | Dist | Pref |R| Reserved | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Valid Lifetime | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 + + 368 | | 369 + Global IP Address for MAP + 370 | | 371 + + 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Fields: 377 Type IPv6 Neighbor Discovery option. TBA. 379 Length 8-bit unsigned integer. The length of the 380 option and MUST be set to 3. 382 Dist A 4 bit unsigned integer identifying the 383 Distance Between MAP and the receiver of the 384 advertisement. Its default value SHOULD be set 385 to 1 if Dynamic MAP discovery is used. The 386 Distance MUST be set to 1 if the MAP is on the 387 same link as the mobile node. This field need 388 not be interpreted as the number of hops 389 between MAP and the mobile node. The only 390 requirement is that the meaning of the 391 Distance field is consistently interpreted 392 within one Domain. A Distance value of Zero 393 MUST NOT be used. 395 Pref The preference of a MAP. A 4 bit unsigned 396 integer. A decimal value of 15 indicates the 397 highest availability. 399 R When set to 1 it indicates that the mobile 400 node MUST form an RCoA based on the prefix in 401 the MAP option. 403 Valid Lifetime The minimum value (in seconds) of both the 404 preferred and valid lifetimes of the prefix 405 assigned to the MAP's subnet. This value 406 indicates the validity of the MAP's address 407 and consequently the time for which the RCoA 408 is valid. 410 Global Address One of the MAP's global addresses. 411 The 64-bit prefix extracted from this address 412 MUST be configured in the MAP to be used for 413 RCoA construction by the mobile node. 415 Although not explicitly included in the MAP option, the prefix length 416 of the MAP's Global IP address MUST be 64. This prefix is the one 417 used by the mobile node to form an RCoA, by appending a 64-bit 418 identifier to the prefix. Hence the need for having a static prefix 419 length for the MAP's subnet. 421 6. Protocol operation 423 This section describes the HMIPv6 protocol. In HMIPv6, the mobile 424 node has two addresses, an RCoA on the MAP's link and an on-link CoA 425 (LCoA). This RCoA is formed in a stateless manner by combining the 426 mobile node's interface identifier and the subnet prefix received in 427 the MAP option. 429 As illustrated in this section, this protocol requires updating the 430 mobile nodes' implementation only. The HA and correspondent node are 431 unchanged. The MAP performs the function of a "local" HA that binds 432 the mobile node's RCoA to an LCoA. 434 6.1. Mobile node Operation 435 When a mobile node moves into a new MAP domain (i.e. its MAP 436 changes), it needs to configure two CoAs: an RCoA on the MAP's link 437 and an on-link CoA (LCoA). The RCoA is formed in a stateless manner. 438 After forming the RCoA based on the prefix received in the MAP 439 option, the mobile node sends a local BU to the MAP with the A and M 440 flags set. The local BU is a BU defined in [1] and includes the 441 mobile node's RCoA in the Home Address Option. No alternate-CoA 442 option is needed in this message. The LCoA is used as the source 443 address of the BU. This BU will bind the mobile node's RCoA (similar 444 to a Home Address) to its LCoA. The MAP (acting as a HA) will then 445 perform DAD (when a new binding is being created) for the mobile 446 node's RCoA on its link and return a Binding Acknowledgement to the 447 MN. This acknowledgement identifies the binding as successful or 448 contains the appropriate fault code. No new error codes need to be 449 supported by the mobile node for this operation. The mobile node MUST 450 silently ignore binding acknowledgements that do not contain a 451 routing header type 2, which includes the mobile node's RCoA. 453 Following a successful registration with the MAP, a bi-directional 454 tunnel between the mobile node and the MAP is established. All 455 packets sent by the mobile node are tunnelled to the MAP. The outer 456 header contains the mobile node's LCoA in the source address field 457 and the MAP's address in the destination address field. The inner 458 header contains the mobile node's RCoA in the source address field 459 and the peer's address in the destination address field. Similarly, 460 all packets addressed to the mobile node's RCoA are intercepted by 461 the MAP and tunnelled to the mobile node's LCoA. 463 This specification allows a mobile node to use more than one RCoA if 464 it received more than one MAP option. In this case, the mobile node 465 MUST perform the binding update procedure for each RCoA. In addition, 466 the mobile node MUST NOT use one RCoA (e.g. RCoA1) derived from a 467 MAP's prefix (e.g. MAP1) as a care-of address in its binding update 468 to another MAP (e.g. MAP2). This would force packets to be 469 encapsulated several times (twice in this example) on their path to 470 the mobile node. This form of multi-level hierarchy will reduce the 471 protocol's efficiency and performance. 473 After registering with the MAP, the mobile node MUST register its new 474 RCoA with its HA by sending a BU that specifies the binding (RCoA, 475 Home Address) as in Mobile IPv6. The mobile node's Home Address is 476 used in the home address option and the RCoA is used as the care-of 477 address in the source address field. The mobile node may also send a 478 similar BU (i.e. that specifies the binding between the Home Address 479 and the RCoA) to its current correspondent nodes. 481 The mobile node SHOULD wait for the binding acknowledgement from the 482 MAP before registering with its HA. It should be noted that when 483 binding the RCoA with the HA and correspondent nodes, the binding 484 lifetime MUST NOT be larger than the mobile node's binding lifetime 485 with the MAP, which is received in the Binding Acknowledgement. 487 In order to speed up the handover between MAPs and reduce packet 488 loss, a mobile node SHOULD send a local BU to its previous MAP 489 specifying its new LCoA. Packets in transit that reach the previous 490 MAP are then forwarded to the new LCoA. 492 The MAP will receive packets addressed to the mobile node's RCoA 493 (from the HA or correspondent nodes). Packets will be tunnelled from 494 the MAP to the mobile node's LCoA. The mobile node will de-capsulate 495 the packets and process them in the normal manner. 497 When the mobile node moves within the same MAP domain, it should only 498 register its new LCoA with its MAP. In this case, the RCoA remains 499 unchanged. 501 Note that a mobile node may send a BU containing its LCoA (instead of 502 its RCoA) to correspondent nodes, which are connected to its same 503 link. Packets will then be routed directly without going through the 504 MAP. 506 6.1.1. Sending packets to correspondent nodes 508 The mobile node can communicate with a correspondent node through the 509 HA, or in a route-optimised manner, as described in [1]. When 510 communicating through the HA, the message formats in [1] can be 511 re-used. 513 If the mobile node communicates directly with the correspondent node 514 (i.e. the CN has a binding cache entry for the mobile node), the 515 mobile node MUST use the same care-of address used to create a 516 binding cache entry in the correspondent node (RCoA) as a source 517 address. According to [1], the mobile node MUST also include a Home 518 Address option in outgoing packets. The Home address option MUST 519 contain the mobile node's home address. 521 6.2. MAP Operations 523 The MAP acts like a HA; it intercepts all packets addressed to 524 registered mobile nodes and tunnels them to the corresponding LCoA, 525 which is stored in its binding cache. 527 A MAP has no knowledge of the mobile node's Home address. The mobile 528 node will send a local BU to the MAP with the M and A flags set. The 529 aim of this BU is to inform the MAP that the mobile node has formed 530 an RCoA (contained in the BU as a Home address). If successful, the 531 MAP MUST return a binding acknowledgement to the mobile node 532 indicating a successful registration. This is identical to the HA 533 operation in [1]. No new error codes are introduced for HMIPv6. The 534 binding acknowledgement MUST include a routing header type 2 that 535 contains the mobile node's RCoA. 537 The MAP MUST be able to accept packets tunnelled from the mobile 538 node, with the mobile node being the tunnel entry point and the MAP 539 being the tunnel exit point. 541 The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are 542 intercepted by the MAP, using proxy Neighbour Advertisement, 543 encapsulated and routed to the mobile node's LCoA. This operation is 544 identical to that of the HA described in [1]. 546 A MAP MAY be configured with the list of valid on-link prefixes that 547 mobile nodes can use to derive LCoAs. This is useful for network 548 operators to stop mobile nodes from continuing to use the MAP after 549 moving to a different administrative domain. If a mobile node sent a 550 binding update containing an LCoA that is not in the MAP's "valid 551 on-link prefixes" list, the MAP could reject the binding update using 552 existing error code 129 (administratively prohibited). 554 6.3. Home Agent Operations 556 The support of HMIPv6 is completely transparent to the HA's 557 operation. Packets addressed to a mobile node's Home Address will be 558 forwarded by the HA to its RCoA as described in [1]. 560 6.4. Correspondent node Operations 562 HMIPv6 is completely transparent to correspondent nodes. 564 6.5. Local Mobility Management optimisation within a MAP domain 566 In [1], it is stated that for short-term communication, particularly 567 communication that may easily be retried upon failure, the mobile 568 node MAY choose to directly use one of its care-of addresses as the 569 source of the packet, thus not requiring the use of a Home Address 570 option in the packet. Such use of the CoA will reduce the overhead of 571 sending each packet due to the absence of additional options. In 572 addition, it will provide an optimal route between the mobile node 573 and correspondent node. 575 In HMIPv6, a mobile node can use its RCoA as the source address 576 without using a Home Address option. In other words, the RCoA can be 577 used as a potential source address for upper layers. Using this 578 feature, the mobile node will be seen by the correspondent node as a 579 fixed node while moving within a MAP domain. 581 This usage of the RCoA does not have the cost of Mobile IPv6 (i.e. no 582 bindings or home address options are sent over the Internet) but 583 still provides local mobility management to the mobile nodes. 584 Although such use of RCoA does not provide global mobility (i.e. 585 communication is broken when a mobile host moves to a new MAP), it 586 would be useful for several applications (e.g. web browsing). The 587 validity of the RCoA as a source address used by applications will 588 depend on the size of a MAP domain and the speed of the mobile node. 589 Furthermore, since the support for BU processing in correspondent 590 nodes is not mandated in [1], this mechanism can provide a way of 591 obtaining route optimisation without sending BUs to the correspondent 592 nodes. 594 Enabling this mechanism can be done by presenting the RCoA as a 595 temporary home address for the mobile node. This may require an 596 implementation to augment its source address selection algorithm with 597 the knowledge of the RCoA in order to use it for the appropriate 598 applications. 600 6.6. Location Privacy 602 In HMIPv6, a mobile node hides its LCoA from its corresponding nodes 603 and its home agent by using its RCoA in the source field of the 604 packets that it sends. As a result, the location tracking of a mobile 605 node by its corresponding nodes or its home agent is difficult since 606 they only know its RCoA and not its LCoA. 608 7. MAP discovery 610 This section describes how a mobile node obtains the MAP address and 611 subnet prefix and how ARs in a domain discover MAPs. Two different 612 methods for MAP discovery are defined below. 614 Dynamic MAP Discovery is based on propagating the MAP option in 615 Router Advertisements from the MAP to the mobile node through certain 616 (configured) router interfaces within the routers in an operator's 617 network. This requires manual configuration of the MAP and the 618 routers receiving the MAP option to allow them to propagate the 619 option on certain interfaces. To ensure a secure communication 620 between routers, router advertisements that are sent between routers 621 for Dynamic MAP discovery SHOULD be authenticated (e.g. using AH, 622 ESP, or SEND). In the case where this authentication is not possible 623 (e.g. third party routers exist between the MAP and ARs), a network 624 operator may prefer to manually configure all the ARs to send the MAP 625 option as described in this document. 627 Manual configuration of the MAP option information in ARs and other 628 MAPs in the same domain is the default mechanism. It should also be 629 possible to configure ARs and MAPs to enable dynamic mechanisms for 630 MAP Discovery. 632 7.1. Dynamic MAP Discovery 634 The process of MAP discovery can be performed in different ways. 635 Router advertisements are used for Dynamic MAP Discovery by 636 introducing a new option. The access router is required to send the 637 MAP option in its router advertisements. This option includes the 638 distance vector from the mobile node (which may not imply the real 639 distance in terms of the number of hops), the preference for this 640 particular MAP, the MAP's global IP address and subnet prefix 642 7.1.1. Router Operation for Dynamic MAP Discovery 644 The ARs within a MAP domain may be configured dynamically with the 645 information related to the MAP options. ARs may obtain this 646 information by listening for RAs with MAP options. Each MAP in the 647 network needs to be configured with a default preference, the right 648 interfaces to send this option on and the IP address to be sent. The 649 initial value of the "Distance" field MAY be set to a default value 650 of 1 and MUST NOT be set to zero. Routers in the MAP domain should be 651 configured to re-send the MAP option on certain interfaces. 653 Upon reception of a router advertisement with the MAP option, the 654 receiving router MUST copy the option and re-send it after 655 incrementing the Distance field by one. If the receiving router was 656 also a MAP, it MUST send its own option together with the received 657 option in the same advertisement. If a router receives more than one 658 MAP option for the same MAP (i.e. the same IP address in the MAP 659 option), from two different interfaces, it MUST choose the option 660 with the smallest distance field. 662 In this manner, information about one or more MAPs can be dynamically 663 passed to a mobile node. Furthermore, by performing the discovery 664 phase in this way, different MAP nodes are able to change their 665 preferences dynamically based on the local policies, node overload or 666 other load sharing protocols being used. 668 7.1.2. MAP Operation for Dynamic MAP Discovery 670 A MAP will be configured to send its option or relay MAP options 671 belonging to other MAPs onto certain interfaces. The choice of 672 interfaces is done by the network administrator (i.e. manual 673 configuration) and depends on the network topology. A default 674 preference value of 10 may be assigned to each MAP. It should be 675 noted that a MAP can change its preference value at any time due to 676 various reasons (e.g. node overload or load sharing). A preference 677 value of zero means that the MAP SHOULD NOT be chosen by new mobile 678 nodes. This value could be reached in cases of node overload or 679 partial node failures. 681 The MAP option is propagated towards ARs in its domain. Each router 682 along the path to an AR will increment the Distance field by one. If 683 a router that is also a MAP receives advertisements from other MAPs, 684 it MUST add its own MAP option and propagate both options to the next 685 router or to the AR (if it has direct connectivity with the AR). 687 7.2. Mobile node Operation 689 When an HMIPv6-aware mobile node receives a router advertisement, it 690 should search for the MAP option. One or more options may be found 691 for different MAP IP addresses. 693 A mobile node SHOULD register with the MAP having the highest 694 preference value. A MAP with a preference value of zero SHOULD NOT be 695 used for new local BUs (i.e. the mobile node can refresh existing 696 bindings but cannot create new ones). A mobile node MAY however 697 choose to register with one MAP over another depending on the value 698 received in the Distance field, provided that the preference value is 699 above zero. 701 A MAP option containing a valid lifetime value of zero means that 702 this MAP MUST NOT be selected by the MN. A valid lifetime of zero 703 indicates a MAP failure. When this option is received, a mobile node 704 MUST choose another MAP and create new bindings. Any existing 705 bindings with this MAP can be assumed to be lost. If no other MAP is 706 available the mobile node MUST revert to using the Mobile IPv6 707 protocol as specified in [1]. 709 If a multihomed mobile node has access to several ARs simultaneously 710 (on different interfaces), it SHOULD use an LCoA on the link defined 711 by the AR that advertises its current MAP. 713 A mobile node MUST store the received option(s) to choose at least 714 one MAP to register with. Storing the options is essential as they 715 will be compared to other options received later for the purpose of 716 the movement detection algorithm. 718 If no MAP options are found in the router advertisement, the mobile 719 node MUST use the Mobile IPv6 protocol as specified in [1]. 721 If the R flag is set, the mobile node MUST use its RCoA as the Home 722 Address when performing the MAP registration. RCoA is then bound to 723 the LCoA in the MAP's Binding Cache. 725 A mobile node MAY choose to register with more than one MAP 726 simultaneously or use both the RCoA and its LCoA as care-of addresses 727 simultaneously with different correspondent nodes. 729 8. Updating previous MAPs 731 When a mobile node moves into a new MAP domain, the mobile node may 732 send a BU to the previous MAP requesting it to forward packets 733 addressed to the mobile node's new CoA. An administrator MAY restrict 734 the MAP from forwarding packets to LCoAs outside the MAP's domain. 735 However, it is RECOMMENDED that MAPs be allowed to forward packets to 736 LCoAs associated with some of the ARs in neighbouring MAP domains, 737 provided that they are located within the same administrative domain. 739 For instance, a MAP could be configured to forward packets to LCoAs 740 associated with ARs that are geographically adjacent to ARs on the 741 boundary of its domain. This will allow for a smooth inter-MAP 742 handover as it allows the mobile node to continue to receive packets 743 while updating the new MAP, its HA and, potentially, correspondent 744 nodes. 746 9. Notes on MAP selection by the mobile node 748 HMIPv6 provides a flexible mechanism for local mobility management 749 within a visited network. As explained earlier a MAP can exist 750 anywhere in the operator's network (including the AR). Several MAPs 751 can be located within the same domain independently of each other. In 752 addition, overlapping MAP domains are also allowed and recommended. 753 Both static and dynamic hierarchies are supported. 755 When the mobile node receives a router advertisement including a MAP 756 option, it should perform actions according to the following movement 757 detection mechanisms. In a Hierarchical Mobile IP network such as the 758 one described in this draft, the mobile node should be: 760 - "Eager" to perform new bindings 761 - "Lazy" in releasing existing bindings 763 The above means that the mobile node should register with any "new" 764 MAP advertised by the AR (Eager). The method by which the mobile node 765 determines whether the MAP is a "new" MAP is described in section 766 9.1. The mobile node should not release existing bindings until it no 767 longer receives the MAP option (or receives it with a lifetime of 768 zero) or the lifetime of its existing binding expires (Lazy). This 769 Eager-Lazy approach described above will assist in providing a 770 fallback mechanism in case of the failure of one of the MAP routers, 771 as it would reduce the time it takes for a mobile node to inform its 772 correspondent nodes and HA about its new care-of address. 774 9.1. MAP selection in a distributed-MAP environment 776 The mobile node needs to consider several factors to optimally select 777 one or more MAPs, where several MAPs are available in the same 778 domain. 780 There are no benefits foreseen in selecting more than one MAP and 781 forcing packets to be sent from the higher MAP down through a 782 hierarchy of MAPs. This approach may add forwarding delays and 783 eliminate the robustness of IP routing between the highest MAP and 784 the mobile node; it is therefore prohibited by this specification. 785 Hence, allowing more than one MAP ("above" the AR) within a network 786 should not imply that the mobile node forces packets to be routed 787 down the hierarchy of MAPs. However, placing more than one MAP 788 "above" the AR can be used for redundancy and as an optimisation for 789 the different mobility scenarios experienced by mobile nodes. The 790 MAPs are used independently from each other by the MN (e.g. each MAP 791 is used for communication to a certain set of CNs). 793 In terms of the Distance-based selection in a network with several 794 MAPs, a mobile node may choose to register with the furthest MAP to 795 avoid frequent re-registrations. This is particularly important for 796 fast mobile nodes that will perform frequent handoffs. In this 797 scenario, the choice of a more distant MAP would reduce the 798 probability of having to change a MAP and informing all correspondent 799 nodes and the HA. This specification does not provide an algorithm 800 for the distance-based MAP selection. However, such algorithm may be 801 introduced in future extensions utilising information about the speed 802 of mobility from lower layers. 804 In a scenario where several MAPs are discovered by the mobile node in 805 one domain, the mobile node may need some sophisticated algorithms to 806 be able to select the appropriate MAP. These algorithms would have 807 the mobile node speed as an input (for distance based selection) 808 combined with the preference field in the MAP option. However, this 809 specification proposes that the mobile node uses the following 810 algorithm as a default, where other optimised algorithms are not 811 available. The following algorithm is simply based on selecting the 812 MAP that is most distant, provided that its preference value did not 813 reach a value of zero. The mobile node operation is shown below: 815 1. Receive and parse all MAP options 816 2. Arrange MAPs in a descending order, starting with the furthest 817 away MAP (i.e. MAP option having largest Dist field) 818 3. Select first MAP in list 819 4. If either the Preference value or the valid lifetime fields are 820 set to zero, select the following MAP in the list. 821 5. Repeat step (4) while new MAP options still exist until a MAP is 822 found with preference value and valid lifetime different from 823 zero. 825 Implementing the steps above would result in mobile nodes selecting 826 by default the most distant or furthest available MAP by default. 827 This will continue to take place, until the preference value reduces 828 to zero. Following this, mobile nodes will start selecting another 829 MAP. 831 9.2. MAP selection in a flat mobility management architecture 833 Network operators may choose a flat architecture in some cases where 834 a Mobile IPv6 handover may be considered a rare event. In these 835 scenarios operators may choose to include the MAP function in ARs 836 only. The inclusion of the MAP function in ARs can still be useful to 837 reduce the time required to update all correspondent nodes and the 838 HA. In this scenario, a mobile node may choose a MAP (in the AR) as 839 an anchor point when performing a handoff. This kind of dynamic 840 hierarchy (or anchoring) is only recommended for cases where inter-AR 841 movement is not frequent. 843 10. Detection and recovery from MAP failures 845 This specification introduces a MAP that can be seen as a local Home 846 Agent in a visited network. A MAP, like a Home Agent, is a single 847 point of failure. If a MAP fails, its binding cache content will be 848 lost, resulting in loss of communication between mobile and 849 correspondent nodes. This situation may be avoided with the use of 850 more than one MAP on the same link and utilising some form of context 851 transfer protocol between them. Alternatively, future versions of the 852 Virtual Router Redundancy Protocol [12], or HA redundancy protocols 853 may allow networks to recover from MAP failures. 855 In cases where such protocols are not supported, the mobile node 856 would need to detect MAP failures. The mobile node can detect this 857 situation when it receives a router advertisement containing a MAP 858 option with a lifetime of zero. The mobile node should start the MAP 859 discovery process and attempt to register with another MAP. After it 860 has selected and registered with another MAP it will also need to 861 inform correspondent nodes and the Home Agent if its RCoA has 862 changed. Note that, in the presence of a protocol that transfers 863 binding cache entries between MAPs for redundancy purposes, a new MAP 864 may be able to provide the same RCoA to the mobile node, e.g. if both 865 MAPs advertise the same prefix in the MAP option. This would save the 866 mobile node from updating correspondent nodes and the Home Agent. 868 Access routers can be triggered to advertise a MAP option with a 869 lifetime of zero (indicating MAP failure) in different ways: 871 - By manual intervention. 872 - In a dynamic manner. 874 ARs can perform Dynamic detection of MAP failure by sending ICMP Echo 875 request messages to the MAP regularly (e.g. every ten seconds). If no 876 response is received an AR may try to aggressively send echo requests 877 to the MAP for a short period of time (e.g. once every 5 seconds for 878 15 seconds); if no reply is received, a MAP option may be sent with a 879 valid lifetime value of zero. 881 This specification does not mandate a particular recovery mechanism. 882 However, any similar mechanism between the MAP and an AR SHOULD be 883 secure to allow for message authentication, integrity protection and 884 protection against replay attacks. 886 11. IANA Considerations 888 Section 4 introduces a new flag (M )to the Binding Update specified 889 in RFC 3775. 890 Section 5 introduces a new IPv6 Neighbour Discovery Option called the 891 MAP Option. An Option Type value for the MAP Option must be assigned 892 by IANA within the option numbering space for IPv6 Neighbour 893 Discovery messages. 895 12. Security considerations 897 This specification introduces a new concept to Mobile IPv6, namely, a 898 Mobility Anchor Point that acts as a local Home Agent. It is crucial 899 that the security relationship between the mobile node and the MAP is 900 of strong nature; it MUST involve mutual authentication, integrity 901 protection and protection against replay attacks. Confidentiality may 902 be needed for payload traffic but is not required for binding updates 903 to the MAP. The absence of any of these protections may lead to 904 malicious mobile nodes impersonating other legitimate ones, 905 impersonating a MAP. Any of these attacks will undoubtedly cause 906 undesirable impacts to the mobile node's communication with all 907 correspondent nodes having knowledge of the mobile node's RCoA. 909 Three different relationships (related to securing binding updates) 910 need to be considered: 912 1) The mobile node - MAP 913 2) The mobile node - Home Agent 914 3) The mobile node - correspondent node 916 12.1. Mobile node-MAP security 918 In order to allow a mobile node to use the MAP's forwarding service, 919 initial authorization (specifically for the service, not for the 920 RCoA) MAY be needed. Authorising a mobile node to use the MAP service 921 can be done based on the identity of the mobile node exchanged during 922 the SA negotiation process. The authorization may be granted based on 923 the mobile node's identity, or based on the identity of a Certificate 924 Authority (CA) that the MAP trusts. For instance, if the mobile node 925 presents a certificate signed by a trusted entity (e.g. a CA that 926 belongs to the same administrative domain, or another trusted roaming 927 partner), it would be sufficient for the MAP to authorise the use of 928 its service. Note that this level of authorisation is independent of 929 authorising the use of a particular RCoA. Similarly, the mobile node 930 would trust the MAP, if it presents a certificate signed by the same 931 CA, or by another CA that the mobile node is configured to trust 932 (e.g. a roaming partner). 934 HMIPv6 uses an additional registration between the mobile node and 935 its current MAP. As explained in this document, when a mobile node 936 moves into a new domain (i.e. served by a new MAP), it obtains an 937 RCoA, a LCoA and registers the binding between these two addresses 938 with the new MAP. The MAP then verifies whether the RCoA has not been 939 registered yet and if so it creates a binding cache entry with the 940 RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to 941 send a new BU that specifies the binding between RCoA and its new 942 LCoA. This BU needs to be authenticated otherwise any host could send 943 a BU for the mobile node's RCoA and hijack the mobile node's packets. 944 However since the RCoA is temporary and is not bound to a particular 945 node, a mobile node does not have to initially (before the first 946 binding update) prove that it owns its RCoA (unlike the requirement 947 on home addresses in Mobile IPv6) when it establishes a Security 948 Association with its MAP. A MAP only needs to ensure that a BU for a 949 particular RCoA was issued by the same mobile node that established 950 the Security Association for that RCoA. 952 The MAP does not need to have prior knowledge of the identity of the 953 mobile node nor its Home Address. As a result the SA between the 954 mobile node and the MAP can be established using any key 955 establishment protocols such as IKE. A return routability test is not 956 necessary. 958 The MAP needs to set the SA for the RCoA (not the LCoA). This can be 959 performed with IKE [6]. The mobile node uses its LCoA as source 960 address but specifies that the RCoA should be used in the SA. This is 961 achieved by using the RCoA as the identity in IKE Phase 2 962 negotiation. This step is identical to the use of the home address in 963 IKE phase 2. 965 If a binding cache entry exists for a given RCoA, the MAP's IKE 966 policy check MUST point to the SA used to install the entry. If the 967 mobile node's credentials stored in the existing SA do not match the 968 ones provided in the current negotiation, the MAP MUST reject the new 969 SA establishment request for such RCoA with an INVALID-ID-INFORMATION 970 notification [6]. This is to prevent two different mobile nodes from 971 registering (intentionally or not) the same RCoA. Upon receiving this 972 notification, the mobile node SHOULD generate a new RCoA and restart 973 the IKE negotiation. Alternatively, a MAP may decide that if a 974 binding cache entry already exists for a particular RCoA, no new 975 security association should be established for such RCoA, 976 independently of the mobile node credentials. This stops the mobile 977 node from re-establishing a security association for the same RCoA. 978 This is not a major problem since both AH and ESP headers allow for 4 979 billion packets to be sent (the size of the sequence number field) 980 using the same security association. 982 Binding updates between the MAP and the mobile node MUST be protected 983 with either AH or ESP in transport mode. When ESP is used, a non-null 984 authentication algorithm MUST be used. 986 12.2. Mobile node-correspondent node security 988 Mobile IPv6 [1] defines a return routability procedure that allows 989 mobile and correspondent nodes to authenticate binding updates and 990 acknowledgements. This specification does not impact the return 991 routability test defined in [1]. However, it is important to note 992 that mobile node implementers need to be careful when selecting the 993 source address of the HOTI and COTI messages defined in [1]. The 994 source address used in HOTI messages MUST be the mobile node's home 995 address. The packet containing the HOTI message is encapsulated 996 twice. The inner encapsulating header contains the RCoA in the source 997 address field and the home agent's address in the destination address 998 field. The outer encapsulating header contains the mobile node's LCoA 999 in the source address field and the MAP's address in the destination 1000 field. 1002 12.3. Mobile node-Home Agent security 1004 The security relationship between the mobile node and its Home Agent, 1005 as discussed in [1], is not impacted by this specification. 1007 13. Acknowledgments 1009 The authors would like to thank Conny Larsson (Ericsson) and Mattias 1010 Pettersson (Ericsson) for their valuable input to this draft. 1011 The authors would also like to thank the members of the French RNRT 1012 MobiSecV6 project (BULL, France Telecom and INRIA) for testing the 1013 first implementation and for their valuable feedback. The INRIA 1014 HMIPv6 project is partially funded by the French Government. 1016 In addition, the authors would like to thank the following members of 1017 the working group in alphabetical order: Samita Chakrabarti (Sun), 1018 Gregory Daley (Monash University), Francis Dupont (GET/Enst 1019 Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave 1020 Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf 1021 (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel 1022 Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik 1023 Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash 1024 University), and Alper Yegin (Samsung) for their comments on the 1025 draft. 1027 14. Authors' Addresses 1029 Hesham Soliman 1030 Flarion Technologies 1031 email: h.soliman@flarion.com 1033 Claude Castelluccia 1034 INRIA Rhone-Alpes 1035 655 avenue de l'Europe 1036 38330 Montbonnot Saint-Martin 1037 France 1038 email: claude.castelluccia@inria.fr 1039 phone: +33 4 76 61 52 15 1041 Karim El Malki 1042 Ericsson AB 1043 LM Ericssons Vag. 8 1044 126 25 Stockholm 1045 Sweden 1046 email: karim.el-malki@ericsson.com 1047 phone: +46 8 7195803 1049 Ludovic Bellier 1050 INRIA Rhone-Alpes 1051 655 avenue de l'Europe 1052 38330 Montbonnot Saint-Martin 1053 France 1054 email: ludovic.bellier@inria.fr 1055 phone: +33 4 76 61 52 15 1057 15. References 1059 15.1. Normative references 1061 [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 1062 IPv6", RFC 3775. 1064 [2] S. Thomson and T. Narten, "IPv6 Stateless Address 1065 Autoconfiguration", RFC 2462. 1067 [3] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery 1068 for IP version 6", RFC 2461. 1070 [4] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 1071 specification", RFC 2460. 1073 [5] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE) ", 1074 RFC 2409. 1076 [6] S. Kent and R. Atkinson, "IP Authentication Header", RFC 2402. 1078 [7] S. Kent and R. Atkinson, "IP Encapsulating Security Payload", 1079 RFC 2406. 1081 [8] S. Kent and R. Atkinson, "Security Architecture for the 1082 Internet", RFC 2401. 1084 [9] A. Conta and S. Deering, "Generic Packet Tunneling in IPv6 1085 Specification", RFC 2473. 1087 [10] S. Bradner, "Keywords to use in RFCs to Indicate Requirement 1088 Levels", RFC2119. 1090 15.2. Informative References 1092 [11] K. El Malki (Editor), et. al, "Low latency Handoffs in Mobile 1093 IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-08, work in 1094 progress. 1096 [12] R. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6", 1097 draft-ietf-mipshop-fast-mipv6-01.txt, work in progress. 1099 [13] K. El Malki and H. Soliman, "Simultaneous Bindings for Mobile 1100 IPv6 Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-03, work 1101 in progress. 1103 [14] P. Ferguson and D. Senie, "Network Ingress Filtering: 1104 Defeating Denial of Service Attacks which employ IP Source Address 1105 Spoofing", RFC2267. 1107 [15] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, 1108 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-04, work 1109 in progress, February 2004. 1111 Appendix A - Fast Mobile IPv6 Handovers and HMIPv6 1113 Fast Handovers are required to ensure that the layer 3 (Mobile IP) 1114 handover delay is minimised, thus also minimising and possibly 1115 eliminating the period of service disruption which normally occurs 1116 when a mobile node moves between two ARs. This period of service 1117 disruption usually occurs due to the time required by the mobile node 1118 to update its HA using Binding Updates after it moves between ARs. 1119 During this time period the mobile node cannot resume or continue 1120 communications. The mechanism to achieve Fast Handovers with Mobile 1121 IPv6 is described in [14] and is briefly summarised here. This 1122 mechanism allows the anticipation of the layer 3 handover such that 1123 data traffic can be redirected to the mobile node's new location 1124 before it moves there. 1126 While the mobile node is connected to its previous Access Router 1127 (PAR) and is about to move to a new Access Router (NAR), the Fast 1128 Handovers in Mobile IPv6 requires in sequence: 1130 1) the mobile node to obtain a new care-of address at the NAR while 1131 connected to the PAR 1132 2) New CoA to be used at NAR case: the mobile node to send a F-BU 1133 (Fast BU) to its previous anchor point (i.e. PAR) to update its 1134 binding cache with the mobile node's new CoA while still attached 1135 to PAR 1136 3) The previous anchor point (i.e. PAR) to start forwarding packets 1137 destined for the mobile node to the mobile node's new CoA at NAR 1138 (or old CoA tunnelled to NAR if new CoA is not applicable). 1139 4) Old CoA to be used at NAR case: the mobile node to send a F-BU 1140 (Fast BU) to its previous anchor point (i.e. PAR), after it has 1141 moved and attached to NAR, in order to update its binding cache 1142 with the mobile node's new CoA. 1144 The mobile node or PAR may initiate the Fast Handover procedure by 1145 using wireless link-layer information or link-layer triggers which 1146 inform that the mobile node will soon be handed off between two 1147 wireless access points respectively attached to PAR and NAR. If the 1148 "trigger" is received at the mobile node, the mobile node will 1149 initiate the layer-3 handover process by sending a Proxy Router 1150 Solicitation message to PAR. Instead if the "trigger" is received at 1151 PAR then it will transmit a Proxy Router Advertisement to the 1152 appropriate mobile node, without the need for solicitations. The 1153 basic Fast Handover message exchanges are illustrated in Figure A.1. 1155 +-----------+ 1a. HI +-----+ 1156 | | ---------------->| NAR | 1157 | PAR | 1b. HAck | | 1158 +-----------+ <--------------- +-----+ 1159 ^ | ^ 1160 (2a. RtSolPr) | | 2b | 1161 | | Pr | 3. Fast BU (F-BU) 1162 | | RtAdv | 4. Fast BA (F-BACK) 1163 | v v 1164 +------------+ 1165 | MN | 1166 +------------+ - - - - - -> 1167 Movement 1169 Figure A.1 - Fast Mobile IPv6 Handover Protocol 1171 The mobile node obtains a new care-of address while connected to PAR 1172 by means of router advertisements containing information from the NAR 1173 (Proxy Router Advertisement which may be sent due to a Proxy Router 1174 Solicitation). The PAR will validate the mobile node's new CoA by 1175 sending a Handover Initiate (HI) message to the NAR. The new CoA sent 1176 in the HI message is formed by appending the mobile node's current 1177 interface identifier to the NAR's prefix. Based on the response 1178 generated in the Handover Acknowledge (HAck) message, the PAR will 1179 either generate a tunnel to the mobile node's new CoA (if the address 1180 was valid) or generate a tunnel to the NAR's address (if the address 1181 was already in use on the new subnet). If the address was already in 1182 use on the new subnet it is assumed that there will be no time to 1183 perform another attempt to configure the mobile node with a CoA on 1184 the new link, so the NAR will generate a host route for the mobile 1185 node using its old CoA. Note that message 1a may precede message 2b 1186 or occur at the same time. 1188 In [14], the ARs act as local Home Agents, which hold binding caches 1189 for the mobile nodes and receive Binding Updates. This makes these 1190 ARs function like the MAP specified in this document. Also, it is 1191 quite possible that the ARs are not directly connected, but 1192 communicate through an aggregation router. Such an aggregation router 1193 is therefore also an ideal position for the MAP functionality. These 1194 are two ways of integrating the HMIPv6 and Fast Handover mechanisms. 1195 The first involves placing MAPs in place of the ARs which is a 1196 natural step. The second scenario involves placing the MAP in an 1197 aggregation router "above" the ARs. In this case, [14] specifies 1198 forwarding of packets between PAR and NAR. This could be inefficient 1199 in terms of delay, bandwidth efficiency since packets will traverse 1200 the MAP-PAR link twice and packets arriving out of order at the 1201 mobile node. Using the MAP in the aggregation router would improve 1202 the efficiency of Fast Handovers which could make use of the MAP to 1203 redirect traffic, thus saving delay and bandwidth between the 1204 aggregation router and the PAR. 1206 +---------+ 1207 | MAP | 1208 +-------------->| | 1209 | +---------+ 1210 | | ^ 1211 | 1a. HI | | 1212 | | | 1213 | | | 1b. HAck 1214 | v | 1215 +---------+ | +---------+ 1216 | | | | NAR | 1217 | PAR | | | | 1218 +---------+ | +---------+ 1219 ^ | | 1220 (2a. RtSolPr) | | 2b | 1221 | | Pr | 3. Fast BU (F-BU) from mobile node to 1222 | | MAP 1223 | | RtAdv | 4. Fast BA (F-BACK) from MAP to 1224 | | | mobile node 1225 | v v 1226 +------------+ 1227 | MN | Movement 1228 +------------+ - - - - - -> 1230 Figure A.2 Fast Mobile IPv6 Handover Protocol using HMIPv6 1232 In Figure A.2, the HI/HAck messages now occur between the MAP and NAR 1233 to check the validity of the newly requested care-of address and to 1234 establish a temporary tunnel should the new care-of address not be 1235 valid. Therefore the same functionality of the Fast Handover 1236 procedure is kept but the anchor point is moved from the PAR to the 1237 MAP. 1239 As in the previous Fast Handover procedure, in the network-determined 1240 case the layer-2 "triggers" at the PAR will cause the PAR to send a 1241 Proxy Router Advertisement to the mobile node with the MAP option. In 1242 the mobile-determined case this is preceded by a Proxy Router 1243 Solicitation from the mobile node. The same layer-2 trigger at PAR in 1244 the network-determined case could be used to independently initiate 1245 Context Transfer (e.g. QoS) between PAR and NAR. In the mobile 1246 determined case the trigger at PAR could be replaced by the reception 1247 of a Proxy Router Solicitation or F-BU. Context Transfer is being 1248 worked on in the IETF Seamoby WG. 1250 The combination of Fast Handover and HMIPv6 allows the anticipation 1251 of the layer 3 handoff such that data traffic can be efficiently 1252 redirected to the mobile node's new location before it moves there. 1253 However it is not easy to determine the correct time to start 1254 forwarding traffic from the MAP to the mobile node's new location, 1255 which has an impact on how smooth the handoff will be. The same 1256 issues arise in [14] with respect to when to start forwarding between 1257 PAR and NAR. Packet loss will occur if this is performed too late or 1258 too early with respect to the time in which the mobile node detaches 1259 from PAR and attaches to NAR. Such packet loss is likely to occur if 1260 the MAP updates its binding cache upon receiving the anticipated F- 1261 BU, since it is not known when exactly the mobile node will perform 1262 or complete the layer-2 handover to NAR relative to when the mobile 1263 node transmits the F-BU. Also, some measure is needed to support the 1264 case in which the mobile node's layer-2 handover unexpectedly fails 1265 (after Fast Handover has been initiated) or when the mobile node 1266 moves quickly back-and-forth between ARs (ping-pong). Simultaneous 1267 bindings [15] provides a solution to these issues. In [15] a new 1268 Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) 1269 message and a new Simultaneous Bindings suboption is defined for Fast 1270 Binding Acknowledgement (F-BAck) message. Using this enhanced 1271 mechanism, upon layer-3 handover, traffic for the mobile node will be 1272 sent from the MAP to both PAR and NAR for a certain period thus 1273 isolating the mobile node from layer-2 effects such as handover 1274 timing, ping-pong or handover failure and providing the mobile node 1275 with uninterrupted layer-3 connectivity. 1277 Intellectual Property Statement 1279 The IETF takes no position regarding the validity or scope of any 1280 Intellectual Property Rights or other rights that might be claimed to 1281 pertain to the implementation or use of the technology described in 1282 this document or the extent to which any license under such rights 1283 might or might not be available; nor does it represent that it has 1284 made any independent effort to identify any such rights. Information 1285 on the IETF's procedures with respect to rights in IETF Documents can 1286 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1288 Copies of IPR disclosures made to the IETF Secretariat and any 1289 assurances of licenses to be made available, or the result of an 1290 attempt made to obtain a general license or permission for the use of 1291 such proprietary rights by implementers or users of this 1292 specification can be obtained from the IETF on-line IPR repository at 1293 http://www.ietf.org/ipr. 1295 The IETF invites any interested party to bring to its attention any 1296 copyrights, patents or patent applications, or other proprietary 1297 rights that may cover technology that may be required to implement 1298 this standard. Please address the information to the IETF at ietf- 1299 ipr@ietf.org. 1301 Copyright Statement 1303 Copyright (C) The Internet Society (2004). This document is subject 1304 to the rights, licenses and restrictions contained in BCP 78, and 1305 except as set forth therein, the authors retain all their rights. 1307 Disclaimer of Validity 1309 This document and the information contained herein are provided on an 1310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1312 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1313 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1314 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1317 This Internet-Draft expires June, 2005.