idnits 2.17.1 draft-ietf-monami6-multiplecoa-02.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 1554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1578. 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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The first situation is when a mobile node wants to return home with interface attached to the home link. In this case, the mobile node MUST de-register all the bindings by sending a Binding Update with lifetime set to zero. The mobile node MAY NOT put any Binding Unique Identifier sub-option in this packet. Then, the receiver deletes all the bindings from its binding cache database. A home agent MUST stop proxy neighbor advertisement for the home address of the mobile node. -- 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 (March 5, 2007) is 6255 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) -- Looks like a reference, but probably isn't: 'MCOA INCOMPLIANT' on line 971 -- Looks like a reference, but probably isn't: 'REASON UNSPECIFIED' on line 972 == Missing Reference: '128' is mentioned on line 972, but not defined ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-02 ** Downref: Normative reference to an Informational draft: draft-ietf-monami6-mipv6-analysis (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '6') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '8') == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-01 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-02 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Monami6 Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Intended status: Standards Track T. Ernst 5 Expires: September 6, 2007 INRIA 6 K. Nagami 7 INTEC NetCore 8 V. Devarapalli 9 Azaire Networks 10 March 5, 2007 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-02.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 September 6, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 According to the current Mobile IPv6 specification, a mobile node may 47 have several care-of addresses, but only one, termed the primary 48 care-of address, 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 access media simultaneously, in which case multiple active 52 IPv6 care-of addresses would be assigned to the mobile node. We thus 53 propose Mobile IPv6 extensions designed to register multiple care-of 54 addresses bound to a single Home Address instead of the sole primary 55 care-of address. For doing so, a new identification number must be 56 carried in each binding for the receiver to distinguish between the 57 bindings corresponding to the same Home Address. Those extensions 58 are targeted to NEMO (Network Mobility) Basic Support as well as to 59 Mobile IPv6. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7 69 3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7 70 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Binding Cache Structure and Binding Update List . . . . . 10 74 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 75 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 76 4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 13 78 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 79 5.1. Management of Care-of Addresses and Binding Unique 80 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14 82 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15 83 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 84 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 85 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 86 5.7. Using Alternate care-of address . . . . . . . . . . . . . 18 87 5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 88 5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 19 89 5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 90 5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 92 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 93 6.1. Searching Binding Cache with Binding Unique Identifier . . 21 94 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 95 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 96 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25 97 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25 99 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 101 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 102 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 103 8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 104 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28 105 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28 106 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 115 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 117 Appendix A. Example Configurations . . . . . . . . . . . . . . . 33 119 Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 122 Intellectual Property and Copyright Statements . . . . . . . . . . 41 124 1. Introduction 126 A mobile node should use various type of network interfaces to obtain 127 durable and wide area network connectivity. Assumed scenarios and 128 motivations for multiple points of attachment, and benefits for doing 129 it are discussed at large in [10]. 131 IPv6 [1] conceptually allows a node to have several addresses on a 132 given interface. Consequently, Mobile IPv6 [2] has mechanisms to 133 manage multiple ``Home Addresses'' based on home agent's managed 134 prefixes such as mobile prefix solicitation and mobile prefix 135 advertisement. But assigning a single Home Address to a node is more 136 advantageous than assigning multiple Home Addresses because 137 applications do not need to be aware of the multiplicity of Home 138 Addresses. If multiple home addresses are available, applications 139 must reset the connection information when the mobile node changes 140 its active network interface (i.e. change the Home Address). 142 According to the Mobile IPv6 specification, a mobile node is not 143 allowed to register multiple care-of addresses bound to a single Home 144 Address. Since NEMO Basic Support [3] is based on Mobile IPv6, the 145 same issues applies to a mobile node acting as mobile router. 146 Multihoming issues pertaining to mobile nodes operating Mobile IPv6 147 and mobile routers operating NEMO Basic Support are respectively 148 discussed [4] and [11] in Monami6 and NEMO Working Group. 150 In this document, we thus propose a new identification number called 151 Binding Unique Identification (BID) number for each binding cache 152 entry to accommodate multiple bindings registration. The BID is 153 assigned to either the interfaces or care-of addresses bound to a 154 single home address of a mobile node. The mobile node notifies the 155 BID to both its Home Agent and correspondent nodes by means of a 156 Binding Update. correspondent nodes and the home agent record the BID 157 into their binding cache. The Home Address thus identifies a mobile 158 node itself whereas the BID identifies each binding registered by a 159 mobile node. By using the BID, multiple bindings can then be 160 distinguished. 162 2. Terminology 164 Terms used in this draft are defined in [2], [5] and [6]. In 165 addition or in replacement of these, the following terms are defined 166 or redefined: 168 Binding Unique Identification number (BID) 170 The BID is an identification number used to distinguish multiple 171 bindings registered by the mobile node. Assignment of distinct 172 BID allows a mobile node to register multiple binding cache 173 entries for a given Home Address. The BID is generated to 174 register multiple bindings in the binding cache for a given 175 address in a way it cannot be duplicated with another BID. The 176 zero value and a negative value MUST NOT be used. After being 177 generated by the mobile node, the BID is stored in the Binding 178 Update List and is sent by the mobile node by means of a sub- 179 option of a Binding Update. A mobile node MAY change the value of 180 a BID at any time according to its administrative policy, for 181 instance to protect its privacy. 183 The BID is conceptually assigned to a binding. An implementation 184 must carefully assign the BID so as to keep using the same BID for 185 the same binding even when the status of the binding is changed. 186 More details can be found in Section 5.1. 188 Binding Unique Identifier sub-option 190 The Binding Unique Identifier sub-option is used to carry the BID. 192 Bulk Registration 194 A mobile node can register multiple bindings by sending a single 195 binding update. The mobile node does not necessarily put all the 196 available care-of addresses in the binding update, but several 197 care-of addresses which can be stored in a Binding Update. The 198 bulk registration is supported only for home registration and 199 deregistration as explained in Section 5.5. Note that a mobile 200 node should not try to perform bulk registration with 201 correspondent nodes. 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [7]. 207 3. Protocol Overview 209 We propose a new identification number (BID) to distinguish multiple 210 bindings pertaining to the same Home Address. The procedures for the 211 mobile node to register multiple bindings are described in the 212 paragraphs below. 214 3.1. Multiple Care-of Addresses Registration 216 Once a mobile node gets several IPv6 global addresses on interfaces, 217 it can register these addresses with its home agent (home 218 registration). If the mobile node wants to register multiple 219 bindings to its home agent, it MUST generate a BID for each care-of 220 address and record it into the binding update list. The mobile node 221 then registers its care-of addresses by sending a Binding Update with 222 a Binding Unique Identifier sub-option. The BID MUST be put in the 223 Binding Unique Identifier sub-option. After receiving the Binding 224 Update, the home agent verifies the request and records the binding 225 in its binding cache. If the newly defined sub-option is present in 226 the Binding Update, the home agent MUST copy the BID from the Binding 227 Update to the corresponding field in the binding entry. Even if 228 there is already an entry for the mobile node, the home agent MUST 229 register a new binding entry for the BID stored in the Binding Unique 230 Identifier sub-option. The mobile node registers multiple care-of 231 addresses either independently (in individual BUs) or multiple at 232 once (in a single BU). 234 If the mobile node wishes to register its binding with a 235 correspondent node, it must operate return routability operations. 236 The mobile node MUST manage a Care-of Keygen Token per care-of 237 address. If it is necessary (ex. Care-of Keygen token is expired), 238 the mobile node exchanges CoTI and CoT for the releative care-of 239 addresses. When the mobile node registers several care-of addresses 240 to a correspondent node, it uses the same BID as the one generated 241 for the home registration's bindings. The binding registration step 242 is the same as for the home registration except for calculating 243 authenticator by using Binding Unique Identifier sub-option as well 244 as the other sub-options specified in RFC 3775. For simplicity, the 245 bulk registration is not supported for correspondent nodes in this 246 document. 248 3.2. Multiple Bindings Management 250 The BID is used as a search key for a corresponding entry in the 251 binding cache in addition to the Home Address. When a home agent and 252 a correspondent node check the binding cache database for the mobile 253 node, it searches a corresponding binding entry with the Home Address 254 and BID of the desired binding. If necessary, a mobile node can use 255 policy and filter information to look up the best binding per 256 sessions, flow, packets, but this is out of scope in this document 257 and is currently discussed in Monami6 WG. 259 If there is no desired binding, it searches the binding cache 260 database with the Home Address as specified in Mobile IPv6. The 261 first matched binding entry may be found, although this is 262 implementation dependent. 264 When one of the care-of addresses has changed, the mobile node sends 265 a Binding Update with the new care-of address and the corresponding 266 BID. The receiver of the Binding Update updates the binding which 267 BID matches the BID contained in the received Binding Unique 268 Identifier sub-option. The mobile node can manage each binding 269 independently owing to BID. 271 If the mobile node decides to act as a regular mobile node compliant 272 with [2] , it just sends a Binding Update without a Binding Unique 273 Identifier sub-option (i.e. normal Binding Update). The receiver of 274 the Binding Update registers only a single binding for the mobile 275 node and, if necessary, deletes all the bindings registering with a 276 BID. Note that the mobile node can continue to use BID even if only 277 a single binding is active at some time. 279 3.3. Returning Home 281 When the mobile node returns home, there are two situations, since 282 the home agent defends the mobile node's Home Address by using the 283 proxy neighbor advertisement. It is impossible to utilize all the 284 interfaces when one interface is attached to the home link and the 285 others are attached to foreign links. If the proxy Neighbor 286 Advertisement for the Home Address is stopped, packets are always 287 routed to the interface attached to the home link. If proxy is not 288 stopped, packets are never routed to the interface attached to the 289 home link. The decision whether a mobile node returns home or not is 290 up to implementers. 292 The first situation is when a mobile node wants to return home with 293 interface attached to the home link. In this case, the mobile node 294 MUST de-register all the bindings by sending a Binding Update with 295 lifetime set to zero. The mobile node MAY NOT put any Binding Unique 296 Identifier sub-option in this packet. Then, the receiver deletes all 297 the bindings from its binding cache database. A home agent MUST stop 298 proxy neighbor advertisement for the home address of the mobile node. 300 The second situation is when a mobile node does not want to return 301 home, though one of its interfaces is attached to its home link. The 302 mobile node disables the interface attached to the home link and 303 keeps using the rest of interfaces attached to foreign links. In 304 this case, the mobile node sends a de-registration Binding Update for 305 the interface attached to the home link with the Binding Unique 306 Identifier sub-option. The receiver of the de-registration Binding 307 Update deletes only the relative binding entry from the binding cache 308 database. The home agent does not stop proxying neighbor 309 advertisement as long as there are still bindings for the other 310 interfaces. It is important to understand that this scenario is not 311 the most efficient because all the traffic from and to the mobile 312 node is going through the bi-directional tunnel, whereas the mobile 313 node is now accessible at one hop from its HA. 315 In the above two cases, a mobile node cannot use interfaces attached 316 to both home and foreign links simultaneously. If this is what a 317 mobile node wants, a home agent can set up another link other than 318 home link and uses the link for the mobile node to return virtually 319 to home network. Even though packets from and to the mobile node are 320 routed via the home agent, the hop count is kept in one. The 321 overhead should be negligible since it is only for an additional IPv6 322 header and processing tunnel (encapsulation and decapsulation) per 323 packets. The detail can be found in Figure 7 325 4. Mobile IPv6 Extensions 327 In this section are described the changes to Mobile IPv6 necessary to 328 manage multiple bindings bound to a same Home Address. 330 4.1. Binding Cache Structure and Binding Update List 332 The following additional items are required in the binding cache and 333 binding update list structure. 335 BID 337 The value MUST be zero if the Binding Unique identifier does not 338 appear in a Binding Update. 340 Priority of the Binding Cache Entry 342 A value of zero indicates No Priority. A value of 255 indicates 343 that the binding corresponding to this BID is a default of this 344 mobile node. The detail can be found in Figure 1. This 345 information is used by [12]. 347 4.2. Message Format Changes 349 4.2.1. Binding Unique Identifier sub-option 351 The Binding Unique Identifier sub-option is included in the Binding 352 Update, Binding Acknowledgment, Binding Refresh Request, and Care-of 353 Test Init and Care-of Test message. 355 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type = TBD | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Binding Unique ID (BID) |Priority/Status|C|O| Reserved | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 362 + + 363 + care-of address (CoA) + 364 + + 365 +---------------------------------------------------------------+ 367 Figure 1: BID Sub-Option 369 Type 371 Type value for Binding Unique Identifier will be assigned later. 373 Length 375 Length value MUST be 4 when C flag is unset. On the other hand if 376 C flag is set, Length value MUST be set to 20. 378 Binding Unique ID (BID) 380 The BID which is assigned to the binding carried in the Binding 381 Update with this sub-option. BID is 16-bit unsigned integer. A 382 value of zero is reserved. 384 Priority/Status 386 When the Binding Unique Identifier sub-option is included in a 387 Binding Update, this field indicates the priority field assigned 388 to each binding. The receiver can utilize this priority to 389 determine which binding is used to deliver packets. The priority 390 is 8-bit unsigned integer. The higher value has higher priority. 391 Values of zero and 255 are reserved for special meaning. 393 A value of zero indicates No Priority. A value of 255 indicates 394 that the binding corresponding to this BID is a default of this 395 mobile node. This default binding is used by the flow binding 396 scheme [12]. If the receiver cannot recognize 255, it MUST ignore 397 this field. 399 When the Binding Unique Identifier sub-option is included in a 400 Binding Acknowledgment, this field indicates the status 401 correspondent to each binding. The mobile node knows the 402 registration status of each binding. The status is 8-bit unsigned 403 integer. The possible status codes are listed below. If the 404 status field is below 128, it indicates that the binding 405 registration was successful. 407 MCOA ACCEPTING BID (0) 409 The registration of the correspond binding is successfully 410 operated. 412 MCOA REASON UNSPECIFIED (128) 413 Registration failed because of unknown errors 415 MCOA INCOMPLIANT (129) 417 Registration failed because Binding Unique Identifier sub- 418 option is not compliant. 420 MCOA BID CONFLICT (130) 422 It indicates that a regular binding (ie without the BID set) is 423 already registered for the home address, and is conflicting 424 with a received Binding Update which BID was set. 426 MCOA BULK REGISTRATION PROHIBITED (131) 428 The C flag can be set only if a Binding Unique Identifier sub- 429 option is presented only in a Binding Update or a Binding 430 Acknowledgment. 432 care-of address (C) flag 434 When this flag is set, a mobile node can store a Care-of Address 435 corresponding to the BID in the Binding Unique Identifier sub- 436 option. This flag must be used whenever a mobile node sends 437 multiple bindings in a single Binding Update, i.e. bulk 438 registration. 440 Overwrite (O) flag 442 When this flag is set, a mobile node requests a home agent to 443 replace all the bindings to binding entries stored in a Binding 444 Update. This flag is valid for Home Registration and 445 Deregistration. 447 Reserved 449 6 bits Reserved field. Reserved field must be set with all 0. 451 Care-of Address 453 Only when C flag is set, only a single Care-of Address matched to 454 the BID is stored. This field is valid only if a Binding Unique 455 Identifier sub-option is stored in Binding Update message. 456 Otherwise, this field can be omitted. The receiver SHOULD ignore 457 this field if the sub-option is presented in other than Binding 458 Update. 460 4.2.2. Binding Acknowledgment 462 The message format of Binding Acknowledgment does not change, but 463 operations listed below are added in this draft. 465 If a Binding Unique Identifier sub-option is included in a Binding 466 Update with the A flag set, a receiver MUST reply a Binding 467 Acknowledgment. The receiver node MUST include the same Binding 468 Unique Identifier sub-option(s) in the Binding Acknowledgment. The 469 receiver MUST specify relative status in the Status field of the 470 Binding Acknowledgment. 472 There are two status fields: the Status field of a Binding 473 Acknowledgment and the Status field of a Binding Unique Identifier 474 sub-option. In this specification, the Status field of a Binding 475 Acknowledgment indicates the registration status of a "Binding 476 Update". The status value in the Binding Acknowledgment is for all 477 Binding Unique Identifier sub-options stored in the Binding 478 Acknowledgment. For example, if the status value is 134 in the 479 status field of the Binding Acknowledgment, all the care-of addresses 480 stored in the Binding Unique Identifier sub-options are rejected 481 because the duplicate address detection has failed on the home agent. 482 The status field of the Binding Unique Identifier sub-option only 483 informs the receiver about the binding relative to the sub-option. 484 Whether each Care-of address has been successfully registered 485 successfully or not is given in the Status field of each Binding 486 Unique Identifier sub-option. 488 New status values for the status field of a Binding Acknowledgment 489 are defined for handling the multiple Care-of Addresses registration: 491 MCOA PROHIBITED(TBD) 493 It implies the multiple care-of address registration is 494 administratively prohibited. 496 MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 498 The bulk binding registration is not supported. 500 MCOA FLAG CONFLICTS (TBD) 502 The flags of the sub-options presented in a Binding Update 503 conflicts. 505 5. Mobile Node Operation 507 5.1. Management of Care-of Addresses and Binding Unique Identifier 509 There are two cases when a mobile node has several Care-of Addresses: 511 1. A mobile node uses several physical network interfaces and 512 acquires a care-of address on each of its interfaces. 514 2. A mobile node uses a single physical network interface, but 515 multiple prefixes are announced on the link the interface is 516 attached to. Several global addresses are configured on this 517 interface for each of the announced prefixes. 519 The difference between the above two cases is only a number of 520 physical network interfaces and therefore does not matter in this 521 document. The Identification number is used to identify a binding. 522 To implement this, a mobile node MAY assign an identification number 523 for each care-of addresses. How to assign an identification number 524 is up to implementers. 526 A mobile node assigns a BID to each care-of address when it wants to 527 register them simultaneously with its Home Address . The value 528 should be generated from a value comprised between 1 to 65535. Zero 529 and negative values MUST NOT be taken as a BID. If a mobile node has 530 only one care-of address, the assignment of a BID is not needed until 531 it has multiple care-of addresses to register with. 533 5.2. Return Routability: Sending CoTI and Receiving CoT 535 When a mobile node wants to register bindings to a Correspondent 536 Node, it MUST send a CoTI per care-of address, while the HoTI and HoT 537 can be exchanged only once for a Home Address. If the Mobile Node 538 manages bindings with BID, it MUST include a Binding Unique 539 Identifier sub-option in a Care-of Test Init message. It MUST NOT 540 set the C and O flag in the sub-option. 542 The receiver (i.e. correspondent node) will calculate a care-of 543 keygen token with the received BID and reply a Care-of Test message 544 which contains a Binding Unique Identifier sub-option as described in 545 Section 6.2. When the mobile node receives the Care-of Test message, 546 the Care-of Test message is verified as same as in [2] and the 547 Binding Unique Identifier sub-option in the Care-of Test MUST be 548 processed as follows: 550 o If a Binding Unique Identifier sub-option is not presented in CoT 551 in reply to the CoTI containing the Binding Unique Identifier sub- 552 option, a correspondent node does not support the Multiple Care-of 553 Address registration. Thus, the mobile node MUST NOT use a 554 Binding Unique Identifier sub-option in the Binding Update. It 555 MUST send a regular Binding Update (i.e. no BID) to the 556 correspondent node [2]. The Mobile Node MAY skip resending 557 regular CoTI message and use the received care-of keygen token for 558 the regular Binding Update, because the correspondent node just 559 ignores and skip the Binding Unique Identifier sub-option and 560 calculates the care-of keygen token as [2] specified. 562 o If the status field of a Binding Unique Identifier sub-option is 563 set to [MCOA BULK REGISTRATION PROHIBITED], the care-of keygen 564 token MUST NOT be used for a Binding Update. It MUST re-send a 565 Care-of Test Init message again with a corrected Binding Unique 566 Identifier sub-option (i.e. C flag MUST be unset). 568 o If the status field is set to less than 128, it sends a Binding 569 Update through Return Routability procedure. 571 The computation of MAC is the same as the one in [2] except for 572 calculation of a care-of keygen token. The calculation of a care-of 573 keygen token is modified as follows. BID is used to generate the 574 care-of keygen token. 576 care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | 577 nonce | BID | 1))) 579 5.3. Binding Registration 581 When a mobile node sends a Binding Update, it MUST decide whether it 582 registers multiple care-of addresses or not. However, this decision 583 is out-of scope in this document. If a mobile node decides not to 584 register multiple care-of addresses, it completely follows the 585 standard RFC 3775 specification. 587 If a mobile node needs to register multiple Care-of Addresses, it 588 MUST use BID to identify a care-of address. The mobile node includes 589 a Binding Unique Identifier sub-option in the Mobility Option field 590 of a Binding Update. The BID is copied from a corresponding Binding 591 Update List entry to the BID field of the Binding Unique Identifier 592 sub-option. If the mobile node wants to replace existing registered 593 bindings on the home agent to the binding entry(s) in the Binding 594 Update, it can set O flag. 596 If a mobile node registers bindings to a correspondent node, it MUST 597 have both active home and care-of keygen tokens for Kbm (see Section 598 5.2.5 of [2]. The care-of keygen tokens MUST be maintained for each 599 care-of address that the mobile node wants to register to the 600 correspondent node, as described in Section 5.2. After computing an 601 Authenticator value, it sends a Binding Update which contains a 602 Binding Unique Identifier sub-option. The Binding Update is 603 protected by a Binding Authorization Data sub-option placed after the 604 Binding Unique Identifier sub-option. The Mobile Node MUST NOT set 605 the C flag in the Binding Unique Identifier sub-option. 607 5.4. Binding Bulk Registration 609 The bulk registration is an optimization for registering multiple 610 care-of addresses only to a home agent by using a single Binding 611 Update. If a mobile node, for instance, does not want to send a lot 612 of control messages through an interface which bandwidth is scarce, 613 it can use this bulk registration and send a Binding Update 614 containing multiple or all the valid care-of addresses from a 615 specific interface which has wider bandwidth. 617 In this case, a mobile node sets the C flag in a Binding Unique 618 Identifier sub-option and stores the particular care-of address in 619 the Binding Unique Identifier sub-option. When the C flag is set, 620 the length field of the suboption MUST be set to 20. The mobile node 621 can store multiple sets of a Binding Unique Identifier sub-option in 622 a Binding Update. If the mobile node wants to replace existing 623 registered bindings on the home agent with the bindings in the sent 624 Binding Update, it can set O flag. Section 6.3 describes this 625 registration procedure in detail. In the bulk registration, all the 626 other binding information such as Lifetime, Sequence Number, binding 627 Flags are shared among the bulked Care-of Addresses. Whether a 628 mobile node registers multiple Care-of Addresses separately or in 629 bulk is up to implementations. 631 In the bulk registration, the Sequence Number field of a Binding 632 Update SHOULD be carefully configured. If each binding uses 633 different sequence number, a mobile node MUST use the largest 634 sequence number from the binding update list used for the bulk 635 registration. If it cannot select a sequence number for all the 636 bindings due to sequence number out of window, it MUST NOT use the 637 bulk registration for the binding which sequence number is out of 638 window and uses a separate Binding Update for the binding. 640 When multiple Binding Unique Identifier sub-options are presented, 641 the flag field of all the sub-options MUST have the same value. For 642 example, if C flag is set, the same flag MUST be set to all the sub- 643 options. 645 5.5. Binding De-Registration 647 When a mobile node decides to delete all the bindings for its home 648 address, it sends a regular de-registration Binding Update. A 649 Binding Unique Identifier sub-option is not required. See 650 Section 6.3 for details. 652 If a mobile node wants to delete a particular binding from its home 653 agent and correspondent nodes (e.g. from foreign link), the mobile 654 node simply sets zero lifetime or uses the home address as the source 655 address in a Binding Update. The Binding Update MUST contain a 656 relative Binding Unique Identifier Sub-option (C flag MUST NOT be 657 set). The receiver will remove only the care-of address that matches 658 the specified BID. 660 On the other hand, when a mobile node decides to return home (ie only 661 uses its interface attached to the home link), it MUST de-register 662 all the registered bindings. To do so, the mobile node stores 663 multiple Binding Unique Identifier sub-options in a Binding Update 664 which lifetime is set to zero or which source address is set to the 665 Home Address. C flag MUST be specified in all the Binding Unique 666 Identifier sub-options. The care-of addresses field of each sub- 667 option MAY be omitted, because the receiver will remove all the 668 care-of addresses which matches the specified BID. 670 O flag is always ignored if a Binding Update is for binding de- 671 registration 673 5.6. Returning Home 675 When a mobile node returns home, it MUST de-register all bindings 676 with the home agent. 678 Although the mobile node SHOULD delete the bindings with 679 Correspondent Nodes as well, the node MAY still keep the binding of 680 the other interface active attached to foreign links only at the 681 Correspondent Nodes. In such case, the mobile node still receives 682 packets at the other interface attached to a foreign link thanks to 683 route optimization. The mobile node also receives packets at the 684 interface attached to the home link when correspondent nodes does not 685 use route optimization. 687 Note that when the mobile node does not want to return home even if 688 one of interfaces is attached to the home link, the mobile node MUST 689 disable the interface. Otherwise, address duplication will be 690 observed because the home agent still defend the Home Address by the 691 proxy neighbor advertisement and the mobile node also enables the 692 same Home Address on the home link. After disabling the interface 693 attached to the home link, the mobile node MUST delete the binding 694 for the interface by sending a de-registration binding update. The 695 de-registration binding update must be sent from one of active 696 interfaces attached to foreign links. As a result, the mobile node 697 no longer receives packets at the interface attached to the home 698 link. All packets are routed to other interfaces attached to a 699 foreign link. 701 5.7. Using Alternate care-of address 703 A mobile node can use an alternate care-of address in a following 704 situation. One care-of address becomes invalid (e.g because the link 705 where it is attached to is no longer available) and MUST be deleted. 706 In such case, the mobile node can not send a Binding Update from the 707 care-of address because the interface's link is lost. The mobile 708 node needs to de-register the remote binding of the care-of address 709 through one of its active care-of addresses. 711 In this case, the mobile node include both Alternate Care-of Address 712 sub-option and Binding Unique Identifier sub-option in a Binding 713 Update. An Alternate care-of address sub-option can be presented 714 only once in a Binding Update after a Binding Unique Identifier sub- 715 option. The care-of address stored in an Alternate Care-of address 716 sub-option is replaced the address in the source address field as 717 same as [2] specified. 719 If C flag is set in a Binding Unique Identifier sub-option, an 720 Alternate Care-of Address sub-option SHOULD NOT be used. A receiver 721 uses the care-of addresses and BID stored in each Binding Unique 722 Identifier sub-option to modify corresponding binding cache entries. 723 Any address can be specified in the Source address field of the IPv6 724 header of the Binding Update even without an Alternate Care-of 725 Address sub-option. 727 5.8. Receiving Binding Acknowledgment 729 The verification of a Binding Acknowledgment is the same as in Mobile 730 IPv6 (section 11.7.3 of RFC 3775). The operation for sending a 731 Binding Acknowledgment is described in Section 6.3. 733 If a mobile node includes a Binding Unique Identifier sub-option in a 734 Binding Update with A flag set, a Binding Acknowledgment MUST have a 735 Binding Unique Identifier sub-option in the Mobility Options field. 736 If no such sub-option appears in the Binding Acknowledgment replied 737 to the Binding Update for the multiple care-of address registration, 738 this means that the originator node of this Binding Acknowledgment 739 might not recognize the Binding Unique Identifier sub-option. The 740 mobile node SHOULD stop registering multiple care-of addresses by 741 using a Binding Unique Identifier sub-option. If the originator is 742 the home agent, the mobile node MAY try to discover a new home agent 743 supporting the multiple care-of address registration or give up with 744 the multiple care-of address registration. 746 If a Binding Unique Identifier sub-option is present in the received 747 Binding Acknowledgment, the mobile node checks the Status field of 748 the Binding Acknowledgment. If the status code indicates successful 749 registration (less than 128), the originator successfully registered 750 the binding information and BID for the mobile node. 752 If the status code of the Binding Acknowledgment is greater than or 753 equal to 128, the mobile node proceeds with relevant operations 754 according to the status code of the Binding Acknowledgment. The 755 status value of the stored Binding Unique Identifier sub-option may 756 be used to decide further operation. 758 o If the Status value of the Binding Acknowledgment is [MCOA 759 PROHIBITED], the mobile node MUST give up registering multiple 760 bindings to the peer sending the Binding Acknowledgment. It MUST 761 return to the regular Mobile IPv6 [2] for the peer node. 763 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 764 mobile node SHOULD stop using bulk registration to the peer 765 sending the Binding Acknowledgment. 767 o If [MCOA FLAG CONFLICTS] is specified in the Binding 768 Acknowledgment, it indicates that the different flag values are 769 used in Binding Unique Identifier sub-options in a Binding Update. 770 If the C flag is set, all sub-options MUST have C flag. It is 771 same for O flag. How to handle other error status codes is 772 specified in [2]. 774 The mobile node also learn detailed registration status from the 775 Status field of each Binding Unique Identifier sub-option. If the 776 value is greater than or equal to 128, the mobile node proceeds with 777 relevant operations according to the status value. 779 o If [MCOA BID CONFLICT] is specified, the binding entry specified 780 by the Binding Unique Identifier sub-option is already registered 781 as a regular binding. In such case, the mobile node SHOULD stop 782 sending Binding Updates with BID, or SHOULD use O flag for the 783 peer sending the Binding Acknowledgment. 785 5.9. Receiving Binding Refresh Request 787 The verification of a Binding Refresh Request is the same as in 788 Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a 789 Binding Refresh Request is described in section Section 6.4. 791 If a mobile node receives a Binding Refresh Request with a Binding 792 Unique Identifier sub-option, this Binding Refresh Request requests a 793 binding indicated by the BID. The mobile node SHOULD update only the 794 respective binding. The mobile node MUST put a Binding Unique 795 Identifier sub-option into the Binding Update sent to refresh the 796 entry. 798 If no Binding Unique Identifier sub-option is present in a Binding 799 Refresh Request, the mobile node sends a Binding Update according to 800 its Binding Update List for the requesting node. On the other hand, 801 if the mobile node does not have any Binding Update List entry for 802 the requesting node, the mobile node needs to register either a 803 single binding or multiple bindings depending on its binding 804 management policy. 806 5.10. Sending Packets to Home Agent 808 When a multihomed mobile node sends packets to its home agent, there 809 are conceptually two ways to construct packets. 811 1. Using Home Address Option. (required additional 24 bytes) 813 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) 815 Beside the additional size of packets, no difference is observed 816 between these two. The routing path is always the same and no 817 redundant path such as dog-leg route or triangular route occurs. 819 However, in this document, the mobile node is capable of using 820 multiple care-of addresses for outgoing packets. This is problem in 821 home agent side because they must verify the Care-of address for all 822 the packets received from the mobile node. Therefore, the mobile 823 node SHOULD use the bi-directional tunnel even if it registers a 824 binding(s) to the home agent. When it uses the Home Address option, 825 the home agent MAY reject the packets because the Care-of address in 826 the packet and the first found Care-of Address in the binding Cache 827 of the home agent are different. The mobile node then receive 828 Binding Error for the packet drop. 830 5.11. Bootstrapping 832 When a mobile node bootstraps and registers multiple bindings at the 833 first time, it SHOULD set O flag in the Binding Unique Identifier 834 sub-option. when old bindings still exists at the Home Agent and 835 Correspondent Nodes, the mobile node has no way to verify which 836 bindings are left as a garbage in those nodes. This scenario happens 837 when a mobile node reboots without correct deregistration. If O flag 838 is used, all the bindings are replaced to the new binding(s). Thus, 839 the garbage bindings are surely removed by the first Binding Update. 840 XXX SEQ 842 6. Home Agent and Correspondent Node Operation 844 6.1. Searching Binding Cache with Binding Unique Identifier 846 If either a correspondent node or a home agent has multiple bindings 847 for a mobile node in their binding cache database, it can use any of 848 the bindings to communicate with the mobile node. How to select the 849 most suitable binding from the binding cache database is out of scope 850 in this document. 852 Whenever a correspondent node searches a binding cache for a home 853 address, it SHOULD uses both the Home Address and the BID as the 854 search key if it knows the corresponding BID. If the priority is 855 available for a binding cache entry, the priority can be used as 856 additional key to search a binding. In the example below, if a 857 correspondent node searches the binding with the Home Address and 858 BID2, it gets binding2 for this mobile node. 860 binding1 [a:b:c:d::EUI, care-of address1, BID1] 861 binding2 [a:b:c:d::EUI, care-of address2, BID2] 862 binding3 [a:b:c:d::EUI, care-of address3, BID3] 864 Figure 2: Searching the Binding Cache 866 A correspondent node basically learns the BID when it receives a 867 Binding Unique Identifier sub-option. At the time, the correspondent 868 node MUST look up its binding cache database with the Home Address 869 and the BID retrieved from the Binding Update. If the correspondent 870 node does not know the BID, it searches for a binding with only a 871 Home Address as performed in Mobile IPv6. In such case, the first 872 matched binding is found. But which binding entry is returned for 873 the normal search depends on implementations. If the correspondent 874 node does not desire to use multiple bindings for a mobile node, it 875 can simply ignore the BID. 877 6.2. Receiving CoTI and Sending CoT 879 When a correspondent node receives a Care-of Test Init message which 880 contains a Binding Unique Identifier sub-option, it MUST process it 881 with following steps. 883 First of all, the Care-of Test Init message is verified according to 884 [2]. The Binding Unique Identifier sub-option MUST be processed as 885 follows: 887 o If a correspondent node does not understand a Binding Unique 888 Identifier sub-option, it will ignore and skip this option. The 889 calculation of a care-of keygen token will thus be done without a 890 BID value. After regular processing of HoTI message according to 891 [2], it will return a Care-of Test message without use of a 892 Binding Unique Identifier sub-option. The mobile node can thus 893 know whether its correspondent can process or not the Binding 894 Unique Identifier sub-option by checking if such option is present 895 in the Care-of Test message. 897 o If C flag is set in the sub-option, the Correspondent Node SHOULD 898 NOT calculate a care-of keygen token and MUST include a Binding 899 Unique Identifier sub-option which status value set to [MCOA BULK 900 REGISTRATION PROHIBITED] in the returned Care-of Test message. 901 All the fields of the Care-of Test message MUST be set to zero. 902 All the Binding Unique Identifier sub-options SHOULD be copied 903 from the received one except for the Status Field and the Care-of 904 Address field. 906 o If O flag is set in the sub-option, the Correspondent Node can 907 ignore this flag and can process it as described in the next 908 bullet. 910 o Otherwise, the correspondent node MUST include a Binding Unique 911 Identifier sub-option which status value MUST be set to [MCOA 912 ACCEPTING BID] in the returning a Care-of Test message. The 913 Binding Unique Identifier sub-option SHOULD be copied from the 914 received one except for the Status Field and the Care-of address 915 Field. 917 The calculation of a care-of keygen token is modified as follows. 918 The BID is used to generate the care-of keygen token. 920 care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | 921 nonce | BID | 1))) 923 6.3. Processing Binding Update 925 If a Binding Update does not contain a Binding Unique Identifier sub- 926 option, its processing is same as in RFC 3775. But if the receiver 927 already has multiple bindings for the Home Address, it MUST replace 928 all existing bindings by the received binding. As a result, the 929 receiver node MUST have only a binding for the mobile node. If the 930 Binding Update is for de-registration, the receiver MUST delete all 931 existing bindings from its Binding Cache. 933 On the other hand, if a Binding Update contains a Binding Unique 934 Identifier sub-option(s), the Binding Update is also validated 935 according to section 9.5.1 of [2] and the following step. 937 o If the home flag is set in the Binding Update, the home agent MUST 938 carefully operate DAD for the received Home Address. If the home 939 agent has already had a binding(s) for the Mobile Node, it MUST 940 avoid running DAD when it receives the Binding Update. 942 If a Binding Unique Identifier sub-option(s) is present, the receiver 943 node MUST process the sub-option. 945 o The length value is examined. The length value MUST be either 4 946 or 20 depending on C flag. If the length is incorrect, the 947 receiver MUST rejects the Binding Update and returns all the 948 received Binding Unique Identifier sub-option which status value 949 is set to [MCOA INCOMPLIANT]. The status field of the Binding 950 Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. 952 o When C flag is set, the receiver MUST support the bulk 953 registration. Otherwise, it MUST reject the Binding Update and 954 returns all the received Binding Unique Identifier sub-option 955 which status value is set to [MCOA REASON UNSPECIFIED]. The 956 status field of the Binding Acknowledgment MUST be set to [MCOA 957 BULK REGISTRATION NOT SUPPORTED]. 959 o When either C or O flag is set, the flags field of all the Binding 960 Unique Identifier sub-option stored in the same Binding Update 961 MUST be equal. Otherwise, the receiver MUST reject the Binding 962 Update and returns all the received Binding Unique Identifier sub- 963 option which status value is set to [MCOA REASON UNSPECIFIED]. 964 The status field of the Binding Acknowledgment MUST be set to 965 [MCOA FLAG CONFLICTS]. 967 o When C flag is specified, the care-of address MUST be given in the 968 Binding Unique Identifier sub-option. Otherwise, the receiver 969 MUST reject the Binding Update and returns all the received 970 Binding Unique Identifier sub-option which status value is set to 971 [MCOA INCOMPLIANT]. The status field of the Binding 972 Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. 974 o If the Lifetime field of the Binding Update is zero, the receiver 975 node deletes the binding entry which BID is same as BID sent by 976 the Binding Unique Identifier sub-option. If the receiver node 977 does not have appropriate binding which BID is matched with the 978 Binding Update, it MUST reject this de-registration Binding 979 Update. If the receiver is a Home Agent, it SHOULD also return a 980 Binding Acknowledgment to the mobile node, in which the Status 981 field is set to [not Home Agent for this mobile node, 133]. If O 982 flag is set in the deregistering Binding Update, the receiver can 983 ignore this flag for deregistration. 985 o If the Lifetime field is not zero, the receiver node registers a 986 binding with the specified BID as a mobile node's binding. The 987 Care-of address is picked from the Binding Update packet as 988 follows: 990 * If C flag is set in the Binding Unique Identifier sub-option, 991 the care-of address must be taken from the care-of address 992 field in each Binding Unique Identifier sub-option. 994 * If C flag is not set in the Binding Unique Identifier sub- 995 option, the care-of address must be taken from the Source 996 Address field of the IPv6 header. 998 * If C flag is not set and an alternate care-of address is 999 present, the care-of address is taken from the Alternate 1000 Care-of address sub-option. 1002 o Once the care-of address(es) has been retrieved from the Binding 1003 Update, it starts registering binding(s). 1005 * Only if O flag is set in the sub-option, the home agent first 1006 removes all the existing bindings and registers the received 1007 bindings. 1009 * If the receiver has a regular binding which does not have BID 1010 for the mobile node, it de-registers the regular binding and 1011 registers a new binding including BID according to the Binding 1012 Update. In this case, the receiver MUST specify [MCOA BID 1013 CONFLICT] to the Binding Unique Identifier sub-option which is 1014 replied to the Mobile Node. The Status field of the replying 1015 Binding Acknowledgment MUST be set to [Binding Update ACCEPTED, 1016 0]. 1018 * If the receiver node has already registered the binding which 1019 BID is matched with requesting BID, then it MUST update the 1020 binding with the Binding Update. 1022 * If the receiver does not have a binding entry which BID is 1023 matched with the requesting BID, it registers a new binding for 1024 the BID. 1026 If all the above operations are successfully finished, the Binding 1027 Acknowledgment containing the Binding Unique Identifier sub-options 1028 MUST be replied to the mobile node if A flag is set in the Binding 1029 Acknowledgment. Whenever a Binding Acknowledgment is returned, all 1030 the Binding Unique Identifier sub-options stored in the Binding 1031 Update MUST be copied to the Binding Acknowledgment. The Care-of 1032 address field of each Binding Unique Identifier sub-option, however, 1033 can be omitted, because the mobile node can match a corresponding 1034 binding update list by using BID. 1036 6.4. Sending Binding Refresh Request 1038 When either a correspondent node or home agent notices that a 1039 registered binding will be expired soon, it MAY send a Binding 1040 Refresh Request. If the registered binding has BID, the 1041 correspondent node SHOULD contain a Binding Unique Identifier sub- 1042 option in the Binding Refresh Request. Then, the Correspondent Node 1043 can receive a Binding Update with a Binding Unique Identifier sub- 1044 option and can update only the particular binding. If the registered 1045 binding does not have BID, then the correspondent node sends a 1046 Binding Refresh Request without the sub-option. 1048 6.5. Receiving Packets from Mobile Node 1050 When a correspondent node receives packets with a Home Address 1051 destination option from a mobile node, it MUST check that the care-of 1052 address appeared in the Source Address field MUST be equal to one of 1053 the care-of addresses in the binding cache entry. If no binding is 1054 found, the packets MUST be silently discarded and MUST send a Binding 1055 Error message according to RFC3775. This verification MUST NOT be 1056 done for a Binding Update. 1058 7. Network Mobility Applicability 1060 Support of multihomed mobile routers is advocated in the NEMO working 1061 group (see R12 "The solution MUST function for multihomed MR and 1062 multihomed mobile networks" in [8]. 1064 Issues regarding mobile routers with multiple interfaces and other 1065 multihoming configurations are documented in [11]. 1067 Since the binding management mechanisms are the same for a mobile 1068 host operating Mobile IPv6 and for a mobile router operating NEMO 1069 Basic Support (RFC 3963), our extensions can also be used to deal 1070 with multiple care-of addresses registration sent from a multihomed 1071 mobile router. 1073 8. IPsec and IKEv2 interaction 1075 Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to 1076 protect signaling messages like Binding Updates, Binding 1077 Acknowledgments and return routability messages. IPsec may also be 1078 used protect all reverse tunneled data traffic. The Mobile IPv6- 1079 IKEv2 specification [9] specifies how IKEv2 can be used to setup the 1080 required IPsec security associations. The following assumptions were 1081 made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with 1082 respect to the use of IKEv2 and IPsec. 1084 o There is only one primary care-of address per mobile node. 1086 o The primary care-of address is stored in the IPsec database for 1087 tunnel encapsulation and decapsulation. 1089 o When the home agent receives a packet from the mobile node, the 1090 source address is verified against the care-of address in the 1091 corresponding binding cache entry. If the packet is a reverse 1092 tunneled packet from the mobile node, the care-of address check is 1093 done against the source address on the outer IPv6 header. The 1094 reverse tunnel packet could either be a tunneled HoTi message or 1095 tunneled data traffic to the correspondent node. 1097 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1098 the care-of address. The IKE SA is based on the care-of address 1099 of the mobile node. 1101 The above assumptions may not be valid when multiple care-of 1102 addresses are used by the mobile node. In the following sections, 1103 the main issues with the use of multiple care-of address with IPsec 1104 are addressed. 1106 8.1. Use of Care-of Address in the IKEv2 exchange 1108 For each home address the mobile node sets up security associations 1109 with the home agent, the mobile node must pick one care-of address 1110 and use that as the source address for all IKEv2 messages exchanged 1111 to create and maintain the IPsec security associations associated 1112 with the home address. The resultant IKEv2 security association is 1113 created based on this care-of address. 1115 If the mobile node needs to change the care-of address, it just sends 1116 a Binding Update with the care-of address it wants to use, with the 1117 corresponding Binding Unique Identifier sub-option, and with the 'K' 1118 bit set. This will force the home agent to update the IKEv2 security 1119 association to use the new care-of address. If the 'K' bit is not 1120 supported on the mobile node or the home agent, the mobile node MUST 1121 re-establish the IKEv2 security association with the new care-of 1122 address. This will also result in new IPsec security associations 1123 being setup for the home address. 1125 8.2. Transport Mode IPsec protected messages 1127 For Mobile IPv6 signaling message protected using IPsec in transport 1128 mode, the use of a particular care-of address among multiple care-of 1129 addresses does not matter for IPsec processing. 1131 For Mobile Prefix Discovery messages, RFC 3775 requires the home 1132 agent to verify that the mobile node is using the care-of address 1133 that is in the binding cache entry that corresponds to the mobile 1134 node's home address. If a different address is used as the source 1135 address, the message is silently dropped by the home agent. This 1136 document requires the home agent implementation to process the 1137 message as long as the source address is is one of the care-of 1138 addresses in the binding cache entry for the mobile node. 1140 8.3. Tunnel Mode IPsec protected messages 1142 The use of IPsec in tunnel mode with multiple care-of address 1143 introduces a few issues that require changes to how the mobile node 1144 and the home agent send and receive tunneled traffic. The route 1145 optimization mechanism described in RFC 3775 mandates the use of 1146 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1147 mobile node and the home agent may also choose to protect all reverse 1148 tunneled payload traffic with IPsec in tunnel mode. The following 1149 sections address multiple care-of address support for these two types 1150 of messages. 1152 8.3.1. Tunneled HoTi and HoT messages 1154 The mobile node MAY use the same care-of address for all HoTi 1155 messages sent reverse tunneled through the home agent. The mobile 1156 node may use the same care-of address irrespective of which 1157 correspondent node the HoTi message is being sent. RFC 3775 requires 1158 the home agent to verify that the mobile node is using the care-of 1159 address that is in the binding cache entry, when it receives a 1160 reverse tunneled HoTi message. If a different address is used as the 1161 source address, the message is silently dropped by the home agent. 1162 This document requires the home agent implementation to decapsulate 1163 and forward the HoTi message as long as the source address is one of 1164 the care-of addresses in the binding cache entry for the mobile node. 1166 When the home agent tunnels a HoT message to the mobile node, the 1167 care-of address used in the outer IPv6 header is not relevant to the 1168 HoT message. So regular IPsec tunnel encapsulation with the care-of 1169 address known to the IPsec implementation on the home agent is 1170 sufficient. 1172 8.3.2. Tunneled Payload Traffic 1174 When the mobile sends and receives multiple traffic flows protected 1175 by IPsec to different care-of addresses, the use of the correct 1176 care-of address for each flow becomes important. Support for this 1177 requires the following two considerations on the home agent. 1179 o When the home agent receives a reverse tunneled payload message 1180 protected by IPsec in tunnel mode, it must check that the care-of 1181 address is one of the care-of addresses in the binding cache 1182 entry. According to RFC 4306, the IPsec implementation on the 1183 home agent does not check the source address on the outer IPv6 1184 header. Therefore the care-of address used in the reverse 1185 tunneled traffic can be different from the care-of address used as 1186 the source address in the IKEv2 exchange. However, the Mobile 1187 IPv6 stack on the home agent MUST verify that the source address 1188 is one of the care-of addresses registered by the mobile node 1189 before decapsulating and forwarding the payload traffic towards 1190 the correspondent node. 1192 o For tunneled IPsec traffic from the home agent to the mobile node, 1193 The IPsec implementation on the home agent may not be aware of 1194 which care-of address to use when performing IPsec tunnel 1195 encapsulation. The Mobile IP stack on the home agent must specify 1196 the tunnel end point for the IPsec tunnel. This may require tight 1197 integration between the IPsec and Mobile IP implementations on the 1198 home agent. 1200 9. Security Considerations 1202 TBD 1204 10. IANA Considerations 1206 TBD 1208 11. Acknowledgments 1210 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 1211 Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti 1212 Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen 1213 (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), 1214 Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), 1215 Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab. 1216 at KEIO University, and WIDE project for their contributions. 1218 12. References 1220 12.1. Normative References 1222 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 1223 (IPv6)", IETF RFC 2460, December 1998. 1225 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1226 IPv6", RFC 3775, June 2004. 1228 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1229 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1230 January 2005. 1232 [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1233 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1234 draft-ietf-monami6-mipv6-analysis-02 (work in progress), 1235 February 2007. 1237 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 1238 RFC 3753, June 2004. 1240 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1241 draft-ietf-nemo-terminology-06 (work in progress), 1242 November 2006. 1244 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1245 Levels", BCP 14, RFC 2119, March 1997. 1247 [8] Ernst, T., "Network Mobility Support Goals and Requirements", 1248 draft-ietf-nemo-requirements-06 (work in progress), 1249 November 2006. 1251 [9] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1252 IKEv2 and the revised IPsec Architecture", 1253 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1254 December 2006. 1256 12.2. Informative References 1258 [10] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1259 Kuladinithi, "Motivations and Scenarios for Using Multiple 1260 Interfaces and Global Addresses", 1261 draft-ietf-monami6-multihoming-motivation-scenario-01 (work in 1262 progress), October 2006. 1264 [11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming 1265 in Network Mobility Support", 1266 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1267 June 2006. 1269 [12] Soliman, H., "Flow Bindings in Mobile IPv6", 1270 draft-soliman-monami6-flow-binding-02 (work in progress), 1271 September 2006. 1273 Appendix A. Example Configurations 1275 In this section, we describe typical scenarios when a mobile node has 1276 multiple network interfaces and acquires multiple Care-of Addresses 1277 bound to a Home Address. 1279 The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. 1280 MN has 3 different interfaces and possibly acquires care-of addresses 1281 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 1282 care-of address. 1284 Figure 3 depicts the scenario where all interfaces of the mobile node 1285 are attached to foreign links. After binding registrations, the home 1286 agent (HA) and the Correspondent Node (CN) have the binding entries 1287 listed in their binding cache database. The mobile node can utilize 1288 all the interfaces. 1290 +----+ 1291 | CN | 1292 +--+-+ 1293 | 1294 +---+------+ +----+ 1295 +------+ Internet |----------+ HA | 1296 | +----+---+-+ +--+-+ 1297 CoA2| | | | Home Link 1298 +--+--+ | | ------+------ 1299 | MN +========+ | 1300 +--+--+ CoA1 | 1301 CoA3| | 1302 +---------------+ 1304 Binding Cache Database: 1305 home agent's binding (Proxy neighbor advertisement is active) 1306 binding [a:b:c:d::EUI care-of address1 BID1] 1307 binding [a:b:c:d::EUI care-of address2 BID2] 1308 binding [a:b:c:d::EUI care-of address3 BID3] 1309 correspondent node's binding 1310 binding [a:b:c:d::EUI care-of address1 BID1] 1311 binding [a:b:c:d::EUI care-of address2 BID2] 1312 binding [a:b:c:d::EUI care-of address3 BID3] 1314 Figure 3: Multiple Interfaces Attached to a Foreign Link 1316 Figure 4 depicts the scenario where MN returns home with one of its 1317 interfaces. After the successful de-registration of the binding to 1318 HA, HA and CN have the binding entries listed in their binding cache 1319 database of Figure 4. MN can communicate with the HA through only 1320 the interface attached to the home link. On the other hand, the 1321 mobile node can communicate with CN from the other interfaces 1322 attached to foreign links (i.e. route optimization). Even when MN is 1323 attached to the home link, it can still send Binding Updates for 1324 other active care-of addresses (CoA2 and CoA3). If CN has bindings, 1325 packets are routed to each Care-of Addresses directly. Any packet 1326 arrived at HA are routed to the primary interface. 1328 +----+ 1329 | CN | 1330 +--+-+ 1331 | 1332 +---+------+ +----+ 1333 +------+ Internet |----------+ HA | 1334 | +--------+-+ +--+-+ 1335 CoA2| | | Home Link 1336 +--+--+ | --+---+------ 1337 | MN +========+ | | 1338 +--+--+ | | | 1339 CoA3| +---|-----------+ 1340 +---------------+ 1342 Binding Cache Database: 1343 home agent's binding (Proxy neighbor advertisement is inactive) 1344 none 1345 correspondent node's binding 1346 binding [a:b:c:d::EUI care-of address2 BID2] 1347 binding [a:b:c:d::EUI care-of address3 BID3] 1349 Figure 4: One of Interface Attached to Home Link and Returning Home 1351 Figure 5 depicts the scenario where MN disables the interface 1352 attached to the home link and communicates with the interfaces 1353 attached to foreign links. The HA and the CN have the binding 1354 entries listed in their binding cache database. MN disable the 1355 interface attached to the home link, because the HA still defends the 1356 home address of the MN by proxy neighbor advertisements. All packets 1357 routed to the home link are intercepted by the HA and tunneled to the 1358 other interfaces attached to the foreign link according to the 1359 binding entries. 1361 +----+ 1362 | CN | 1363 +--+-+ 1364 | 1365 +---+------+ +----+ 1366 +------+ Internet |----------+ HA | 1367 | +----+-----+ +--+-+ 1368 CoA2| | | Home Link 1369 +--+--+ | --+---+------ 1370 | MN +========+ | 1371 +--+--+ CoA1 | 1372 | | 1373 +---------------------------+ 1374 (Disable interface) 1376 Binding Cache Database: 1377 home agent's binding (Proxy neighbor advertisement is active) 1378 binding [a:b:c:d::EUI care-of address1 BID1] 1379 binding [a:b:c:d::EUI care-of address2 BID2] 1380 correspondent node's binding 1381 binding [a:b:c:d::EUI care-of address1 BID1] 1382 binding [a:b:c:d::EUI care-of address2 BID2] 1384 Figure 5: One of Interface Attached to Home Link and Not Returning 1385 Home 1387 Figure 6 depicts the scenario where multiple interfaces of MN are 1388 attached to the home link. The HA and CN have the binding entries 1389 listed in Figure 6 in their binding cache database. The MN can not 1390 use the interface attached to a foreign link unless a CN has a 1391 binding for the interface. All packets which arrive at the HA are 1392 routed to one of the MN's interfaces attached to the home link. 1394 +----+ 1395 | CN | 1396 +--+-+ 1397 | 1398 +---+------+ +----+ 1399 +------+ Internet |----------+ HA | 1400 | +----------+ +--+-+ 1401 CoA2| | Home Link 1402 +--+--+ --+----+---+------ 1403 | MN +===================+ | 1404 +--+--+ | 1405 | | 1406 +---------------------------+ 1408 Binding Cache Database: 1409 home agent's binding (Proxy neighbor advertisement is inactive) 1410 none 1411 correspondent node's binding 1412 binding [a:b:c:d::EUI care-of address2 BID2] 1414 Figure 6: Several Interfaces Attached to Home Link and Returning Home 1416 Figure 7 depicts the scenario where interfaces of MN are attached to 1417 the foreign links. One of foreign link is managed by the home agent. 1418 The HA and CN have the binding entries listed in Figure 7 in their 1419 binding cache database. The home agent advertises a prefix which is 1420 other than home prefix. The mobile node will generate a care-of 1421 address from the prefix and registers it to the home agent. Even if 1422 the mobile node attaches to a foreign link, the link is managed by 1423 its home agent. It will tunnel the packets to the home agent, but 1424 the home agent is one-hop neighbor. The cost of tunnel is 1425 negligible. If the mobile node wants to utilize not only an 1426 interface attached to home but also interfaces attached to foreign 1427 link, it can use this foreign link of the home agent to return a one 1428 hop foreign link on behalf of a home link. This is different from 1429 the general returning home, but this enable the capability of using 1430 interfaces attached to both home and foreign link without any 1431 modifications to Mobile IPv6 and NEMO basic support. 1433 +----+ 1434 | CN | 1435 +--+-+ 1436 | 1437 +---+------+ +----+ 1438 +------+ Internet |----------+ HA | 1439 | +----+-----+ ++-+-+ 1440 CoA2| | | | Home Link 1441 +--+--+ | ----|-+------ 1442 | MN +========+ | 1443 +--+--+ CoA1 ---+-+------ 1444 CoA3 | | Foreign Link 1445 +---------------------------+ 1447 Binding Cache Database: 1448 home agent's binding (Proxy neighbor advertisement is active) 1449 binding [a:b:c:d::EUI care-of address1 BID1] 1450 binding [a:b:c:d::EUI care-of address2 BID2] 1451 binding [a:b:c:d::EUI care-of address3 BID3] 1452 correspondent node's binding 1453 binding [a:b:c:d::EUI care-of address1 BID1] 1454 binding [a:b:c:d::EUI care-of address2 BID2] 1455 binding [a:b:c:d::EUI care-of address3 BID3] 1457 Figure 7: Emulating to Utilize Interfaces Attached to both Home and 1458 Foreign Links 1460 Appendix B. Changes From Previous Versions 1462 Changes from draft-ietf-monami6-multiplecoa-01.txt 1464 o Updating the text of BID definition. The older text was unclear 1465 whether a BID is assigned to a binding or a interface. It is now 1466 clearly defined that BID is assigned to each binding. 1468 o Removing R flag according to complexity. 1470 o Introducing O (Overwrite) flag. This flag is useful when a MN 1471 sends all the active CoAs to HA or CN all at once. It also useful 1472 when a MN reboots and sends a first BU to HA and CN. see 1473 Section 5.11 in detail. 1475 o Removing the Binding Error texts, since there is no way to know 1476 BID when BE is sent by CN. 1478 o Clearing up the Status code of Binding Unique Identifier sub- 1479 option and Binding Acknowledgment. Renewing the texts in 1480 Section 6.3. 1482 o Adding new section "Sending Packets to HA" and "Receiving Packets 1483 from MN". 1485 o adding how to handle correspondent nodes which do not support MCoA 1486 extension in Section 5.2. 1488 o Return routability is now extended to carry and use BID to 1489 generate Authenticator. Section 6.2 and Section 5.2 are added. 1491 o Adding a new section: IPsec and IKEv2 interaction. 1493 o Shortening Introduction. We also remove several useless texts in 1494 this doc. 1496 Authors' Addresses 1498 Ryuji Wakikawa 1499 Keio University 1500 Department of Environmental Information, Keio University. 1501 5322 Endo 1502 Fujisawa, Kanagawa 252-8520 1503 Japan 1505 Phone: +81-466-49-1100 1506 Fax: +81-466-49-1395 1507 Email: ryuji@sfc.wide.ad.jp 1508 URI: http://www.wakikawa.org/ 1510 Thierry Ernst 1511 INRIA 1512 INRIA Rocquencourt 1513 Domaine de Voluceau B.P. 105 1514 Le Chesnay, 78153 1515 France 1517 Phone: +33-1-39-63-59-30 1518 Fax: +33-1-39-63-54-91 1519 Email: thierry.ernst@inria.fr 1520 URI: http://www.nautilus6.org/~thierry 1522 Kenichi Nagami 1523 INTEC NetCore Inc. 1524 1-3-3, Shin-suna 1525 Koto-ku, Tokyo 135-0075 1526 Japan 1528 Phone: +81-3-5565-5069 1529 Fax: +81-3-5565-5094 1530 Email: nagami@inetcore.com 1532 Vijay Devarapalli 1533 Azaire Networks 1534 3121 Jay Street 1535 Santa Clara, CA 95054 1536 USA 1538 Email: vijay.devarapalli@azairenet.com 1540 Full Copyright Statement 1542 Copyright (C) The IETF Trust (2007). 1544 This document is subject to the rights, licenses and restrictions 1545 contained in BCP 78, and except as set forth therein, the authors 1546 retain all their rights. 1548 This document and the information contained herein are provided on an 1549 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1550 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1551 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1552 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1553 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1556 Intellectual Property 1558 The IETF takes no position regarding the validity or scope of any 1559 Intellectual Property Rights or other rights that might be claimed to 1560 pertain to the implementation or use of the technology described in 1561 this document or the extent to which any license under such rights 1562 might or might not be available; nor does it represent that it has 1563 made any independent effort to identify any such rights. Information 1564 on the procedures with respect to rights in RFC documents can be 1565 found in BCP 78 and BCP 79. 1567 Copies of IPR disclosures made to the IETF Secretariat and any 1568 assurances of licenses to be made available, or the result of an 1569 attempt made to obtain a general license or permission for the use of 1570 such proprietary rights by implementers or users of this 1571 specification can be obtained from the IETF on-line IPR repository at 1572 http://www.ietf.org/ipr. 1574 The IETF invites any interested party to bring to its attention any 1575 copyrights, patents or patent applications, or other proprietary 1576 rights that may cover technology that may be required to implement 1577 this standard. Please address the information to the IETF at 1578 ietf-ipr@ietf.org. 1580 Acknowledgment 1582 Funding for the RFC Editor function is provided by the IETF 1583 Administrative Support Activity (IASA).