idnits 2.17.1 draft-ietf-monami6-multiplecoa-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1626. 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 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 (November 4, 2008) is 5645 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 972, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1122, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1163, 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-05 -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: May 8, 2009 Wichorus 6 T. Ernst 7 INRIA 8 K. Nagami 9 INTEC NetCore 10 November 4, 2008 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-10.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of 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 May 8, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 According to the current Mobile IPv6 specification, a mobile node may 47 have several care-of addresses, but only one, called the primary 48 care-of address, that can be registered with its home agent and the 49 correspondent nodes. However, for matters of cost, bandwidth, delay, 50 etc, it is useful for the mobile node to get Internet access through 51 multiple accesses simultaneously, in which case the mobile node would 52 be configured with multiple active IPv6 care-of addresses. This 53 document proposes extensions to the Mobile IPv6 protocol to register 54 and use multiple care-of addresses. The extensions proposed in this 55 document can be used by Mobile Routers using the NEMO (Network 56 Mobility) Basic Support protocol as well. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11 67 4.1. Binding Cache Structure and Binding Update List . . . . . 11 68 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 11 69 4.3. New Status Values for Binding Acknowledgement . . . . . . 13 71 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15 72 5.1. Management of Care-of Address(es) and Binding 73 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 15 74 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15 75 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 16 76 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 17 77 5.5. Returning Home: Using Single Interface . . . . . . . . . . 17 78 5.5.1. Using only Interface attached to the Home Link . . . . 17 79 5.5.2. Using only Interface attached to the Visited Link . . 17 80 5.6. Returning Home: Simultaneous Home and Visited Link 81 Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 82 5.6.1. Problems of Simultaneous Home and Foreign 83 Attachments . . . . . . . . . . . . . . . . . . . . . 18 84 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 18 85 5.6.3. Sending Deregistration Binding Update . . . . . . . . 20 86 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 20 87 5.6.5. Sending Packets from the Home Link . . . . . . . . . . 22 88 5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 22 89 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 23 90 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 24 91 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 24 93 6. Home Agent and Correspondent Node Operation . . . . . . . . . 25 94 6.1. Searching Binding Cache with Binding Identifier . . . . . 25 95 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 25 96 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 28 97 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 28 99 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 29 101 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 30 102 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 30 103 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 31 105 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 32 106 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 32 107 9.2. Transport Mode IPsec protected messages . . . . . . . . . 33 108 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 33 109 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 33 110 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 34 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 116 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38 120 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 123 Intellectual Property and Copyright Statements . . . . . . . . . . 41 125 1. Introduction 127 A mobile node may use various types of network interfaces to obtain 128 durable and wide area network connectivity. This is increasingly 129 become true with mobile nodes having multiple interfaces such as 130 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for 131 and benefits of using multiple points of attachment are discussed in 132 [ID-MOTIVATION]. When a mobile node with multiple interfaces uses 133 Mobile IPv6 [RFC-3775] for mobility management, it cannot use its 134 multiple interfaces to send and receive packets while taking 135 advantage of session continuity provided by Mobile IPv6. This is 136 because Mobile IPv6 allows the mobile node to only bind one care-of 137 address at a time with its home address. See [ID-MIP6ANALYSIS] on a 138 further analysis of using multiple interfaces and addresses with 139 Mobile IPv6. 141 This document proposes extensions to Mobile IPv6 to allow a mobile 142 node to register multiple care-of addresses for a home address and 143 create multiple binding cache entries. A new Binding Identification 144 (BID) number is created for each binding the mobile node wants to 145 create and sent in the binding update. The home agent that receives 146 this Binding Update creates separate binding for each BID. The BID 147 information is stored in the corresponding binding cache entry. The 148 BID information can now be used to identify individual bindings. The 149 same extensions can also be used in Binding Updates sent to the 150 correspondent nodes. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC-2119]. 158 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 159 [RFC-4885]. In addition or in replacement of these, the following 160 terms are defined or redefined: 162 Binding Identification number (BID) 164 The BID is an identification number used to distinguish multiple 165 bindings registered by the mobile node. Assignment of distinct 166 BIDs allows a mobile node to register multiple binding cache 167 entries for a given home address. The BIDs assigned to a same 168 home address MUST NOT be duplicated at a time. Zero and negative 169 values MUST NOT be used. Each BID is generated and managed by a 170 mobile node. The BID is stored in the Binding Update List and is 171 sent by the mobile node in the Binding Update. A mobile node MAY 172 change the value of a BID at any time according to its 173 administrative policy, for instance to protect its privacy. An 174 implementation must carefully assign the BID so as to keep using 175 the same BID for the same binding even when the status of the 176 binding is changed. More details can be found in Section 5.1. 178 Binding Identifier Mobility Option 180 The Binding Identifier mobility option is used to carry the BID 181 information. 183 Bulk Registration 185 A mobile node can register multiple bindings at once by sending a 186 single Binding Update. A mobile node can also replace some or all 187 the bindings available at the home agent with the new bindings by 188 using the bulk registration. Bulk registration is supported only 189 for home registration (i.e. with the home agent) as explained in 190 Section 5.3. A mobile node MUST NOT perform bulk registration 191 mechanism described in this specification with a correspondent 192 node. 194 3. Protocol Overview 196 A new extension called the Binding identification number (BID) is 197 introduced to distinguish between multiple bindings pertaining to the 198 same home address. If a mobile node configures several IPv6 global 199 addresses on one or more of its interfaces, it can register these 200 addresses with its home agent as care-of addresses. If the mobile 201 node wants to register multiple bindings, it MUST generate a BID for 202 each care-of address and store the BID in the binding update list. A 203 mobile node can manipulate each binding independently by using the 204 BIDs. The mobile node then registers its care-of addresses by 205 sending a Binding Update with a Binding Identifier mobility option. 206 The BID is included in the Binding Identifier mobility option. After 207 receiving the Binding Update with a Binding Identifier mobility 208 option, the home agent MUST copy the BID from the Binding Identifier 209 mobility option to the corresponding field in the binding cache 210 entry. If there is an existing binding cache entry for the mobile 211 node, and if the BID in the Binding Update does not match the one 212 with the existing entry, the home agent MUST create a new binding 213 cache entry for the new care-of address and BID. The mobile node can 214 register multiple care-of addresses either independently in 215 individual Binding Updates or multiple at once in a single Binding 216 Update. 218 If the mobile host wishes to register its binding with a 219 correspondent node, it must perform return routability operations as 220 described in [RFC-3775]. This includes managing a Care-of Keygen 221 token per care-of address and exchanging CoTi and CoT message with 222 the correspondent node for each care-of address. The mobile node MAY 223 use the same BID that it used with the home agent for a particular 224 care-of address. For protocol simplicity, bulk registration to 225 correspondent nodes is not supported in this document. This is 226 because the Return Routability mechanism introduced in [RFC-3775] 227 cannot be easily extended to verify multiple care-of addresses stored 228 in a single Binding Update. 230 Figure 1 illustrates the configuration where the mobile node obtains 231 multiple care-of addresses at foreign links. The mobile node can 232 utilize all the care-of addresses. In Figure 1, the home address of 233 the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 234 different interfaces and possibly acquires care-of addresses 1-3 235 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to 236 each care-of address. 238 +----+ 239 | CN | 240 +--+-+ 241 | 242 +---+------+ +----+ 243 +------+ Internet |----------+ HA | 244 | +----+---+-+ +--+-+ 245 CoA2| | | | Home Link 246 +--+--+ | | ------+------ 247 | MN +========+ | 248 +--+--+ CoA1 | 249 CoA3| | 250 +---------------+ 252 Binding Cache Database: 253 home agent's binding (Proxy neighbor advertisement is active) 254 binding [2001:db8::EUI care-of address1 BID1] 255 binding [2001:db8::EUI care-of address2 BID2] 256 binding [2001:db8::EUI care-of address3 BID3] 257 correspondent node's binding 258 binding [2001:db8::EUI care-of address1 BID1] 259 binding [2001:db8::EUI care-of address2 BID2] 260 binding [2001:db8::EUI care-of address3 BID3] 262 Figure 1: Multiple Care-of Address Registration 264 If the mobile node decides to act as a regular mobile node compliant 265 with [RFC-3775], it sends a Binding Update without any Binding 266 Identifier mobility options. The receiver of the Binding Update 267 deletes all the bindings registering with a BID and registers only a 268 single binding for the mobile node. Note that the mobile node can 269 continue using the BID even if it has only a single binding that is 270 active. 272 Binding cache lookup is done based on the home address and BID 273 information if a BID is available. This is different from RFC 3775, 274 where only the home address is used for binding cache lookup. 275 Binding cache lookup is operated for either protocol signaling and 276 data packets. For the protocol signaling such as a binding update, 277 BID should be always carried by a BID sub-option in a protocol 278 signaling. Therefore, a correspondent binding cache that matches the 279 specified BID MUST be found from the binding cache database. On the 280 other hand, for the data packets, no BID information is carried in a 281 packet. The binding cache lookup may involve policy or flow filters 282 to retrieve a correspondent BID per packet in cases where some policy 283 or flow filters are used to direct a certain packet or flow to a 284 particular care-of address. However, the binding cache lookup using 285 policy or flow filters is out of scope for this document. If no such 286 mechanism is available and no BID is found for a packet, a node 287 SHOULD use the binding which was last verified by receiving data 288 packets or signaling from the mobile node. In case the binding cache 289 lookup for data packets, using the combination of home address and 290 BID, does not return a valid binding cache entry, the home agent 291 SHOULD perform the lookup based on only the home address as described 292 in [RFC-3775]. 294 The mobile node may return to the home link through one of its 295 interfaces. There are two options possible for the mobile node when 296 its returns home. Section 5.6 and Section 5.5.1 describe the 297 returning home procedures in more detail. 299 1. The mobile node uses only the interface with which it attaches to 300 the home link. This is illustrated in Figure 2. It de-registers 301 all bindings with the home agent related to all care-of 302 addresses. The interfaces still attached to the visited link(s) 303 are no longer going to be receiving any encapsulated traffic from 304 the home agent. On the other hand, the mobile node can continue 305 communicating with the correspondent node from the other 306 interfaces attached to foreign links by using route optimization. 307 Even if the mobile node is attached to the home link, it can 308 still send Binding Updates for other active care-of addresses 309 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 310 node has bindings, packets are routed to each Care-of Addresses 311 directly. 313 +----+ 314 | CN | 315 +--+-+ 316 | 317 +---+------+ +----+ 318 +------+ Internet |----------+ HA | 319 | +----+-----+ +--+-+ 320 CoA2| | | Home Link 321 +--+--+ | --+---+------ 322 | MN +========+ | 323 +--+--+ CoA1 | 324 | | 325 +---------------------------+ 327 Binding Cache Database: 328 home agent's binding 329 none 330 correspondent node's binding 331 binding [2001:db8::EUI care-of address1 BID1] 332 binding [2001:db8::EUI care-of address2 BID2] 334 Figure 2: Using only Interface Attached to Home Link 336 2. The mobile node may simultaneously use both the interface 337 attached to the home link and the interfaces still attached to 338 the visited link(s) as shown in Figure 3. There are two possible 339 topologies depending on whether the home agent is only router on 340 the home link or not. The operation of Neighbor Discovery [RFC- 341 4861] is different in the two topologies. More details can be 342 found in Section 5.6. The home agent and the correspondent node 343 have the binding entries listed in Figure 3 in their binding 344 cache database in both topologies. The home agent also knows 345 that the mobile node is attached to the home link. All the 346 traffic from the Internet is intercepted by the home agent first 347 and routed to either the interface attached to the home link or 348 the one of the foreign links. How the home agent decides to 349 route a particular flow to the interface attached to the home 350 link or foreign link is out of scope in this document. 352 Topology-a) 353 +----+ 354 | CN | 355 +--+-+ 356 | 357 +---+------+ +----+ 358 +------+ Internet |----------+ HA | 359 | +----+-----+ +--+-+ 360 CoA2| | | Home Link 361 +--+--+ | --+---+------ 362 | MN +========+ | 363 +--+--+ CoA1 | 364 | | 365 +---------------------------+ 367 Topology-b) 368 +----+ 369 | CN | 370 +--+-+ 371 | 372 +---+------+ Router +----+ 373 +------+ Internet |-------R | HA | 374 | +----+-----+ | +--+-+ 375 CoA2| | | | Home Link 376 +--+--+ | --+-+-------+------ 377 | MN +========+ | 378 +--+--+ CoA1 | 379 | | 380 +---------------------------+ 382 Binding Cache Database: 383 home agent's binding 384 binding [2001:db8::EUI care-of address1 BID1] 385 binding [2001:db8::EUI care-of address2 BID2] 386 correspondent node's binding 387 binding [2001:db8::EUI care-of address1 BID1] 388 binding [2001:db8::EUI care-of address2 BID2] 390 Figure 3: Simultaneous Home and Visited Link Operation 392 4. Mobile IPv6 Extensions 394 This section summarizes the extensions to Mobile IPv6 necessary for 395 manage multiple bindings. 397 4.1. Binding Cache Structure and Binding Update List 399 The BID is required to be stored in the binding cache and binding 400 update list structure. 402 The sequence number value MUST be shared among all the binding update 403 list entries related to binding updates sent to a particular home 404 agent or correspondent node. Whenever a mobile node sends either 405 individual or bulk binding update, the sequence number is 406 incremented. When a home agent receives an individual BU, it should 407 update the sequence number for all the bindings for a particular 408 mobile node with the sequence number in the received BU. 410 4.2. Binding Identifier Mobility Option 412 The Binding Identifier mobility option is included in the Binding 413 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 414 Test Init and Care-of Test message. The Binding Identifier Mobility 415 Option has an alignment requirement of 2n if the Care-of Address 416 field is not present. Otherwise, it has the alignment requirement of 417 8n + 2. 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = TBD | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Binding ID (BID) | Status |O|H| Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 426 + + 427 : IPv4 or IPv6 care-of address (CoA) : 428 + + 429 +---------------------------------------------------------------+ 431 Figure 4: BID Mobility Option 433 Type 435 Type value for Binding Identifier is TBD 437 Length 439 8-bit unsigned integer. Length of the option, in octets, 440 excluding the Type and Length fields. It MUST be set to either 4, 441 12, or 20 depending on the care-of address field. When the 442 care-of address is not carried by this option, the length value 443 MUST be set to 4. If the IPv4 care-of address is stored in the 444 care-of address field, the length MUST be 12. Otherwise, the 445 Length value MUST be set to 20 for IPv6 care-of address. 447 Binding ID (BID) 449 The BID which is assigned to the binding indicated by the care-of 450 address in the Binding Update or the BID mobility option. The BID 451 is a 16-bit unsigned integer. The value of zero is reserved and 452 MUST NOT be used. 454 Status 456 The Status field is an 8-bit unsigned integer. When the Binding 457 Identifier mobility option is included in a Binding 458 Acknowledgement, this field overwrites the status field in the 459 Binding Acknowledgement only for this BID. If this field is set 460 to zero, the receiver ignores this field and uses the registration 461 status stored in the Binding Acknowledgement message. The 462 receiver MUST ignore this field if the Binding Identifier mobility 463 option is not carried within either the Binding Acknowledgement or 464 the Care-of Test messages. The possible status codes are the same 465 as the status codes of Binding Acknowledgement. This Status field 466 is also used to carry error information related to the care-of 467 address test in the Care-of Test message. 469 Overwrite (O) flag 471 When this flag is set, all the binding cache entries for a mobile 472 node are replaced by new entries registering with this binding 473 update message. This flag is only used when BID Mobility Option 474 is carried with Binding Update. 476 Simultaneous Home and Foreign Binding (H) flag 478 This flag indicates that the mobile node registers multiple 479 bindings to the home agent while is attached to the home link. 480 This flag is valid only for a Binding Update sent to the home 481 agent. 483 Reserved 485 5 bits Reserved field. The value MUST be initialized to zero by 486 the sender, and MUST be ignored by the receiver. 488 Care-of Address 490 If a Binding Identifier mobility option is included in a Binding 491 Update, either IPv4 or IPv6 care-of address for the corresponding 492 BID can be stored in this field. If no address is specified in 493 this field, the length of this field MUST be zero (i.e. not 494 appeared in the option). If no address is specified in this 495 field, a care-of address is taken from the source address of the 496 IPv6 header. If the option is included in any other messages than 497 a Binding Update, the length of this field MUST be also zero. 499 4.3. New Status Values for Binding Acknowledgement 501 New status values for the status field in a Binding Acknowledgement 502 are defined for handling the multiple Care-of Addresses registration: 504 MCOA NOTCOMPLETE (TBD less than 128) 506 In bulk registration, not all the binding identifier mobility 507 option are successfully registered. Some of them are rejected. 508 The error status value of the failed mobility option is 509 individually stored in the status field of the binding identifier 510 mobility option. 512 MCOA RETURNHOME WO/NDP (TBD less than 128) 514 When a mobile node returns home, it MUST NOT use NDP for the home 515 address on the home link. This is explained in more detail in 516 Section 5.6 518 MCOA MALFORMED (TBD more than 128) 520 Registration failed because Binding Identifier mobility option was 521 not formatted correctly. 523 MCOA BID CONFLICT (TBD more than 128) 525 The home agent cannot cache both a regular binding and a BID 526 extended binding simultaneously. It returns this status value 527 when the received binding conflicts with the existing binding 528 cache entry(ies). 530 MCOA PROHIBITED(TBD more than 128) 532 It implies the multiple care-of address registration is 533 administratively prohibited. 535 MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) 537 Bulk binding registration is not either permitted or supported. 538 Note that the bulk registration is optional procedure and might 539 not be available on a home agent. 541 MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) 543 Simultaneous home and foreign attachment is neither supported nor 544 permitted. 546 5. Mobile Node Operation 548 5.1. Management of Care-of Address(es) and Binding Identifier(s) 550 There are two cases when a mobile node might acquire several care-of 551 addresses. A mixture of the two cases is also possible. Note that a 552 mobile node can use BID regardless of the number of interfaces and 553 care-of addresses. Whether a mobile node uses BID or not is 554 determined by a local configuration. 556 1. A mobile node may be using several physical network interfaces 557 and acquires a care-of address on each of its interfaces. 559 2. A mobile node uses a single physical network interface, but 560 receives advertisements for multiple prefixes on the link the 561 interface is attached to. This will result in the mobile node 562 configuring several global addresses on the interface from each 563 of the announced prefixes. 565 The difference between the above two cases is only in the number of 566 physical network interfaces and therefore irrelevant in this 567 document. What is of significance is the fact that the mobile node 568 has several addresses it can use as care-of addresses. 570 A mobile node assigns a BID to each care-of address when it wants to 571 register them simultaneously with its home address. The BID MUST be 572 unique for a given home address and care-of address pair. The value 573 should be an integer between 1 and 65535. Zero value MUST NOT be 574 used as BIDs. If a mobile node has only one care-of address, the 575 assignment of a BID is not needed until it has multiple care-of 576 addresses to register with, at which time all of the care-of 577 addresses MUST be mapped to BIDs. 579 5.2. Binding Registration 581 For the multiple Care-of Addresses registration, the mobile node MUST 582 include a Binding Identifier mobility option(s) in the Binding Update 583 as shown in Figure 5. The BID is copied from a corresponding Binding 584 Update List entry to the BID field of the Binding Identifier mobility 585 option. When IPsec ESP is used for protecting the Binding Update, 586 the care-of address can be carried in the Care-of Address field of 587 the Binding Identifier mobility option. If this is done, the 588 alternate care-of address option MUST NOT be included in the Binding 589 Update. For binding registration to a correspondent node, the mobile 590 node MUST have both active Home and Care-of Keygen tokens for Kbm 591 (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. 592 The care-of Keygen tokens MUST be maintained for each care-of address 593 that the mobile node wants to register to the correspondent node. 595 The Binding Update to the correspondent node is protected by the 596 Binding Authorization Data mobility option that is placed after the 597 Binding Identifier mobility option. 599 IPv6 header (src=CoA, dst=HA) 600 IPv6 Home Address Option 601 ESP Header* 602 Mobility header 603 Binding Update 604 Mobility Options 605 Binding Identifier mobility option 606 Binding Authorization mobility option+ 607 (*) if necessary, for home registration 608 (+) if necessary, for route optimization 610 Figure 5: Binding Update for Binding Registration 612 If the mobile node wants to replace existing registered bindings on 613 the home agent with the single binding in the sent Binding Update, it 614 sets the 'O' flag. Section 6.2 describes this registration procedure 615 in detail. 617 5.3. Bulk Registration 619 Bulk registration is an optimization for binding multiple care-of 620 addresses to a home address using a single Binding Update. This is 621 very useful if the mobile node, for instance, does not want to send a 622 lot of signaling messages through an interface where the bandwidth is 623 scarce. This document specifies bulk registration only for the 624 mobile node's home registration. A mobile node performing bulk 625 registration with a correspondent node is out of scope. 627 To use bulk registration, the mobile node includes a Binding 628 Identifier Mobility option for each BID and Care-of address pair it 629 wants to register in the same Binding Update message. This is shown 630 in Figure 6. The rest of the fields and options in the Binding 631 Update such as Lifetime, Sequence Number, and the flags in the 632 Binding Update are common across all care-of addresses. The 633 alternate care-of address option MUST NOT be used. 635 IPv6 header (src=CoA, dst=HA) 636 IPv6 Home Address Option 637 ESP Header 638 Mobility header 639 Binding Update 640 Mobility Options 641 Binding Identifier mobility options (CoA) 643 Figure 6: Binding Update for Bulk Registration 645 If the mobile node wants to replace existing registered bindings on 646 the home agent with the multiple bindings in the sent Binding Update, 647 it sets the 'O' flag. 649 5.4. Binding De-Registration 651 When a mobile node decides to delete all the bindings for its home 652 address, it sends a regular de-registration Binding Update with 653 lifetime set to zero as defined in [RFC-3775]. The Binding 654 Identifier mobility option is not required. 656 If a mobile node wants to delete a particular binding(s) from its 657 home agent and correspondent nodes, the mobile node sends a Binding 658 Update with lifetime set to zero and includes a Binding Identifier 659 mobility option(s) with the BID(s) it wants to de-register. The 660 receiver will remove only the care-of address(es) that match(es) the 661 specified BID(s). The care-of addresses field in each mobility 662 option SHOULD be omitted by the sender (i.e. the field does not 663 appear in the option) and MUST be ignored by the receiver. This is 664 because the receiver will remove the binding that matches the 665 specified BID. 667 5.5. Returning Home: Using Single Interface 669 The mobile node may return to the home link, by attaching to the home 670 link through one of its interfaces. When the mobile node wants to 671 return home, it should be configured with information on what 672 interface it needs to use. 674 5.5.1. Using only Interface attached to the Home Link 676 The mobile node returns home and de-registers all the bindings as 677 shown in Figure 2 and as defined in [RFC-3775]. De-registering all 678 the bindings is the same as binding de-registration from foreign link 679 described in Section 5.4. After the de-registration step, all the 680 packets routed by the home agent are only forwarded to the interface 681 attached to the home link, even if there are other active interfaces 682 attached to the visited link(s). While the mobile node de-registers 683 all the bindings from the home agent, it may continue registering 684 bindings for interface(s) attached to visited link(s) to the 685 correspondent node as shown in Figure 2. 687 5.5.2. Using only Interface attached to the Visited Link 689 The mobile node returns home in physically and shuts down the 690 interface attached to the home link. As a result, a mobile node does 691 not return home even though it attaches to the home link by one of 692 interfaces. Following procedures should be taken by the mobile node. 693 Before shutting down the interface, any binding for the care-of 694 address previously associated with the interface should be deleted. 695 To delete the binding cache entry, the mobile node SHOULD send a de- 696 registration Binding Update with the lifetime set to zero and include 697 the corresponding BID information. If the mobile node does not send 698 a de-registration Binding Update, the binding for the care-of address 699 previously assigned to the interface remains at the home agent until 700 its lifetime expires. 702 In this scenario, despite the fact that the mobile node is connected 703 to its home link, all of its traffic is sent and received via the 704 home agent and its foreign links. 706 5.6. Returning Home: Simultaneous Home and Visited Link Operation 708 5.6.1. Problems of Simultaneous Home and Foreign Attachments 710 The mobile node returns home and continues using all the interfaces 711 attached to both foreign and home links as shown in Figure 3. The 712 mobile node indicates this by setting the 'H' flag in the BID 713 mobility option as defined below. There are additional requirements 714 on the Returning Home procedures for possible Neighbor Discovery 715 states conflicts at the home link. 717 In [RFC-3775], the home agent intercepts packets meant for the mobile 718 node using the Proxy Neighbor Discovery [RFC-4861] while the mobile 719 node is away from the home link. When the mobile node returns home, 720 the home agent deletes the binding cache and stops proxying for the 721 home address so that a mobile node can configure its home address on 722 the interface attached to the home link. In this specification, a 723 mobile node may return home, configure the home address on the 724 interface attached to the home link, but still use the interfaces 725 attached to the foreign links. In this case, a possible conflict 726 arises when the both the home agent and the mobile node try to defend 727 the home address. If the home agent stops proxying for the home 728 address, the packets are always routed to the interface attached to 729 the home link and are never routed to the interfaces attached to the 730 visited links. It is required to avoid the conflict between the home 731 agent and the mobile node, while still allowing the simultaneous use 732 of home and foreign links. The following describes the mechanism for 733 achieving this. 735 5.6.2. Overview and Approach 737 In this specification, the home agent MUST intercept all the packets 738 meant for the mobile node and decide whether to send the traffic 739 directly to the home address on the link or tunnel to the care-of 740 address. The home agent intercepts all the packets even when the 741 mobile node is attached to the home link through one of its 742 interfaces. The home agent would make this decision based on the 743 type of flow. How to make this decision is out of scope in this 744 document. 746 Two scenarios are illustrated in Figure 3, depending on whether the 747 Home Agent is the only router at the home link or not. The 748 difference is on who defends the home address by (Proxy) Neighbor 749 Discovery on the home link. 751 1. Mobile node defends the home address by the regular Neighbor 752 Discovery Protocol (illustrated as topology-a in Figure 3). The 753 home agent is the only router on the home link. Therefore the 754 home agent is capable of intercepting packets without relying on 755 the proxy Neighbor Discovery protocol and the mobile node can 756 manage the Neighbor Cache entry of the home address on the home 757 link as a regular IPv6 node.　However, there is one 758 limitation of this scenario. If a correspondent node is located 759 at the home link, the home agent may not intercept the packets 760 destined to the mobile node. These packets are routed only via 761 the home link, but this is most optimized path for the mobile 762 node to communicate with nodes on the home link. 764 2. If there are other routers on the home link apart from the home 765 agent, then it cannot be guaranteed that all packets meant for 766 the mobile node are routed to the home agent. In this case, the 767 mobile node MUST NOT operate Neighbor Discovery protocol for the 768 home address on the home link. This allows the home agent to 769 keep using proxy neighbor discovery and thus it keeps receiving 770 all the packets sent to the mobile node's home address. If the 771 home agent, according to its local policy, needs to deliver 772 packets to the mobile node over the home link, an issue arises 773 with respect to how the home agent discovers the mobile node's 774 link local address. This specification uses Link-layer Address 775 (LLA) Option defined in [RFC-5268] in order to carry the mobile 776 node's link-layer address in the Binding Update. Likewise, the 777 mobile node would also know the link-layer address of the default 778 router address to send packets from the home link without 779 Neighbor Discovery. The link-layer address is used to transmit 780 packets from and to the mobile node on the home link. The 781 packets are transmitted without the Neighbor Discovery protocol 782 by constructing the link-layer header manually. This operation 783 is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a 784 deregistration binding update to the home agent's link-layer 785 address in returning home operation. 787 5.6.3. Sending Deregistration Binding Update 789 o As soon as a mobile node returns home, it sends a de-registration 790 Binding Update to the home agent from the interface attached to 791 the home link. 793 o The mobile node MUST include the BID mobility option specifying 794 the BID the mobile node had previously associated with the 795 interface attached to the home link. The 'H' flag MUST be set in 796 the BID mobility option. For the binding deregistration, a mobile 797 node SHOULD NOT store a care-of address in the Care-of Address 798 field of the BID mobility option. The receive, the home agent, 799 can match the removed binding with BID value in the BID mobility 800 option. If the mobile node has to remove multiple bindings 801 simultaneously, it contains multiple BID mobility options with O 802 flag set. When the 'H' flag is set, the home agent recognizes 803 that the mobile node wants to continue using interfaces attached 804 to both home and visited links. Note that H flag MUST be set for 805 all the binding updates sent from the mobile node (ex. Binding 806 Update for the interface(s) attached to the foreign link(s)). If 807 the home agent does not allow this scenario, it MUST send a 808 Binding Acknowledgement with the status code [MCOA SIMULTANEOUS 809 HOME AND FOREIGN PROHIBITED] set. 811 o The mobile node SHOULD include the Link-layer Address (LLA) Option 812 [RFC-5268] to notify the mobile node's link-layer address to the 813 home agent, too. The option code of the Link-layer Address (LLA) 814 option MUST be set to '2' (Link-layer Address of the mobile node). 815 This link-layer address is required for the home agent to send the 816 Binding Acknowledgement and to forward the mobile node's packet. 818 o According to [RFC-3775], the mobile node MUST start responding to 819 Neighbor Solicitation for its home address right after it sends 820 the deregistration Binding Update to the home agent. However, in 821 this specification, the mobile node MUST NOT respond to Neighbor 822 Solicitation before receiving a Binding Acknowledgement, since the 823 home agent may continue proxying for the home address. If the 824 mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value 825 in the received Binding Acknowledgment, it MUST NOT respond to 826 Neighbor Solicitation even after the Binding Acknowledgement. 828 5.6.4. Sending Binding Acknowledgement 830 o When the home agent sends the Binding Acknowledgement after 831 successfully processing the binding de-registration, it MUST set 832 the status value to either 0 [Binding Update Accepted] or to [MCOA 833 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 834 Acknowledgment depending on home agent configuration at the home 835 link. The new values are: 837 * Binding Update Accepted (0): NDP is permitted for the home 838 address at the home link. This is regular returning home 839 operation of [RFC-3775] 841 * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home 842 address at the home link 844 If the binding update is rejected, the appropriate error value 845 MUST be set to the status field. In this case, the home agent 846 operation is same as [RFC-3775]. 848 o Only if the home agent is certainly the only router in the home 849 link, it MAY turn off Neighbor Discovery for the requested home 850 address and responds with the [Binding Update Accepted] status 851 value to the mobile node. Since the mobile node will not reply to 852 Neighbor Solicitation for the home address before receiving the 853 Binding Acknowledgement, the home agent SHOULD use the link-layer 854 address carried by the Link Layer Address option [RFC-5268] in the 855 received Binding Update. After the completion of the binding 856 deregistration, the mobile node starts regular Neighbor Discovery 857 operations for the home address on the home link. The neighbor 858 cache entry for the home address is created by the regular 859 exchange of Neighbor Solicitation and Neighbor Advertisement. 861 o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] 862 value in the Status field of the BID mobility option. The home 863 agent learns the mobile node's link-layer address by receiving the 864 link-layer address option carried by the Binding Update. It 865 stores the link-layer address as a neighbor cache entry for the 866 mobile node so that it can send the packets to the mobile node's 867 link-layer address. 869 o Note that the use of proxy Neighbor Discovery is easier way to 870 intercept the mobile nodes' packets instead of IP routing in some 871 deployment scenarios. Therefore, even if a home agent is the only 872 router, it is an implementation and operational choice whether the 873 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 874 WO/NDP]. 876 o If BID option is not included in the Binding Acknowledgement, the 877 home agent might not recognize the simultaneous home and foreign 878 attachment. The home agent might have processed the de- 879 registration Binding Update as a regular de-registration as 880 described in [RFC-3775] and deletes all the registered binding 881 cache entries for the mobile node. Thus, the mobile node SHOULD 882 stop using the interface attached to foreign link and use only the 883 interface attached to the home link. 885 5.6.5. Sending Packets from the Home Link 887 o When the mobile node receives the Binding Acknowledgement with the 888 status value 'Binding Update Accepted' and the BID option, it can 889 configure its home address to the interface attached to the home 890 link and start operating Neighbor Discovery for the home address 891 on the home link. Packets can be transmitted from and to the 892 mobile node as if the mobile node is a regular IPv6 node. 894 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 895 the Binding Acknowledgement, it MUST NOT operate Neighbor 896 Discovery for the home address. When the mobile node sends 897 packets from the interface attached to the home link, it MUST 898 learn the link-layer address of the next hop (i.e. default router 899 of the mobile node). A mobile node learns the default router's 900 link-layer address from a Source Link-Layer Address option in 901 Router Advertisements. The mobile node sends packets directly to 902 the default router's link-layer address. This is done by 903 constructing the packet including link-layer header with the 904 learned link-layer address of the default router. The home agent 905 also forwards the packet to the mobile node on the home link by 906 using the mobile node's link-layer address. The link-layer 907 address SHOULD be cached when the home agent received the 908 deregistration Binding Update message. Note that the default 909 router MUST NOT cache the mobile node's link-layer address as a 910 neighbor cache when it forwards the packet from the mobile node to 911 the home agent. 913 5.6.6. Leaving from the Home Link 915 o When the mobile node detaches from the home link, it SHOULD 916 immediately send a binding update for one of active care-of 917 address with H flag unset. When the 'H' flag of BID option is 918 unset in any Binding Update, the home agent stop forwarding the 919 mobile node's packet to the home link. 921 5.6.6.1. Changing Behavior during the attachment to the home link 923 If a mobile node decides to return home completely without any active 924 foreign link attachment, it simply sends a deregistration binding 925 update as described in Section 5.5.1. Once the home agent receives 926 such de-registration binding update, the home agent clears all the 927 binding and states for the mobile node. 929 If a mobile node decides to stop using the interface attached to the 930 home link, it simply sends a binding update from the one of active 931 care-of address. In the Binding Update, the mobile node should 932 include the BID option for the care-of address and unset the H flag 933 of BID option. The home agent clears the states of the mobile node 934 for the interface attached to the home link and stop forwarding the 935 packets to the mobile node on the home link. 937 5.7. Receiving Binding Acknowledgement 939 The verification of a Binding Acknowledgement is the same as Mobile 940 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 941 Binding Acknowledgement is described in Section 6.2. 943 If a mobile node includes a Binding Identifier mobility option in a 944 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 945 carry a Binding Identifier mobility option. According to [RFC-3775], 946 the receiver of the Binding Update ignores unknown mobility options 947 and process the Binding Update without the unknown mobility option. 948 Therefore, if no such mobility option is included in the Binding 949 Acknowledgement in response to a Binding Update for multiple care-of 950 address registration, this indicates that the originating node of the 951 Binding Acknowledgement does not support processing the Binding 952 Identifier mobility option regardless of status value. In such case, 953 the receiver of the Binding Update may create a regular binding. The 954 mobile node then stop multiple care-of address registration with that 955 node. If it is home registration, the mobile node MAY attempt to 956 discover another home agent supporting BID mobility option for the 957 home registration. 959 If a Binding Identifier mobility option is present in the received 960 Binding Acknowledgement, the mobile node checks the status field in 961 the option. If the status value in the Binding Identifier mobility 962 option is zero, the mobile node uses the value in the Status field of 963 the Binding Acknowledgement. Otherwise, it uses the value in the 964 Status field of the Binding Identifier mobility option. 966 If the status code is greater than or equal to 128, the mobile node 967 starts relevant operations according to the error code. Otherwise, 968 the mobile node assumes that the originator (home agent or 969 correspondent node) successfully registered the binding information 970 and BID for the mobile node. 972 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 973 stop registering multiple bindings to the node that sent the 974 Binding Acknowledgement. 976 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 977 mobile node SHOULD stop using bulk registrations with the node 978 that sent the Binding Acknowledgement. 980 o If [MCOA MALFORMED] is specified, it indicates that the binding 981 identifier mobility option is formatted wrongly. 983 o If [MCOA BID CONFLICT] is specified, the binding entry specified 984 by the Binding Identifier mobility option is already registered as 985 a regular binding. In such case, the mobile node SHOULD stop 986 sending Binding Updates with BID, or SHOULD use the 'O' flag to 987 reset all the registered bindings. 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 Section 6.3. 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. The mobile node 1000 MUST include a Binding Identifier mobility option in the Binding 1001 Update. 1003 5.9. Bootstrapping 1005 When a mobile node bootstraps and registers multiple bindings for the 1006 first time, it MUST set the 'O' flag in the Binding Identifier 1007 mobility option. If old bindings still exists at the home agent, the 1008 mobile node has no knowledge of which bindings still exist at the 1009 home agent. This scenario happens when a mobile node reboots and 1010 looses state regarding the registrations. If the 'O' flag is set, 1011 all the bindings are replaced by the new binding(s). If the mobile 1012 node receives the Binding Acknowledgement with the status code set to 1013 135 [Sequence number out of window], it MUST follow the operations 1014 described in [RFC-3775]. 1016 The 'O' flag can also be used in individual Binding Updates sent to 1017 the correspondent nodes to override any existing binding cache 1018 entries at the correspondent node. 1020 6. Home Agent and Correspondent Node Operation 1022 6.1. Searching Binding Cache with Binding Identifier 1024 If either a correspondent node or a home agent has multiple bindings 1025 for a mobile node in their binding cache database, it can use any of 1026 the bindings to communicate with the mobile node. This section 1027 explains how to retrieve the desired binding for the binding 1028 management. This document does not provide any mechanism to select 1029 the suitable binding for forwarding data packets. 1031 A node which is either a correspondent node or a home agent SHOULD 1032 use both the home address and the BID as the search key of the 1033 binding cache if it knows the corresponding BID (ex. when processing 1034 signaling messages). In the example below, if a node searches the 1035 binding with the home address and BID2, it gets binding2 for this 1036 mobile node. 1038 binding1 [2001:db8::EUI, care-of address1, BID1] 1039 binding2 [2001:db8::EUI, care-of address2, BID2] 1040 binding3 [2001:db8::EUI, care-of address3, BID3] 1042 Figure 7: Searching the Binding Cache 1044 The node learns the BID when it receives a Binding Identifier 1045 mobility option. At that time, the node MUST look up its binding 1046 cache database with the home address and the BID retrieved from the 1047 Binding Update. If the node does not know the BID, it searches for a 1048 binding with only the home address. In such a case, the first 1049 matched binding is found. If the node does not desire to use 1050 multiple bindings for a mobile node, it can simply ignore the BID. 1052 6.2. Processing Binding Update 1054 If a Binding Update does not contain a Binding Identifier mobility 1055 option, its processing is same as in [RFC-3775]. If the receiver 1056 already has multiple bindings for the home address, it MUST replace 1057 all the existing bindings by the received binding. As a result, the 1058 receiver node MUST have only one binding cache entry for the mobile 1059 node. If the Binding Update is for de-registration, the receiver 1060 MUST delete all existing bindings from its Binding Cache. 1062 If the Binding Update contains a Binding Identifier mobility 1063 option(s), it is first validated according to section 9.5.1 of [RFC- 1064 3775]. Then the receiver processes the Binding Identifier mobility 1065 option(s) as described in the following steps. 1067 o The length value is examined. The length value MUST be either 4, 1068 8, or 20 depending on the Care-of Address field. If the length is 1069 incorrect, the receiver MUST reject the Binding Update and returns 1070 the status value set to [MCOA MALFORMED]. 1072 o When the Length value is either 12 or 20, the care-of address MUST 1073 be present in the Binding Identifier mobility option. If the 1074 valid care-of address is not present, the receiver MUST reject the 1075 Binding Identifier mobility option and returns the status value 1076 set to [MCOA MALFORMED]. 1078 o When multiple Binding Identifier mobility options are present in 1079 the Binding Update, it is treated as bulk registration. If the 1080 receiving node is a correspondent node, it MUST reject the Binding 1081 Update and returns the status value in the binding Acknowledgement 1082 set to [MCOA BULK REGISTRATION NOT SUPPORT] 1084 o If the Lifetime field in the Binding Update is set to zero, the 1085 receiving node deletes the binding entry that corresponds to the 1086 BID in the Binding Identifier mobility option. If the receiving 1087 node does not have an appropriate binding for the BID, it MUST 1088 reject the Binding Update and send a Binding Acknowledgement with 1089 status set to 133 [not home agent for this mobile node]. 1091 o If the 'O' flag is set in the de-registering Binding Update, it is 1092 ignored. If the 'H' flag is set, the home agent stores a home 1093 address in the Care-of Address field of the binding cache entry. 1094 The home agent MUST follow the descriptions described in 1095 Section 5.6. 1097 o If the Lifetime field is not set to zero, the receiving node 1098 registers a binding with the specified BID as a mobile node's 1099 binding. The Care-of address is obtained from the Binding Update 1100 packet as follows: 1102 * If the Length value of the Binding Identifier mobility option 1103 is 20, the care-of address is copied the IPv6 address from the 1104 care-of address field in the Binding Identifier mobility 1105 option. When the Length value is 12, the address MUST be the 1106 IPv4 valid address. Detail information can be found in 1107 Section 8. 1109 * If the Length value of the Binding Identifier mobility option 1110 is 4, the care-of address is copied from the source address 1111 field of the IPv6 header. 1113 * If the Length value of the Binding Identifier mobility option 1114 is 4 and an alternate care-of address is present, the care-of 1115 address is copied from the Alternate Care-of address mobility 1116 option. 1118 o Once the care-of address(es) have been retrieved from the Binding 1119 Update, the receiving nodes creates new binding(s). 1121 * If 'O' flag is not set in all the Binding Identifier options, 1122 the home agent MUST return the status value [MCOA MALFORMED] by 1123 Binding Acknowledgement. 1125 * If the 'O' flag is set in the Binding Identifier mobility 1126 option, the home agent removes all the existing bindings and 1127 registers the received bindings. 1129 * If the receiver has a regular binding which does not have BID 1130 for the mobile node, it must not process the binding update. 1131 The receiver should sent a binding acknowledgement with status 1132 set to [MCOA BID CONFLICT]. 1134 * If the receiver already has a binding with the same BID but 1135 different care-of address, it MUST update the binding and 1136 respond with a Binding Acknowledgement with status set to 0 1137 [Binding Update accepted]. 1139 * If the receiver does not have a binding entry for the BID, it 1140 registers a new binding for the BID and responds with a Binding 1141 Acknowledgement with status set to 0 [Binding Update accepted]. 1143 If all the above operations are successfully completed, a Binding 1144 Acknowledgement containing the Binding Identifier mobility options 1145 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 1146 is sent, all the Binding Identifier mobility options stored in the 1147 Binding Update MUST be copied to the Binding Acknowledgement except 1148 the status field. The Care-of address field in each Binding 1149 Identifier mobility option, however, can be omitted, because the 1150 mobile node can match a corresponding binding update list entry using 1151 the BID. 1153 When a correspondent node sends a Binding Acknowledgement, the status 1154 value MUST be always stored in the Status field of the Binding 1155 Acknowledgement and the Status field of Binding Identifier mobility 1156 option MUST be always set to zero. 1158 When the home agent sends a Binding Acknowledgement, the status value 1159 can be stored in the Status field of either a Binding Acknowledgement 1160 or a Binding Identifier mobility option. If the status value is 1161 specific to one of bindings in the bulk registration, the status 1162 value MUST be stored in the Status field in the corresponding Binding 1163 Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be 1164 set to the Status field of the Binding Acknowledgement so that the 1165 receiver can examine the Status field of each Binding Identifier 1166 mobility option for further operations. Otherwise, the status field 1167 of the Binding Identifier mobility option MUST be set to zero and the 1168 home agent status field of the Binding Acknowledgement is used. 1170 6.3. Sending Binding Refresh Request 1172 When a node (home agent or correspondent node) sends a Binding 1173 Refresh Request for a particular binding created with the BID, the 1174 node SHOULD include the Binding Identifier mobility option in the 1175 Binding Refresh Request. The node MAY include multiple Binding 1176 Identifier mobility options if there are multiple bindings that need 1177 to be refreshed. 1179 6.4. Receiving Packets from Mobile Node 1181 When a node receives packets with a Home Address destination option 1182 from a mobile node, it MUST check that the care-of address that 1183 appears in the source address field of the IPv6 header MUST be equal 1184 to one of the care-of addresses in the binding cache entry. If no 1185 binding is found, the packets MUST be discarded. The node MUST also 1186 send a Binding Error message as specified in [RFC-3775]. This 1187 verification MUST NOT be done for a Binding Update. 1189 7. Network Mobility Applicability 1191 The binding management mechanisms are the same for a mobile host that 1192 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1193 Support protocol [RFC-3963]. Therefore the extensions described in 1194 this document can also be used to support a mobile router with 1195 multiple care-of addresses. [RFC-4980] is a document for an analysis 1196 of NEMO multihoming. 1198 8. DSMIPv6 Applicability 1200 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1201 register an IPv4 care-of address instead of the IPv6 care-of address 1202 when the mobile node is attached to an IPv4-only access network. It 1203 also allows the mobile node to acquire an IPv4 home address in 1204 addition to an IPv6 home address for use with IPv4-only correspondent 1205 nodes. This section describes how multiple care-of address 1206 registration works with IPv4 care-of and home addresses. 1208 8.1. IPv4 Care-of Address Registration 1210 The mobile node can use the extensions described in the document to 1211 register multiple care-of addresses, even if some of the care-of 1212 addresses are IPv4 address. 1214 Bulk registration MUST NOT be used for the initial binding from an 1215 IPv4 care-of address. This is because, the Binding Update and 1216 binding acknowledgement exchange is used to detect NAT on the path 1217 between the mobile node and the home agent. So the mobile node needs 1218 to check for a NAT between each IPv4 care-of address and the home 1219 agent. 1221 The Binding Update MUST be sent to the IPv4 home agent address by 1222 using UDP and IPv4 headers as shown in Figure 8. It is similar to 1223 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1224 used when the BID mobility option is used. 1226 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1227 UDP Header 1228 IPv6 header (src=V6HoA, dst=HAADDR) 1229 ESP Header 1230 Mobility header 1231 -Binding Update 1232 Mobility Options 1233 - Binding Identifier (IPv4 CoA) 1235 Figure 8: Initial Binding Update for IPv4 Care-of Address 1237 If a NAT is not detected, the mobile node can update the IPv4 care-of 1238 address by using bulk registration. The mobile node can register the 1239 IPv4 care-of address along with other IPv4 and IPv6 care-of 1240 addresses. Figure 9 shows the Binding Update format when the mobile 1241 node sends a Binding Update from one of its IPv6 care-of addresses. 1242 If the mobile node sends a Binding Update from IPv4 care-of address, 1243 it MUST follow the format described in Figure 8. Note that the IPv4 1244 Care-of Address must be registered by non bulk Binding registration, 1245 whenever it is changed. 1247 IPv6 header (src=V6CoA, dst=HAADDR) 1248 IPv6 Home Address Option 1249 ESP Header 1250 Mobility header 1251 -Binding Update 1252 Mobility Options 1253 - Binding Identifier (IPv6/v4 CoA) 1254 - Binding Identifier (IPv6/v4 CoA) 1255 - ... 1257 Figure 9: Binding Bulk Registration for IPv4 care-of address 1259 If the home agent rejects the IPv4 care-of address, it MUST store the 1260 error code value in the Status field of the BID mobility option. 1262 8.2. IPv4 HoA Management 1264 When the mobile node wants to configure an IPv4 home address in 1265 addition to the IPv6 home address, it can request for one using the 1266 IPv4 Home Address option in the Binding Update. If the home agent 1267 accepts the Binding Update, the mobile node can now register multiple 1268 care-of addresses for the IPv4 home address in addition to the IPv6 1269 home address. The same set of care-of addresses will be registered 1270 for both IPv6 and IPv4 home addresses. The mobile node cannot bind 1271 different set of care-of addresses to each home address. 1273 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1274 acknowledgement option in the Binding Acknowledgement only if the 1275 mobile node had requested for an IPv4 home address in the 1276 corresponding Binding Update. The IPv4 address acknowledgement 1277 option MUST be present before any BID option. The status field of 1278 the IPv4 address acknowledgement option contains only the error code 1279 corresponding to the IPv4 home address management. The error values 1280 related to the IPv4 care-of address registration MUST be stored in 1281 the BID mobility option. 1283 9. IPsec and IKEv2 interaction 1285 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1286 use of IPsec to protect signaling messages like Binding Updates, 1287 Binding Acknowledgements and return routability messages. IPsec may 1288 also be used protect all tunneled data traffic. The Mobile IPv6- 1289 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1290 setup the required IPsec security associations. The following 1291 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1292 respect to the use of IKEv2 and IPsec. 1294 o There is only one primary care-of address per mobile node. 1296 o The primary care-of address is stored in the IPsec database for 1297 tunnel encapsulation and decapsulation. 1299 o When the home agent receives a packet from the mobile node, the 1300 source address is verified against the care-of address in the 1301 corresponding binding cache entry. If the packet is a reverse 1302 tunneled packet from the mobile node, the care-of address check is 1303 done against the source address on the outer IPv6 header. The 1304 reverse tunnel packet could either be a tunneled HoTi message or 1305 tunneled data traffic to the correspondent node. 1307 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1308 the care-of address. The IKE SA is based on the care-of address 1309 of the mobile node. 1311 The above assumptions may not be valid when multiple care-of 1312 addresses are used by the mobile node. In the following sections, 1313 the main issues with the use of multiple care-of address with IPsec 1314 are addressed. 1316 9.1. Use of Care-of Address in the IKEv2 exchange 1318 For each home address the mobile node sets up security associations 1319 with the home agent, the mobile node must pick one care-of address 1320 and use that as the source address for all IKEv2 messages exchanged 1321 to create and maintain the IPsec security associations associated 1322 with the home address. The resultant IKEv2 security association is 1323 created based on this care-of address. 1325 If the mobile node needs to change the care-of address, it just sends 1326 a Binding Update with the care-of address it wants to use, with the 1327 corresponding Binding Identifier mobility option, and with the 'K' 1328 bit set. This will force the home agent to update the IKEv2 security 1329 association to use the new care-of address. If the 'K' bit is not 1330 supported on the mobile node or the home agent, the mobile node MUST 1331 re-establish the IKEv2 security association with the new care-of 1332 address. This will also result in new IPsec security associations 1333 being setup for the home address. 1335 9.2. Transport Mode IPsec protected messages 1337 For Mobile IPv6 signaling message protected using IPsec in transport 1338 mode, the use of a particular care-of address among multiple care-of 1339 addresses does not matter for IPsec processing. 1341 The home agent processes Mobile Prefix Discovery messages with the 1342 same rules of data packets described in Section 6.4. 1344 9.3. Tunnel Mode IPsec protected messages 1346 The use of IPsec in tunnel mode with multiple care-of address 1347 introduces a few issues that require changes to how the mobile node 1348 and the home agent send and receive tunneled traffic. The route 1349 optimization mechanism described in [RFC-3775] mandates the use of 1350 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1351 mobile node and the home agent may also choose to protect all reverse 1352 tunneled payload traffic with IPsec in tunnel mode. The following 1353 sections address multiple care-of address support for these two types 1354 of messages. 1356 9.3.1. Tunneled HoTi and HoT messages 1358 The mobile node MAY use the same care-of address for all HoTi 1359 messages sent reverse tunneled through the home agent. The mobile 1360 node may use the same care-of address irrespective of which 1361 correspondent node the HoTi message is being sent. RFC 3775 requires 1362 the home agent to verify that the mobile node is using the care-of 1363 address that is in the binding cache entry, when it receives a 1364 reverse tunneled HoTi message. If a different address is used as the 1365 source address, the message is silently dropped by the home agent. 1366 This document requires the home agent implementation to decapsulate 1367 and forward the HoTi message as long as the source address is one of 1368 the care-of addresses in the binding cache entry for the mobile node. 1370 When the home agent tunnels a HoT message to the mobile node, the 1371 care-of address used in the outer IPv6 header is not relevant to the 1372 HoT message. So regular IPsec tunnel encapsulation with the care-of 1373 address known to the IPsec implementation on the home agent is 1374 sufficient. 1376 9.3.2. Tunneled Payload Traffic 1378 When the mobile sends and receives multiple traffic flows protected 1379 by IPsec to different care-of addresses, the use of the correct 1380 care-of address for each flow becomes important. Support for this 1381 requires the following two considerations on the home agent. 1383 o When the home agent receives a reverse tunneled payload message 1384 protected by IPsec in tunnel mode, it must check that the care-of 1385 address is one of the care-of addresses in the binding cache 1386 entry. According to RFC 4306, the IPsec implementation on the 1387 home agent does not check the source address on the outer IPv6 1388 header. Therefore the care-of address used in the reverse 1389 tunneled traffic can be different from the care-of address used as 1390 the source address in the IKEv2 exchange. However, the Mobile 1391 IPv6 stack on the home agent MUST verify that the source address 1392 is one of the care-of addresses registered by the mobile node 1393 before decapsulating and forwarding the payload traffic towards 1394 the correspondent node. 1396 o For tunneled IPsec traffic from the home agent to the mobile node, 1397 The IPsec implementation on the home agent may not be aware of 1398 which care-of address to use when performing IPsec tunnel 1399 encapsulation. The Mobile IP stack on the home agent must specify 1400 the tunnel end point for the IPsec tunnel. This may require tight 1401 integration between the IPsec and Mobile IP implementations on the 1402 home agent. 1404 10. Security Considerations 1406 The security considerations for securing the Binding Update and 1407 binding acknowledgement messages with multiple care-of address are 1408 very similar to the security considerations for securing the Binding 1409 Update and binding acknowledgement. Please see [RFC-3775] for more 1410 information. The Binding Update and binding acknowledgement messages 1411 with multiple care-of addresses are securely exchanged as described 1412 in [RFC-3775], [RFC-4877] and Section 9. Additional security 1413 considerations are described below. 1415 With simultaneous binding support, it is possible for a malicious 1416 mobile node to successfully bind a number of victims' addresses as 1417 valid care-of addresses for the mobile node with its home agent. 1418 Once these addresses have been bound, the malicious mobile node can 1419 perform a re-direction attack by instructing the home agent (e.g. 1420 setting filtering rules to direct a large file transfer) to tunnel 1421 packets to the victims' addresses. Such risk is highlighted in [ID- 1422 MIP6ANALYSIS]. These attacks are possible because the care-of 1423 addresses sent by the mobile node in the Binding Update messages are 1424 not verified by home agent, i.e., the home agent does not check if 1425 the mobile node is at the care-of address it is claiming to be. The 1426 security model for Mobile IPv6 assumes that there is a trust 1427 relationship between the mobile node and its home agent. Any 1428 malicious attack by the mobile node is traceable by the home agent. 1429 This acts as a deterrent for the mobile node to launch such attacks. 1431 Although such risk exists in Mobile IPv6, the risk level is escalated 1432 when simultaneous multiple care-of address bindings are performed. 1433 In Mobile IPv6, a mobile node can only have a single care-of address 1434 binding per home address at a given time. However, for simultaneous 1435 multiple care-of address bindings, a mobile node can have more than 1436 one care-of address binding per home address at a given time. This 1437 implies that a mobile node using simultaneous binding support can 1438 effectively bind more than a single victim's address. Another 1439 difference is the degree of risk involved. In the single care-of 1440 address binding case, once the re-direction attack is initiated, a 1441 malicious mobile node would be unable to use its home address for 1442 communications (such as to receive control packets pertaining to the 1443 file transfer). However, in the simultaneous binding support case, a 1444 malicious mobile node could bind a valid care-of address in addition 1445 to multiple victims addresses. This valid care-of address could then 1446 be used by the malicious mobile node to set up flow filtering rules 1447 at its home agent, thereby controlling and/or launching new re- 1448 direction attacks. 1450 Thus, in view of such risks, it is advisable for a home agent to 1451 employ some form of care-of address verification mechanism before 1452 using the care-of addresses as a valid routing path to a mobile node. 1453 These mechanisms are out-of scope for this document. The home agent 1454 can also choose to reject bulk registration by using [MCOA BULK 1455 REGISTRATION PROHIBITED] in a Binding Acknowledgement. 1457 11. IANA Considerations 1459 The following Extension Types MUST be assigned by IANA: 1461 o Binding Identifier mobility option type: This must be assigned 1462 from the same space as mobility option in [RFC-3775]. 1464 o New Successful Status of Binding Acknowledgement: This status code 1465 must be assigned from the same space as binding acknowledgement 1466 status codes in [RFC-3775]. 1468 * MCOA NOTCOMPLETE (TBD) 1470 * MCOA RETURNHOME WO/NDP (TBD) 1472 o New Unsuccessful Status of Binding Acknowledgement: These status 1473 codes must also be assigned from the same space as binding 1474 acknowledgement status codes in [RFC-3775]. 1476 * MCOA MALFORMED (TBD) 1478 * MCOA BID CONFLICT (TBD) 1480 * MCOA PROHIBITED(TBD) 1482 * MCOA BULK REGISTRATION PROHIBITED (TBD) 1484 * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD) 1486 12. Acknowledgements 1488 The authors would like to special thank George Tsirtsis for thorough 1489 review and suggestions. The authors would also like to thank 1490 Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin 1491 Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas 1492 Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to 1493 Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke 1494 Uehara, Masafumi Watari and Jun Murai for earlier work on this 1495 subject. 1497 13. References 1499 13.1. Normative References 1501 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1502 Requirement Levels", BCP 14, RFC 2119, March 1997. 1504 [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, 1505 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 1506 2007.. 1508 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1509 in IPv6", RFC 3775, June 2004. 1511 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1512 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1513 January 2005. 1515 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1516 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1518 13.2. Informative References 1520 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1521 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1522 Interfaces and Global Addresses", 1523 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1524 progress), May 2008. 1526 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1527 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1529 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1530 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1531 draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. 1533 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1534 RFC 3753, June 2004. 1536 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1537 Terminology", RFC 4885, July 2007. 1539 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1540 and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in 1541 progress), July 2008. 1543 [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June 1544 2008. 1546 Authors' Addresses 1548 Ryuji Wakikawa 1549 Toyota ITC / Keio University 1550 6-6-20 Akasaka, Minato-ku 1551 Tokyo 107-0052 1552 Japan 1554 Phone: +81-3-5561-8276 1555 Fax: +81-3-5561-8292 1556 Email: ryuji@jp.toyota-itc.com 1558 Vijay Devarapalli 1559 Wichorus 1560 3590 North First St 1561 San Jose, CA 95134 1562 USA 1564 Email: vijay@wichorus.com 1566 Thierry Ernst 1567 INRIA 1568 INRIA Rocquencourt 1569 Domaine de Voluceau B.P. 105 1570 Le Chesnay, 78153 1571 France 1573 Phone: +33-1-39-63-59-30 1574 Fax: +33-1-39-63-54-91 1575 Email: thierry.ernst@inria.fr 1576 URI: http://www.nautilus6.org/~thierry 1578 Kenichi Nagami 1579 INTEC NetCore Inc. 1580 1-3-3, Shin-suna 1581 Koto-ku, Tokyo 135-0075 1582 Japan 1584 Phone: +81-3-5565-5069 1585 Fax: +81-3-5565-5094 1586 Email: nagami@inetcore.com 1588 Full Copyright Statement 1590 Copyright (C) The IETF Trust (2008). 1592 This document is subject to the rights, licenses and restrictions 1593 contained in BCP 78, and except as set forth therein, the authors 1594 retain all their rights. 1596 This document and the information contained herein are provided on an 1597 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1598 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1599 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1600 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1601 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1602 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1604 Intellectual Property 1606 The IETF takes no position regarding the validity or scope of any 1607 Intellectual Property Rights or other rights that might be claimed to 1608 pertain to the implementation or use of the technology described in 1609 this document or the extent to which any license under such rights 1610 might or might not be available; nor does it represent that it has 1611 made any independent effort to identify any such rights. Information 1612 on the procedures with respect to rights in RFC documents can be 1613 found in BCP 78 and BCP 79. 1615 Copies of IPR disclosures made to the IETF Secretariat and any 1616 assurances of licenses to be made available, or the result of an 1617 attempt made to obtain a general license or permission for the use of 1618 such proprietary rights by implementers or users of this 1619 specification can be obtained from the IETF on-line IPR repository at 1620 http://www.ietf.org/ipr. 1622 The IETF invites any interested party to bring to its attention any 1623 copyrights, patents or patent applications, or other proprietary 1624 rights that may cover technology that may be required to implement 1625 this standard. Please address the information to the IETF at 1626 ietf-ipr@ietf.org. 1628 Acknowledgment 1630 Funding for the RFC Editor function is provided by the IETF 1631 Administrative Support Activity (IASA).