idnits 2.17.1 draft-ietf-monami6-multiplecoa-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2009) is 5529 days in the past. Is this intentional? 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: 'MCOA PROHIBITED' is mentioned on line 1115, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1230, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1322, but not defined == Missing Reference: 'ID-DSMIP6' is mentioned on line 1457, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-07 ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-00 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa (Ed.) 3 Internet-Draft Toyota ITC/Keio Univ. 4 Intended status: Standards Track V. Devarapalli (Ed.) 5 Expires: September 7, 2009 Wichorus 6 T. Ernst 7 INRIA 8 K. Nagami 9 INTEC NetCore 10 March 6, 2009 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-12.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 7, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 According to the current Mobile IPv6 specification, a mobile node may 61 have several care-of addresses, but only one, called the primary 62 care-of address, that can be registered with its home agent and the 63 correspondent nodes. However, for matters of cost, bandwidth, delay, 64 etc, it is useful for the mobile node to get Internet access through 65 multiple accesses simultaneously, in which case the mobile node would 66 be configured with multiple active IPv6 care-of addresses. This 67 document proposes extensions to the Mobile IPv6 protocol to register 68 and use multiple care-of addresses. The extensions proposed in this 69 document can be used by Mobile Routers using the NEMO (Network 70 Mobility) Basic Support protocol as well. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 80 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 13 81 4.1. Binding Cache Structure and Binding Update List . . . . . 13 82 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13 83 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14 84 4.4. New Status Values for Binding Acknowledgement . . . . . . 15 86 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18 87 5.1. Management of Care-of Address(es) and Binding 88 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18 89 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18 90 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19 91 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20 92 5.5. Returning Home: Using Single Interface . . . . . . . . . . 20 93 5.5.1. Using only Interface attached to the Home Link . . . . 21 94 5.5.2. Using only Interface attached to the Visited Link . . 21 95 5.6. Returning Home: Simultaneous Home and Visited Link 96 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21 97 5.6.1. Problems of Simultaneous Home and Foreign 98 Attachments . . . . . . . . . . . . . . . . . . . . . 21 99 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22 100 5.6.3. Sending Deregistration Binding Update . . . . . . . . 23 101 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 24 102 5.6.5. Home Binding for Flow Binding Support . . . . . . . . 25 103 5.6.6. Sending Packets from the Home Link . . . . . . . . . . 26 104 5.6.7. Leaving from the Home Link . . . . . . . . . . . . . . 27 106 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 27 107 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 28 108 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 29 110 6. Home Agent and Correspondent Node Operation . . . . . . . . . 30 111 6.1. Searching Binding Cache with Binding Identifier . . . . . 30 112 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 30 113 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 33 114 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 33 116 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 34 118 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 35 119 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 35 120 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 36 122 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 38 123 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 38 124 9.2. Transport Mode IPsec protected messages . . . . . . . . . 39 125 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 39 126 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 39 127 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 40 129 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 131 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 133 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 136 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 137 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 141 1. Introduction 143 A mobile node may use various types of network interfaces to obtain 144 durable and wide area network connectivity. This has increasingly 145 become true with mobile nodes having multiple interfaces such as 146 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and 147 benefits of using multiple points of attachment are discussed in [ID- 148 MOTIVATION]. When a mobile node with multiple interfaces uses Mobile 149 IPv6 [RFC-3775] for mobility management, it cannot use its multiple 150 interfaces to send and receive packets while taking advantage of 151 session continuity provided by Mobile IPv6. This is because Mobile 152 IPv6 allows the mobile node to only bind one care-of address at a 153 time with its home address. See [ID-MIP6ANALYSIS] for a further 154 analysis of using multiple interfaces and addresses with Mobile IPv6. 156 This document proposes extensions to Mobile IPv6 to allow a mobile 157 node to register multiple care-of addresses for a home address and 158 create multiple binding cache entries. A new Binding Identification 159 (BID) number is created for each binding the mobile node wants to 160 create and sent in the Binding Update. The home agent that receives 161 this Binding Update creates a separate binding for each BID. The BID 162 information is stored in the corresponding binding cache entry. The 163 BID information can now be used to identify individual bindings. The 164 same extensions can also be used in Binding Updates sent to the 165 correspondent nodes. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC-2119]. 173 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 174 [RFC-4885]. In addition to or as a replacement of these, the 175 following terms are defined or redefined: 177 Binding Identification number (BID) 179 The BID is an identification number used to distinguish multiple 180 bindings registered by the mobile node. Assignment of distinct 181 BIDs allows a mobile node to register multiple binding cache 182 entries for a given home address. The BIDs assigned to a same 183 home address must not be duplicated at a time. Zero value is 184 reserved for future extension. Each BID is generated and managed 185 by a mobile node. The BID is stored in the binding update List 186 and is sent by the mobile node in the Binding Update. A mobile 187 node may change the value of a BID at any time according to its 188 administrative policy, for instance to protect its privacy. An 189 implementation must carefully assign the BID so as to keep using 190 the same BID for the same binding even when the status of the 191 binding is changed. More details can be found in Section 5.1. 193 Binding Identifier Mobility Option 195 The Binding Identifier mobility option is used to carry the BID 196 information. 198 Bulk Registration 200 A mobile node can register multiple bindings at once by sending a 201 single Binding Update. A mobile node can also replace some or all 202 the bindings available at the home agent with the new bindings by 203 using the bulk registration. Bulk registration is supported only 204 for home registration (i.e. with the home agent) as explained in 205 Section 5.3. A mobile node must not perform bulk registration 206 mechanism described in this specification with a correspondent 207 node. 209 3. Protocol Overview 211 A new extension called the Binding identification number (BID) is 212 introduced to distinguish between multiple bindings pertaining to the 213 same home address. If a mobile node configures several IPv6 global 214 addresses on one or more of its interfaces, it can register these 215 addresses with its home agent as care-of addresses. If the mobile 216 node wants to register multiple bindings, it MUST generate a BID for 217 each care-of address and store the BID in the binding update list. A 218 mobile node can manipulate each binding independently by using the 219 BIDs. The mobile node then registers its care-of addresses by 220 sending a Binding Update with a Binding Identifier mobility option. 221 The BID is included in the Binding Identifier mobility option. After 222 receiving the Binding Update with a Binding Identifier mobility 223 option, the home agent MUST copy the BID from the Binding Identifier 224 mobility option to the corresponding field in the binding cache 225 entry. If there is an existing binding cache entry for the mobile 226 node, and if the BID in the Binding Update does not match the one 227 with the existing entry, the home agent MUST create a new binding 228 cache entry for the new care-of address and BID. The mobile node can 229 register multiple care-of addresses either independently in 230 individual Binding Updates or multiple at once in a single Binding 231 Update. 233 If the mobile host wishes to register its binding with a 234 correspondent node, it must perform return routability operations as 235 described in [RFC-3775]. This includes managing a Care-of Keygen 236 token per care-of address and exchanging Care-of Test Init and 237 Care-of Test message with the correspondent node for each care-of 238 address. The mobile node MAY use the same BID that it used with the 239 home agent for a particular care-of address. For protocol 240 simplicity, bulk registration to correspondent nodes is not supported 241 in this document. This is because the Return Routability mechanism 242 introduced in [RFC-3775] cannot be easily extended to verify multiple 243 care-of addresses stored in a single Binding Update. 245 Figure 1 illustrates the configuration where the mobile node obtains 246 multiple care-of addresses at foreign links. The mobile node can 247 utilize all the care-of addresses. In Figure 1, the home address of 248 the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 249 different interfaces and possibly acquires care-of addresses 1-3 250 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to 251 each care-of address. 253 +----+ 254 | CN | 255 +--+-+ 256 | 257 +---+------+ +----+ 258 +------+ Internet |----------+ HA | 259 | +----+---+-+ +--+-+ 260 CoA2| | | | Home Link 261 +--+--+ | | ------+------ 262 | MN +--------+ | 263 +--+--+ CoA1 | 264 CoA3| | 265 +---------------+ 267 Binding Cache Database: 268 home agent's binding (Proxy neighbor advertisement is active) 269 binding [2001:db8::EUI BID1 care-of address1] 270 binding [2001:db8::EUI BID2 care-of address2] 271 binding [2001:db8::EUI BID3 care-of address3] 272 correspondent node's binding 273 binding [2001:db8::EUI BID1 care-of address1] 274 binding [2001:db8::EUI BID2 care-of address2] 275 binding [2001:db8::EUI BID3 care-of address3] 277 Figure 1: Multiple Care-of Address Registration 279 If the mobile node decides to act as a regular mobile node compliant 280 with [RFC-3775], it sends a Binding Update without any Binding 281 Identifier mobility options. The receiver of the Binding Update 282 deletes all the bindings registering with a BID and registers only a 283 single binding for the mobile node. Note that the mobile node can 284 continue using the BID even if it has only a single binding that is 285 active. 287 Binding cache lookup is done based on the home address and BID 288 information if a BID is available. This is different from RFC 3775, 289 where only the home address is used for binding cache lookup. 290 Binding cache lookup is operated for either protocol signaling and 291 data packets. For the protocol signaling such as a Binding Update, 292 BID should be always carried by a BID sub-option in a protocol 293 signaling. Therefore, a correspondent binding cache that matches the 294 specified BID MUST be found from the binding cache database. On the 295 other hand, for the data packets, no BID information is carried in a 296 packet. The binding cache lookup may involve policy or flow filters 297 to retrieve a correspondent BID per packet in cases where some policy 298 or flow filters are used to direct a certain packet or flow to a 299 particular care-of address. However, the binding cache lookup using 300 policy or flow filters is out of scope for this document. If no such 301 mechanism is available and no BID is found for a packet, a node 302 SHOULD use the binding which was last verified by receiving data 303 packets or signaling from the mobile node. In case the binding cache 304 lookup for data packets, using the combination of home address and 305 BID, does not return a valid binding cache entry, the home agent 306 SHOULD perform the lookup based on only the home address as described 307 in [RFC-3775]. 309 In any case, to avoid problems with upper layer protocols and TCP in 310 particular, a single packet flow as identified by the 5-tuple SHOULD 311 only be sent to a single care-of address at a time. 313 The mobile node may return to the home link through one of its 314 interfaces. There are two options possible for the mobile node when 315 its returns home. Section 5.6 and Section 5.5.1 describe the 316 returning home procedures in more detail. 318 1. The mobile node uses only the interface with which it attaches to 319 the home link. This is illustrated in Figure 2. It de-registers 320 all bindings with the home agent related to all care-of 321 addresses. The interfaces still attached to the visited link(s) 322 are no longer going to be receiving any encapsulated traffic from 323 the home agent. On the other hand, the mobile node can continue 324 communicating with the correspondent node from the other 325 interfaces attached to foreign links by using route optimization. 326 Even if the mobile node is attached to the home link, it can 327 still send Binding Updates for other active care-of addresses 328 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 329 node has bindings, packets are routed to each Care-of Addresses 330 directly. 332 +----+ 333 | CN | 334 +--+-+ 335 | 336 +---+------+ +----+ 337 +------+ Internet |----------+ HA | 338 | +----+-----+ +--+-+ 339 CoA2| | | Home Link 340 +--+--+ | --+---+------ 341 | MN +--------+ | 342 +--+--+ CoA1 | 343 | | 344 +---------------------------+ 346 Binding Cache Database: 347 home agent's binding 348 none 349 correspondent node's binding 350 binding [2001:db8::EUI BID1 care-of address1] 351 binding [2001:db8::EUI BID2 care-of address2] 353 Figure 2: Using only Interface Attached to Home Link 355 2. The mobile node may simultaneously use both the interface 356 attached to the home link and the interfaces still attached to 357 the visited link(s) as shown in Figure 3. There are two possible 358 topologies depending on whether the home agent is the only router 359 on the home link or not. The operation of Neighbor Discovery 360 [RFC-4861] is different in the two topologies. More details can 361 be found in Section 5.6. The home agent and the correspondent 362 node have the binding entries listed in Figure 3 in their binding 363 cache database in both topologies. The home agent also knows 364 that the mobile node is attached to the home link. All the 365 traffic from the Internet is intercepted by the home agent first 366 and routed to either the interface attached to the home link or 367 the one of the foreign links. How the home agent decides to 368 route a particular flow to the interface attached to the home 369 link or foreign link is out of scope in this document. 371 Topology-a) 372 +----+ 373 | CN | 374 +--+-+ 375 | 376 +---+------+ +----+ 377 +------+ Internet |----------+ HA | 378 | +----+-----+ +--+-+ 379 CoA2| | | Home Link 380 +--+--+ | --+---+------ 381 | MN +--------+ | 382 +--+--+ CoA1 | 383 | | 384 +---------------------------+ 386 Topology-b) 387 +----+ 388 | CN | 389 +--+-+ 390 | 391 +---+------+ Router +----+ 392 +------+ Internet |-------R | HA | 393 | +----+-----+ | +--+-+ 394 CoA2| | | | Home Link 395 +--+--+ | --+-+-------+------ 396 | MN +--------+ | 397 +--+--+ CoA1 | 398 | | 399 +---------------------------+ 401 Binding Cache Database: 402 home agent's binding 403 binding [2001:db8::EUI BID1 care-of address1] 404 binding [2001:db8::EUI BID2 care-of address2] 405 correspondent node's binding 406 binding [2001:db8::EUI BID1 care-of address1] 407 binding [2001:db8::EUI BID2 care-of address2] 409 Figure 3: Simultaneous Home and Visited Link Operation 411 This specification keeps backwards compatibility with [RFC-3775]. If 412 a receiver (either home agent or correspondent node) does not support 413 this specification, it does not understand the binding identifier 414 mobility option. The receiver skip the unknown mobility option (i.e. 415 Binding Identifier mobility option) and process the Binding Update as 416 defined in [RFC-3775]. In order to keep the backward compatibility 417 with [RFC-3775], when a mobile node sends a Binding Update message 418 with extensions described in this document, the receiver needs to 419 reflect the Binding Identifier mobility option in the Binding 420 Acknowledgement. If the mobile node finds no Binding Identifier 421 mobility options in the received Binding Acknowledgement, it assumes 422 the other end node does not support this specification. In such 423 case, the mobile node needs to fall back to the legacy RFC-3775 424 compliant mobile node. If it is the home registration, the mobile 425 node MAY try to discover another home agent supporting Binding 426 Identifier mobility option for the home registration. 428 4. Mobile IPv6 Extensions 430 This section summarizes the extensions to Mobile IPv6 necessary for 431 manage multiple bindings. 433 4.1. Binding Cache Structure and Binding Update List 435 The BID is required to be stored in the binding cache and binding 436 update list structure. 438 The sequence number value MUST be shared among all the binding update 439 list entries related to Binding Updates sent to a particular home 440 agent or correspondent node. Whenever a mobile node sends either an 441 individual or a bulk Binding Update, the sequence number is 442 incremented. When a home agent receives an individual Binding 443 Update, it should update the sequence number for all the bindings for 444 a particular mobile node with the sequence number in the received 445 Binding Update. 447 4.2. Binding Update Message 449 This specification extends the Binding Update message with a new 450 flag. The flag is shown and described below. 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Sequence # | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 . . 459 . Mobility options . 460 . . 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: Binding Update message 466 Overwrite (O) flag 468 When this flag is set, all the binding cache entries for a mobile 469 node are replaced by new entries registering with this Binding 470 Update message. This flag is only used when BID Mobility Option 471 is carried with Binding Update. 473 Reserved 475 6 bits Reserved field. 477 4.3. Binding Identifier Mobility Option 479 The Binding Identifier mobility option is included in the Binding 480 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 481 Test Init and Care-of Test message. The Binding Identifier Mobility 482 Option has an alignment requirement of 2n if the Care-of Address 483 field is not present. Otherwise, it has the alignment requirement of 484 8n + 2. 486 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = TBD | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Binding ID (BID) | Status |H| Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 493 + + 494 : IPv4 or IPv6 care-of address (CoA) : 495 + + 496 +---------------------------------------------------------------+ 498 Figure 5: BID Mobility Option 500 Type 502 Type value for Binding Identifier is TBD 504 Length 506 8-bit unsigned integer. Length of the option, in octets, 507 excluding the Type and Length fields. It MUST be set to either 4, 508 8, or 20 depending on the care-of address field. When the care-of 509 address is not carried by this option, the length value MUST be 510 set to 4. If the IPv4 care-of address is stored in the care-of 511 address field, the length MUST be 8. Otherwise, the Length value 512 MUST be set to 20 for IPv6 care-of address. 514 Binding ID (BID) 516 The BID which is assigned to the binding indicated by the care-of 517 address in the Binding Update or the Binding Identifier mobility 518 option. The BID is a 16-bit unsigned integer. The value of zero 519 is reserved and MUST NOT be used. 521 Status 523 The Status field is an 8-bit unsigned integer. When the Binding 524 Identifier mobility option is included in a Binding 525 Acknowledgement, this field overwrites the status field in the 526 Binding Acknowledgement only for this BID. If this field is set 527 to zero, the receiver ignores this field and uses the registration 528 status stored in the Binding Acknowledgement message. The 529 receiver MUST ignore this field if the Binding Identifier mobility 530 option is not carried within either the Binding Acknowledgement or 531 the Care-of Test messages. The possible status codes are the same 532 as the status codes of Binding Acknowledgement. This Status field 533 is also used to carry error information related to the care-of 534 address test in the Care-of Test message. 536 Simultaneous Home and Foreign Binding (H) flag 538 This flag indicates that the mobile node registers multiple 539 bindings to the home agent while is attached to the home link. 540 This flag is valid only for a Binding Update sent to the home 541 agent. 543 Reserved 545 7 bits Reserved field. The value MUST be initialized to zero by 546 the sender, and SHOULD be ignored by the receiver. 548 Care-of Address 550 If a Binding Identifier mobility option is included in a Binding 551 Update for the home registration, either IPv4 or IPv6 care-of 552 address for the corresponding BID can be stored in this field. 553 For the binding registration to correspondent nodes (i.e. route 554 optimization), only IPv6 care-of address can be stored in this 555 field. If no address is specified in this field, the length of 556 this field MUST be zero (i.e. not appeared in the option). If no 557 address is specified in this field, a care-of address is taken 558 from the source address field of the IPv6 header of the Binding 559 Update. If the option is included in any other messages than a 560 Binding Update, the length of this field MUST be also zero. 562 4.4. New Status Values for Binding Acknowledgement 564 New status values for the status field in a Binding Acknowledgement 565 are defined for handling the multiple Care-of Addresses registration: 567 MCOA NOTCOMPLETE (TBD less than 128) 569 In bulk registration, not all the binding identifier mobility 570 options were successfully registered. Some of them were rejected. 571 The error status value of the failed mobility option is 572 individually stored in the status field of the binding identifier 573 mobility option. 575 MCOA RETURNHOME WO/NDP (TBD less than 128) 577 When a mobile node returns home, it MUST NOT use Neighbor 578 Discovery Protocol (NDP) for the home address on the home link. 579 This is explained in more detail in Section 5.6 581 MCOA MALFORMED (TBD more than 128) 583 Registration failed because Binding Identifier mobility option was 584 not formatted correctly. This value is used in the following 585 cases. 587 * when the wrong length value is specified (neither 4, 8 nor 20) 588 in the length field of the Binding Identifier mobility option. 590 * when a unicast routable address is not specified in the care-of 591 address field of the Binding Identifier mobility option. 593 * when a care-of address is not appeared in the care-of address 594 field of the Binding Identifier mobility option stored in an 595 IPsec ESP protected Binding Update. 597 MCOA BID CONFLICT (TBD more than 128) 599 The home agent cannot cache both a regular binding and a BID 600 extended binding simultaneously. It returns this status value 601 when the received binding conflicts with the existing binding 602 cache entry(ies). 604 MCOA PROHIBITED(TBD more than 128) 606 It implies the multiple care-of address registration is 607 administratively prohibited. 609 MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) 611 Bulk binding registration is not either permitted or supported. 612 Note that the bulk registration is an optional procedure and might 613 not be available on a home agent. 615 MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) 617 Simultaneous home and foreign attachment is neither supported nor 618 permitted. 620 5. Mobile Node Operation 622 5.1. Management of Care-of Address(es) and Binding Identifier(s) 624 There are two cases when a mobile node might acquire several care-of 625 addresses. A mixture of the two cases is also possible. Note that a 626 mobile node can use BID regardless of the number of interfaces and 627 care-of addresses. Whether a mobile node uses BID or not is 628 determined by a local configuration. 630 1. A mobile node is using several physical network interfaces and 631 acquires a care-of address on each of its interfaces. 633 2. A mobile node uses a single physical network interface, but 634 receives advertisements for multiple prefixes on the link the 635 interface is attached to. This will result in the mobile node 636 configuring several global addresses on the interface from each 637 of the announced prefixes. 639 The difference between the above two cases is only in the number of 640 physical network interfaces and therefore irrelevant in this 641 document. What is of significance is the fact that the mobile node 642 has several addresses it can use as care-of addresses. 644 A mobile node assigns a BID to each care-of address when it wants to 645 register them simultaneously with its home address. The BID MUST be 646 unique for a given home address. The value is an integer between 1 647 and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node 648 has only one care-of address, the assignment of a BID is not needed 649 until it has multiple care-of addresses to register with, at which 650 time all of the care-of addresses MUST be mapped to BIDs. 652 5.2. Binding Registration 654 For the multiple Care-of Addresses registration, the mobile node MUST 655 include a Binding Identifier mobility option(s) in the Binding Update 656 as shown in Figure 6. The BID is copied from a corresponding binding 657 update List entry to the BID field of the Binding Identifier mobility 658 option. 660 When IPsec ESP is used for protecting the Binding Update, a care-of 661 address MUST be carried in an alternate care-of address mobility 662 option as described in [RFC-4877]. However, in this specification, 663 the care-of address MUST be carried in the Care-of Address field of 664 the Binding Identifier mobility option. In order to save bits of the 665 Binding Update, the alternate care-of address option MUST NOT be 666 included. 668 For binding registration to a correspondent node, the mobile node 669 MUST have both active Home and Care-of Keygen tokens for Kbm (see 670 Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The 671 care-of Keygen tokens MUST be maintained for each care-of address 672 that the mobile node wants to register to the correspondent node. 673 The Binding Update to the correspondent node is protected by the 674 Binding Authorization Data mobility option that is placed after the 675 Binding Identifier mobility option. 677 IPv6 header (src=Care-of Address, dst=Home Agent Address) 678 IPv6 Home Address Option 679 ESP Header* 680 Mobility header 681 Binding Update 682 Mobility Options 683 Binding Identifier mobility option 684 Binding Authorization mobility option+ 685 (*) if necessary, for home registration 686 (+) if necessary, for route optimization 688 Figure 6: Binding Update for Binding Registration 690 If the mobile node wants to replace existing registered bindings on 691 the home agent with the single binding in the sent Binding Update, it 692 sets the 'O' flag. The single binding will be registered with the 693 assigned BID. Section 6.2 describes this registration procedure in 694 detail. Note that if the mobile node wants to register a RFC-3775 695 compliant binding (i.e. no BID assigned to that binding), it sends a 696 Binding Update without any Binding Identifier mobility option. 698 5.3. Bulk Registration 700 Bulk registration is an optimization for binding multiple care-of 701 addresses to a home address using a single Binding Update. This is 702 very useful if the mobile node, for instance, does not want to send a 703 lot of signaling messages through an interface where the bandwidth is 704 scarce. This document specifies bulk registration only for the 705 mobile node's home registration. A mobile node performing bulk 706 registration with a correspondent node is out of scope. 708 To use bulk registration, the mobile node includes a Binding 709 Identifier Mobility option for each BID and Care-of address pair it 710 wants to register in the same Binding Update message. This is shown 711 in Figure 7. The rest of the fields and options in the Binding 712 Update such as Lifetime, Sequence Number, and the flags in the 713 Binding Update are common across all care-of addresses. 715 When IPsec ESP is used for protecting the Binding Update, a care-of 716 address MUST be carried in an alternate care-of address mobility 717 option as described in [RFC-4877]. However, in the bulk 718 registration, the care-of addresses are always carried in the Care-of 719 Address field of the Binding Identifier mobility option. In order to 720 save bits of the Binding Update, the alternate care-of address option 721 MUST NOT be included in such Binding Update. 723 IPv6 header (src=Care-of Address, dst=Home Agent Address) 724 IPv6 Home Address Option 725 ESP Header 726 Mobility header 727 Binding Update 728 Mobility Options 729 Binding Identifier (including Care-of Address) 731 Figure 7: Binding Update for Bulk Registration 733 If the mobile node wants to replace existing registered bindings on 734 the home agent with the multiple bindings in the sent Binding Update, 735 it sets the 'O' flag in the Binding Update. 737 5.4. Binding De-Registration 739 When a mobile node decides to delete all the bindings for its home 740 address, it sends a regular de-registration Binding Update with 741 lifetime set to zero as defined in [RFC-3775]. The Binding 742 Identifier mobility option is not required. 744 If a mobile node wants to delete a particular binding(s) from its 745 home agent and correspondent nodes, the mobile node sends a Binding 746 Update with lifetime set to zero and includes a Binding Identifier 747 mobility option(s) with the BID(s) it wants to de-register. The 748 receiver will remove only the care-of address(es) that match(es) the 749 specified BID(s). The care-of addresses field in each mobility 750 option SHOULD be omitted by the sender (i.e. the field does not 751 appear in the option) and MUST be ignored by the receiver. This is 752 because the receiver will remove the binding that matches the 753 specified BID. 755 5.5. Returning Home: Using Single Interface 757 The mobile node may return to the home link, by attaching to the home 758 link through one of its interfaces. When the mobile node wants to 759 return home, it should be configured with information on what 760 interface it needs to use. 762 5.5.1. Using only Interface attached to the Home Link 764 The mobile node returns home and de-registers all the bindings as 765 shown in Figure 2 and as defined in [RFC-3775]. De-registering all 766 the bindings is the same as binding de-registration from foreign link 767 described in Section 5.4. After the de-registration step, all the 768 packets routed by the home agent are only forwarded to the interface 769 attached to the home link, even if there are other active interfaces 770 attached to the visited link(s). While the mobile node de-registers 771 all the bindings from the home agent, it may continue registering 772 bindings for interface(s) attached to visited link(s) to the 773 correspondent node as shown in Figure 2. 775 5.5.2. Using only Interface attached to the Visited Link 777 The mobile node returns home physically but shuts down the interface 778 attached to the home link. As a result, a mobile node does not 779 return home even though it attaches to the home link by one of 780 interfaces. Following procedures should be taken by the mobile node. 781 Before shutting down the interface, any binding for the care-of 782 address previously associated with the interface should be deleted. 783 To delete the binding cache entry, the mobile node SHOULD send a de- 784 registration Binding Update with the lifetime set to zero and include 785 the corresponding BID information. If the mobile node does not send 786 a de-registration Binding Update, the binding for the care-of address 787 previously assigned to the interface remains at the home agent until 788 its lifetime expires. 790 In this scenario, despite the fact that the mobile node is connected 791 to its home link, all of its traffic is sent and received via the 792 home agent and its foreign links. 794 5.6. Returning Home: Simultaneous Home and Visited Link Operation 796 5.6.1. Problems of Simultaneous Home and Foreign Attachments 798 The mobile node returns home and continues using all the interfaces 799 attached to both foreign and home links as shown in Figure 3. The 800 mobile node indicates this by setting the 'H' flag in the Binding 801 Identifier mobility option as defined below. There are additional 802 requirements on the Returning Home procedures for possible Neighbor 803 Discovery state conflicts at the home link. 805 In [RFC-3775], the home agent intercepts packets meant for the mobile 806 node using Proxy Neighbor Discovery [RFC-4861] while the mobile node 807 is away from the home link. When the mobile node returns home, the 808 home agent deletes the binding cache and stops proxying for the home 809 address so that a mobile node can configure its home address on the 810 interface attached to the home link. In this specification, a mobile 811 node may return home, configure the home address on the interface 812 attached to the home link, but still use the interfaces attached to 813 the foreign links. In this case, a possible conflict arises when the 814 both the home agent and the mobile node try to defend the home 815 address. If the home agent stops proxying for the home address, the 816 packets are always routed to the interface attached to the home link 817 and are never routed to the interfaces attached to the visited links. 818 It is required to avoid the conflict between the home agent and the 819 mobile node, while still allowing the simultaneous use of home and 820 foreign links. The following describes the mechanism for achieving 821 this. 823 5.6.2. Overview and Approach 825 In this scenario, the home agent MUST intercept all the packets meant 826 for the mobile node and decide whether to send the traffic directly 827 to the home address on the link or tunnel to the care-of address. 828 The home agent intercepts all the packets even when the mobile node 829 is attached to the home link through one of its interfaces. The home 830 agent would make this decision based on the type of flow. How to 831 make this decision is out of scope in this document. 833 Two scenarios are illustrated in Figure 3, depending on whether the 834 Home Agent is the only router at the home link or not. The 835 difference is on who defends the home address by (Proxy) Neighbor 836 Discovery on the home link. 838 1. Mobile node defends the home address by the regular Neighbor 839 Discovery Protocol (illustrated as topology-a in Figure 3). The 840 home agent is the only router on the home link. Therefore the 841 home agent is capable of intercepting packets without relying on 842 the proxy Neighbor Discovery protocol and the mobile node can 843 manage the Neighbor Cache entry of the home address on the home 844 link as a regular IPv6 node. However, there is one limitation of 845 this scenario. If a correspondent node is located at the home 846 link, the home agent may not intercept the packets destined to 847 the mobile node. These packets are routed only via the home 848 link, but this is the most optimal path for the mobile node to 849 communicate with nodes on the home link. 851 2. If there are other routers on the home link apart from the home 852 agent, then it cannot be guaranteed that all packets meant for 853 the mobile node are routed to the home agent. In this case, the 854 mobile node MUST NOT operate the Neighbor Discovery protocol for 855 the home address on the home link. This allows the home agent to 856 keep using proxy neighbor discovery and thus it keeps receiving 857 all the packets sent to the mobile node's home address. If the 858 home agent, according to its local policy, needs to deliver 859 packets to the mobile node over the home link, an issue arises 860 with respect to how the home agent discovers the mobile node's 861 link local address. This specification uses the Mobility Header 862 Link-layer Address Option defined in [RFC-5268] in order to carry 863 the mobile node's link-layer address in the Binding Update. 864 Likewise, the mobile node would also know the link-layer address 865 of the default router address to send packets from the home link 866 without Neighbor Discovery. The link-layer address is used to 867 transmit packets from and to the mobile node on the home link. 868 The packets are transmitted without the Neighbor Discovery 869 protocol by constructing the link-layer header manually. This 870 operation is similar to Mobile IPv6 [RFC-3775] when a mobile node 871 sends a deregistration binding update to the home agent's link- 872 layer address in the operation for returning home. 874 5.6.3. Sending Deregistration Binding Update 876 o As soon as a mobile node returns home, it sends a de-registration 877 Binding Update to the home agent from the interface attached to 878 the home link. Note that if the mobile node runs the flow binding 879 [ID-FLOWBINDING], it MAY create its home binding and continue 880 registering its binding to the home agent from the home link. The 881 mobile node does not need to operate binding deregistration 882 described in this section. The detail operation can be found in 883 Section 5.6.5 885 o The mobile node MUST include the Binding Identifier mobility 886 option specifying the BID the mobile node had previously 887 associated with the interface attached to the home link. The 'H' 888 flag MUST be set in the Binding Identifier mobility option. For 889 the binding deregistration, a mobile node SHOULD NOT store a 890 care-of address in the Care-of Address field of the Binding 891 Identifier mobility option. The receiver, the home agent, can 892 match the removed binding with BID value in the Binding Identifier 893 mobility option. 895 o If the mobile node has to remove multiple bindings simultaneously, 896 it overwrites the existing binding entries by using 'O' flag and 897 should not send Binding Update messages for removing multiple 898 care-of addresses. The mobile node contains multiple Binding 899 Identifier mobility options for the active care-of addresses and 900 sets 'O' flag in the Binding Update message. 902 o When the 'H' flag is set, the home agent recognizes that the 903 mobile node wants to continue using interfaces attached to both 904 home and visited links. Note that H flag MUST be set for the 905 subsequent Binding Updates sent from the mobile node (ex. Binding 906 Update for the interface(s) attached to the foreign link(s)). If 907 the home agent does not allow this scenario, it MUST send a 908 Binding Acknowledgement with the status code [MCOA SIMULTANEOUS 909 HOME AND FOREIGN PROHIBITED] set. 911 o The mobile node SHOULD include the Mobility Header Link-layer 912 Address Option [RFC-5268] to notify the mobile node's link-layer 913 address to the home agent, too. The option code of the Mobility 914 Header Link-layer Address option MUST be set to '2' (Link-layer 915 Address of the mobile node). This link-layer address is required 916 for the home agent to send the Binding Acknowledgement and to 917 forward the mobile node's packet. 919 o According to [RFC-3775], the mobile node MUST start responding to 920 Neighbor Solicitation for its home address right after it sends 921 the deregistration Binding Update to the home agent. However, in 922 this specification, the mobile node MUST NOT respond to Neighbor 923 Solicitation before receiving a Binding Acknowledgement, since the 924 home agent may continue proxying for the home address. If the 925 mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value 926 in the received Binding Acknowledgment, it MUST NOT respond to 927 Neighbor Solicitation even after the Binding Acknowledgement. 929 5.6.4. Sending Binding Acknowledgement 931 The operations described in this section is for Home Agent and not 932 for Mobile Node. However, the Home Agent operations described in 933 this section are related to the returning home using simultaneous use 934 of home and foreign links. 936 o When the home agent sends the Binding Acknowledgement after 937 successfully processing the binding de-registration, it MUST set 938 the status value to either 0 [Binding Update Accepted] or to [MCOA 939 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 940 Acknowledgment depending on home agent configuration at the home 941 link. The new values are: 943 * Binding Update Accepted (0): Neighbor Discovery Protocol is 944 permitted for the home address at the home link. This is 945 regular returning home operation of [RFC-3775] 947 * MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is 948 prohibited for the home address at the home link 950 The respective Binding Identifier mobility options need to be 951 included in the Binding Acknowledgement. 953 o If the Binding Update is rejected, the appropriate error value 954 MUST be set in the status field. In this case, the home agent 955 operation is the same as [RFC-3775]. 957 o Only if the home agent is certainly the only router in the home 958 link, it MAY turn off Neighbor Discovery for the requested home 959 address and responds with the [Binding Update Accepted] status 960 value to the mobile node. Since the mobile node will not reply to 961 Neighbor Solicitation for the home address before receiving the 962 Binding Acknowledgement, the home agent SHOULD use the link-layer 963 address carried by the Link Layer Address option [RFC-5268] in the 964 received Binding Update. After the completion of the binding 965 deregistration, the mobile node starts regular Neighbor Discovery 966 operations for the home address on the home link. The neighbor 967 cache entry for the home address is created by the regular 968 exchange of Neighbor Solicitation and Neighbor Advertisement. 970 o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] 971 value in the Status field of the Binding Identifier mobility 972 option. The home agent learns the mobile node's link-layer 973 address by receiving the Mobility Header link-layer address option 974 carried by the Binding Update. It stores the link-layer address 975 as a neighbor cache entry for the mobile node so that it can send 976 the packets to the mobile node's link-layer address. 978 o Note that the use of proxy Neighbor Discovery is an easier way to 979 intercept the mobile nodes' packets instead of IP routing in some 980 deployment scenarios. Therefore, even if a home agent is the only 981 router, it is an implementation and operational choice whether the 982 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 983 WO/NDP]. 985 o If BID option is not included in the Binding Acknowledgement, the 986 home agent might not recognize the simultaneous home and foreign 987 attachment. The home agent might have processed the de- 988 registration Binding Update as a regular de-registration as 989 described in [RFC-3775] and deletes all the registered binding 990 cache entries for the mobile node. Thus, the mobile node SHOULD 991 stop using the interface attached to foreign link and use only the 992 interface attached to the home link. 994 5.6.5. Home Binding for Flow Binding Support 996 The Flow Binding extensions [ID-FLOWBINDING] allows nodes to bind one 997 or more flows to a care-of address (BID). If a mobile node returns 998 home and deletes its binding for the interface attached to the home 999 link, flow bindings cannot be specified to that interface. Thus, it 1000 is necessary to keep the BID for the interface attached to the home 1001 link. 1003 For this purpose, if the Flow Binding is being used, the home agent 1004 MAY create a home binding where the care-of address is equal to the 1005 mobile node's home address. This home binding is conceptual data 1006 structure and can be implementation specific. The home binding is 1007 created only when the mobile node is present at both the home and 1008 foreign links. The home binding is created when a mobile node 1009 requests by sending a Binding Update. 1011 When the home binding is used, the binding de-registration operation 1012 described in Section 5.6.3 is not necessary. Instead of sending a 1013 deregistering binding update, the mobile node needs to send a 1014 registering binding update with a Binding Identifier mobility option 1015 which H flag is set. The lifetime is set to the requesting lifetime 1016 of the home binding. Once the home agent receives the Binding 1017 Update, it creates a home binding as described in Section 5.2 except 1018 for one point. The main difference of the home binding is that the 1019 care-of address is set to the home address. The home agent needs to 1020 treat this binding as a home binding. The management of the home 1021 binding is same as the binding management described in this 1022 specification. The home binding can be also created by bulk binding 1023 registration (Section 5.3). The mobile node stores its home address 1024 in the care-of address field of the Binding Identifier mobility 1025 option and sets H flag to the option. It needs to refresh the 1026 lifetime of the home binding by sending Binding Updates. 1028 5.6.6. Sending Packets from the Home Link 1030 o When the mobile node receives the Binding Acknowledgement with the 1031 status value 'Binding Update Accepted' and the BID option, it can 1032 configure its home address to the interface attached to the home 1033 link and start operating Neighbor Discovery for the home address 1034 on the home link. Packets can be transmitted from and to the 1035 mobile node as if the mobile node is a regular IPv6 node. 1037 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 1038 the Binding Acknowledgement, it MUST NOT operate Neighbor 1039 Discovery for the home address. When the mobile node sends 1040 packets from the interface attached to the home link, it MUST 1041 learn the link-layer address of the next hop (i.e. default router 1042 of the mobile node). A mobile node learns the default router's 1043 link-layer address from a Source Link-Layer Address option in 1044 Router Advertisements. The mobile node sends packets directly to 1045 the default router's link-layer address. This is done by 1046 constructing the packet including a link-layer header with the 1047 learned link-layer address of the default router. The home agent 1048 also forwards the packet to the mobile node on the home link by 1049 using the mobile node's link-layer address. The link-layer 1050 address SHOULD be cached when the home agent received the 1051 deregistration Binding Update message. Note that the default 1052 router MUST NOT cache the mobile node's link-layer address in the 1053 neighbor cache when it forwards the packet from the mobile node to 1054 the home agent. 1056 5.6.7. Leaving from the Home Link 1058 o When the mobile node detaches from the home link, it SHOULD 1059 immediately send a Binding Update for one of active care-of 1060 address with H flag unset. When the 'H' flag of BID option is 1061 unset in any Binding Update, the home agent stop forwarding the 1062 mobile node's packets to the home link. 1064 5.6.7.1. Changing Behavior during the attachment to the home link 1066 If a mobile node decides to return home completely without any active 1067 foreign link attachment, it simply sends a deregistration Binding 1068 Update as described in Section 5.5.1. Once the home agent receives 1069 such de-registration Binding Update, the home agent clears all the 1070 binding(s) and state for the mobile node. 1072 If a mobile node decides to stop using the interface attached to the 1073 home link, it simply sends a Binding Update from one of the active 1074 care-of addresses. In the Binding Update, the mobile node should 1075 include the BID option for the care-of address and unset the H flag 1076 of the BID option. The home agent clears the state of the mobile 1077 node for the interface attached to the home link and stops forwarding 1078 the packets to the mobile node on the home link. 1080 5.7. Receiving Binding Acknowledgement 1082 The verification of a Binding Acknowledgement is the same as Mobile 1083 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 1084 Binding Acknowledgement is described in Section 6.2. 1086 If a mobile node includes a Binding Identifier mobility option in a 1087 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 1088 carry a Binding Identifier mobility option. According to [RFC-3775], 1089 the receiver of the Binding Update ignores unknown mobility options 1090 and processes the Binding Update without the unknown mobility option. 1091 Therefore, if no such mobility option is included in the Binding 1092 Acknowledgement in response to a Binding Update for multiple care-of 1093 address registration, this indicates that the originating node of the 1094 Binding Acknowledgement does not support processing the Binding 1095 Identifier mobility option regardless of status value. In such case, 1096 the receiver of the Binding Update may create a regular binding. The 1097 mobile node then no longer attempts multiple care-of address 1098 registration with that node. If this occurs with home registration 1099 the mobile node MAY attempt to discover another home agent supporting 1100 Binding Identifier mobility option for the home registration. 1102 If a Binding Identifier mobility option is present in the received 1103 Binding Acknowledgement, the mobile node checks the status field in 1104 the option. If the status value in the Binding Identifier mobility 1105 option is zero, the mobile node uses the value in the Status field of 1106 the Binding Acknowledgement. Otherwise, it uses the value in the 1107 Status field of the Binding Identifier mobility option. 1109 If the status code is greater than or equal to 128, the mobile node 1110 starts relevant operations according to the error code. Otherwise, 1111 the mobile node assumes that the originator (home agent or 1112 correspondent node) successfully registered the binding information 1113 and BID for the mobile node. 1115 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 1116 stop registering multiple bindings with the node that sent the 1117 Binding Acknowledgement. 1119 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 1120 mobile node needs to stop using bulk registrations with the node 1121 that sent the Binding Acknowledgement. It should assume that none 1122 of the attempted registrations were successful. 1124 o If [MCOA MALFORMED] is specified, it indicates that the binding 1125 identifier mobility option is formatted wrongly presumably due to 1126 a programming error or major packet corruption. . 1128 o If [MCOA BID CONFLICT] is specified, the binding entry specified 1129 by the Binding Identifier mobility option is already registered as 1130 a regular binding. In such case, the mobile node needs to stop 1131 sending Binding Updates with BID, or SHOULD use the 'O' flag to 1132 reset all the registered bindings as described in Section 5.9. 1134 5.8. Receiving Binding Refresh Request 1136 The verification of a Binding Refresh Request is the same as in 1137 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 1138 a Binding Refresh Request is described in Section 6.3. 1140 If a mobile node receives a Binding Refresh Request with a Binding 1141 Identifier mobility option, it indicates that the node sending the 1142 Binding Refresh Request message is requesting the mobile node to send 1143 a new Binding Update for the BID. The mobile node SHOULD then send a 1144 Binding Update at least for the respective binding. The mobile node 1145 MUST include a Binding Identifier mobility option in the Binding 1146 Update. 1148 5.9. Bootstrapping 1150 When a mobile node bootstraps and registers multiple bindings for the 1151 first time, it MUST set the 'O' flag in the Binding Update message. 1152 If old bindings still exists at the home agent, the mobile node has 1153 no knowledge of which bindings still exist at the home agent. This 1154 scenario happens when a mobile node reboots and loses state regarding 1155 the registrations. If the 'O' flag is set, all the bindings are 1156 replaced by the new binding(s). If the mobile node receives the 1157 Binding Acknowledgement with the status code set to 135 [Sequence 1158 number out of window], it MUST follow the operations described in 1159 [RFC-3775]. 1161 The 'O' flag can also be used in individual Binding Updates sent to 1162 the correspondent nodes to override any existing binding cache 1163 entries at the correspondent node. 1165 6. Home Agent and Correspondent Node Operation 1167 6.1. Searching Binding Cache with Binding Identifier 1169 If either a correspondent node or a home agent has multiple bindings 1170 for a mobile node in their binding cache database, it can use any of 1171 the bindings to communicate with the mobile node. This section 1172 explains how to retrieve the desired binding for the binding 1173 management. This document does not provide any mechanism to select 1174 the suitable binding for forwarding data packets. 1176 A node which is either a correspondent node or a home agent SHOULD 1177 use both the home address and the BID as the search key of the 1178 binding cache if it knows the corresponding BID (example: when 1179 processing signaling messages). In the example below, if a node 1180 searches the binding with the home address and BID2, it gets binding2 1181 for this mobile node. 1183 binding1 [2001:db8::EUI, care-of address1, BID1] 1184 binding2 [2001:db8::EUI, care-of address2, BID2] 1185 binding3 [2001:db8::EUI, care-of address3, BID3] 1187 Figure 8: Searching the Binding Cache 1189 The node learns the BID when it receives a Binding Identifier 1190 mobility option. At that time, the node MUST look up its binding 1191 cache database with the home address and the BID retrieved from the 1192 Binding Update. If the node does not know the BID, it searches for a 1193 binding with only the home address. In such a case, the first 1194 matched binding is found. If the node does not desire to use 1195 multiple bindings for a mobile node, it can simply ignore the BID. 1197 6.2. Processing Binding Update 1199 If a Binding Update does not contain a Binding Identifier mobility 1200 option, its processing is the same as in [RFC-3775]. If the receiver 1201 already has multiple bindings for the home address, it MUST replace 1202 all the existing bindings by the received binding. As a result, the 1203 receiver node MUST have only one RFC-3775 compliant binding cache 1204 entry for the mobile node's home address. If the Binding Update is 1205 for de-registration, the receiver MUST delete all existing bindings 1206 from its Binding Cache. 1208 If the Binding Update contains a Binding Identifier mobility 1209 option(s), it is first validated according to section 9.5.1 of [RFC- 1210 3775]. Then the receiver processes the Binding Identifier mobility 1211 option(s) as described in the following steps. 1213 o The length value is examined. The length value MUST be either 4, 1214 8, or 20 depending on the Care-of Address field. If the length is 1215 incorrect, the receiver MUST reject the Binding Update and returns 1216 the status value set to [MCOA MALFORMED]. 1218 o When the Length value is either 8 or 20, the care-of address MUST 1219 be present in the Binding Identifier mobility option. If the 1220 unicast routable address [RFC-3775] is not present in the care-of 1221 address field, the receiver MUST reject the Binding Identifier 1222 mobility option and returns the status value set to [MCOA 1223 MALFORMED]. 1225 o If the Binding Update is protected with IPsec ESP, the care-of 1226 address MUST be present in the Binding Identifier mobility option. 1227 If no address is present in the care-of address field in the 1228 Binding Identifier mobility option, the home agent MUST reject the 1229 Binding Identifier mobility option and returns the status value 1230 set to [MCOA MALFORMED]. 1232 o If the care-of address is present in both the alternate care-of 1233 address mobility option and the Binding Identifier mobility option 1234 at the same time, the home agent MUST ignore the alternate care-of 1235 address mobility option and continue processing the Binding Update 1236 with the care-of address from the Binding Identifier mobility 1237 option. 1239 o When multiple Binding Identifier mobility options are present in 1240 the Binding Update, it is treated as bulk registration. If the 1241 receiving node is a correspondent node, it MUST reject the Binding 1242 Update and returns the status value in the binding Acknowledgement 1243 set to [MCOA BULK REGISTRATION NOT SUPPORT]. 1245 o If the Lifetime field in the Binding Update is set to zero, the 1246 receiving node deletes the binding entry that corresponds to the 1247 BID in the Binding Identifier mobility option. If the receiving 1248 node does not have an appropriate binding for the BID, it MUST 1249 reject the Binding Update and send a Binding Acknowledgement with 1250 status set to 133 [not home agent for this mobile node]. 1252 o If the 'O' flag is set in the de-registering Binding Update, it is 1253 ignored. If the 'H' flag is set, the home agent stores a home 1254 address in the Care-of Address field of the binding cache entry. 1255 The home agent MUST follow the descriptions described in 1256 Section 5.6. 1258 o If the Lifetime field is not set to zero, the receiving node 1259 registers a binding with the specified BID as a mobile node's 1260 binding. The Care-of address is obtained from the Binding Update 1261 packet as follows: 1263 * If the Length value of the Binding Identifier mobility option 1264 is 20, the care-of address is copied the IPv6 address from the 1265 care-of address field in the Binding Identifier mobility 1266 option. When the Length value is 8, the address MUST be the 1267 IPv4 valid address. Detail information can be found in 1268 Section 8. 1270 * If the Length value of the Binding Identifier mobility option 1271 is 4, the care-of address is copied from the source address 1272 field of the IPv6 header of the Binding Update. 1274 * If the Length value of the Binding Identifier mobility option 1275 is 4 and an alternate care-of address is present, the care-of 1276 address is copied from the Alternate Care-of address mobility 1277 option. 1279 o Once the care-of address(es) have been retrieved from the Binding 1280 Update, the receiving nodes creates new binding(s). 1282 * If the 'O' flag is set in the Binding Update, the home agent 1283 removes all the existing bindings and registers the received 1284 binding(s). 1286 * If the 'O' flag is unset in the Binding Update and the receiver 1287 has a regular binding which does not have BID for the mobile 1288 node, it must not process the Binding Update. The receiver 1289 should sent a Binding Acknowledgement with status set to [MCOA 1290 BID CONFLICT]. 1292 * If the receiver already has a binding with the same BID but 1293 different care-of address, it MUST update the binding and 1294 respond with a Binding Acknowledgement with status set to 0 1295 [Binding Update accepted]. 1297 * If the receiver does not have a binding entry for the BID, it 1298 registers a new binding for the BID and responds with a Binding 1299 Acknowledgement with status set to 0 [Binding Update accepted]. 1301 If all the above operations are successfully completed, a Binding 1302 Acknowledgement containing the Binding Identifier mobility options 1303 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 1304 is sent, all the Binding Identifier mobility options stored in the 1305 Binding Update MUST be copied to the Binding Acknowledgement except 1306 the status field. The Care-of address field in each Binding 1307 Identifier mobility option, however, MAY be omitted, because the 1308 mobile node can match a corresponding binding update list entry using 1309 the BID. 1311 When a correspondent node sends a Binding Acknowledgement, the status 1312 value MUST be always stored in the Status field of the Binding 1313 Acknowledgement and the Status field of Binding Identifier mobility 1314 option MUST be always set to zero. 1316 When the home agent sends a Binding Acknowledgement, the status value 1317 can be stored in the Status field of either a Binding Acknowledgement 1318 or a Binding Identifier mobility option. If the status value is 1319 specific to one of bindings in the bulk registration, the status 1320 value MUST be stored in the Status field in the corresponding Binding 1321 Identifier mobility option. In this case, the Status field of the 1322 Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that 1323 the receiver can examine the Status field of each Binding Identifier 1324 mobility option for further operations. Otherwise, the status field 1325 of the Binding Identifier mobility option MUST be set to zero and the 1326 home agent status field of the Binding Acknowledgement is used. 1328 6.3. Sending Binding Refresh Request 1330 When a node (home agent or correspondent node) sends a Binding 1331 Refresh Request for a particular binding created with the BID, the 1332 node SHOULD include the Binding Identifier mobility option in the 1333 Binding Refresh Request. The node MAY include multiple Binding 1334 Identifier mobility options if there are multiple bindings that need 1335 to be refreshed. 1337 6.4. Receiving Packets from Mobile Node 1339 When a node receives packets with a Home Address destination option 1340 from a mobile node, it MUST check that the care-of address that 1341 appears in the source address field of the IPv6 header MUST be equal 1342 to one of the care-of addresses in the binding cache entry. If no 1343 binding is found, the packets MUST be discarded. The node MUST also 1344 send a Binding Error message as specified in [RFC-3775]. This 1345 verification MUST NOT be done for a Binding Update. 1347 7. Network Mobility Applicability 1349 The binding management mechanisms are the same for a mobile host that 1350 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1351 Support protocol [RFC-3963]. Therefore the extensions described in 1352 this document can also be used to support a mobile router with 1353 multiple care-of addresses. [RFC-4980] is a document for an analysis 1354 of NEMO multihoming. 1356 8. DSMIPv6 Applicability 1358 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1359 register an IPv4 care-of address instead of the IPv6 care-of address 1360 when the mobile node is attached to an IPv4-only access network. It 1361 also allows the mobile node to acquire an IPv4 home address in 1362 addition to an IPv6 home address for use with IPv4-only correspondent 1363 nodes. This section describes how multiple care-of address 1364 registration works with IPv4 care-of and home addresses. 1366 8.1. IPv4 Care-of Address Registration 1368 The mobile node can use the extensions described in the document to 1369 register multiple care-of addresses, even if some of the care-of 1370 addresses are IPv4 address. 1372 Bulk registration MUST NOT be used for the initial binding from an 1373 IPv4 care-of address. This is because, the Binding Update and 1374 Binding Acknowledgement exchange is used to detect NAT on the path 1375 between the mobile node and the home agent. So the mobile node needs 1376 to check for a NAT between each IPv4 care-of address and the home 1377 agent. 1379 The Binding Update MUST be sent to the IPv4 home agent address by 1380 using UDP and IPv4 headers as shown in Figure 9. It is similar to 1381 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1382 used when the BID mobility option is used. 1384 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1385 UDP Header 1386 IPv6 header (src=V6HoA, dst=HAADDR) 1387 ESP Header 1388 Mobility header 1389 -Binding Update 1390 Mobility Options 1391 - Binding Identifier (IPv4 CoA) 1392 *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6] 1394 Figure 9: Initial Binding Update for IPv4 Care-of Address 1396 If a NAT is not detected, the mobile node can update the IPv4 care-of 1397 address by using bulk registration. The mobile node can register the 1398 IPv4 care-of address along with other IPv4 and IPv6 care-of 1399 addresses. Figure 10 shows the Binding Update format when the mobile 1400 node sends a Binding Update from one of its IPv6 care-of addresses. 1401 If the mobile node sends a Binding Update from IPv4 care-of address, 1402 it MUST follow the format described in Figure 9. Note that the IPv4 1403 Care-of Address must be registered by non bulk Binding registration, 1404 whenever it is changed. 1406 As shown in Figure 9, IPv4 care-of address will be appeared in 1407 Binding Identifier mobility option. The IPv4 care-of address 1408 mobility option defined in [ID-DSMIP6] MUST always be omitted. The 1409 receiver of the Binding Update message for an IPv4 care-of address 1410 MUST use the IPv4 address stored in the Binding Identifier mobility 1411 option instead of the IPv4 care-of address mobility option. 1413 IPv6 header (src=Care-of Address, dst=Home Agent Address) 1414 IPv6 Home Address Option 1415 ESP Header 1416 Mobility header 1417 -Binding Update 1418 Mobility Options 1419 - Binding Identifier (IPv6/v4 CoA) 1420 - Binding Identifier (IPv6/v4 CoA) 1421 - ... 1423 Figure 10: Binding Bulk Registration for IPv4 care-of address 1425 When the home agent returns a Binding Acknowledgement for the IPv4 1426 care-of address registration, it SHOULD NOT use the IPv4 address 1427 Acknowledgement mobility option and SHOULD use only the Binding 1428 Identifier mobility option. The registration status for the IPv4 1429 Care-of address is stored in the Status field of the Binding 1430 Identifier mobility option. However, if the home agent needs to 1431 store the status value specially defined for the IPv4 address 1432 Acknowledgement mobility option, it MUST store the status value in 1433 the IPv4 address Acknowledgement mobility option and MUST NOT store 1434 it in Binding Identifier mobility option. In such case, the home 1435 agent MUST include both the IPv4 address Acknowledgement mobility 1436 option and Binding Identifier mobility option. 1438 8.2. IPv4 Home Address Management 1440 When the mobile node wants to configure an IPv4 home address in 1441 addition to the IPv6 home address, it can request for one using the 1442 IPv4 Home Address option in the Binding Update. If the home agent 1443 accepts the Binding Update, the mobile node can now register multiple 1444 care-of addresses for the IPv4 home address in addition to the IPv6 1445 home address. The mobile node MUST always use the IPv4 home address 1446 mobility option for any purposes of the IPv4 home address management. 1447 The same set of care-of addresses will be registered for both IPv6 1448 and IPv4 home addresses. The mobile node cannot bind a different set 1449 of care-of addresses to each home address. 1451 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1452 Acknowledgement option in the Binding Acknowledgement only if the 1453 mobile node had requested for an IPv4 home address in the 1454 corresponding Binding Update. The IPv4 address Acknowledgement 1455 option MUST be present before any Binding Identifier mobility option. 1456 The status field of the IPv4 address Acknowledgement option contains 1457 only the error code defined in Section 4.2.1 of [ID-DSMIP6]. The 1458 home agent MUST always include the IPv4 address Acknowledgement 1459 mobility option in the Binding Acknowledgement for the IPv4 home 1460 address registration. 1462 9. IPsec and IKEv2 interaction 1464 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1465 use of IPsec to protect signaling messages including Binding Updates, 1466 Binding Acknowledgement and return routability messages. IPsec may 1467 also be used protect all tunneled data traffic. The Mobile IPv6- 1468 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1469 setup the required IPsec security associations. The following 1470 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1471 respect to the use of IKEv2 and IPsec. 1473 o There is only one primary care-of address per mobile node. 1475 o The primary care-of address is stored in the IPsec database for 1476 tunnel encapsulation and decapsulation. 1478 o When the home agent receives a packet from the mobile node, the 1479 source address is verified against the care-of address in the 1480 corresponding binding cache entry. If the packet is a reverse 1481 tunneled packet from the mobile node, the care-of address check is 1482 done against the source address on the outer IPv6 header. The 1483 reverse tunnel packet could either be a tunneled Home Test Init 1484 message or tunneled data traffic to the correspondent node. 1486 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1487 the care-of address. The IKE SA is based on the care-of address 1488 of the mobile node. 1490 The above assumptions may not be valid when multiple care-of 1491 addresses are used by the mobile node. In the following sections, 1492 the main issues with the use of multiple care-of address with IPsec 1493 are addressed. 1495 9.1. Use of Care-of Address in the IKEv2 exchange 1497 For each home address the mobile node sets up security associations 1498 with the home agent, the mobile node must pick one care-of address 1499 and use that as the source address for all IKEv2 messages exchanged 1500 to create and maintain the IPsec security associations associated 1501 with the home address. The resultant IKEv2 security association is 1502 created based on this care-of address. 1504 If the mobile node needs to change the care-of address, it just sends 1505 a Binding Update with the care-of address it wants to use, with the 1506 corresponding Binding Identifier mobility option, and with the 'K' 1507 bit set. This will force the home agent to update the IKEv2 security 1508 association to use the new care-of address. If the 'K' bit is not 1509 supported on the mobile node or the home agent, the mobile node MUST 1510 re-establish the IKEv2 security association with the new care-of 1511 address. This will also result in new IPsec security associations 1512 being setup for the home address. 1514 9.2. Transport Mode IPsec protected messages 1516 For Mobile IPv6 signaling message protected using IPsec in transport 1517 mode, the use of a particular care-of address among multiple care-of 1518 addresses does not matter for IPsec processing. 1520 The home agent processes Mobile Prefix Discovery messages with the 1521 same rules of data packets described in Section 6.4. 1523 9.3. Tunnel Mode IPsec protected messages 1525 The use of IPsec in tunnel mode with multiple care-of address 1526 introduces a few issues that require changes to how the mobile node 1527 and the home agent send and receive tunneled traffic. The route 1528 optimization mechanism described in [RFC-3775] mandates the use of 1529 IPsec protection in tunnel mode for the Home Test Init and Home Test 1530 messages. The mobile node and the home agent may also choose to 1531 protect all reverse tunneled payload traffic with IPsec in tunnel 1532 mode. The following sections address multiple care-of address 1533 support for these two types of messages. 1535 9.3.1. Tunneled Home Test Init and Home Test messages 1537 The mobile node MAY use the same care-of address for all Home Test 1538 Init messages sent reverse tunneled through the home agent. The 1539 mobile node may use the same care-of address irrespective of which 1540 correspondent node the Home Test Init message is being sent. RFC 1541 3775 requires the home agent to verify that the mobile node is using 1542 the care-of address that is in the binding cache entry, when it 1543 receives a reverse tunneled Home Test Init message. If a different 1544 address is used as the source address, the message is silently 1545 dropped by the home agent. This document requires the home agent 1546 implementation to decapsulate and forward the Home Test Init message 1547 as long as the source address is one of the care-of addresses in the 1548 binding cache entry for the mobile node. 1550 When the home agent tunnels a Home Test message to the mobile node, 1551 the care-of address used in the outer IPv6 header is not relevant to 1552 the Home Test message. So regular IPsec tunnel encapsulation with 1553 the care-of address known to the IPsec implementation on the home 1554 agent is sufficient. 1556 9.3.2. Tunneled Payload Traffic 1558 When the mobile sends and receives multiple traffic flows protected 1559 by IPsec to different care-of addresses, the use of the correct 1560 care-of address for each flow becomes important. Support for this 1561 requires the following two considerations on the home agent. 1563 o When the home agent receives a reverse tunneled payload message 1564 protected by IPsec in tunnel mode, it still needs to be aware of 1565 which care-of address is being used. According to [RFC-4306], the 1566 IPsec implementation on the home agent does not check the source 1567 address on the outer IPv6 header. However, the stack on the home 1568 agent MUST still be informed about the source address in order to 1569 choose the most recently used care-of address, as discussed in 1570 Section 3 (in the absence of a user-supplied policy) 1572 o For tunneled IPsec traffic from the home agent to the mobile node, 1573 The IPsec implementation on the home agent may not be aware of 1574 which care-of address to use when performing IPsec tunnel 1575 encapsulation. The Mobile IP stack on the home agent must specify 1576 the tunnel end point for the IPsec tunnel. This may require tight 1577 integration between the IPsec and Mobile IP implementations on the 1578 home agent. 1580 10. Security Considerations 1582 The security considerations for securing the Binding Update and 1583 Binding Acknowledgement messages with multiple care-of address are 1584 very similar to the security considerations for securing the Binding 1585 Update and Binding Acknowledgement. Please see [RFC-3775] for more 1586 information. The Binding Update and binding Acknowledgement messages 1587 with multiple care-of addresses are securely exchanged as described 1588 in [RFC-3775], [RFC-4877] and Section 9. Additional security 1589 considerations are described below. 1591 With simultaneous binding support, it is possible for a malicious 1592 mobile node to successfully bind a number of victims' addresses as 1593 valid care-of addresses for the mobile node with its home agent. 1594 Once these addresses have been bound, the malicious mobile node can 1595 perform a re-direction attack by instructing the home agent (e.g. 1596 setting filtering rules to direct a large file transfer) to tunnel 1597 packets to the victims' addresses. Such risk is highlighted in [ID- 1598 MIP6ANALYSIS]. These attacks are possible because the care-of 1599 addresses sent by the mobile node in the Binding Update messages are 1600 not verified by the home agent, i.e., the home agent does not check 1601 if the mobile node is at the care-of address it is claiming to be. 1602 The security model for Mobile IPv6 assumes that there is a trust 1603 relationship between the mobile node and its home agent. Any 1604 malicious attack by the mobile node is traceable by the home agent. 1605 This acts as a deterrent for the mobile node to launch such attacks. 1607 Although such a risk exists in Mobile IPv6, the risk level is 1608 increased when simultaneous multiple care-of address bindings are 1609 performed. In Mobile IPv6, a mobile node can only have a single 1610 care-of address binding per home address at a given time. However, 1611 for simultaneous multiple care-of address bindings, a mobile node can 1612 have more than one care-of address binding per home address at a 1613 given time. This implies that a mobile node using simultaneous 1614 binding support can effectively bind more than a single victim's 1615 address. Another difference is the degree of risk involved. In the 1616 single care-of address binding case, once the re-direction attack is 1617 initiated, a malicious mobile node would be unable to use its home 1618 address for communications (such as to receive control packets 1619 pertaining to the file transfer). However, in the simultaneous 1620 binding support case, a malicious mobile node could bind a valid 1621 care-of address in addition to multiple victims addresses. This 1622 valid care-of address could then be used by the malicious mobile node 1623 to set up flow filtering rules at its home agent, thereby controlling 1624 and/or launching new re-direction attacks. 1626 Thus, in view of such risks, it is advisable for a home agent to 1627 employ some form of care-of address verification mechanism before 1628 using the care-of addresses as a valid routing path to a mobile node. 1629 These mechanisms are out-of scope for this document. 1631 In the binding registration of Mobile IPv6, a care-of address is 1632 always verified its reachability by a home agent. This reachability 1633 test may decrease the above risks. However, when bulk registration 1634 is used, a home agent cannot verify reachability of care-of addresses 1635 carried in a Binding Identifier mobility option. Therefore, the home 1636 agent can choose to reject bulk registration by using [MCOA BULK 1637 REGISTRATION PROHIBITED] in a Binding Acknowledgement. 1638 Alternatively, when a mobile node first registers a care-of address, 1639 it uses the individual binding updates for the first appeared care-of 1640 address. During the initial binding registration, a home agent can 1641 verify the address reachability for that given care-of address. 1642 After that, the mobile node uses bulk registration to refresh the 1643 care-of address. 1645 11. IANA Considerations 1647 The following Extension Types MUST be assigned by IANA: 1649 o Binding Identifier mobility option type: This must be assigned 1650 from the same space as mobility option in [RFC-3775]. 1652 o New Successful Status of Binding Acknowledgement: This status code 1653 must be assigned from the same space as binding acknowledgement 1654 status codes in [RFC-3775]. 1656 * MCOA NOTCOMPLETE (TBD) 1658 * MCOA RETURNHOME WO/NDP (TBD) 1660 o New Unsuccessful Status of Binding Acknowledgement: These status 1661 codes must also be assigned from the same space as Binding 1662 Acknowledgement status codes in [RFC-3775]. 1664 * MCOA MALFORMED (TBD) 1666 * MCOA BID CONFLICT (TBD) 1668 * MCOA PROHIBITED(TBD) 1670 * MCOA BULK REGISTRATION PROHIBITED (TBD) 1672 * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD) 1674 12. Acknowledgements 1676 The authors would like to special thank George Tsirtsis for thorough 1677 review and suggestions. The authors would also like to thank 1678 Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin 1679 Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas 1680 Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to 1681 Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke 1682 Uehara, Masafumi Watari and Jun Murai for earlier work on this 1683 subject. 1685 13. References 1687 13.1. Normative References 1689 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1690 Requirement Levels", BCP 14, RFC 2119, March 1997. 1692 [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, 1693 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 1694 2007.. 1696 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1697 in IPv6", RFC 3775, June 2004. 1699 [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with 1700 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 1702 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1703 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1704 January 2005. 1706 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1707 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1709 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1710 and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in 1711 progress), December 2008. 1713 [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June 1714 2008. 1716 13.2. Informative References 1718 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1719 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1720 Interfaces and Global Addresses", 1721 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1722 progress), May 2008. 1724 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1725 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1727 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1728 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1729 draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. 1731 [ID-FLOWBINDING] H. Soliman, N. Montavont, N. Fikouras, and K. 1732 Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", 1733 draft-ietf-mext-flow-binding-00 (Work in progress), May 2008. 1735 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1736 RFC 3753, June 2004. 1738 [RFC-4306] C. Kaufman (Editor), "Internet Key Exchange (IKEv2) 1739 Protocol", RFC 4306, December 2005. 1741 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1742 Terminology", RFC 4885, July 2007. 1744 Authors' Addresses 1746 Ryuji Wakikawa 1747 Toyota ITC / Keio University 1748 6-6-20 Akasaka, Minato-ku 1749 Tokyo 107-0052 1750 Japan 1752 Phone: +81-3-5561-8276 1753 Fax: +81-3-5561-8292 1754 Email: ryuji@jp.toyota-itc.com 1756 Vijay Devarapalli 1757 Wichorus 1758 3590 North First St 1759 San Jose, CA 95134 1760 USA 1762 Email: vijay@wichorus.com 1764 Thierry Ernst 1765 INRIA 1766 INRIA Rocquencourt 1767 Domaine de Voluceau B.P. 105 1768 Le Chesnay, 78153 1769 France 1771 Phone: +33-1-39-63-59-30 1772 Fax: +33-1-39-63-54-91 1773 Email: thierry.ernst@inria.fr 1774 URI: http://www.nautilus6.org/~thierry 1776 Kenichi Nagami 1777 INTEC NetCore Inc. 1778 1-3-3, Shin-suna 1779 Koto-ku, Tokyo 135-0075 1780 Japan 1782 Phone: +81-3-5565-5069 1783 Fax: +81-3-5565-5094 1784 Email: nagami@inetcore.com