idnits 2.17.1 draft-ietf-monami6-multiplecoa-14.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 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.) -- The document date (May 27, 2009) is 5420 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 963, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1061, but not defined == Missing Reference: 'MCOA UNKNOWN' is mentioned on line 1108, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1153, but not defined == Missing Reference: 'ID-DSMIP6' is mentioned on line 1357, but not defined == Unused Reference: 'ID-FLOWBINDING' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: 'RFC-4306' is defined on line 1646, but no explicit reference was found in the text ** 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-01 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 10 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 4 Intended status: Standards Track V. Devarapalli 5 Expires: November 28, 2009 Wichorus 6 G. Tsirtsis 7 Qualcomm 8 T. Ernst 9 INRIA 10 K. Nagami 11 INTEC NetCore 12 May 27, 2009 14 Multiple Care-of Addresses Registration 15 draft-ietf-monami6-multiplecoa-14.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 28, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 According to the current Mobile IPv6 specification, a mobile node may 54 have several care-of addresses, but only one, called the primary 55 care-of address, that can be registered with its home agent and the 56 correspondent nodes. However, for matters of cost, bandwidth, delay, 57 etc, it is useful for the mobile node to get Internet access through 58 multiple accesses simultaneously, in which case the mobile node would 59 be configured with multiple active IPv6 care-of addresses. This 60 document proposes extensions to the Mobile IPv6 protocol to register 61 and use multiple care-of addresses. The extensions proposed in this 62 document can be used by Mobile Routers using the NEMO (Network 63 Mobility) Basic Support protocol as well. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Binding Cache Structure and Binding Update List . . . . . 13 75 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13 76 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14 77 4.4. New Status Values for Binding Acknowledgement . . . . . . 15 79 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18 80 5.1. Management of Care-of Address(es) and Binding 81 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18 82 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18 83 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19 84 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20 85 5.5. Returning Home with complete binding de-registration: 86 Using Single Interface . . . . . . . . . . . . . . . . . . 20 87 5.5.1. Using only Interface attached to the Home Link . . . . 21 88 5.5.2. Using only Interface attached to the Visited Link . . 21 89 5.6. Returning Home: Simultaneous Home and Visited Link 90 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21 91 5.6.1. Problems of Simultaneous Home and Foreign 92 Attachments . . . . . . . . . . . . . . . . . . . . . 21 93 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22 94 5.6.3. Home Binding Support . . . . . . . . . . . . . . . . . 23 95 5.6.4. Sending Packets from the Home Link . . . . . . . . . . 23 96 5.6.5. Leaving from the Home Link . . . . . . . . . . . . . . 24 97 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24 98 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25 99 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26 101 6. Home Agent and Correspondent Node Operation . . . . . . . . . 27 102 6.1. Searching Binding Cache with Binding Identifier . . . . . 27 103 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 27 104 6.3. Sending Binding Acknowledgement for home link 105 registration . . . . . . . . . . . . . . . . . . . . . . . 30 106 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 31 107 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 31 109 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32 111 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33 112 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33 113 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34 115 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 36 116 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 36 117 9.2. Transport Mode IPsec protected messages . . . . . . . . . 37 118 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 37 119 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 37 120 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 38 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 124 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 126 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 130 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 134 1. Introduction 136 A mobile node may use various types of network interfaces to obtain 137 durable and wide area network connectivity. This has increasingly 138 become true with mobile nodes having multiple interfaces such as 139 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and 140 benefits of using multiple points of attachment are discussed in [ID- 141 MOTIVATION]. When a mobile node with multiple interfaces uses Mobile 142 IPv6 [RFC-3775] for mobility management, it cannot use its multiple 143 interfaces to send and receive packets while taking advantage of 144 session continuity provided by Mobile IPv6. This is because Mobile 145 IPv6 allows the mobile node to only bind one care-of address at a 146 time with its home address. See [ID-MIP6ANALYSIS] for a further 147 analysis of using multiple interfaces and addresses with Mobile IPv6. 149 This document proposes extensions to Mobile IPv6 to allow a mobile 150 node to register multiple care-of addresses for a home address and 151 create multiple binding cache entries. A new Binding Identification 152 (BID) number is created for each binding the mobile node wants to 153 create and sent in the Binding Update. The home agent that receives 154 this Binding Update creates a separate binding for each BID. The BID 155 information is stored in the corresponding binding cache entry. The 156 BID information can now be used to identify individual bindings. The 157 same extensions can also be used in Binding Updates sent to the 158 correspondent nodes. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC-2119]. 166 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 167 [RFC-4885]. In addition to or as a replacement of these, the 168 following terms are defined or redefined: 170 Binding Identification number (BID) 172 The BID is an identification number used to distinguish multiple 173 bindings registered by the mobile node. Assignment of distinct 174 BIDs allows a mobile node to register multiple binding cache 175 entries for a given home address. The BIDs assigned to a same 176 home address must not be duplicated at a time. Zero value is 177 reserved for future extension. Each BID is generated and managed 178 by a mobile node. The BID is stored in the binding update List 179 and is sent by the mobile node in the Binding Update. A mobile 180 node may change the value of a BID at any time according to its 181 administrative policy, for instance to protect its privacy. An 182 implementation must carefully assign the BID so as to keep using 183 the same BID for the same binding even when the status of the 184 binding is changed. More details can be found in Section 5.1. 186 Binding Identifier Mobility Option 188 The Binding Identifier mobility option is used to carry the BID 189 information. 191 Bulk Registration 193 A mobile node can register multiple bindings at once by sending a 194 single Binding Update. A mobile node can also replace some or all 195 the bindings available at the home agent with the new bindings by 196 using the bulk registration. Bulk registration is supported only 197 for home registration (i.e. with the home agent) as explained in 198 Section 5.3. A mobile node must not perform bulk registration 199 mechanism described in this specification with a correspondent 200 node. 202 3. Protocol Overview 204 A new extension called the Binding identification number (BID) is 205 introduced to distinguish between multiple bindings pertaining to the 206 same home address. If a mobile node configures several IPv6 global 207 addresses on one or more of its interfaces, it can register these 208 addresses with its home agent as care-of addresses. If the mobile 209 node wants to register multiple bindings, it MUST generate a BID for 210 each care-of address and store the BID in the binding update list. A 211 mobile node can manipulate each binding independently by using the 212 BIDs. The mobile node then registers its care-of addresses by 213 sending a Binding Update with a Binding Identifier mobility option. 214 The BID is included in the Binding Identifier mobility option. After 215 receiving the Binding Update with a Binding Identifier mobility 216 option, the home agent MUST copy the BID from the Binding Identifier 217 mobility option to the corresponding field in the binding cache 218 entry. If there is an existing binding cache entry for the mobile 219 node, and if the BID in the Binding Update does not match the one 220 with the existing entry, the home agent MUST create a new binding 221 cache entry for the new care-of address and BID. The mobile node can 222 register multiple care-of addresses either independently in 223 individual Binding Updates or multiple at once in a single Binding 224 Update. 226 If the mobile host wishes to register its binding with a 227 correspondent node, it must perform return routability operations as 228 described in [RFC-3775]. This includes managing a Care-of Keygen 229 token per care-of address and exchanging Care-of Test Init and 230 Care-of Test message with the correspondent node for each care-of 231 address. The mobile node MAY use the same BID that it used with the 232 home agent for a particular care-of address. For protocol 233 simplicity, bulk registration to correspondent nodes is not supported 234 in this document. This is because the Return Routability mechanism 235 introduced in [RFC-3775] cannot be easily extended to verify multiple 236 care-of addresses stored in a single Binding Update. 238 Figure 1 illustrates the configuration where the mobile node obtains 239 multiple care-of addresses at foreign links. The mobile node can 240 utilize all the care-of addresses. In Figure 1, the home address of 241 the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 242 different interfaces and possibly acquires care-of addresses 1-3 243 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to 244 each care-of address. 246 +----+ 247 | CN | 248 +--+-+ 249 | 250 +---+------+ +----+ 251 +------+ Internet |----------+ HA | 252 | +----+---+-+ +--+-+ 253 CoA2| | | | Home Link 254 +--+--+ | | ------+------ 255 | MN +--------+ | 256 +--+--+ CoA1 | 257 CoA3| | 258 +---------------+ 260 Binding Cache Database: 261 home agent's binding (Proxy neighbor advertisement is active) 262 binding [2001:db8::EUI BID1 care-of address1] 263 binding [2001:db8::EUI BID2 care-of address2] 264 binding [2001:db8::EUI BID3 care-of address3] 265 correspondent node's binding 266 binding [2001:db8::EUI BID1 care-of address1] 267 binding [2001:db8::EUI BID2 care-of address2] 268 binding [2001:db8::EUI BID3 care-of address3] 270 Figure 1: Multiple Care-of Address Registration 272 If the mobile node decides to act as a regular mobile node compliant 273 with [RFC-3775], it sends a Binding Update without any Binding 274 Identifier mobility options. The receiver of the Binding Update 275 deletes all the bindings registered with a BID and registers only a 276 single binding for the mobile node. Note that the mobile node can 277 continue using the BID even if it has only a single binding that is 278 active. 280 Binding cache lookup is done based on the home address and BID 281 information if a BID is available. This is different from RFC 3775, 282 where only the home address is used for binding cache lookup. 283 Binding cache lookup is operated for either protocol signaling and 284 data packets. For the protocol signaling such as a Binding Update, 285 BID should be always carried by a BID sub-option in a protocol 286 signaling. Therefore, a correspondent binding cache that matches the 287 specified BID MUST be found from the binding cache database. On the 288 other hand, for the data packets, no BID information is carried in a 289 packet. The binding cache lookup may involve policy or flow filters 290 to retrieve a correspondent BID per packet in cases where some policy 291 or flow filters are used to direct a certain packet or flow to a 292 particular care-of address. However, the binding cache lookup using 293 policy or flow filters is out of scope for this document. If no such 294 mechanism is available and no BID is found for a packet, a node 295 SHOULD use the binding which was last verified by receiving data 296 packets or signaling from the mobile node. In case the binding cache 297 lookup for data packets, using the combination of home address and 298 BID, does not return a valid binding cache entry, the home agent 299 SHOULD perform the lookup based on only the home address as described 300 in [RFC-3775]. 302 In any case, to avoid problems with upper layer protocols and TCP in 303 particular, a single packet flow as identified by the 5-tuple SHOULD 304 only be sent to a single care-of address at a time. 306 The mobile node may return to the home link through one of its 307 interfaces. There are two options possible for the mobile node when 308 its returns home. Section 5.6 and Section 5.5.1 describe the 309 returning home procedures in more detail. 311 1. The mobile node uses only the interface with which it attaches to 312 the home link and takes back full ownership of its HoA on the 313 home link. This is illustrated in Figure 2. It de-registers all 314 bindings with the home agent related to all care-of addresses. 315 The interfaces still attached to the visited link(s) are no 316 longer going to be receiving any encapsulated traffic from the 317 home agent. On the other hand, the mobile node can continue 318 communicating with the correspondent nodes from the other 319 interfaces attached to foreign links by using route optimization. 320 Even if the mobile node is attached to the home link, it can 321 still send Binding Updates for other active care-of addresses 322 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 323 node has bindings, packets are routed from and to each Care-of 324 Addresses directly. 326 +----+ 327 | CN | 328 +--+-+ 329 | 330 +---+------+ +----+ 331 +------+ Internet |----------+ HA | 332 | +----+-----+ +--+-+ 333 CoA2| | | Home Link 334 +--+--+ | --+---+------ 335 | MN +--------+ | 336 +--+--+ CoA1 | 337 | | 338 +---------------------------+ 340 Binding Cache Database: 341 home agent's binding 342 none 343 correspondent node's binding 344 binding [2001:db8::EUI BID1 care-of address1] 345 binding [2001:db8::EUI BID2 care-of address2] 347 Figure 2: Using only Interface Attached to Home Link 349 2. The mobile node may simultaneously use both the interface 350 attached to the home link and the interfaces still attached to 351 the visited link(s) as shown in Figure 3. There are two possible 352 topologies depending on whether the home agent is the only router 353 on the home link or not. The operation of Neighbor Discovery 354 [RFC-4861] is different in the two topologies. More details can 355 be found in Section 5.6. The home agent and the correspondent 356 node have the binding entries listed in Figure 3 in their binding 357 cache database in both topologies. The home agent also knows 358 that the mobile node is attached to the home link. All the 359 traffic from the Internet is intercepted by the home agent first 360 and routed to either the interface attached to the home link or 361 the one of the foreign links. How the home agent decides to 362 route a particular flow to the interface attached to the home 363 link or foreign link is out of scope in this document. 365 Topology-a) 366 +----+ 367 | CN | 368 +--+-+ 369 | 370 +---+------+ +----+ 371 +------+ Internet |----------+ HA | 372 | +----+-----+ +--+-+ 373 CoA2| | | Home Link 374 +--+--+ | --+---+------ 375 | MN +--------+ | 376 +--+--+ CoA1 | 377 | | 378 +---------------------------+ 380 Topology-b) 381 +----+ 382 | CN | 383 +--+-+ 384 | 385 +---+------+ Router +----+ 386 +------+ Internet |-------R | HA | 387 | +----+-----+ | +--+-+ 388 CoA2| | | | Home Link 389 +--+--+ | --+-+-------+------ 390 | MN +--------+ | 391 +--+--+ CoA1 | 392 | | 393 +---------------------------+ 395 Binding Cache Database: 396 home agent's binding 397 binding [2001:db8::EUI BID1 care-of address1] 398 binding [2001:db8::EUI BID2 care-of address2] 399 correspondent node's binding 400 binding [2001:db8::EUI BID1 care-of address1] 401 binding [2001:db8::EUI BID2 care-of address2] 403 Figure 3: Simultaneous Home and Visited Link Operation 405 This specification keeps backwards compatibility with [RFC-3775]. If 406 a receiver (either home agent or correspondent node) does not support 407 this specification, it does not understand the binding identifier 408 mobility option. The receiver skip the unknown mobility option (i.e. 409 Binding Identifier mobility option) and process the Binding Update as 410 defined in [RFC-3775]. In order to keep the backward compatibility 411 with [RFC-3775], when a mobile node sends a Binding Update message 412 with extensions described in this document, the receiver needs to 413 reflect the Binding Identifier mobility option in the Binding 414 Acknowledgement. If the mobile node finds no Binding Identifier 415 mobility options in the received Binding Acknowledgement, it assumes 416 the other end node does not support this specification. In such 417 case, the mobile node needs to fall back to the legacy RFC-3775 418 compliant mobile node. If it is the home registration, the mobile 419 node MAY try to discover another home agent supporting Binding 420 Identifier mobility option for the home registration. 422 4. Mobile IPv6 Extensions 424 This section summarizes the extensions to Mobile IPv6 necessary for 425 manage multiple bindings. 427 4.1. Binding Cache Structure and Binding Update List 429 The BID is required to be stored in the binding cache and binding 430 update list structure. 432 The sequence number value MUST be shared among all the binding update 433 list entries related to Binding Updates sent to a particular home 434 agent or correspondent node. Whenever a mobile node sends either an 435 individual or a bulk Binding Update, the sequence number is 436 incremented. When a home agent receives an individual Binding 437 Update, it should update the sequence number for all the bindings for 438 a particular mobile node with the sequence number in the received 439 Binding Update. 441 4.2. Binding Update Message 443 This specification extends the Binding Update message with a new 444 flag. The flag is shown and described below. 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Sequence # | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | | 452 . . 453 . Mobility options . 454 . . 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 4: Binding Update message 460 Overwrite (O) flag 462 When this flag is set, all the binding cache entries for a mobile 463 node are replaced by new entries registering with this Binding 464 Update message. This flag is only used when BID Mobility Option 465 is carried with Binding Update. 467 Reserved 469 6 bits Reserved field. 471 4.3. Binding Identifier Mobility Option 473 The Binding Identifier mobility option is included in the Binding 474 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 475 Test Init and Care-of Test message. The Binding Identifier Mobility 476 Option has an alignment requirement of 2n if the Care-of Address 477 field is not present. Otherwise, it has the alignment requirement of 478 8n + 2. 480 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type = TBD | Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Binding ID (BID) | Status |H| Reserved | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 487 + + 488 : IPv4 or IPv6 care-of address (CoA) : 489 + + 490 +---------------------------------------------------------------+ 492 Figure 5: BID Mobility Option 494 Type 496 Type value for Binding Identifier is TBD 498 Length 500 8-bit unsigned integer. Length of the option, in octets, 501 excluding the Type and Length fields. It MUST be set to either 4, 502 8, or 20 depending on the care-of address field. When the care-of 503 address is not carried by this option, the length value MUST be 504 set to 4. If the IPv4 care-of address is stored in the care-of 505 address field, the length MUST be 8. Otherwise, the Length value 506 MUST be set to 20 for IPv6 care-of address. 508 Binding ID (BID) 510 The BID which is assigned to the binding indicated by the care-of 511 address in the Binding Update or the Binding Identifier mobility 512 option. The BID is a 16-bit unsigned integer. The value of zero 513 is reserved and SHOULD NOT be used. 515 Status 517 The Status field is an 8-bit unsigned integer. When the Binding 518 Identifier mobility option is included in a Binding 519 Acknowledgement, this field overwrites the status field in the 520 Binding Acknowledgement only for this BID. If this field is set 521 to zero, the receiver ignores this field and uses the registration 522 status stored in the Binding Acknowledgement message. The 523 receiver MUST ignore this field if the Binding Identifier mobility 524 option is not carried within either the Binding Acknowledgement or 525 the Care-of Test messages. The possible status codes are the same 526 as the status codes of Binding Acknowledgement. This Status field 527 is also used to carry error information related to the care-of 528 address test in the Care-of Test message. 530 Simultaneous Home and Foreign Binding (H) flag 532 This flag indicates that the mobile node registers multiple 533 bindings to the home agent while it is attached to the home link. 534 This flag is valid only for a Binding Update sent to the home 535 agent. 537 Reserved 539 7 bits Reserved field. The value MUST be initialized to zero by 540 the sender, and SHOULD be ignored by the receiver. 542 Care-of Address 544 If a Binding Identifier mobility option is included in a Binding 545 Update for the home registration, either IPv4 or IPv6 care-of 546 address for the corresponding BID can be stored in this field. 547 For the binding registration to correspondent nodes (i.e. route 548 optimization), only IPv6 care-of address can be stored in this 549 field. If no address is specified in this field, the length of 550 this field MUST be zero (i.e. not appeared in the option). If the 551 option is included in any other messages than a Binding Update, 552 the length of this field MUST be also zero. 554 4.4. New Status Values for Binding Acknowledgement 556 New status values for the status field in a Binding Acknowledgement 557 are defined for handling the multiple Care-of Addresses registration: 559 MCOA NOTCOMPLETE (TBD less than 128) 560 In bulk registration, not all the binding identifier mobility 561 options were successfully registered. Some of them were rejected. 562 The error status value of the failed mobility option is 563 individually stored in the status field of the binding identifier 564 mobility option. 566 MCOA RETURNHOME WO/NDP (TBD less than 128) 568 When a mobile node returns home, it MUST NOT use Neighbor 569 Discovery Protocol (NDP) for the home address on the home link. 570 This is explained in more detail in Section 5.6 572 MCOA MALFORMED (TBD more than 128) 574 Registration failed because Binding Identifier mobility option was 575 not formatted correctly. This value is used in the following 576 cases. 578 * when the wrong length value is specified (neither 4, 8 nor 20) 579 in the length field of the Binding Identifier mobility option. 581 * when a unicast routable address is not specified in the care-of 582 address field of the Binding Identifier mobility option. 584 * when a care-of address does not appear in the care-of address 585 field of the Binding Identifier mobility option stored in an 586 IPsec ESP protected Binding Update. 588 MCOA NON-MCOA BINDING EXISTS (TBD more than 128) 590 It indicates that a bootstrapping multiple care-of address 591 registration was performed without the 'O' flag set. 593 MCOA UNKOWN COA(TBD more than 128) 595 It indicates that a Binding Identifier Mobility Option did not 596 include a Care-of address field and the receiver has no record for 597 the Binding ID indicated in the same option. 599 MCOA PROHIBITED(TBD more than 128) 601 It implies the multiple care-of address registration is 602 administratively prohibited. 604 MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) 605 Bulk binding registration is not either permitted or supported. 606 Note that the bulk registration is an optional procedure and might 607 not be available on a home agent. 609 MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) 611 Simultaneous home and foreign attachment is neither supported nor 612 permitted. 614 5. Mobile Node Operation 616 5.1. Management of Care-of Address(es) and Binding Identifier(s) 618 There are two cases when a mobile node might acquire several care-of 619 addresses. A mixture of the two cases is also possible. Note that a 620 mobile node can use BID regardless of the number of interfaces and 621 care-of addresses. Whether a mobile node uses BID or not is 622 determined by a local configuration. 624 1. A mobile node is using several physical network interfaces and 625 acquires a care-of address on each of its interfaces. 627 2. A mobile node uses a single physical network interface, but 628 receives advertisements for multiple prefixes on the link the 629 interface is attached to. This will result in the mobile node 630 configuring several global addresses on the interface from each 631 of the announced prefixes. 633 The difference between the above two cases is only in the number of 634 physical network interfaces and therefore irrelevant in this 635 document. What is of significance is the fact that the mobile node 636 has several addresses it can use as care-of addresses. 638 A mobile node assigns a BID to each care-of address when it wants to 639 register them simultaneously with its home address. The BID MUST be 640 unique for a given home address. The value is an integer between 1 641 and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node 642 has only one care-of address, the assignment of a BID is not needed 643 until it has multiple care-of addresses to register with, at which 644 time all of the care-of addresses MUST be mapped to BIDs. 646 When a mobile node registers a given BID for the first time it MUST 647 include the care-of address field in the Binding Identifier mobility 648 option. For any subsequent registrations that either re-register or 649 de-register the same BID, the MN need not include the care-of address 650 field in the Binding Identifier mobility option. 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. 658 When IPsec ESP is used for protecting the Binding Update, a care-of 659 address MUST be carried in an alternate care-of address mobility 660 option as described in [RFC-4877]. However, in this specification, 661 the care-of address MUST be carried in the Care-of Address field of 662 the Binding Identifier mobility option. In order to save bits of the 663 Binding Update, the alternate care-of address option MUST NOT be 664 included. 666 For binding registration to a correspondent node, the mobile node 667 MUST have both active Home and Care-of Keygen tokens for Kbm (see 668 Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The 669 care-of Keygen tokens MUST be maintained for each care-of address 670 that the mobile node wants to register to the correspondent node. 671 The Binding Update to the correspondent node is protected by the 672 Binding Authorization Data mobility option that is placed after the 673 Binding Identifier mobility option. 675 IPv6 header (src=Care-of Address, dst=Home Agent Address) 676 IPv6 Home Address Option 677 ESP Header* 678 Mobility header 679 Binding Update 680 Mobility Options 681 Binding Identifier mobility option 682 Binding Authorization mobility option+ 683 (*) if necessary, for home registration 684 (+) if necessary, for route optimization 686 Figure 6: Binding Update for Binding Registration 688 If the mobile node wants to replace existing registered bindings on 689 the home agent with the single binding in the sent Binding Update, it 690 sets the 'O' flag. It the 'O' flag is not set then the binding will 691 be added to existing bindings in the home agent. The single binding 692 will be registered with the assigned BID. Section 6.2 describes this 693 registration procedure in detail. 695 5.3. Bulk Registration 697 Bulk registration is an optimization for binding multiple care-of 698 addresses to a home address using a single Binding Update. This is 699 very useful if the mobile node, for instance, does not want to send a 700 lot of signaling messages through an interface where the bandwidth is 701 scarce. This document specifies bulk registration only for the 702 mobile node's home registration. A mobile node performing bulk 703 registration with a correspondent node is out of scope. 705 To use bulk registration, the mobile node includes a Binding 706 Identifier Mobility option for each BID it wants to register in the 707 same Binding Update message. As with single registrations (see 708 Section 5.1), the care of address field is included for BID 709 registered for the first time. This is shown in Figure 7. The rest 710 of the fields and options in the Binding Update such as Lifetime, 711 Sequence Number, and the flags in the Binding Update are common 712 across all care-of addresses. 714 IPv6 header (src=Care-of Address, dst=Home Agent Address) 715 IPv6 Home Address Option 716 ESP Header 717 Mobility header 718 Binding Update 719 Mobility Options 720 Binding Identifier1 (including Care-of Address) 721 Binding Identifier2 (including Care-of Address) 722 Binding Identifier3 (no Care-of Address) 723 Binding IdentifierN (no Care-of Address) 725 : 727 Figure 7: Binding Update for Bulk Registration 729 As with regular registrations, if the mobile node wants to replace 730 existing registered bindings on the home agent with the multiple 731 bindings in the sent Binding Update, it sets the 'O' flag in the 732 Binding Update, otherwise the bindings are added to the existing 733 bindings in the home agent. 735 5.4. Binding De-Registration 737 When a mobile node decides to delete all the bindings for its home 738 address, it sends a regular de-registration Binding Update with 739 lifetime set to zero as defined in [RFC-3775]. The Binding 740 Identifier mobility option is not required. 742 If a mobile node wants to delete a particular binding(s) from its 743 home agent and correspondent nodes, the mobile node sends a Binding 744 Update with lifetime set to zero and includes a Binding Identifier 745 mobility option(s) with the BID(s) it wants to de-register. The 746 receiver will remove only the care-of address(es) that match(es) the 747 specified BID(s). Since de-registration attempts to remove a BID 748 that already exists, the care-of addresses field in each binding 749 identifier option can be omitted by the sender as defined in 750 Section 5.1. 752 5.5. Returning Home with complete binding de-registration: Using Single 753 Interface 755 The mobile node may return to the home link, by attaching to the home 756 link through one of its interfaces. When the mobile node wants to 757 return home, it should be configured with information on what 758 interface it needs to use. 760 5.5.1. Using only Interface attached to the Home Link 762 The mobile node returns home and de-registers all the bindings it has 763 with the home agent as shown in Figure 2 and as defined in [RFC- 764 3775]. After the de-registration step, all the packets routed by the 765 home agent are only forwarded to the interface attached to the home 766 link, even if there are other active interfaces attached to the 767 visited link(s). While the mobile node de-registers all the bindings 768 from the home agent, it may continue registering bindings for 769 interface(s) attached to visited link(s) to the correspondent node as 770 shown in Figure 2. 772 5.5.2. Using only Interface attached to the Visited Link 774 The mobile node returns home physically but shuts down the interface 775 attached to the home link. As a result, a mobile node does not 776 return home even though it attaches to the home link by one of 777 interfaces. Before shutting down the interface, any binding for the 778 care-of address previously associated with the interface should be 779 deleted as defined in Section 5.4. 781 In this scenario, despite the fact that the mobile node is connected 782 to its home link, all of its traffic is sent and received via the 783 home agent and its foreign links. 785 5.6. Returning Home: Simultaneous Home and Visited Link Operation 787 5.6.1. Problems of Simultaneous Home and Foreign Attachments 789 The mobile node returns home and continues using all the interfaces 790 attached to both foreign and home links as shown in Figure 3. 792 In [RFC-3775], the home agent intercepts packets meant for the mobile 793 node using Proxy Neighbor Discovery [RFC-4861] while the mobile node 794 is away from the home link. When the mobile node returns home, the 795 home agent deletes the binding cache and stops proxying for the home 796 address so that a mobile node can configure its home address on the 797 interface attached to the home link. In this specification, a mobile 798 node may return home, configure the home address on the interface 799 attached to the home link, but still use the interfaces attached to 800 the foreign links. In this case, a possible conflict arises when 801 both the home agent and the mobile node try to defend the home 802 address. If the home agent stops proxying for the home address, the 803 packets are always routed to the interface attached to the home link 804 and are never routed to the interfaces attached to the visited links. 805 It is required to avoid the conflict between the home agent and the 806 mobile node, while still allowing the simultaneous use of home and 807 foreign links. The following describes the mechanism for achieving 808 this. 810 5.6.2. Overview and Approach 812 The home agent MUST intercept all the packets meant for the mobile 813 node whether the mobile node is attached to the home link or not and 814 decide whether to send the traffic directly to the home address on 815 the link or tunnel to the care-of address. 817 Two scenarios are illustrated in Figure 3, depending on whether the 818 Home Agent is the only router at the home link or not. The 819 difference is on who defends the home address by (Proxy) Neighbor 820 Discovery on the home link. 822 1. Mobile node defends the home address by the regular Neighbor 823 Discovery Protocol (illustrated as topology-a in Figure 3). The 824 home agent is the only router on the home link. Therefore the 825 home agent is capable of intercepting packets without relying on 826 the proxy Neighbor Discovery protocol and the mobile node can 827 manage the Neighbor Cache entry of the home address on the home 828 link as a regular IPv6 node. However, there is one limitation of 829 this scenario. If a correspondent node is located at the home 830 link, the home agent may not intercept the packets destined to 831 the mobile node. These packets are routed only via the home 832 link, but this is the most optimal path for the mobile node to 833 communicate with nodes on the home link. 835 2. If there are other routers on the home link apart from the home 836 agent, then it cannot be guaranteed that all packets meant for 837 the mobile node are routed to the home agent. In this case, the 838 mobile node MUST NOT operate the Neighbor Discovery protocol for 839 the home address on the home link. This allows the home agent to 840 keep using proxy neighbor discovery and thus it keeps receiving 841 all the packets sent to the mobile node's home address. If the 842 home agent, according to its local policy, needs to deliver 843 packets to the mobile node over the home link, an issue arises 844 with respect to how the home agent discovers the mobile node's 845 link local address. This specification uses the Mobility Header 846 Link-layer Address Option defined in [RFC-5268] in order to carry 847 the mobile node's link-layer address in the Binding Update. 848 Likewise, the mobile node would also know the link-layer address 849 of the default router address to send packets from the home link 850 without Neighbor Discovery. The link-layer address is used to 851 transmit packets from and to the mobile node on the home link. 852 The packets are transmitted without the Neighbor Discovery 853 protocol by constructing the link-layer header manually. This 854 operation is similar to Mobile IPv6 [RFC-3775] when a mobile node 855 sends a deregistration binding update to the home agent's link- 856 layer address in the operation for returning home. 858 5.6.3. Home Binding Support 860 When the home binding is used, the mobile node MUST send a 861 registering binding update with a Binding Identifier mobility option 862 whith H flag set. The lifetime MUST be set to a non-zero lifetime of 863 the home binding, and the care-of address MUST be set to the home 864 address. The mobile node registers only one home binding at the time 865 even if it attaches to the home link by multiple interfaces. 867 The mobile node SHOULD include the Mobility Header Link-layer Address 868 Option [RFC-5268] to notify the mobile node's link-layer address to 869 the home agent, too. The option code of the Mobility Header Link- 870 layer Address option MUST be set to '2' (Link-layer Address of the 871 mobile node). This link-layer address is required for the home agent 872 to send the Binding Acknowledgement and to forward the mobile node's 873 packet. 875 According to [RFC-3775], the mobile node MUST start responding to 876 Neighbor Solicitation for its home address right after it sends the 877 deregistration Binding Update to the home agent. However, in this 878 specification, the mobile node MUST NOT respond to Neighbor 879 Solicitation before receiving a Binding Acknowledgement, since the 880 home agent may continue proxying for the home address. If the mobile 881 node receives [MCOA RETURNHOME WO/NDP (TBD)] status value in the 882 received Binding Acknowledgment, it MUST NOT respond to Neighbor 883 Solicitation even after the Binding Acknowledgement. 885 The management of the home binding is same as the binding management 886 described in this specification. The home binding can be included in 887 a bulk binding registration (Section 5.3). The MN SHOULD refresh the 888 lifetime of the home binding by sending appropriate Binding Updates 889 as with any other binding. 891 5.6.4. Sending Packets from the Home Link 893 o When the mobile node receives the Binding Acknowledgement with the 894 status value 'Binding Update Accepted' and the BID option, it can 895 configure its home address to the interface attached to the home 896 link and start operating Neighbor Discovery for the home address 897 on the home link. Packets can be transmitted from and to the 898 mobile node as if the mobile node is a regular IPv6 node. 900 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 901 the Binding Acknowledgement, it MUST NOT operate Neighbor 902 Discovery for the home address. When the mobile node sends 903 packets from the interface attached to the home link, it MUST 904 learn the link-layer address of the next hop (i.e. default router 905 of the mobile node). A mobile node learns the default router's 906 link-layer address from a Source Link-Layer Address option in 907 Router Advertisements. The mobile node sends packets directly to 908 the default router's link-layer address. This is done by 909 constructing the packet including a link-layer header with the 910 learned link-layer address of the default router. The home agent 911 also forwards the packet to the mobile node on the home link by 912 using the mobile node's link-layer address. The link-layer 913 address SHOULD be cached when the home agent received the 914 deregistration Binding Update message. Note that the default 915 router MUST NOT cache the mobile node's link-layer address in the 916 neighbor cache when it forwards the packet from the mobile node to 917 the home agent. 919 5.6.5. Leaving from the Home Link 921 When the mobile node detaches from the home link, it SHOULD 922 immediately send a Binding Update for one of active care-of address 923 with H flag unset. When the 'H' flag of BID option is unset in any 924 Binding Update, the home agent stop forwarding the mobile node's 925 packets to the home link. 927 5.7. Receiving Binding Acknowledgement 929 The verification of a Binding Acknowledgement is the same as Mobile 930 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 931 Binding Acknowledgement is described in Section 6.2. 933 If a mobile node includes a Binding Identifier mobility option in a 934 Binding Update with the 'A' flag set, a Binding Acknowledgement 935 SHOULD carry a Binding Identifier mobility option. According to 936 [RFC-3775], the receiver of the Binding Update ignores unknown 937 mobility options and processes the Binding Update without the unknown 938 mobility option. Therefore, if no such mobility option is included 939 in the Binding Acknowledgement in response to a Binding Update for 940 multiple care-of address registration, this indicates that the 941 originating node of the Binding Acknowledgement does not support 942 processing the Binding Identifier mobility option regardless of 943 status value. In such case, the receiver of the Binding Update may 944 create a regular binding. The mobile node then SHOULD no longer 945 attempt multiple care-of address registration with that node. If 946 this occurs with home registration the mobile node MAY attempt to 947 discover another home agent supporting Binding Identifier mobility 948 option for the home registration. 950 If a Binding Identifier mobility option is present in the received 951 Binding Acknowledgement, the mobile node checks the status field in 952 the option. If the status value in the Binding Identifier mobility 953 option is zero, the mobile node uses the value in the Status field of 954 the Binding Acknowledgement. Otherwise, it uses the value in the 955 Status field of the Binding Identifier mobility option. 957 If the status code is greater than or equal to 128, the mobile node 958 starts relevant operations according to the error code. Otherwise, 959 the mobile node assumes that the originator (home agent or 960 correspondent node) successfully registered the binding information 961 and BID for the mobile node. 963 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 964 stop registering multiple bindings with the node that sent the 965 Binding Acknowledgement. 967 o If the Status value is [MCOA BULK REGISTRATION PROHIBITED], the 968 mobile node needs to stop using bulk registrations with the node 969 that sent the Binding Acknowledgement. It should assume that none 970 of the attempted registrations were successful. 972 o If [MCOA MALFORMED] is specified, it indicates that the binding 973 identifier mobility option is formatted wrongly presumably due to 974 a programming error or major packet corruption. 976 o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that 977 there is non-MCoA binding entry in the receiver. The mobile node 978 MUST set 'O' flag so that all the registered bindings are replaced 979 by an MCoA registration as described in Section 5.9. 981 o If [MCOA UNKNOWN COA] is specified, it means that the mobile node 982 sent a binding identifier mobility option without a care-of 983 address field but the receiver could not find an entry for the BID 984 indicated. If the mobile node is trying to deregister a BID, it 985 need not do anything further. If the mobile node is trying to 986 refresh a binding it SHOULD send a binding identifier mobility 987 option including the care-of address field. 989 5.8. Receiving Binding Refresh Request 991 The verification of a Binding Refresh Request is the same as in 992 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 993 a Binding Refresh Request is described in Section 6.4. 995 If a mobile node receives a Binding Refresh Request with a Binding 996 Identifier mobility option, it indicates that the node sending the 997 Binding Refresh Request message is requesting the mobile node to send 998 a new Binding Update for the BID. The mobile node SHOULD then send a 999 Binding Update at least for the respective binding, as described in 1000 Section 5.2 and Section 5.3. 1002 5.9. Bootstrapping 1004 When a mobile node bootstraps and registers multiple bindings for the 1005 first time, it MUST set the 'O' flag in the Binding Update message. 1006 If old bindings still exist at the home agent, the mobile node has no 1007 knowledge of which bindings still exist at the home agent. This 1008 scenario happens when a mobile node reboots and loses state regarding 1009 the registrations. If the 'O' flag is set, all the bindings are 1010 replaced by the new binding(s). 1012 6. Home Agent and Correspondent Node Operation 1014 6.1. Searching Binding Cache with Binding Identifier 1016 If either a correspondent node or a home agent has multiple bindings 1017 for a mobile node in their binding cache database, it can use any of 1018 the bindings to communicate with the mobile node. This section 1019 explains how to retrieve the desired binding for the binding 1020 management. This document does not provide any mechanism to select 1021 the suitable binding for forwarding data packets. 1023 A node which is either a correspondent node or a home agent SHOULD 1024 use both the home address and the BID as the search key of the 1025 binding cache if it knows the corresponding BID (example: when 1026 processing signaling messages). In the example below, if a node 1027 searches the binding with the home address and BID2, it gets binding2 1028 for this mobile node. 1030 binding1 [2001:db8::EUI, care-of address1, BID1] 1031 binding2 [2001:db8::EUI, care-of address2, BID2] 1032 binding3 [2001:db8::EUI, care-of address3, BID3] 1034 Figure 8: Searching the Binding Cache 1036 The node learns the BID when it receives a Binding Identifier 1037 mobility option. At that time, the node MUST look up its binding 1038 cache database with the home address and the BID retrieved from the 1039 Binding Update. If the node does not know the BID, it searches for a 1040 binding with only the home address. In such a case, the first 1041 matched binding is found. If the node does not desire to use 1042 multiple bindings for a mobile node, it can simply ignore the BID. 1044 6.2. Processing Binding Update 1046 If a Binding Update does not contain a Binding Identifier mobility 1047 option, its processing is the same as in [RFC-3775]. If the receiver 1048 already has multiple bindings for the home address, it MUST replace 1049 all the existing bindings with the received binding. If the [RFC- 1050 3775] Binding Update is for de-registration, the receiver MUST delete 1051 all existing bindings from its Binding Cache. 1053 If the Binding Update contains a Binding Identifier mobility 1054 option(s), it is first validated according to section 9.5.1 of [RFC- 1055 3775]. Then the receiver processes the Binding Identifier mobility 1056 option(s) as described in the following steps. 1058 o The length value is examined. The length value MUST be either 4, 1059 8, or 20 depending on the Care-of Address field. If the length is 1060 incorrect, the receiver MUST reject the Binding Update and returns 1061 the status value set to [MCOA MALFORMED]. 1063 o When the Length value is either 8 or 20, the care-of address MUST 1064 be present in the Binding Identifier mobility option. If the 1065 unicast routable address [RFC-3775] is not present in the care-of 1066 address field, the receiver MUST reject the Binding Identifier 1067 mobility option and returns the status value set to [MCOA 1068 MALFORMED]. 1070 o When multiple Binding Identifier mobility options are present in 1071 the Binding Update, it is treated as bulk registration. If the 1072 receiving node is a correspondent node, it MUST reject the Binding 1073 Update and returns the status value in the binding Acknowledgement 1074 set to [MCOA BULK REGISTRATION PROHIBITED]. 1076 o If the Lifetime field in the Binding Update is set to zero, the 1077 receiving node deletes the binding entry that corresponds to the 1078 BID in the Binding Identifier mobility option. If the receiving 1079 node does not have an appropriate binding for the BID, it MUST 1080 reject the Binding Update and send a Binding Acknowledgement with 1081 status set to 133 [not home agent for this mobile node]. 1083 o If the 'O' flag is set in the de-registering Binding Update, it is 1084 ignored. If the 'H' flag is set, the home agent stores a home 1085 address in the Care-of Address field of the binding cache entry. 1086 The home agent MUST follow the descriptions described in 1087 Section 5.6. 1089 o If the Lifetime field is not set to zero, the receiving node 1090 registers a binding with the specified BID as a mobile node's 1091 binding. The Care-of address is obtained from the Binding Update 1092 packet as follows: 1094 * If the Length value of the Binding Identifier mobility option 1095 is 20, the care-of address is the IPv6 address copied from the 1096 care-of address field in the Binding Identifier mobility 1097 option. 1099 * When the Length value is 8, the address MUST be the IPv4 valid 1100 address. How to obtain an IPv4 care-of address is described in 1101 Section 8. 1103 * When the Length value is 4 and If the Binding Identifier is 1104 present in the Binding Cache, the receiving node MUST update 1105 the associated binding entry. Otherwise, the receiving node 1106 MUST reject that Binding Identifier mobility option and send a 1107 Binding Acknowledgement with the status for that Binding 1108 Identifier mobility option set to [MCOA UNKNOWN]. 1110 o Once the care-of address(es) have been retrieved from the Binding 1111 Update, the receiving nodes creates new binding(s). 1113 * If the 'O' flag is set in the Binding Update, the receiving 1114 node removes all the existing bindings and registers the 1115 received binding(s). 1117 * If the 'O' flag is unset in the Binding Update and the receiver 1118 has a regular binding which does not have BID for the mobile 1119 node, it must not process the Binding Update. The receiver 1120 should sent a Binding Acknowledgement with status set to [MCOA 1121 NON-MCOA BINDING EXISTS]. 1123 * If the receiver already has a binding with the same BID but 1124 different care-of address, it MUST update the binding and 1125 respond with a Binding Acknowledgement with status set to 0 1126 [Binding Update accepted]. 1128 * If the receiver does not have a binding entry for the BID, it 1129 registers a new binding for the BID and responds with a Binding 1130 Acknowledgement with status set to 0 [Binding Update accepted]. 1132 If all the above operations are successfully completed and 'A' flag 1133 is set in the Binding Update, a Binding Acknowledgement containing 1134 the Binding Identifier mobility options MUST be sent to the mobile 1135 node. Whenever a Binding Acknowledgement is sent, all the Binding 1136 Identifier mobility options stored in the Binding Update MUST be 1137 copied to the Binding Acknowledgement except the status field. The 1138 Care-of address field in each Binding Identifier mobility option, 1139 however, MAY be omitted, because the mobile node can match a 1140 corresponding binding update list entry using the BID. 1142 When a correspondent node sends a Binding Acknowledgement, the status 1143 value MUST be always stored in the Status field of the Binding 1144 Acknowledgement and the Status field of Binding Identifier mobility 1145 option MUST be always set to zero. 1147 When the home agent sends a Binding Acknowledgement, the status value 1148 can be stored in the Status field of either a Binding Acknowledgement 1149 or a Binding Identifier mobility option. If the status value is 1150 specific to one of bindings in the bulk registration, the status 1151 value MUST be stored in the Status field in the corresponding Binding 1152 Identifier mobility option. In this case, the Status field of the 1153 Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that 1154 the receiver can examine the Status field of each Binding Identifier 1155 mobility option for further operations. Otherwise, the status field 1156 of the Binding Identifier mobility option MUST be set to zero and the 1157 home agent status field of the Binding Acknowledgement is used. 1159 6.3. Sending Binding Acknowledgement for home link registration 1161 The operations described in this section are related to the returning 1162 home using simultaneous use of home and foreign links. 1164 o When the home agent sends the Binding Acknowledgement after 1165 successfully processing the home binding registration, it MUST set 1166 the status value to either 0 [Binding Update Accepted] or to [MCOA 1167 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 1168 Acknowledgment depending on home agent configuration at the home 1169 link. The new values are: 1171 * Binding Update Accepted (0): Neighbor Discovery Protocol is 1172 permitted for the home address at the home link. This is 1173 regular returning home operation of [RFC-3775] 1175 * MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is 1176 prohibited for the home address at the home link 1178 The respective Binding Identifier mobility options need to be 1179 included in the Binding Acknowledgement. 1181 o If the Binding Update is rejected, the appropriate error value 1182 MUST be set in the status field. In this case, the home agent 1183 operation is the same as [RFC-3775]. 1185 o Only if the home agent is certainly the only router in the home 1186 link, it MAY turn off Neighbor Discovery for the requested home 1187 address and responds with the [Binding Update Accepted] status 1188 value to the mobile node. Since the mobile node will not reply to 1189 Neighbor Solicitation for the home address before receiving the 1190 Binding Acknowledgement, the home agent SHOULD use the link-layer 1191 address carried by the Mobility Header Link-Layer Address option 1192 [RFC-5268] in the received Binding Update. After the completion 1193 of the home binding registration, the mobile node starts regular 1194 Neighbor Discovery operations for the home address on the home 1195 link. The neighbor cache entry for the home address is created by 1196 the regular exchange of Neighbor Solicitation and Neighbor 1197 Advertisement. 1199 o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] 1200 value in the Status field of the Binding Identifier mobility 1201 option. The home agent learns the mobile node's link-layer 1202 address by receiving the Mobility Header link-layer address option 1203 carried by the Binding Update. It stores the link-layer address 1204 as a neighbor cache entry for the mobile node so that it can send 1205 the packets to the mobile node's link-layer address. 1207 o Note that the use of proxy Neighbor Discovery is an easier way to 1208 intercept the mobile nodes' packets instead of IP routing in some 1209 deployment scenarios. Therefore, even if a home agent is the only 1210 router, it is an implementation and operational choice whether the 1211 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 1212 WO/NDP]. 1214 o If BID option is not included in the Binding Acknowledgement, the 1215 home agent might not recognize the home registration. The home 1216 agent might have processed the home registration Binding Update as 1217 a regular de-registration as described in [RFC-3775] and deletes 1218 all the registered binding cache entries for the mobile node. 1219 Thus, the mobile node SHOULD stop using the interface attached to 1220 foreign link and use only the interface attached to the home link. 1222 6.4. Sending Binding Refresh Request 1224 When a node (home agent or correspondent node) sends a Binding 1225 Refresh Request for a particular binding created with the BID, the 1226 node SHOULD include the Binding Identifier mobility option in the 1227 Binding Refresh Request. The node MAY include multiple Binding 1228 Identifier mobility options if there are multiple bindings that need 1229 to be refreshed. 1231 6.5. Receiving Packets from Mobile Node 1233 When a node receives packets with a Home Address destination option 1234 from a mobile node, it MUST check that the care-of address that 1235 appears in the source address field of the IPv6 header is equal to 1236 one of the care-of addresses in the binding cache entry. If no 1237 binding is found, the packets MUST be discarded. The node MUST also 1238 send a Binding Error message as specified in [RFC-3775]. This 1239 verification MUST NOT be done for a Binding Update. 1241 7. Network Mobility Applicability 1243 The binding management mechanisms are the same for a mobile host that 1244 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1245 Support protocol [RFC-3963]. Therefore the extensions described in 1246 this document can also be used to support a mobile router with 1247 multiple care-of addresses. [RFC-4980] is a document for an analysis 1248 of NEMO multihoming. 1250 8. DSMIPv6 Applicability 1252 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1253 register an IPv4 care-of address instead of the IPv6 care-of address 1254 when the mobile node is attached to an IPv4-only access network. It 1255 also allows the mobile node to acquire an IPv4 home address in 1256 addition to an IPv6 home address for use with IPv4-only correspondent 1257 nodes. This section describes how the multiple care-of address 1258 registration works with IPv4 care-of and home addresses. 1260 8.1. IPv4 Care-of Address Registration 1262 The mobile node can use the extensions described in the document to 1263 register multiple care-of addresses, even if some of the care-of 1264 addresses are IPv4 addresses. 1266 Bulk registration MUST NOT be used for the initial binding 1267 registration from an IPv4 care-of address. This is because, the 1268 Binding Update and Binding Acknowledgement exchange is used to detect 1269 NAT on the path between the mobile node and the home agent. So the 1270 mobile node needs to check for a NAT between each IPv4 care-of 1271 address and the home agent. 1273 The Binding Update MUST be sent to the IPv4 home agent address by 1274 using UDP and IPv4 headers as shown in Figure 9. It is similar to 1275 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1276 used when the BID mobility option is used. 1278 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1279 UDP Header 1280 IPv6 header (src=V6HoA, dst=HAADDR) 1281 ESP Header 1282 Mobility header 1283 -Binding Update 1284 Mobility Options 1285 - Binding Identifier (IPv4 CoA) 1286 *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6] 1288 Figure 9: Initial Binding Update for IPv4 Care-of Address 1290 If a NAT is not detected, the mobile node can update the IPv4 care-of 1291 address by using bulk registration. The mobile node can register the 1292 IPv4 care-of address along with other IPv4 and IPv6 care-of 1293 addresses. Figure 10 shows the Binding Update format when the mobile 1294 node sends a Binding Update from one of its IPv6 care-of addresses. 1295 If the mobile node sends a Binding Update from IPv4 care-of address, 1296 it MUST follow the format described in Figure 9. Note that the IPv4 1297 Care-of Address must be registered by non bulk Binding registration, 1298 whenever it is changed. 1300 As shown in Figure 9, IPv4 care-of address will be appeared in 1301 Binding Identifier mobility option. The IPv4 care-of address 1302 mobility option defined in [ID-DSMIP6] MUST always be omitted. The 1303 receiver of the Binding Update message for an IPv4 care-of address 1304 MUST treat the IPv4 address stored in the Binding Identifier mobility 1305 option as the one in the IPv4 care-of address mobility option of [ID- 1306 DSMIP6]. If the IPv4 address in the Binding Identifier mobility 1307 option is different from one in the source address field in the IPv4 1308 header of the Binding Update (i.e. V4ADDR in Figure 9), the source 1309 address is used as an IPv4 care-of address. Otherwise, the IPv4 1310 address in the Binding Identifier mobility option is used as an IPv4 1311 care-of address. 1313 IPv6 header (src=Care-of Address, dst=Home Agent Address) 1314 IPv6 Home Address Option 1315 ESP Header 1316 Mobility header 1317 -Binding Update 1318 Mobility Options 1319 - Binding Identifier (IPv6/v4 CoA) 1320 - Binding Identifier (IPv6/v4 CoA) 1321 - ... 1323 Figure 10: Binding Bulk Registration for IPv4 care-of address 1325 When the home agent returns a Binding Acknowledgement for the IPv4 1326 care-of address registration, it SHOULD NOT use the IPv4 address 1327 Acknowledgement mobility option and SHOULD use only the Binding 1328 Identifier mobility option. The registration status for the IPv4 1329 Care-of address is stored in the Status field of the Binding 1330 Identifier mobility option. However, if the home agent needs to 1331 store the status value specially defined for the IPv4 address 1332 Acknowledgement mobility option, it MUST store the status value in 1333 the IPv4 address Acknowledgement mobility option and MUST NOT store 1334 it in Binding Identifier mobility option. In such case, the home 1335 agent MUST include both the IPv4 address Acknowledgement mobility 1336 option and Binding Identifier mobility option. 1338 8.2. IPv4 Home Address Management 1340 When the mobile node wants to configure an IPv4 home address in 1341 addition to the IPv6 home address, it can request for one using the 1342 IPv4 Home Address option in the Binding Update. If the home agent 1343 accepts the Binding Update, the mobile node can now register multiple 1344 care-of addresses for the IPv4 home address in addition to the IPv6 1345 home address. The mobile node MUST always use the IPv4 home address 1346 mobility option for any purposes of the IPv4 home address management. 1347 The same set of care-of addresses will be registered for both IPv6 1348 and IPv4 home addresses. The mobile node cannot bind a different set 1349 of care-of addresses to each home address. 1351 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1352 Acknowledgement option in the Binding Acknowledgement only if the 1353 mobile node had requested for an IPv4 home address in the 1354 corresponding Binding Update. The IPv4 address Acknowledgement 1355 option MUST be present before any Binding Identifier mobility option. 1356 The status field of the IPv4 address Acknowledgement option contains 1357 only the error code defined in Section 4.2.1 of [ID-DSMIP6]. The 1358 home agent MUST always include the IPv4 address Acknowledgement 1359 mobility option in the Binding Acknowledgement for the IPv4 home 1360 address registration. 1362 9. IPsec and IKEv2 interaction 1364 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1365 use of IPsec to protect signaling messages including Binding Updates, 1366 Binding Acknowledgement and return routability messages. IPsec may 1367 also be used protect all tunneled data traffic. The Mobile IPv6- 1368 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1369 setup the required IPsec security associations. The following 1370 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1371 respect to the use of IKEv2 and IPsec. 1373 o There is only one primary care-of address per mobile node. 1375 o The primary care-of address is stored in the IPsec database for 1376 tunnel encapsulation and decapsulation. 1378 o When the home agent receives a packet from the mobile node, the 1379 source address is verified against the care-of address in the 1380 corresponding binding cache entry. If the packet is a reverse 1381 tunneled packet from the mobile node, the care-of address check is 1382 done against the source address on the outer IPv6 header. The 1383 reverse tunnel packet could either be a tunneled Home Test Init 1384 message or tunneled data traffic to the correspondent node. 1386 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1387 the care-of address. The IKE SA is based on the care-of address 1388 of the mobile node. 1390 The above assumptions may not be valid when multiple care-of 1391 addresses are used by the mobile node. In the following sections, 1392 the main issues with the use of multiple care-of address with IPsec 1393 are addressed. 1395 9.1. Use of Care-of Address in the IKEv2 exchange 1397 For each home address the mobile node sets up security associations 1398 with the home agent, the mobile node must pick one care-of address 1399 and use that as the source address for all IKEv2 messages exchanged 1400 to create and maintain the IPsec security associations associated 1401 with the home address. The resultant IKEv2 security association is 1402 created based on this care-of address. 1404 If the mobile node needs to change the care-of address, it just sends 1405 a Binding Update with the care-of address it wants to use, with the 1406 corresponding Binding Identifier mobility option, and with the 'K' 1407 bit set. This will force the home agent to update the IKEv2 security 1408 association to use the new care-of address. If the 'K' bit is not 1409 supported on the mobile node or the home agent, the mobile node MUST 1410 re-establish the IKEv2 security association with the new care-of 1411 address. This will also result in new IPsec security associations 1412 being setup for the home address. 1414 9.2. Transport Mode IPsec protected messages 1416 For Mobile IPv6 signaling message protected using IPsec in transport 1417 mode, the use of a particular care-of address among multiple care-of 1418 addresses does not matter for IPsec processing. 1420 The home agent processes Mobile Prefix Discovery messages with the 1421 same rules of data packets described in Section 6.5. 1423 9.3. Tunnel Mode IPsec protected messages 1425 The use of IPsec in tunnel mode with multiple care-of address 1426 introduces a few issues that require changes to how the mobile node 1427 and the home agent send and receive tunneled traffic. The route 1428 optimization mechanism described in [RFC-3775] mandates the use of 1429 IPsec protection in tunnel mode for the Home Test Init and Home Test 1430 messages. The mobile node and the home agent may also choose to 1431 protect all reverse tunneled payload traffic with IPsec in tunnel 1432 mode. The following sections address multiple care-of address 1433 support for these two types of messages. 1435 9.3.1. Tunneled Home Test Init and Home Test messages 1437 The mobile node MAY use the same care-of address for all Home Test 1438 Init messages sent reverse tunneled through the home agent. The 1439 mobile node may use the same care-of address irrespective of which 1440 correspondent node the Home Test Init message is being sent. RFC 1441 3775 requires the home agent to verify that the mobile node is using 1442 the care-of address that is in the binding cache entry, when it 1443 receives a reverse tunneled Home Test Init message. If a different 1444 address is used as the source address, the message is silently 1445 dropped by the home agent. This document requires the home agent 1446 implementation to decapsulate and forward the Home Test Init message 1447 as long as the source address is one of the care-of addresses in the 1448 binding cache entry for the mobile node. 1450 When the home agent tunnels a Home Test message to the mobile node, 1451 the care-of address used in the outer IPv6 header is not relevant to 1452 the Home Test message. So regular IPsec tunnel encapsulation with 1453 the care-of address known to the IPsec implementation on the home 1454 agent is sufficient. 1456 9.3.2. Tunneled Payload Traffic 1458 When the mobile sends and receives multiple traffic flows protected 1459 by IPsec to different care-of addresses, the use of the correct 1460 care-of address for each flow becomes important. Support for this 1461 requires the following two considerations on the home agent. 1463 o When the home agent receives a reverse tunneled payload message 1464 protected by IPsec in tunnel mode, the source address used in the 1465 outer IPv6 header is irrelevant to IPsec, since the tunnel mode 1466 security association is based on the addresses in the inner IPv6 1467 header. Therefore, the same IPsec security association can be 1468 used for payload traffic tunneled from any of the care-of 1469 addresses. Note that the care-of address used in the reverse 1470 tunneled traffic can be different from the care-of address used as 1471 the source address in the IKEv2 exchange. However, this does not 1472 cause an issue due to the above mentioned reason. 1474 o For tunneled IPsec traffic from the home agent to the mobile node, 1475 the IPsec implementation on the home agent will not be aware of 1476 which care-of address to use when performing IPsec tunnel 1477 encapsulation. The Mobile IP stack on the home agent, based on 1478 the binding cache entries created by the mobile node, knows which 1479 care-of address the packet belonging to a particular flow needs to 1480 be tunneled to. The destination address for the outer IP header 1481 must either by conveyed dynamically per packet to the IPsec stack 1482 when it performs the encapsulation or the Mobile IPv6 stack must 1483 get access to the packet after IPsec processing is done and modify 1484 the destination address. The first option requires changes to the 1485 IPsec implementation. In the second option, there is a need for 1486 special processing in the forwarding function to replace the 1487 destination address on the outer header with the correct care-of 1488 address. The exact technique to achieve the above is 1489 implementation specific. 1491 10. Security Considerations 1493 The security considerations for securing the Binding Update and 1494 Binding Acknowledgement messages with multiple care-of address are 1495 very similar to the security considerations for securing the Binding 1496 Update and Binding Acknowledgement. Please see [RFC-3775] for more 1497 information. The Binding Update and binding Acknowledgement messages 1498 with multiple care-of addresses are securely exchanged as described 1499 in [RFC-3775], [RFC-4877] and Section 9. Additional security 1500 considerations are described below. 1502 With simultaneous binding support, it is possible for a malicious 1503 mobile node to successfully bind a number of victims' addresses as 1504 valid care-of addresses for the mobile node with its home agent. 1505 Once these addresses have been bound, the malicious mobile node can 1506 perform a re-direction attack by instructing the home agent (e.g. 1507 setting filtering rules to direct a large file transfer) to tunnel 1508 packets to the victims' addresses. Such risk is highlighted in [ID- 1509 MIP6ANALYSIS]. These attacks are possible because the care-of 1510 addresses sent by the mobile node in the Binding Update messages are 1511 not verified by the home agent, i.e., the home agent does not check 1512 if the mobile node is at the care-of address it is claiming to be. 1513 The security model for Mobile IPv6 assumes that there is a trust 1514 relationship between the mobile node and its home agent. Any 1515 malicious attack by the mobile node is traceable by the home agent. 1516 This acts as a deterrent for the mobile node to launch such attacks. 1518 Although such a risk exists in Mobile IPv6, the risk level is 1519 increased when simultaneous multiple care-of address bindings are 1520 performed. In Mobile IPv6, a mobile node can only have a single 1521 care-of address binding per home address at a given time. However, 1522 for simultaneous multiple care-of address bindings, a mobile node can 1523 have more than one care-of address binding per home address at a 1524 given time. This implies that a mobile node using simultaneous 1525 binding support can effectively bind more than a single victim's 1526 address. Another difference is the degree of risk involved. In the 1527 single care-of address binding case, once the re-direction attack is 1528 initiated, a malicious mobile node would be unable to use its home 1529 address for communications (such as to receive control packets 1530 pertaining to the file transfer). However, in the simultaneous 1531 binding support case, a malicious mobile node could bind a valid 1532 care-of address in addition to multiple victims addresses. This 1533 valid care-of address could then be used by the malicious mobile node 1534 to set up flow filtering rules at its home agent, thereby controlling 1535 and/or launching new re-direction attacks. 1537 Thus, in view of such risks, it is advisable for a home agent to 1538 employ some form of care-of address verification mechanism before 1539 using the care-of addresses as a valid routing path to a mobile node. 1540 These mechanisms are out-of scope for this document. 1542 In the binding registration of Mobile IPv6, a care-of address is 1543 always verified its reachability by a home agent. This reachability 1544 test may decrease the above risks. However, when bulk registration 1545 is used, a home agent cannot verify reachability of care-of addresses 1546 carried in a Binding Identifier mobility option. Therefore, the home 1547 agent can choose to reject bulk registration by using [MCOA BULK 1548 REGISTRATION PROHIBITED] in a Binding Acknowledgement. 1549 Alternatively, when a mobile node first registers a care-of address, 1550 it uses the individual binding updates for the first appeared care-of 1551 address. During the initial binding registration, a home agent can 1552 verify the address reachability for that given care-of address. 1553 After that, the mobile node uses bulk registration to refresh the 1554 care-of address. 1556 11. IANA Considerations 1558 The following Extension Types MUST be assigned by IANA: 1560 o Binding Identifier mobility option type: This must be assigned 1561 from the same space as mobility option in [RFC-3775]. 1563 o New Successful Status of Binding Acknowledgement: This status code 1564 must be assigned from the same space as binding acknowledgement 1565 status codes in [RFC-3775]. 1567 * MCOA NOTCOMPLETE (TBD) 1569 * MCOA RETURNHOME WO/NDP (TBD) 1571 o New Unsuccessful Status of Binding Acknowledgement: These status 1572 codes must also be assigned from the same space as Binding 1573 Acknowledgement status codes in [RFC-3775]. 1575 * MCOA MALFORMED (TBD) 1577 * MCOA NON-MCOA BINDING EXISTS (TBD) 1579 * MCOA PROHIBITED(TBD) 1581 * MCOA UNKNOWN COA(TBD) 1583 * MCOA BULK REGISTRATION PROHIBITED (TBD) 1585 * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD) 1587 12. Acknowledgements 1589 The authors would also like to thank Masafumi Aramoto, Keigo Aso, 1590 Julien Charbon, Tero Kauppinen, Benjamin Lim, Martti Kuparinen, 1591 Romain Kuntz, Heikki Mahkonen, Nicolas Montavont, Chan-Wah Ng for 1592 their discussions and inputs. Thanks to Susumu Koshiba, Hiroki 1593 Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi 1594 Watari and Jun Murai for earlier work on this subject. 1596 13. References 1598 13.1. Normative References 1600 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1601 Requirement Levels", BCP 14, RFC 2119, March 1997. 1603 [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, 1604 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 1605 2007.. 1607 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1608 in IPv6", RFC 3775, June 2004. 1610 [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with 1611 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 1613 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1614 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1615 January 2005. 1617 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1618 and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in 1619 progress), December 2008. 1621 [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June 1622 2008. 1624 13.2. Informative References 1626 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1627 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1628 Interfaces and Global Addresses", 1629 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1630 progress), May 2008. 1632 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1633 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1635 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1636 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1637 draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. 1639 [ID-FLOWBINDING] H. Soliman, N. Montavont, N. Fikouras, and K. 1640 Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", 1641 draft-ietf-mext-flow-binding-01 (Work in progress), February 2009. 1643 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1644 RFC 3753, June 2004. 1646 [RFC-4306] C. Kaufman (Editor), "Internet Key Exchange (IKEv2) 1647 Protocol", RFC 4306, December 2005. 1649 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1650 Terminology", RFC 4885, July 2007. 1652 Authors' Addresses 1654 Ryuji Wakikawa (Editor) 1655 TOYOTA InfoTechnology Center Co., Ltd. 1657 Email: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com) 1659 Vijay Devarapalli 1660 Wichorus 1662 Email: vijay@wichorus.com 1664 George Tsirtsis 1665 Qualcomm 1667 Email: Tsirtsis@gmail.com 1669 Thierry Ernst 1670 INRIA 1672 Email: thierry.ernst@inria.fr 1674 Kenichi Nagami 1675 INTEC NetCore Inc. 1677 Email: nagami@inetcore.com