idnits 2.17.1 draft-ietf-monami6-multiplecoa-03.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 1492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1516. 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 6 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 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: When the Mobile Node returns home, it de-registers a binding for the interface. While the bindings for the interfaces attached to the foreign link are still active. Intercepting packets, the Home Agent can decide whether it tunnels to the foreign interface or routes to the home interface of the Mobile Node. To do so, the Home Agent must know that the Mobile Node is back to the home link. However, if the binding is deleted according to [2], there is no way for the Home Agent to know that the Mobile Node is at the home, too. The Home Agent SHOULD invalidate the binding for the interface attached to the home link and MAY NOT delete it. It can alternatively mark that the Mobile Node is at the home link, too. As an example, the Home Agent inserts the Home Address of the Mobile Node in the Care-of Address field of the Mobile Node. The binding is named "Home Binding" in this doc. The Home Agent MAY manage this home binding as same as the other binding entry in terms of lifetime validation, etc. The Mobile Node MAY send multiple binding de- registration to keep this home binding active. Alternatively, the Home Agent can use infinity lifetime for the lifetime of the home binding. When the Mobile Node leaves the Home Link, it can update the home binding to the normal binding. Before that, the Home Agent believes the Mobile Node is at the home and may route packets for the Mobile Node to the Home Link. -- 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 (July 9, 2007) is 6135 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 977 -- Looks like a reference, but probably isn't: 'REASON UNSPECIFIED' on line 978 == Missing Reference: '128' is mentioned on line 978, 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 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: January 10, 2008 INRIA 6 K. Nagami 7 INTEC NetCore 8 V. Devarapalli 9 Azaire Networks 10 July 9, 2007 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-03.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 January 10, 2008. 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 . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . 19 88 5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 20 89 5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 90 5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21 92 6. Home Agent and Correspondent Node Operation . . . . . . . . . 22 93 6.1. Searching Binding Cache with Binding Unique Identifier . . 22 94 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22 95 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23 96 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 26 97 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26 99 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27 101 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28 102 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28 103 8.2. Transport Mode IPsec protected messages . . . . . . . . . 29 104 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29 105 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29 106 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 115 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 117 Appendix A. Example Configurations . . . . . . . . . . . . . . . 34 119 Appendix B. Changes From Previous Versions . . . . . . . . . . . 38 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 122 Intellectual Property and Copyright Statements . . . . . . . . . . 40 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. This restriction is 317 related to the Proxy NDP operation on a Home Agent. The Home Agent 318 needs to defend a mobile node's home address by the proxy NDP for 319 packet interception, while the mobile node defends its home address 320 by regular NDP to send and receive packets at the interface attached 321 to the home link. Two nodes, Home Agent and Mobile Node, compete ND 322 state. This will causes address duplication problem at the end. 323 This document recommends not to use the Proxy NDP for this scenario. 324 When one of the Mobile Node's interface is attached to the home link 325 and the other is attached to the foreign link and it decides to 326 utilize both interfaces, it notifies the Home Agent using the H flag 327 which means the Mobile Node is attached to the home link. If the 328 proxy NDP is disabled, the main problem can be solved. In the 329 Multiple Care-of Address Registration case, the elimination of Proxy 330 NDP enable that Mobile Node and Home Agent maintain multiple 331 bindings, one of the Mobile Node's interface is attached to the home 332 link and the other is attached to the foreign link. 334 4. Mobile IPv6 Extensions 336 In this section are described the changes to Mobile IPv6 necessary to 337 manage multiple bindings bound to a same Home Address. 339 4.1. Binding Cache Structure and Binding Update List 341 The following additional items are required in the binding cache and 342 binding update list structure. 344 BID 346 The value MUST be zero if the Binding Unique identifier does not 347 appear in a Binding Update. 349 4.2. Message Format Changes 351 4.2.1. Binding Unique Identifier sub-option 353 The Binding Unique Identifier sub-option is included in the Binding 354 Update, Binding Acknowledgment, Binding Refresh Request, and Care-of 355 Test Init and Care-of Test message. 357 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type = TBD | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Binding Unique ID (BID) | Status |C|O|H|Reserved | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 364 + + 365 + care-of address (CoA) + 366 + + 367 +---------------------------------------------------------------+ 369 Figure 1: BID Sub-Option 371 Type 373 Type value for Binding Unique Identifier will be assigned later. 375 Length 376 Length value MUST be 4 when C flag is unset. On the other hand if 377 C flag is set, Length value MUST be set to 20. 379 Binding Unique ID (BID) 381 The BID which is assigned to the binding carried in the Binding 382 Update with this sub-option. BID is 16-bit unsigned integer. A 383 value of zero is reserved. 385 Status 387 When the Binding Unique Identifier sub-option is included in a 388 Binding Acknowledgment, this field indicates the status 389 correspondent to each binding. The mobile node knows the 390 registration status of each binding. The status is 8-bit unsigned 391 integer. The possible status codes are listed below. If the 392 status field is below 128, it indicates that the binding 393 registration was successful. 395 MCOA ACCEPTING BID (0) 397 The registration of the correspond binding is successfully 398 operated. 400 MCOA REASON UNSPECIFIED (128) 402 Registration failed because of unknown errors 404 MCOA INCOMPLIANT (129) 406 Registration failed because Binding Unique Identifier sub- 407 option is not compliant. 409 MCOA BID CONFLICT (130) 411 It indicates that a regular binding (ie without the BID set) is 412 already registered for the home address, and is conflicting 413 with a received Binding Update which BID was set. 415 care-of address (C) flag 417 When this flag is set, a mobile node can store a Care-of Address 418 corresponding to the BID in the Binding Unique Identifier sub- 419 option. This flag must be used whenever a mobile node sends 420 multiple bindings in a single Binding Update, i.e. bulk 421 registration. 423 Overwrite (O) flag 425 When this flag is set, a mobile node requests a home agent to 426 replace all the bindings to binding entries stored in a Binding 427 Update. This flag is valid for Home Registration and 428 Deregistration. 430 Home Binding (H) flag 432 This flag indicates that the mobile node is attached to the home 433 link. This flag is valid for Home Registration, Deregistration 434 and bulk registration. 436 Reserved 438 5 bits Reserved field. Reserved field must be set with all 0. 440 Care-of Address 442 Only when C flag is set, only a single Care-of Address matched to 443 the BID is stored. This field is valid only if a Binding Unique 444 Identifier sub-option is stored in Binding Update message. 445 Otherwise, this field can be omitted. The receiver SHOULD ignore 446 this field if the sub-option is presented in other than Binding 447 Update. 449 4.2.2. Binding Acknowledgment 451 The message format of Binding Acknowledgment does not change, but 452 operations listed below are added in this draft. 454 If a Binding Unique Identifier sub-option is included in a Binding 455 Update with the A flag set, a receiver MUST reply a Binding 456 Acknowledgment. The receiver node MUST include the same Binding 457 Unique Identifier sub-option(s) in the Binding Acknowledgment. The 458 receiver MUST specify relative status in the Status field of the 459 Binding Acknowledgment. 461 There are two status fields: the Status field of a Binding 462 Acknowledgment and the Status field of a Binding Unique Identifier 463 sub-option. In this specification, the Status field of a Binding 464 Acknowledgment indicates the registration status of a "Binding 465 Update". The status value in the Binding Acknowledgment is for all 466 Binding Unique Identifier sub-options stored in the Binding 467 Acknowledgment. For example, if the status value is 134 in the 468 status field of the Binding Acknowledgment, all the care-of addresses 469 stored in the Binding Unique Identifier sub-options are rejected 470 because the duplicate address detection has failed on the home agent. 472 The status field of the Binding Unique Identifier sub-option only 473 informs the receiver about the binding relative to the sub-option. 474 Whether each Care-of address has been successfully registered 475 successfully or not is given in the Status field of each Binding 476 Unique Identifier sub-option. 478 New status values for the status field of a Binding Acknowledgment 479 are defined for handling the multiple Care-of Addresses registration: 481 MCOA PROHIBITED(TBD) 483 It implies the multiple care-of address registration is 484 administratively prohibited. 486 MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 488 The bulk binding registration is not supported. 490 MCOA FLAG CONFLICTS (TBD) 492 The flags of the sub-options presented in a Binding Update 493 conflicts. 495 5. Mobile Node Operation 497 5.1. Management of Care-of Addresses and Binding Unique Identifier 499 There are two cases when a mobile node has several Care-of Addresses: 501 1. A mobile node uses several physical network interfaces and 502 acquires a care-of address on each of its interfaces. 504 2. A mobile node uses a single physical network interface, but 505 multiple prefixes are announced on the link the interface is 506 attached to. Several global addresses are configured on this 507 interface for each of the announced prefixes. 509 The difference between the above two cases is only a number of 510 physical network interfaces and therefore does not matter in this 511 document. The Identification number is used to identify a binding. 512 To implement this, a mobile node MAY assign an identification number 513 for each care-of addresses. How to assign an identification number 514 is up to implementers. 516 A mobile node assigns a BID to each care-of address when it wants to 517 register them simultaneously with its Home Address . The value 518 should be generated from a value comprised between 1 to 65535. Zero 519 and negative values MUST NOT be taken as a BID. If a mobile node has 520 only one care-of address, the assignment of a BID is not needed until 521 it has multiple care-of addresses to register with. 523 5.2. Return Routability: Sending CoTI and Receiving CoT 525 When a mobile node wants to register bindings to a Correspondent 526 Node, it MUST send a CoTI per care-of address, while the HoTI and HoT 527 can be exchanged only once for a Home Address. If the Mobile Node 528 manages bindings with BID, it MUST include a Binding Unique 529 Identifier sub-option in a Care-of Test Init message. It MUST NOT 530 set the C and O flag in the sub-option. 532 The receiver (i.e. correspondent node) will calculate a care-of 533 keygen token as specified in [2] and reply a Care-of Test message 534 which contains a Binding Unique Identifier sub-option as described in 535 Section 6.2. When the mobile node receives the Care-of Test message, 536 the Care-of Test message is verified as same as in [2] and the 537 Binding Unique Identifier sub-option in the Care-of Test MUST be 538 processed as follows: 540 o If a Binding Unique Identifier sub-option is not presented in CoT 541 in reply to the CoTI containing the Binding Unique Identifier sub- 542 option, a correspondent node does not support the Multiple Care-of 543 Address registration. Thus, the mobile node MUST NOT use a 544 Binding Unique Identifier sub-option in the Binding Update. It 545 MUST send a regular Binding Update (i.e. no BID) to the 546 correspondent node [2]. The Mobile Node MAY skip resending 547 regular CoTI message and use the received care-of keygen token for 548 the regular Binding Update, because the correspondent node just 549 ignores and skip the Binding Unique Identifier sub-option and 550 calculates the care-of keygen token as [2] specified. 552 o If the status field of a Binding Unique Identifier sub-option is 553 set to [MCOA INCOMPLIANT], the received care-of keygen token MUST 554 NOT be used for sending a Binding Update. It MUST re-send a 555 Care-of Test Init message again with a corrected Binding Unique 556 Identifier sub-option which C flag MUST be unset. 558 o If the status field is set to less than 128, it sends a Binding 559 Update through Return Routability procedure. 561 5.3. Binding Registration 563 When a mobile node sends a Binding Update, it MUST decide whether it 564 registers multiple care-of addresses or not. However, this decision 565 is out-of scope in this document. If a mobile node decides not to 566 register multiple care-of addresses, it completely follows the 567 standard RFC 3775 specification. 569 If a mobile node needs to register multiple Care-of Addresses, it 570 MUST use BID to identify a care-of address. The mobile node includes 571 a Binding Unique Identifier sub-option in the Mobility Option field 572 of a Binding Update. The BID is copied from a corresponding Binding 573 Update List entry to the BID field of the Binding Unique Identifier 574 sub-option. If the mobile node wants to replace existing registered 575 bindings on the home agent to the binding entry(s) in the Binding 576 Update, it can set O flag. 578 If a mobile node registers bindings to a correspondent node, it MUST 579 have both active home and care-of keygen tokens for Kbm (see Section 580 5.2.5 of [2]. The care-of keygen tokens MUST be maintained for each 581 care-of address that the mobile node wants to register to the 582 correspondent node, as described in Section 5.2. After computing an 583 Authenticator value, it sends a Binding Update which contains a 584 Binding Unique Identifier sub-option. The Binding Update is 585 protected by a Binding Authorization Data sub-option placed after the 586 Binding Unique Identifier sub-option. The Mobile Node MUST NOT set 587 the C flag in the Binding Unique Identifier sub-option. 589 5.4. Binding Bulk Registration 591 The bulk registration is an optimization for registering multiple 592 care-of addresses only to a home agent by using a single Binding 593 Update. If a mobile node, for instance, does not want to send a lot 594 of control messages through an interface which bandwidth is scarce, 595 it can use this bulk registration and send a Binding Update 596 containing multiple or all the valid care-of addresses from a 597 specific interface which has wider bandwidth. 599 In this case, a mobile node sets the C flag in a Binding Unique 600 Identifier sub-option and stores the particular care-of address in 601 the Binding Unique Identifier sub-option. When the C flag is set, 602 the length field of the suboption MUST be set to 20. The mobile node 603 can store multiple sets of a Binding Unique Identifier sub-option in 604 a Binding Update. If the mobile node wants to replace existing 605 registered bindings on the home agent with the bindings in the sent 606 Binding Update, it can set O flag. Section 6.3 describes this 607 registration procedure in detail. In the bulk registration, all the 608 other binding information such as Lifetime, Sequence Number, binding 609 Flags are shared among the bulked Care-of Addresses. Whether a 610 mobile node registers multiple Care-of Addresses separately or in 611 bulk is up to implementations. 613 In the bulk registration, the Sequence Number field of a Binding 614 Update SHOULD be carefully configured. If each binding uses 615 different sequence number, a mobile node MUST use the largest 616 sequence number from the binding update list used for the bulk 617 registration. If it cannot select a sequence number for all the 618 bindings due to sequence number out of window, it MUST NOT use the 619 bulk registration for the binding which sequence number is out of 620 window and uses a separate Binding Update for the binding. 622 When multiple Binding Unique Identifier sub-options are presented, 623 the flag field of all the sub-options MUST have the same value. For 624 example, if C flag is set, the same flag MUST be set to all the sub- 625 options. 627 5.5. Binding De-Registration 629 When a mobile node decides to delete all the bindings for its home 630 address, it sends a regular de-registration Binding Update. A 631 Binding Unique Identifier sub-option is not required. See 632 Section 6.3 for details. 634 If a mobile node wants to delete a particular binding from its home 635 agent and correspondent nodes (e.g. from foreign link), the mobile 636 node simply sets zero lifetime or uses the home address as the source 637 address in a Binding Update. The Binding Update MUST contain a 638 relative Binding Unique Identifier Sub-option (C flag MUST NOT be 639 set). The receiver will remove only the care-of address that matches 640 the specified BID. 642 On the other hand, when a mobile node decides to return home (ie only 643 uses its interface attached to the home link), it MUST de-register 644 all the registered bindings. To do so, the mobile node stores 645 multiple Binding Unique Identifier sub-options in a Binding Update 646 which lifetime is set to zero or which source address is set to the 647 Home Address. C flag MUST be specified in all the Binding Unique 648 Identifier sub-options. The care-of addresses field of each sub- 649 option MAY be omitted, because the receiver will remove all the 650 care-of addresses which matches the specified BID. 652 O flag is always ignored if a Binding Update is for binding de- 653 registration 655 5.6. Returning Home 657 When a mobile node returns home, it MUST de-register all bindings 658 with the home agent. 660 Although the mobile node SHOULD delete the bindings with 661 Correspondent Nodes as well, the node MAY still keep the binding of 662 the other interface active attached to foreign links only at the 663 Correspondent Nodes. In such case, the mobile node still receives 664 packets at the other interface attached to a foreign link thanks to 665 route optimization. The mobile node also receives packets at the 666 interface attached to the home link when correspondent nodes does not 667 use route optimization. 669 Note that when the mobile node does not want to return home even if 670 one of interfaces is attached to the home link, the mobile node MUST 671 disable the interface. Otherwise, address duplication will be 672 observed because the home agent still defend the Home Address by the 673 proxy neighbor advertisement and the mobile node also enables the 674 same Home Address on the home link. After disabling the interface 675 attached to the home link, the mobile node MUST delete the binding 676 for the interface by sending a de-registration binding update. The 677 de-registration binding update must be sent from one of active 678 interfaces attached to foreign links. As a result, the mobile node 679 no longer receives packets at the interface attached to the home 680 link. All packets are routed to other interfaces attached to a 681 foreign link. 683 Alternatively, the Mobile Node may choose to activate both the 684 interfaces attached to the home link and the foreign link, and 685 communicates with all of the interfaces. The Mobile Node notifies 686 the Home Agent using the H flag which means the Mobile Node is 687 attached to the home link. The Mobile Node may notify the care-of 688 address of the interface(s) attached to the foreign link(s) in the 689 same message using bulk registration. The Home Agent then no longer 690 uses Proxy Neighbor Advertisement to intercept packets and the Mobile 691 Node can utilize both of interfaces attached to the home link and the 692 foreign link simultaneously. The Home Agent can intercept packets by 693 IP routing, but not by proxy Neighbor Discovery. 695 When the Mobile Node returns home, it de-registers a binding for the 696 interface. While the bindings for the interfaces attached to the 697 foreign link are still active. Intercepting packets, the Home Agent 698 can decide whether it tunnels to the foreign interface or routes to 699 the home interface of the Mobile Node. To do so, the Home Agent must 700 know that the Mobile Node is back to the home link. However, if the 701 binding is deleted according to [2], there is no way for the Home 702 Agent to know that the Mobile Node is at the home, too. The Home 703 Agent SHOULD invalidate the binding for the interface attached to the 704 home link and MAY NOT delete it. It can alternatively mark that the 705 Mobile Node is at the home link, too. As an example, the Home Agent 706 inserts the Home Address of the Mobile Node in the Care-of Address 707 field of the Mobile Node. The binding is named "Home Binding" in 708 this doc. The Home Agent MAY manage this home binding as same as the 709 other binding entry in terms of lifetime validation, etc. The Mobile 710 Node MAY send multiple binding de- registration to keep this home 711 binding active. Alternatively, the Home Agent can use infinity 712 lifetime for the lifetime of the home binding. When the Mobile Node 713 leaves the Home Link, it can update the home binding to the normal 714 binding. Before that, the Home Agent believes the Mobile Node is at 715 the home and may route packets for the Mobile Node to the Home Link. 717 5.7. Using Alternate care-of address 719 A mobile node can use an alternate care-of address in a following 720 situation. One care-of address becomes invalid (e.g because the link 721 where it is attached to is no longer available) and MUST be deleted. 722 In such case, the mobile node can not send a Binding Update from the 723 care-of address because the interface's link is lost. The mobile 724 node needs to de-register the remote binding of the care-of address 725 through one of its active care-of addresses. 727 In this case, the mobile node include both Alternate Care-of Address 728 sub-option and Binding Unique Identifier sub-option in a Binding 729 Update. An Alternate care-of address sub-option can be presented 730 only once in a Binding Update after a Binding Unique Identifier sub- 731 option. The care-of address stored in an Alternate Care-of address 732 sub-option is replaced the address in the source address field as 733 same as [2] specified. 735 If C flag is set in a Binding Unique Identifier sub-option, an 736 Alternate Care-of Address sub-option SHOULD NOT be used. A receiver 737 uses the care-of addresses and BID stored in each Binding Unique 738 Identifier sub-option to modify corresponding binding cache entries. 739 Any address can be specified in the Source address field of the IPv6 740 header of the Binding Update even without an Alternate Care-of 741 Address sub-option. 743 5.8. Receiving Binding Acknowledgment 745 The verification of a Binding Acknowledgment is the same as in Mobile 746 IPv6 (section 11.7.3 of RFC 3775). The operation for sending a 747 Binding Acknowledgment is described in Section 6.3. 749 If a mobile node includes a Binding Unique Identifier sub-option in a 750 Binding Update with A flag set, a Binding Acknowledgment MUST have a 751 Binding Unique Identifier sub-option in the Mobility Options field. 752 If no such sub-option appears in the Binding Acknowledgment replied 753 to the Binding Update for the multiple care-of address registration, 754 this means that the originator node of this Binding Acknowledgment 755 might not recognize the Binding Unique Identifier sub-option. The 756 mobile node SHOULD stop registering multiple care-of addresses by 757 using a Binding Unique Identifier sub-option. If the originator is 758 the home agent, the mobile node MAY try to discover a new home agent 759 supporting the multiple care-of address registration or give up with 760 the multiple care-of address registration. 762 If a Binding Unique Identifier sub-option is present in the received 763 Binding Acknowledgment, the mobile node checks the Status field of 764 the Binding Acknowledgment. If the status code indicates successful 765 registration (less than 128), the originator successfully registered 766 the binding information and BID for the mobile node. 768 If the status code of the Binding Acknowledgment is greater than or 769 equal to 128, the mobile node proceeds with relevant operations 770 according to the status code of the Binding Acknowledgment. The 771 status value of the stored Binding Unique Identifier sub-option may 772 be used to decide further operation. 774 o If the Status value of the Binding Acknowledgment is [MCOA 775 PROHIBITED], the mobile node MUST give up registering multiple 776 bindings to the peer sending the Binding Acknowledgment. It MUST 777 return to the regular Mobile IPv6 [2] for the peer node. 779 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 780 mobile node SHOULD stop using bulk registration to the peer 781 sending the Binding Acknowledgment. 783 o If [MCOA FLAG CONFLICTS] is specified in the Binding 784 Acknowledgment, it indicates that the different flag values are 785 used in Binding Unique Identifier sub-options in a Binding Update. 786 If the C flag is set, all sub-options MUST have C flag. It is 787 same for O flag. How to handle other error status codes is 788 specified in [2]. 790 The mobile node also learn detailed registration status from the 791 Status field of each Binding Unique Identifier sub-option. If the 792 value is greater than or equal to 128, the mobile node proceeds with 793 relevant operations according to the status value. 795 o If [MCOA BID CONFLICT] is specified, the binding entry specified 796 by the Binding Unique Identifier sub-option is already registered 797 as a regular binding. In such case, the mobile node SHOULD stop 798 sending Binding Updates with BID, or SHOULD use O flag for the 799 peer sending the Binding Acknowledgment. 801 5.9. Receiving Binding Refresh Request 803 The verification of a Binding Refresh Request is the same as in 804 Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a 805 Binding Refresh Request is described in section Section 6.4. 807 If a mobile node receives a Binding Refresh Request with a Binding 808 Unique Identifier sub-option, this Binding Refresh Request requests a 809 binding indicated by the BID. The mobile node SHOULD update only the 810 respective binding. The mobile node MUST put a Binding Unique 811 Identifier sub-option into the Binding Update sent to refresh the 812 entry. 814 If no Binding Unique Identifier sub-option is present in a Binding 815 Refresh Request, the mobile node sends a Binding Update according to 816 its Binding Update List for the requesting node. On the other hand, 817 if the mobile node does not have any Binding Update List entry for 818 the requesting node, the mobile node needs to register either a 819 single binding or multiple bindings depending on its binding 820 management policy. 822 5.10. Sending Packets to Home Agent 824 When a multihomed mobile node sends packets to its home agent, there 825 are conceptually two ways to construct packets. 827 1. Using Home Address Option. (required additional 24 bytes) 828 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) 830 Beside the additional size of packets, no difference is observed 831 between these two. The routing path is always the same and no 832 redundant path such as dog-leg route or triangular route occurs. 834 However, in this document, the mobile node is capable of using 835 multiple care-of addresses for outgoing packets. This is problem in 836 home agent side because they must verify the Care-of address for all 837 the packets received from the mobile node. Therefore, the mobile 838 node SHOULD use the bi-directional tunnel even if it registers a 839 binding(s) to the home agent. When it uses the Home Address option, 840 the home agent MAY reject the packets because the Care-of address in 841 the packet and the first found Care-of Address in the binding Cache 842 of the home agent are different. The mobile node then receive 843 Binding Error for the packet drop. 845 5.11. Bootstrapping 847 When a mobile node bootstraps and registers multiple bindings at the 848 first time, it SHOULD set O flag in the Binding Unique Identifier 849 sub-option. when old bindings still exists at the Home Agent and 850 Correspondent Nodes, the mobile node has no way to verify which 851 bindings are left as a garbage in those nodes. This scenario happens 852 when a mobile node reboots without correct deregistration. If O flag 853 is used, all the bindings are replaced to the new binding(s). Thus, 854 the garbage bindings are surely removed by the first Binding Update. 855 XXX SEQ 857 6. Home Agent and Correspondent Node Operation 859 6.1. Searching Binding Cache with Binding Unique Identifier 861 If either a correspondent node or a home agent has multiple bindings 862 for a mobile node in their binding cache database, it can use any of 863 the bindings to communicate with the mobile node. How to select the 864 most suitable binding from the binding cache database is out of scope 865 in this document. 867 Whenever a correspondent node searches a binding cache for a home 868 address, it SHOULD uses both the Home Address and the BID as the 869 search key if it knows the corresponding BID. In the example below, 870 if a correspondent node searches the binding with the Home Address 871 and BID2, it gets binding2 for this mobile node. 873 binding1 [a:b:c:d::EUI, care-of address1, BID1] 874 binding2 [a:b:c:d::EUI, care-of address2, BID2] 875 binding3 [a:b:c:d::EUI, care-of address3, BID3] 877 Figure 2: Searching the Binding Cache 879 A correspondent node basically learns the BID when it receives a 880 Binding Unique Identifier sub-option. At the time, the correspondent 881 node MUST look up its binding cache database with the Home Address 882 and the BID retrieved from the Binding Update. If the correspondent 883 node does not know the BID, it searches for a binding with only a 884 Home Address as performed in Mobile IPv6. In such case, the first 885 matched binding is found. But which binding entry is returned for 886 the normal search depends on implementations. If the correspondent 887 node does not desire to use multiple bindings for a mobile node, it 888 can simply ignore the BID. 890 6.2. Receiving CoTI and Sending CoT 892 When a correspondent node receives a Care-of Test Init message which 893 contains a Binding Unique Identifier sub-option, it MUST process it 894 with following steps. 896 First of all, the Care-of Test Init message is verified according to 897 [2]. The Binding Unique Identifier sub-option MUST be processed as 898 follows: 900 o If a correspondent node does not understand a Binding Unique 901 Identifier sub-option, it will ignore and skip this option. The 902 calculation of a care-of keygen token will thus be done without a 903 BID value. After regular processing of HoTI message according to 904 [2], it will return a Care-of Test message without use of a 905 Binding Unique Identifier sub-option. The mobile node can thus 906 know whether its correspondent can process or not the Binding 907 Unique Identifier sub-option by checking if such option is present 908 in the Care-of Test message. 910 o If C flag is set in the sub-option, the Correspondent Node SHOULD 911 NOT calculate a care-of keygen token and MUST include a Binding 912 Unique Identifier sub-option which status value set to [MCOA 913 INCOMPLIANT] in the returned Care-of Test message. All the fields 914 of the Care-of Test message MUST be set to zero. All the Binding 915 Unique Identifier sub-options SHOULD be copied from the received 916 one except for the Status Field and the Care-of Address field. 918 o If O flag is set in the sub-option, the Correspondent Node can 919 ignore this flag and can process it as described in the next 920 bullet. 922 o Otherwise, the correspondent node MUST include a Binding Unique 923 Identifier sub-option which status value MUST be set to [MCOA 924 ACCEPTING BID] in the returning a Care-of Test message. The 925 Binding Unique Identifier sub-option SHOULD be copied from the 926 received one except for the Status Field and the Care-of address 927 Field. 929 6.3. Processing Binding Update 931 If a Binding Update does not contain a Binding Unique Identifier sub- 932 option, its processing is same as in RFC 3775. But if the receiver 933 already has multiple bindings for the Home Address, it MUST replace 934 all existing bindings by the received binding. As a result, the 935 receiver node MUST have only a binding for the mobile node. If the 936 Binding Update is for de-registration, the receiver MUST delete all 937 existing bindings from its Binding Cache. 939 On the other hand, if a Binding Update contains a Binding Unique 940 Identifier sub-option(s), the Binding Update is also validated 941 according to section 9.5.1 of [2] and the following step. 943 o If the home flag is set in the Binding Update, the home agent MUST 944 carefully operate DAD for the received Home Address. If the home 945 agent has already had a binding(s) for the Mobile Node, it MUST 946 avoid running DAD when it receives the Binding Update. 948 If a Binding Unique Identifier sub-option(s) is present, the receiver 949 node MUST process the sub-option. 951 o The length value is examined. The length value MUST be either 4 952 or 20 depending on C flag. If the length is incorrect, the 953 receiver MUST rejects the Binding Update and returns all the 954 received Binding Unique Identifier sub-option which status value 955 is set to [MCOA INCOMPLIANT]. The status field of the Binding 956 Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. 958 o When C flag is set, the receiver MUST support the bulk 959 registration. Otherwise, it MUST reject the Binding Update and 960 returns all the received Binding Unique Identifier sub-option 961 which status value is set to [MCOA REASON UNSPECIFIED]. The 962 status field of the Binding Acknowledgment MUST be set to [MCOA 963 BULK REGISTRATION NOT SUPPORTED]. 965 o When either C or O flag is set, the flags field of all the Binding 966 Unique Identifier sub-option stored in the same Binding Update 967 MUST be equal. Otherwise, the receiver MUST reject the Binding 968 Update and returns all the received Binding Unique Identifier sub- 969 option which status value is set to [MCOA REASON UNSPECIFIED]. 970 The status field of the Binding Acknowledgment MUST be set to 971 [MCOA FLAG CONFLICTS]. 973 o When C flag is specified, the care-of address MUST be given in the 974 Binding Unique Identifier sub-option. Otherwise, the receiver 975 MUST reject the Binding Update and returns all the received 976 Binding Unique Identifier sub-option which status value is set to 977 [MCOA INCOMPLIANT]. The status field of the Binding 978 Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. 980 o If the Lifetime field of the Binding Update is zero, the receiver 981 node deletes the binding entry which BID is same as BID sent by 982 the Binding Unique Identifier sub-option. If the receiver node 983 does not have appropriate binding which BID is matched with the 984 Binding Update, it MUST reject this de-registration Binding 985 Update. If the receiver is a Home Agent, it SHOULD also return a 986 Binding Acknowledgment to the mobile node, in which the Status 987 field is set to [not Home Agent for this mobile node, 133]. If O 988 flag is set in the deregistering Binding Update, the receiver can 989 ignore this flag for deregistration. If the H flag is set, the 990 home agent stores a Home Address in the Care-of Address field of 991 the binding cache entry. The home agent no longer performs proxy 992 NDP for this mobile node until this entry is deleted. 994 o If the Lifetime field is not zero, the receiver node registers a 995 binding with the specified BID as a mobile node's binding. The 996 Care-of address is picked from the Binding Update packet as 997 follows: 999 * If C flag is set in the Binding Unique Identifier sub-option, 1000 the care-of address must be taken from the care-of address 1001 field in each Binding Unique Identifier sub-option. 1003 * If C flag is not set in the Binding Unique Identifier sub- 1004 option, the care-of address must be taken from the Source 1005 Address field of the IPv6 header. 1007 * If C flag is not set and an alternate care-of address is 1008 present, the care-of address is taken from the Alternate 1009 Care-of address sub-option. 1011 o Once the care-of address(es) has been retrieved from the Binding 1012 Update, it starts registering binding(s). 1014 * Only if O flag is set in the sub-option, the home agent first 1015 removes all the existing bindings and registers the received 1016 bindings. 1018 * If the receiver has a regular binding which does not have BID 1019 for the mobile node, it de-registers the regular binding and 1020 registers a new binding including BID according to the Binding 1021 Update. In this case, the receiver MUST specify [MCOA BID 1022 CONFLICT] to the Binding Unique Identifier sub-option which is 1023 replied to the Mobile Node. The Status field of the replying 1024 Binding Acknowledgment MUST be set to [Binding Update ACCEPTED, 1025 0]. 1027 * If the receiver node has already registered the binding which 1028 BID is matched with requesting BID, then it MUST update the 1029 binding with the Binding Update. 1031 * If the receiver does not have a binding entry which BID is 1032 matched with the requesting BID, it registers a new binding for 1033 the BID. 1035 If all the above operations are successfully finished, the Binding 1036 Acknowledgment containing the Binding Unique Identifier sub-options 1037 MUST be replied to the mobile node if A flag is set in the Binding 1038 Acknowledgment. Whenever a Binding Acknowledgment is returned, all 1039 the Binding Unique Identifier sub-options stored in the Binding 1040 Update MUST be copied to the Binding Acknowledgment. The Care-of 1041 address field of each Binding Unique Identifier sub-option, however, 1042 can be omitted, because the mobile node can match a corresponding 1043 binding update list by using BID. 1045 6.4. Sending Binding Refresh Request 1047 When either a correspondent node or home agent notices that a 1048 registered binding will be expired soon, it MAY send a Binding 1049 Refresh Request. If the registered binding has BID, the 1050 correspondent node SHOULD contain a Binding Unique Identifier sub- 1051 option in the Binding Refresh Request. Then, the Correspondent Node 1052 can receive a Binding Update with a Binding Unique Identifier sub- 1053 option and can update only the particular binding. If the registered 1054 binding does not have BID, then the correspondent node sends a 1055 Binding Refresh Request without the sub-option. 1057 6.5. Receiving Packets from Mobile Node 1059 When a correspondent node receives packets with a Home Address 1060 destination option from a mobile node, it MUST check that the care-of 1061 address appeared in the Source Address field MUST be equal to one of 1062 the care-of addresses in the binding cache entry. If no binding is 1063 found, the packets MUST be silently discarded and MUST send a Binding 1064 Error message according to RFC3775. This verification MUST NOT be 1065 done for a Binding Update. 1067 7. Network Mobility Applicability 1069 Support of multihomed mobile routers is advocated in the NEMO working 1070 group (see R12 "The solution MUST function for multihomed MR and 1071 multihomed mobile networks" in [8]. 1073 Issues regarding mobile routers with multiple interfaces and other 1074 multihoming configurations are documented in [11]. 1076 Since the binding management mechanisms are the same for a mobile 1077 host operating Mobile IPv6 and for a mobile router operating NEMO 1078 Basic Support (RFC 3963), our extensions can also be used to deal 1079 with multiple care-of addresses registration sent from a multihomed 1080 mobile router. 1082 8. IPsec and IKEv2 interaction 1084 Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to 1085 protect signaling messages like Binding Updates, Binding 1086 Acknowledgments and return routability messages. IPsec may also be 1087 used protect all reverse tunneled data traffic. The Mobile IPv6- 1088 IKEv2 specification [9] specifies how IKEv2 can be used to setup the 1089 required IPsec security associations. The following assumptions were 1090 made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with 1091 respect to the use of IKEv2 and IPsec. 1093 o There is only one primary care-of address per mobile node. 1095 o The primary care-of address is stored in the IPsec database for 1096 tunnel encapsulation and decapsulation. 1098 o When the home agent receives a packet from the mobile node, the 1099 source address is verified against the care-of address in the 1100 corresponding binding cache entry. If the packet is a reverse 1101 tunneled packet from the mobile node, the care-of address check is 1102 done against the source address on the outer IPv6 header. The 1103 reverse tunnel packet could either be a tunneled HoTi message or 1104 tunneled data traffic to the correspondent node. 1106 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1107 the care-of address. The IKE SA is based on the care-of address 1108 of the mobile node. 1110 The above assumptions may not be valid when multiple care-of 1111 addresses are used by the mobile node. In the following sections, 1112 the main issues with the use of multiple care-of address with IPsec 1113 are addressed. 1115 8.1. Use of Care-of Address in the IKEv2 exchange 1117 For each home address the mobile node sets up security associations 1118 with the home agent, the mobile node must pick one care-of address 1119 and use that as the source address for all IKEv2 messages exchanged 1120 to create and maintain the IPsec security associations associated 1121 with the home address. The resultant IKEv2 security association is 1122 created based on this care-of address. 1124 If the mobile node needs to change the care-of address, it just sends 1125 a Binding Update with the care-of address it wants to use, with the 1126 corresponding Binding Unique Identifier sub-option, and with the 'K' 1127 bit set. This will force the home agent to update the IKEv2 security 1128 association to use the new care-of address. If the 'K' bit is not 1129 supported on the mobile node or the home agent, the mobile node MUST 1130 re-establish the IKEv2 security association with the new care-of 1131 address. This will also result in new IPsec security associations 1132 being setup for the home address. 1134 8.2. Transport Mode IPsec protected messages 1136 For Mobile IPv6 signaling message protected using IPsec in transport 1137 mode, the use of a particular care-of address among multiple care-of 1138 addresses does not matter for IPsec processing. 1140 For Mobile Prefix Discovery messages, RFC 3775 requires the home 1141 agent to verify that the mobile node is using the care-of address 1142 that is in the binding cache entry that corresponds to the mobile 1143 node's home address. If a different address is used as the source 1144 address, the message is silently dropped by the home agent. This 1145 document requires the home agent implementation to process the 1146 message as long as the source address is is one of the care-of 1147 addresses in the binding cache entry for the mobile node. 1149 8.3. Tunnel Mode IPsec protected messages 1151 The use of IPsec in tunnel mode with multiple care-of address 1152 introduces a few issues that require changes to how the mobile node 1153 and the home agent send and receive tunneled traffic. The route 1154 optimization mechanism described in RFC 3775 mandates the use of 1155 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1156 mobile node and the home agent may also choose to protect all reverse 1157 tunneled payload traffic with IPsec in tunnel mode. The following 1158 sections address multiple care-of address support for these two types 1159 of messages. 1161 8.3.1. Tunneled HoTi and HoT messages 1163 The mobile node MAY use the same care-of address for all HoTi 1164 messages sent reverse tunneled through the home agent. The mobile 1165 node may use the same care-of address irrespective of which 1166 correspondent node the HoTi message is being sent. RFC 3775 requires 1167 the home agent to verify that the mobile node is using the care-of 1168 address that is in the binding cache entry, when it receives a 1169 reverse tunneled HoTi message. If a different address is used as the 1170 source address, the message is silently dropped by the home agent. 1171 This document requires the home agent implementation to decapsulate 1172 and forward the HoTi message as long as the source address is one of 1173 the care-of addresses in the binding cache entry for the mobile node. 1175 When the home agent tunnels a HoT message to the mobile node, the 1176 care-of address used in the outer IPv6 header is not relevant to the 1177 HoT message. So regular IPsec tunnel encapsulation with the care-of 1178 address known to the IPsec implementation on the home agent is 1179 sufficient. 1181 8.3.2. Tunneled Payload Traffic 1183 When the mobile sends and receives multiple traffic flows protected 1184 by IPsec to different care-of addresses, the use of the correct 1185 care-of address for each flow becomes important. Support for this 1186 requires the following two considerations on the home agent. 1188 o When the home agent receives a reverse tunneled payload message 1189 protected by IPsec in tunnel mode, it must check that the care-of 1190 address is one of the care-of addresses in the binding cache 1191 entry. According to RFC 4306, the IPsec implementation on the 1192 home agent does not check the source address on the outer IPv6 1193 header. Therefore the care-of address used in the reverse 1194 tunneled traffic can be different from the care-of address used as 1195 the source address in the IKEv2 exchange. However, the Mobile 1196 IPv6 stack on the home agent MUST verify that the source address 1197 is one of the care-of addresses registered by the mobile node 1198 before decapsulating and forwarding the payload traffic towards 1199 the correspondent node. 1201 o For tunneled IPsec traffic from the home agent to the mobile node, 1202 The IPsec implementation on the home agent may not be aware of 1203 which care-of address to use when performing IPsec tunnel 1204 encapsulation. The Mobile IP stack on the home agent must specify 1205 the tunnel end point for the IPsec tunnel. This may require tight 1206 integration between the IPsec and Mobile IP implementations on the 1207 home agent. 1209 9. Security Considerations 1211 As shown in Section 8, the Multiple Care-of Addresses Registration 1212 requires IPsec protected all the signalings between a mobile node and 1213 its home agent. 1215 10. IANA Considerations 1217 The following Extension Types MUST be assigned by IANA: 1219 1. Binding Unique Identifier sub-option type 1221 2. New Status of Binding Acknowledgement 1223 11. Acknowledgments 1225 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 1226 Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson), 1227 Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen 1228 (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki 1229 Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji 1230 Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) 1231 in alphabetical order, the Jun Murai Lab. at KEIO University. 1233 12. References 1235 12.1. Normative References 1237 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 1238 (IPv6)", IETF RFC 2460, December 1998. 1240 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1241 IPv6", RFC 3775, June 2004. 1243 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1244 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1245 January 2005. 1247 [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1248 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1249 draft-ietf-monami6-mipv6-analysis-02 (work in progress), 1250 February 2007. 1252 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 1253 RFC 3753, June 2004. 1255 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1256 draft-ietf-nemo-terminology-06 (work in progress), 1257 November 2006. 1259 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1260 Levels", BCP 14, RFC 2119, March 1997. 1262 [8] Ernst, T., "Network Mobility Support Goals and Requirements", 1263 draft-ietf-nemo-requirements-06 (work in progress), 1264 November 2006. 1266 [9] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1267 IKEv2 and the revised IPsec Architecture", 1268 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1269 December 2006. 1271 12.2. Informative References 1273 [10] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1274 Kuladinithi, "Motivations and Scenarios for Using Multiple 1275 Interfaces and Global Addresses", 1276 draft-ietf-monami6-multihoming-motivation-scenario-01 (work in 1277 progress), October 2006. 1279 [11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming 1280 in Network Mobility Support", 1281 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1282 June 2006. 1284 Appendix A. Example Configurations 1286 In this section, we describe typical scenarios when a mobile node has 1287 multiple network interfaces and acquires multiple Care-of Addresses 1288 bound to a Home Address. The Home Address of the mobile node (MN in 1289 figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly 1290 acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns 1291 BID1, BID2 and BID3 to each care-of address. 1293 +----+ 1294 | CN | 1295 +--+-+ 1296 | 1297 +---+------+ +----+ 1298 +------+ Internet |----------+ HA | 1299 | +----+---+-+ +--+-+ 1300 CoA2| | | | Home Link 1301 +--+--+ | | ------+------ 1302 | MN +========+ | 1303 +--+--+ CoA1 | 1304 CoA3| | 1305 +---------------+ 1307 Binding Cache Database: 1308 home agent's binding (Proxy neighbor advertisement is active) 1309 binding [a:b:c:d::EUI care-of address1 BID1] 1310 binding [a:b:c:d::EUI care-of address2 BID2] 1311 binding [a:b:c:d::EUI care-of address3 BID3] 1312 correspondent node's binding 1313 binding [a:b:c:d::EUI care-of address1 BID1] 1314 binding [a:b:c:d::EUI care-of address2 BID2] 1315 binding [a:b:c:d::EUI care-of address3 BID3] 1317 Figure 3: Multiple Interfaces Attached to a Foreign Link 1319 Figure 3 depicts the scenario where all interfaces of the mobile node 1320 are attached to foreign links. After binding registrations, the home 1321 agent (HA) and the Correspondent Node (CN) have the binding entries 1322 listed in their binding cache database. The mobile node can utilize 1323 all the interfaces. 1325 +----+ 1326 | CN | 1327 +--+-+ 1328 | 1329 +---+------+ +----+ 1330 +------+ Internet |----------+ HA | 1331 | +--------+-+ +--+-+ 1332 CoA2| | | Home Link 1333 +--+--+ | --+---+------ 1334 | MN +========+ | | 1335 +--+--+ | | | 1336 CoA3| +---|-----------+ 1337 +---------------+ 1339 Binding Cache Database: 1340 home agent's binding (Proxy neighbor advertisement is inactive) 1341 none 1342 correspondent node's binding 1343 binding [a:b:c:d::EUI care-of address2 BID2] 1344 binding [a:b:c:d::EUI care-of address3 BID3] 1346 Figure 4: One of Interface Attached to Home Link and Returning Home 1348 Figure 4 depicts the scenario where MN returns home with one of its 1349 interfaces. After the successful de-registration of the binding to 1350 HA, HA and CN have the binding entries listed in their binding cache 1351 database of Figure 4. MN can communicate with the HA through only 1352 the interface attached to the home link. On the other hand, the 1353 mobile node can communicate with CN from the other interfaces 1354 attached to foreign links (i.e. route optimization). Even when MN is 1355 attached to the home link, it can still send Binding Updates for 1356 other active care-of addresses (CoA2 and CoA3). If CN has bindings, 1357 packets are routed to each Care-of Addresses directly. Any packet 1358 arrived at HA are routed to the primary interface. 1360 +----+ 1361 | CN | 1362 +--+-+ 1363 | 1364 +---+------+ +----+ 1365 +------+ Internet |----------+ HA | 1366 | +----+-----+ +--+-+ 1367 CoA2| | | Home Link 1368 +--+--+ | --+---+------ 1369 | MN +========+ | 1370 +--+--+ CoA1 | 1371 | | 1372 +---------------------------+ 1373 (Disable interface) 1375 Binding Cache Database: 1376 home agent's binding (Proxy neighbor advertisement is active) 1377 binding [a:b:c:d::EUI care-of address1 BID1] 1378 binding [a:b:c:d::EUI care-of address2 BID2] 1379 correspondent node's binding 1380 binding [a:b:c:d::EUI care-of address1 BID1] 1381 binding [a:b:c:d::EUI care-of address2 BID2] 1383 Figure 5: One of Interface Attached to Home Link and Not Returning 1384 Home 1386 Figure 5 depicts the scenario where MN disables the interface 1387 attached to the home link and communicates with the interfaces 1388 attached to foreign links. The HA and the CN have the binding 1389 entries listed in their binding cache database. MN disable the 1390 interface attached to the home link, because the HA still defends the 1391 home address of the MN by proxy neighbor advertisements. All packets 1392 routed to the home link are intercepted by the HA and tunneled to the 1393 other interfaces attached to the foreign link according to the 1394 binding entries. 1396 +----+ 1397 | CN | 1398 +--+-+ 1399 | 1400 +---+------+ +----+ 1401 +------+ Internet |----------+ HA | 1402 | +----------+ +--+-+ 1403 CoA2| | Home Link 1404 +--+--+ --+----+---+------ 1405 | MN +===================+ | 1406 +--+--+ | 1407 | | 1408 +---------------------------+ 1410 Binding Cache Database: 1411 home agent's binding (Proxy neighbor advertisement is inactive) 1412 none 1413 correspondent node's binding 1414 binding [a:b:c:d::EUI care-of address2 BID2] 1416 Figure 6: Several Interfaces Attached to Home Link and Returning Home 1418 Figure 6 depicts the scenario where multiple interfaces of MN are 1419 attached to the home link. The HA and CN have the binding entries 1420 listed in Figure 6 in their binding cache database. The MN can not 1421 use the interface attached to a foreign link unless a CN has a 1422 binding for the interface. All packets which arrive at the HA are 1423 routed to one of the MN's interfaces attached to the home link. 1425 Appendix B. Changes From Previous Versions 1427 Changes from draft-ietf-monami6-multiplecoa-02.txt 1429 o Add Security Considerations 1431 o Add IANA Considerations 1433 o Add H flag for BID option and Modify Returning Home. 1435 Authors' Addresses 1437 Ryuji Wakikawa 1438 Keio University 1439 Department of Environmental Information, Keio University. 1440 5322 Endo 1441 Fujisawa, Kanagawa 252-8520 1442 Japan 1444 Phone: +81-466-49-1100 1445 Fax: +81-466-49-1395 1446 Email: ryuji@sfc.wide.ad.jp 1447 URI: http://www.wakikawa.org/ 1449 Thierry Ernst 1450 INRIA 1451 INRIA Rocquencourt 1452 Domaine de Voluceau B.P. 105 1453 Le Chesnay, 78153 1454 France 1456 Phone: +33-1-39-63-59-30 1457 Fax: +33-1-39-63-54-91 1458 Email: thierry.ernst@inria.fr 1459 URI: http://www.nautilus6.org/~thierry 1460 Kenichi Nagami 1461 INTEC NetCore Inc. 1462 1-3-3, Shin-suna 1463 Koto-ku, Tokyo 135-0075 1464 Japan 1466 Phone: +81-3-5565-5069 1467 Fax: +81-3-5565-5094 1468 Email: nagami@inetcore.com 1470 Vijay Devarapalli 1471 Azaire Networks 1472 3121 Jay Street 1473 Santa Clara, CA 95054 1474 USA 1476 Email: vijay.devarapalli@azairenet.com 1478 Full Copyright Statement 1480 Copyright (C) The IETF Trust (2007). 1482 This document is subject to the rights, licenses and restrictions 1483 contained in BCP 78, and except as set forth therein, the authors 1484 retain all their rights. 1486 This document and the information contained herein are provided on an 1487 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1488 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1489 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1490 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1491 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1492 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1494 Intellectual Property 1496 The IETF takes no position regarding the validity or scope of any 1497 Intellectual Property Rights or other rights that might be claimed to 1498 pertain to the implementation or use of the technology described in 1499 this document or the extent to which any license under such rights 1500 might or might not be available; nor does it represent that it has 1501 made any independent effort to identify any such rights. Information 1502 on the procedures with respect to rights in RFC documents can be 1503 found in BCP 78 and BCP 79. 1505 Copies of IPR disclosures made to the IETF Secretariat and any 1506 assurances of licenses to be made available, or the result of an 1507 attempt made to obtain a general license or permission for the use of 1508 such proprietary rights by implementers or users of this 1509 specification can be obtained from the IETF on-line IPR repository at 1510 http://www.ietf.org/ipr. 1512 The IETF invites any interested party to bring to its attention any 1513 copyrights, patents or patent applications, or other proprietary 1514 rights that may cover technology that may be required to implement 1515 this standard. Please address the information to the IETF at 1516 ietf-ipr@ietf.org. 1518 Acknowledgment 1520 Funding for the RFC Editor function is provided by the IETF 1521 Administrative Support Activity (IASA).