idnits 2.17.1 draft-ietf-monami6-multiplecoa-04.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 1450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1474. 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: 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, 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 documentation. 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 (November 19, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MCOA PROHIBITED' is mentioned on line 675, but not defined == Missing Reference: 'MCOA INCOMPLIANT' is mentioned on line 866, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (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. 'ID-MIP6ANALYSIS') ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Downref: Normative reference to an Informational RFC: RFC 4885 ** Downref: Normative reference to an Informational RFC: RFC 4886 == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-02 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Monami6 Working Group R. Wakikawa (Editor) 3 Internet-Draft Keio University 4 Intended status: Standards Track T. Ernst 5 Expires: May 22, 2008 INRIA 6 K. Nagami 7 INTEC NetCore 8 V. Devarapalli 9 Azaire Networks 10 November 19, 2007 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 22, 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 69 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 70 4.1. Binding Cache Structure and Binding Update List . . . . . 10 71 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 72 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 73 4.3. New Status Values for Binding Acknowledgment . . . . . . . 12 75 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Management of Care-of Addresses and Binding Unique 77 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 79 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 80 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15 81 5.5. Binding De-Registration and Returning Home . . . . . . . . 16 82 5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 17 83 5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 18 84 5.8. Sending Packets to Home Agent . . . . . . . . . . . . . . 19 85 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 19 87 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 88 6.1. Searching Binding Cache with Binding Unique Identifier . . 21 89 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 90 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 91 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24 92 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25 94 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 96 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 97 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 98 8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 99 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28 100 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28 101 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 110 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 112 Appendix A. Example Configurations . . . . . . . . . . . . . . . 34 114 Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 117 Intellectual Property and Copyright Statements . . . . . . . . . . 41 119 1. Introduction 121 A mobile node should use various type of network interfaces to obtain 122 durable and wide area network connectivity. The assumed scenarios 123 and motivations for multiple points of attachment, and benefits for 124 doing it are discussed at large in [ID-MOTIVATION]. 126 IPv6 [RFC-2460] conceptually allows a node to have several addresses 127 on a given interface. Consequently, Mobile IPv6 [RFC-3775] has 128 mechanisms to manage multiple ``Home Addresses'' based on home 129 agent's managed prefixes such as mobile prefix solicitation and 130 mobile prefix advertisement. But assigning a single Home Address to 131 a node is more advantageous than assigning multiple Home Addresses 132 because applications do not need to be aware of the multiplicity of 133 Home Addresses. If multiple home addresses are available, 134 applications must reset the connection information when the mobile 135 node changes its active network interface (i.e. change the Home 136 Address). 138 According to the Mobile IPv6 specification, a mobile node is not 139 allowed to register multiple care-of addresses bound to a single Home 140 Address. Since NEMO Basic Support [RFC-3963] is based on Mobile 141 IPv6, the same issues apply to a mobile node acting as a mobile 142 router. Multihoming issues pertaining to mobile nodes operating 143 Mobile IPv6 and mobile routers operating NEMO Basic Support are 144 respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6 145 and NEMO Working Group. 147 In this document, we thus propose a new identification number called 148 Binding Unique Identification (BID) number for each binding cache 149 entry to accommodate multiple bindings registration. The mobile node 150 notifies the BID to both its Home Agent and correspondent nodes by 151 means of a Binding Update. Correspondent nodes and the home agent 152 record the BID into their binding cache. The Home Address thus 153 identifies a mobile node itself whereas the BID identifies each 154 binding registered by a mobile node. By using the BID, multiple 155 bindings can then be distinguished. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC-2119]. 163 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 164 [RFC-4885]. In addition or in replacement of these, the following 165 terms are defined or redefined: 167 Binding Unique Identification number (BID) 169 The BID is an identification number used to distinguish multiple 170 bindings registered by the mobile node. Assignment of distinct 171 BID allows a mobile node to register multiple binding cache 172 entries for a given Home Address. The BID is conceptually 173 assigned to a binding in a way it cannot be duplicated with 174 another BID. The zero value and a negative value MUST NOT be 175 used. After being generated by the mobile node, the BID is stored 176 in the Binding Update List and is sent by the mobile node by means 177 of a sub-option of a Binding Update. A mobile node MAY change the 178 value of a BID at any time according to its administrative policy, 179 for instance to protect its privacy. An implementation must 180 carefully assign the BID so as to keep using the same BID for the 181 same binding even when the status of the binding is changed. More 182 details can be found in Section 5.1. 184 Binding Unique Identifier sub-option 186 The Binding Unique Identifier sub-option is used to carry the BID. 188 Bulk Registration 190 A mobile node can register multiple bindings at once by sending a 191 single binding update. The mobile node does not necessarily put 192 all the available care-of addresses in the binding update, but 193 several care-of addresses. A mobile node can also replace all the 194 bindings available at the home agent with the new bindings by 195 using the bulk registration. The bulk registration is supported 196 only for home registration and deregistration as explained in 197 Section 5.5. A mobile node MUST NOT perform bulk registration 198 with correspondent nodes. 200 3. Protocol Overview 202 A new identification number (BID) is introduced to distinguish 203 multiple bindings pertaining to the same Home Address. Once a mobile 204 node gets several IPv6 global addresses on interfaces, it can 205 register these addresses with its home agent. If the mobile node 206 wants to register multiple bindings, it MUST generate a BID for each 207 care-of address and record the BID into the binding update list. A 208 mobile node can manage each binding independently owing to BID. The 209 mobile node then registers its care-of addresses by sending a Binding 210 Update with a Binding Unique Identifier sub-option. The BID MUST be 211 included in the Binding Unique Identifier sub-option. After 212 receiving such Binding Update and Binding Unique Identifier sub- 213 option, the home agent MUST copy the BID from the Binding Unique 214 Identifier sub-option to the corresponding field in the binding cache 215 entry. Even if there is already an entry for the mobile node's home 216 address, the home agent MUST register a new binding entry for the BID 217 stored in the Binding Unique Identifier sub-option. The mobile node 218 registers multiple care-of addresses either independently in 219 individual Binding Updates or multiple at once in a single Binding 220 Update. 222 If the mobile host wishes to register its binding with a 223 correspondent node, it must operate return routability operations. 224 The mobile host MUST manage a Care-of Keygen Token per care-of 225 address. If it is necessary (ex. Care-of Keygen token is expired), 226 the mobile host exchanges CoTI and CoT for the relative care-of 227 addresses. When the mobile host registers several care-of addresses 228 to a correspondent node, it uses the same BID as the one generated 229 for the home registration's bindings. The binding registration step 230 is the same as for the home registration except for calculating 231 authenticator by using Binding Unique Identifier sub-option as well 232 as the other sub-options specified in [RFC-3775]. For simplicity, 233 the bulk registration is not supported for correspondent nodes in 234 this document. 236 If the mobile node decides to act as a regular mobile node compliant 237 with [RFC-3775] , it just sends a Binding Update without any Binding 238 Unique Identifier sub-options (i.e. normal Binding Update). The 239 receiver of the Binding Update deletes all the bindings registering 240 with a BID and registers only a single binding for the mobile node. 241 Note that the mobile node can continue to use BID even if only a 242 single binding is active at some time. 244 The BID is used as a search key for a corresponding entry in the 245 binding cache in addition to the Home Address. When a home agent and 246 a correspondent node check the binding cache database for the mobile 247 node, they search a corresponding binding entry with the Home Address 248 and BID of the desired binding. If necessary, a mobile node can use 249 policy and filter information to look up the best binding per 250 sessions, flow, packets, but this is out of scope in this document 251 and is currently discussed in Monami6 WG. If there is no desired 252 binding, it searches the binding cache database with the Home Address 253 as specified in Mobile IPv6. The first matched binding entry may be 254 found, although this is implementation dependent. 256 A mobile node carefully operates the returning home. The Home Agent 257 needs to defend a mobile node's home address by the proxy NDP for 258 packet interception, while the mobile node defends its home address 259 by regular NDP to send and receive packets at the interface attached 260 to the home link. Two nodes, Home Agent and Mobile Node, compete ND 261 state. This will causes address duplication problem at the end. If 262 the proxy neighbor advertisement for the Home Address is stopped, 263 packets are always routed to the interface attached to the home link. 264 On the other hand, packets are never routed to the interface attached 265 to the home link when the proxy is active. 267 When a mobile node wants to return home with interface attached to 268 the home link, it MUST de-register all the bindings by sending a 269 Binding Update with lifetime set to zero as described in [RFC-3775] 270 and [RFC-3963]. The mobile node does not put any Binding Unique 271 Identifier sub-option in this Binding Update. The receiver deletes 272 all the bindings from its binding cache database. On the other hand, 273 a mobile node does not want to return home and keeps the interfaces 274 attached to the foreign links active, when one of its interfaces is 275 attached to its home link. The mobile node disables the interface 276 attached to the home link and keeps using the rest of interfaces 277 attached to foreign links. In this case, the mobile node sends a de- 278 registration Binding Update including the BID for the interface 279 attached to the home link. The receiver of the de-registration 280 Binding Update deletes only the relative binding entry from the 281 binding cache database. The home agent does not stop proxying 282 neighbor advertisement as long as there are still bindings for the 283 other interfaces. It is important to understand that this scenario 284 is not the most efficient because all the traffic from and to the 285 mobile node is going through the bi-directional tunnel, whereas the 286 mobile node is now accessible at one hop from its home agent. 288 In the above two cases, a mobile node cannot use interfaces attached 289 to both home and foreign links simultaneously. If the proxy NDP is 290 disabled, the main problem can be solved. In the Multiple Care-of 291 Address Registration, the elimination of Proxy NDP enables that 292 Mobile Node and Home Agent maintain multiple bindings for the 293 interfaces attached to the home link and the foreign links. The 294 mobile node sends the binding update with H flag set for the 295 interface attached to the home link. The detail operation can be 296 found in Section 5.5. 298 4. Mobile IPv6 Extensions 300 This section summarizes the changes to Mobile IPv6 necessary to 301 manage multiple bindings bound to a same Home Address. 303 4.1. Binding Cache Structure and Binding Update List 305 The BID is required in the binding cache and binding update list 306 structure. 308 4.2. Message Format Changes 310 4.2.1. Binding Unique Identifier sub-option 312 The Binding Unique Identifier sub-option is included in the Binding 313 Update, Binding Acknowledgment, Binding Refresh Request, and Care-of 314 Test Init and Care-of Test message. 316 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type = TBD | Length | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Binding Unique ID (BID) | Status |C|O|H|Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 323 + + 324 + care-of address (CoA) + 325 + + 326 +---------------------------------------------------------------+ 328 Figure 1: BID Sub-Option 330 Type 332 Type value for Binding Unique Identifier is TBD 334 Length 336 Length value MUST be 4 when C flag is unset. Otherwise, the 337 Length value MUST be set to 20. 339 Binding Unique ID (BID) 341 The BID which is assigned to the binding carried in the Binding 342 Update with this sub-option. BID is 16-bit unsigned integer. A 343 value of zero is reserved. 345 Status 347 When the Binding Unique Identifier sub-option is included in a 348 Binding Acknowledgment, this field overwrites the status field 349 correspondent to each binding in the Binding Acknowledgment. If 350 this field is zero, the receiver MUST use the registration status 351 stored in the Binding Acknowledgment message. This Status field 352 can be used to carry error information for a Care-of Test message. 353 The status is 8-bit unsigned integer. The possible status codes 354 are the same as the status codes of Binding Acknowledgment. 356 Care-of address (C) flag 358 When this flag is set, a mobile node can store a Care-of Address 359 corresponding to the BID in the Binding Unique Identifier sub- 360 option. This flag must be used whenever a mobile node sends 361 multiple bindings in a single Binding Update, i.e. bulk 362 registration or MUST be used as a substitute for an alternate 363 care-of address option. This flag is valid only for binding 364 update for the home agent. 366 Overwrite (O) flag 368 When this flag is set, a mobile node requests a home agent to 369 replace all the bindings to binding entries stored in a Binding 370 Update. This flag is valid only for binding update for the home 371 agent. 373 Home Binding (H) flag 375 This flag indicates that the mobile node is attached to the home 376 link. This flag is valid only for binding update for the home 377 agent. 379 Reserved 381 5 bits Reserved field. Reserved field must be set with all 0. 383 Care-of Address 385 When C flag is set, a Care-of Address matched to the BID is 386 stored. This field is valid only if a Binding Unique Identifier 387 sub-option is stored in Binding Update message. Otherwise, this 388 field can be omitted. The receiver SHOULD ignore this field if 389 the sub-option is presented in other than Binding Update. 391 4.3. New Status Values for Binding Acknowledgment 393 New status values for the status field in a Binding Acknowledgment 394 are defined for handling the multiple Care-of Addresses registration: 396 MCOA INCOMPLIANT (TBD) 398 Registration failed because Binding Unique Identifier sub-option 399 is not compliant. 401 MCOA BID CONFLICT (TBD) 403 It indicates that a regular binding (i.e. without the BID set) is 404 already registered for the home address, and is conflicting with a 405 received Binding Update which BID is set. 407 MCOA PROHIBITED(TBD) 409 It implies the multiple care-of address registration is 410 administratively prohibited. 412 MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 414 The bulk binding registration is not supported. 416 MCOA FLAG CONFLICTS (TBD) 418 The flags of the sub-options presented in a Binding Unique 419 Identifier sub-options conflicts. 421 5. Mobile Node Operation 423 5.1. Management of Care-of Addresses and Binding Unique Identifier 425 There are two cases when a mobile node has several Care-of Addresses: 427 1. A mobile node uses several physical network interfaces and 428 acquires a care-of address on each of its interfaces. 430 2. A mobile node uses a single physical network interface, but 431 multiple prefixes are announced on the link the interface is 432 attached to. Several global addresses are configured on this 433 interface for each of the announced prefixes. 435 The difference between the above two cases is only a number of 436 physical network interfaces and therefore does not matter in this 437 document. The Identification number is used to identify a binding. 438 To implement this, a mobile node MAY assign an identification number 439 for each care-of addresses. How to assign an identification number 440 is up to implementers. 442 A mobile node assigns a BID to each care-of address when it wants to 443 register them simultaneously with its Home Address . The value 444 should be generated from a value comprised between 1 to 65535. Zero 445 and negative values MUST NOT be taken as a BID. If a mobile node has 446 only one care-of address, the assignment of a BID is not needed until 447 it has multiple care-of addresses to register with. 449 5.2. Return Routability: Sending CoTI and Receiving CoT 451 When a mobile node wants to register bindings to a Correspondent 452 Node, it MUST have the valid care-of Keygen token per care-of 453 address, while the HoTI and HoT can be exchanged only once for a Home 454 Address. 456 If the Mobile Node manages bindings with BID, it MUST include a 457 Binding Unique Identifier sub-option in a Care-of Test Init message. 458 It MUST NOT set the any flags in the sub-option. The receiver (i.e. 459 correspondent node) will calculate a care-of Keygen token as 460 specified in [RFC-3775] and reply a Care-of Test message and the 461 Binding Unique Identifier sub-option as described in Section 6.2. 462 When the mobile node receives the Care-of Test message, the Care-of 463 Test message is verified as same as in [RFC-3775]. If a Binding 464 Unique Identifier sub-option is not presented in CoT in reply to the 465 CoTI containing the Binding Unique Identifier sub-option, the 466 correspondent node does not support the Multiple Care-of Address 467 registration. Thus, the mobile node MUST NOT use a Binding Unique 468 Identifier sub-option in the future Binding Update. The Mobile Node 469 MAY skip resending regular CoTI message and keep the received care-of 470 Keygen token for the regular Binding Update, because the 471 correspondent node just ignores and skip the Binding Unique 472 Identifier sub-option and calculates the care-of Keygen token as 473 [RFC-3775] specified. 475 5.3. Binding Registration 477 When a mobile node sends a Binding Update, it MUST decide whether it 478 registers multiple care-of addresses or not. However, this decision 479 is out-of scope in this document. If a mobile node decides not to 480 register multiple care-of addresses, it completely follows the 481 RFC3775 specification. 483 For the multiple Care-of Addresses registration, the mobile node MUST 484 include a Binding Unique Identifier sub-option(s) in the Mobility 485 Option field of a Binding Update as shown in Figure 2. The BID is 486 copied from a corresponding Binding Update List entry to the BID 487 field of the Binding Unique Identifier sub-option. When ESP is used 488 for binding update, the care-of address MUST be stored in the Care-of 489 Address field by setting C flag as a substitute for the alternate 490 care-of address option. The alternate care-of address option MUST be 491 omitted. Additionally for binding registration to a correspondent 492 node, the mobile node MUST have both active home and care-of Keygen 493 tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen 494 tokens MUST be maintained for each care-of address that the mobile 495 node wants to register to the correspondent node, as described in 496 Section 5.2. After computing an Authenticator value for the Binding 497 Authorization sub-option, it sends a Binding Update which contains a 498 Binding Unique Identifier sub-option. The Binding Update is 499 protected by a Binding Authorization Data sub-option placed after the 500 Binding Unique Identifier sub-option. 502 IPv6 header (src=CoA, dst=HA) 503 IPv6 Home Address Option 504 ESP Header (for home registration) 505 Mobility header 506 -BU 507 Mobility Options 508 - Binding Unique Identifier sub-option 509 - Binding Authorization sub-option 510 (for Route Optimization) 512 Figure 2: Binding Update for Binding Registration 514 5.4. Binding Bulk Registration 516 The bulk registration is an optimization for registering multiple 517 care-of addresses only to a home agent by using a single Binding 518 Update. If a mobile node, for instance, does not want to send a lot 519 of control messages through an interface which bandwidth is scarce, 520 it can use this bulk registration and send a Binding Update 521 containing multiple or all the valid care-of addresses. 523 A mobile node sets the C flag in a Binding Unique Identifier sub- 524 option and stores the particular care-of address in the Binding 525 Unique Identifier sub-option. The mobile node stores multiple sets 526 of a Binding Unique Identifier sub-option in a Binding Update as 527 shown in Figure 3. When multiple Binding Unique Identifier sub- 528 options are presented in a Binding Update, the flag field of all the 529 sub-options MUST have the same value. For example, if C flag is set, 530 the same flag MUST be set to all the sub-options. Otherwise, the 531 mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding 532 Acknowledgment. In the bulk registration, all the other binding 533 information such as Lifetime, Sequence Number, binding Flags are 534 shared among the bulked Care-of Addresses. The alternate care-of 535 address option MUST be omitted when ESP is used to protect a binding 536 update. In the bulk registration, the Sequence Number field of a 537 Binding Update SHOULD be carefully configured. If each binding uses 538 different sequence number, a mobile node MUST use the largest 539 sequence number from the binding update list used for the bulk 540 registration. If it cannot select a sequence number for all the 541 bindings due to sequence number out of window, it MUST NOT use the 542 bulk registration for the binding which sequence number is out of 543 window and uses a separate Binding Update for the binding. 545 IPv6 header (src=CoA, dst=HA) 546 IPv6 Home Address Option 547 ESP Header 548 Mobility header 549 -BU 550 Mobility Options 551 - Binding Unique Identifier sub-options 552 (C flag is set, O flag is optional, 553 BID and CoA are stored) 555 Figure 3: Binding Update for Binding Bulk Registration 557 If the mobile node wants to replace existing registered bindings on 558 the home agent with the bindings in the sent Binding Update, it can 559 set O flag. Section 6.3 describes this registration procedure in 560 detail. 562 5.5. Binding De-Registration and Returning Home 564 When a mobile node decides to delete all the bindings for its home 565 address at a visiting network, it simply sends a regular de- 566 registration Binding Update which lifetime is set to zero. A Binding 567 Unique Identifier sub-option is not required. 569 If a mobile node wants to delete a particular binding(s) from its 570 home agent and correspondent nodes (e.g. from foreign link), the 571 mobile node simply sets zero lifetime for the sending binding update. 572 The Binding Update MUST contain a relative Binding Unique Identifier 573 Sub-option(s). The receiver will remove only the care-of address(es) 574 that matches to the specified BID. For the bulk de-registration, the 575 care-of addresses field of each sub-option SHOULD be omitted, because 576 the receiver will remove all the care-of addresses which matches the 577 specified BID. 579 When a mobile node returns home, it SHOULD de-register all bindings 580 with the home agent by sending a regular de-registration binding 581 update to flush all the registered bindings. However, there are 582 several scenarios for returning home described in Appendix A 583 (Figure 7, Figure 8, Figure 9). We have discussed this feature in 584 Monami6 working group now. This part might be updated in the next 585 revision. 587 As shown in Figure 7 in Appendix A, a mobile node de-registers all 588 the binding from the home agent, while it MAY still keep the bindings 589 of the other interface active attached to foreign links only at the 590 Correspondent Nodes. By doing this, the mobile node still receives 591 packets from the Correspondent Node at the interface attached to a 592 foreign link thanks to route optimization. If the correspondent 593 nodes does not use route optimization, the mobile node receives such 594 packets at the interface attached to the home link. 596 In Figure 8, a mobile node does not want to return home even if one 597 of interfaces is attached to the home link. The mobile node MUST 598 disable the interface attached to the home link. Otherwise, address 599 duplication will be observed because the home agent still defend the 600 Home Address by the proxy neighbor advertisement and the mobile node 601 also enables the same Home Address on the home link. After disabling 602 the interface attached to the home link, the mobile node MUST delete 603 the binding for the disabled interface by sending a de-registration 604 binding update. The de-registration binding update is sent from one 605 of active interfaces attached to foreign links. As a result, the 606 mobile node no longer receives packets at the interface attached to 607 the home link. All packets are routed to other interfaces attached 608 to a foreign link. 610 Alternatively, the Mobile Node may choose to activate both the 611 interfaces attached to the home link and the foreign link, and 612 communicates with all of the interfaces. The Mobile Node notifies 613 the Home Agent using the H flag which means the Mobile Node is 614 attached to the home link. The Mobile Node may notify the care-of 615 address of the interface(s) attached to the foreign link(s) in the 616 same message using bulk registration. The Home Agent then no longer 617 uses Proxy Neighbor Advertisement to intercept packets and the Mobile 618 Node can utilize both of interfaces attached to the home link and the 619 foreign link simultaneously. The Home Agent can intercept packets by 620 IP routing, but not by proxy Neighbor Discovery. The detailed 621 operation of no NDP operation can be found in [ID-NONDP]. 623 When the Mobile Node returns home, it de-registers a binding for the 624 interface. While the bindings for the interfaces attached to the 625 foreign link are still active. Intercepting packets, the Home Agent 626 can decide whether it tunnels to the foreign interface or routes to 627 the home interface of the Mobile Node. To do so, the Home Agent must 628 know that the Mobile Node is back to the home link. However, if the 629 binding is deleted, there is no way for the Home Agent to know that 630 the Mobile Node is at the home, too. The Home Agent SHOULD 631 invalidate the binding for the interface attached to the home link 632 and MAY NOT delete it. It can alternatively mark that the Mobile 633 Node is at the home link, too. As an example, the Home Agent inserts 634 the Home Address of the Mobile Node in the Care-of Address field of 635 the Mobile Node. The binding is named "Home Binding" in this 636 documentation. The Home Agent MAY manage this home binding as same 637 as the other binding entry in terms of lifetime validation, etc. The 638 Mobile Node MAY send multiple binding de- registration to keep this 639 home binding active. Alternatively, the Home Agent can use infinity 640 lifetime for the lifetime of the home binding. When the Mobile Node 641 leaves the Home Link, it can update the home binding to the normal 642 binding. Before that, the Home Agent believes the Mobile Node is at 643 the home and may route packets for the Mobile Node to the Home Link. 645 5.6. Receiving Binding Acknowledgment 647 The verification of a Binding Acknowledgment is the same as Mobile 648 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 649 Binding Acknowledgment is described in Section 6.3. 651 If a mobile node includes a Binding Unique Identifier sub-option in a 652 Binding Update with A flag set, a Binding Acknowledgment MUST carry a 653 Binding Unique Identifier sub-option in the Mobility Options field. 654 If no such sub-option is appeared in the Binding Acknowledgment 655 replied to the Binding Update for the multiple care-of address 656 registration, this indicates that the originator node of this Binding 657 Acknowledgment might not recognize the Binding Unique Identifier sub- 658 option. The mobile node SHOULD stop registering multiple care-of 659 addresses by using a Binding Unique Identifier sub-option. 661 If a Binding Unique Identifier sub-option is present in the received 662 Binding Acknowledgment, the mobile node checks the registration 663 status for the Care-of address(es). The status value MUST be 664 retrieved as follows. If the status value in the Binding Unique 665 Identifier sub-option is zero, the mobile node uses the value in the 666 Status field of the Binding Acknowledgment. Otherwise, it uses the 667 value in the Status field of the Binding Unique Identifier sub- 668 option. 670 If the status code is greater than or equal to 128, the mobile node 671 starts relevant operations according to the error code. Otherwise, 672 the originator (home agent or correspondent node) successfully 673 registered the binding information and BID for the mobile node. 675 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 676 give up registering multiple bindings to the peer sending the 677 Binding Acknowledgment. It MUST return to the regular Mobile IPv6 678 [RFC-3775] for the peer node. 680 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 681 mobile node SHOULD stop using bulk registration to the peer 682 sending the Binding Acknowledgment. 684 o If [MCOA FLAG CONFLICTS] is specified, it indicates that the 685 different flag values are used in Binding Unique Identifier sub- 686 options in a Binding Update. If the C flag is set, all sub- 687 options MUST have C flag. It is same for O flag. How to handle 688 other error status codes is specified in [RFC-3775]. 690 o If [MCOA BID CONFLICT] is specified, the binding entry specified 691 by the Binding Unique Identifier sub-option is already registered 692 as a regular binding. In such case, the mobile node SHOULD stop 693 sending Binding Updates with BID, or SHOULD use O flag for the 694 peer to reset all the registered bindings. 696 5.7. Receiving Binding Refresh Request 698 The verification of a Binding Refresh Request is the same as in 699 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 700 a Binding Refresh Request is described in section Section 6.4. 702 If a mobile node receives a Binding Refresh Request with a Binding 703 Unique Identifier sub-option, this Binding Refresh Request requests a 704 new binding indicated by the BID. The mobile node SHOULD update only 705 the respective binding. The mobile node MUST put a Binding Unique 706 Identifier sub-option into the Binding Update sent to refresh the 707 entry. 709 If no Binding Unique Identifier sub-option is present in a Binding 710 Refresh Request, the mobile node sends a Binding Update according to 711 its Binding Update List. On the other hand, if the mobile node does 712 not have any Binding Update List entry for the requesting node, the 713 mobile node needs to register either a single binding or multiple 714 bindings depending on its binding management policy. 716 5.8. Sending Packets to Home Agent 718 When a multihomed mobile node sends packets to its home agent, there 719 are conceptually two ways to construct packets. 721 1. Using Home Address Option. (required additional 24 bytes) 723 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) 725 Beside the additional size of packets, no difference is observed 726 between these two. The routing path is always the same and no 727 redundant path such as dog-leg route occurs. However, in this 728 document, the mobile node is capable of using multiple care-of 729 addresses for outgoing packets. This is problem in home agent side 730 because they must verify the Care-of address for all the packets 731 received from the mobile node (i.e. ingress filtering). When it uses 732 the Home Address option, the home agent MAY check the care-of address 733 in the packet with the registering binding entries. This causes 734 additional overhead to the home agent. Therefore, the mobile node 735 SHOULD use the bi-directional tunnel even if it registers a 736 binding(s) to the home agent. 738 5.9. Bootstrapping 740 When a mobile node bootstraps and registers multiple bindings at the 741 first time, it SHOULD set O flag in the Binding Unique Identifier 742 sub-option. If old bindings still exists at the Home Agent, the 743 mobile node has no way to know which bindings are remained as a 744 garbage. This scenario happens when a mobile node reboots without 745 correct deregistration. If O flag is used, all the bindings are 746 replaced to the new binding(s). Thus, the garbage bindings are 747 surely replaced by new bindings registered with the first Binding 748 Update. If the mobile node receives the Binding Acknowledgment with 749 the status code set to 135 [Sequence number out of window], it MUST 750 retry sending a Binding Update with the last accepted sequence number 751 which is notified by the Binding Acknowledgment. 753 For Correspondent nodes, the mobile node cannot use the O flag 754 because of no bulk registration support. Thus, if necessary, it MUST 755 sends a regular binding first to overwrite the remaining bindings at 756 the correspondent node. Then, it can re-register the set of bindings 757 by using Multiple Care-of Address Registration. 759 6. Home Agent and Correspondent Node Operation 761 6.1. Searching Binding Cache with Binding Unique Identifier 763 If either a correspondent node or a home agent has multiple bindings 764 for a mobile node in their binding cache database, it can use any of 765 the bindings to communicate with the mobile node. How to select the 766 most suitable binding from the binding cache database is out of scope 767 in this document. 769 Whenever a correspondent node searches a binding cache for a home 770 address, it SHOULD uses both the Home Address and the BID as the 771 search key if it knows the corresponding BID. In the example below, 772 if a correspondent node searches the binding with the Home Address 773 and BID2, it gets binding2 for this mobile node. 775 binding1 [a:b:c:d::EUI, care-of address1, BID1] 776 binding2 [a:b:c:d::EUI, care-of address2, BID2] 777 binding3 [a:b:c:d::EUI, care-of address3, BID3] 779 Figure 4: Searching the Binding Cache 781 A correspondent node basically learns the BID when it receives a 782 Binding Unique Identifier sub-option. At the time, the correspondent 783 node MUST look up its binding cache database with the Home Address 784 and the BID retrieved from the Binding Update. If the correspondent 785 node does not know the BID, it searches for a binding with only a 786 Home Address as performed in Mobile IPv6. In such case, the first 787 matched binding is found. But which binding entry is returned for 788 the normal search depends on implementations. If the correspondent 789 node does not desire to use multiple bindings for a mobile node, it 790 can simply ignore the BID. 792 6.2. Receiving CoTI and Sending CoT 794 When a correspondent node receives a CoTI message which contains a 795 Binding Unique Identifier sub-option, it MUST process it with 796 following steps. 798 First of all, the CoTI message is verified according to [RFC-3775]. 799 The Binding Unique Identifier sub-option MUST be, then, processed as 800 follows: 802 o If a correspondent node does not understand a Binding Unique 803 Identifier sub-option, it just ignores and skip this option. The 804 calculation of a care-of Keygen token will thus be done without a 805 BID value. The correspondent node returns a CoT message without a 806 Binding Unique Identifier sub-option. The mobile node can thus 807 know whether the correspondent can process the Binding Unique 808 Identifier sub-option or not, by checking if such option is 809 present in the CoT message. 811 o If either or both C and O flag is set in the sub-option, the 812 Correspondent Node SHOULD NOT calculate a care-of Keygen token and 813 MUST include a Binding Unique Identifier sub-option which status 814 value set to [MCOA INCOMPLIANT] in the returned Care-of Test 815 message. 817 o Otherwise, the correspondent node MUST include a Binding Unique 818 Identifier sub-option which status value MUST be set to zero in 819 the returning a CoT message. 821 o All the Binding Unique Identifier sub-options SHOULD be copied 822 from the received one except for the Status Field for CoT. The 823 Care-of address field of each Binding Unique Identifier sub- 824 option, however, can be omitted, because the mobile node can match 825 a corresponding binding update list by using BID. 827 6.3. Processing Binding Update 829 If a Binding Update does not contain a Binding Unique Identifier sub- 830 option, its processing is same as in [RFC-3775]. But if the receiver 831 already has multiple bindings for the home address, it MUST replace 832 all the existing bindings by the received binding. As a result, the 833 receiver node MUST have only a binding for the mobile node. If the 834 Binding Update is for de-registration, the receiver MUST delete all 835 existing bindings from its Binding Cache. 837 If a Binding Update contains a Binding Unique Identifier sub- 838 option(s), it is validated according to section 9.5.1 of [RFC-3775] 839 and the following step. 841 o If the home registration flag is set in the Binding Update, the 842 home agent MUST carefully operate DAD for the received Home 843 Address. If the home agent has already had a binding(s) for the 844 Mobile Node, it MUST avoid running DAD check when it receives the 845 Binding Update. 847 The receiver node MUST process the Binding Unique Identifier sub- 848 option(s) in the following steps. When a correspondent node sends a 849 Binding Acknowledgment, the status value is always stored in the 850 Status field of the Binding Acknowledgment and keep the Status field 851 of Binding Unique Identifier sub-option to zero. For the Home Agent, 852 the status value can be stored in the Status field of either a 853 Binding Acknowledgment or a Binding Unique Identifier sub-option. If 854 the status value is specific to one of bindings in the bulk 855 registration, the status value MUST be stored in the Status field in 856 the corresponding Binding Unique Identifier sub-option. 858 o The length value is examined. The length value MUST be either 4 859 or 20 depending on C flag. If the length is incorrect, the 860 receiver MUST rejects the Binding Update and returns the status 861 value set to [MCOA INCOMPLIANT]. 863 o When C flag is specified, the care-of address MUST be given in the 864 Binding Unique Identifier sub-option. Otherwise, the receiver 865 MUST reject the Binding Unique Identifier sub-option and returns 866 the status value set to [MCOA INCOMPLIANT]. 868 o When multiple binding Unique Identifier sub-options are presented, 869 the receiver MUST support the bulk registration. Only a home 870 agent can accept the bulk registration. Otherwise, it MUST reject 871 the Binding Update and returns the status value set to [MCOA BULK 872 REGISTRATION NOT SUPPORT] in the Binding Acknowledgment. 874 o When multiple binding Unique Identifier sub-options are presented, 875 the flags field of all the Binding Unique Identifier sub-option 876 stored in the same Binding Update MUST be equal. Otherwise, the 877 receiver MUST reject the Binding Update and returns the status 878 value set to [MCOA FLAG CONFLICTS] in the Binding Acknowledgment. 880 o If the Lifetime field of the Binding Update is zero, the receiver 881 node deletes the binding entry which BID is same as BID sent by 882 the Binding Unique Identifier sub-option. If the receiver node 883 does not have appropriate binding which BID is matched with the 884 Binding Update, it MUST reject this de-registration Binding Update 885 for the binding cache. If the receiver is a Home Agent, it SHOULD 886 also return the status value set to [not Home Agent for this 887 mobile node, 133]. 889 o If O flag is set in the deregistering Binding Update, the receiver 890 can ignore this flag for deregistration. If the H flag is set, 891 the home agent stores a Home Address in the Care-of Address field 892 of the binding cache entry. The home agent no longer performs 893 proxy NDP for this mobile node until this entry is deleted. 895 o If the Lifetime field is not zero, the receiver node registers a 896 binding with the specified BID as a mobile node's binding. The 897 Care-of address is picked from the Binding Update packet as 898 follows: 900 * If C flag is set in the Binding Unique Identifier sub-option, 901 the care-of address must be taken from the care-of address 902 field in each Binding Unique Identifier sub-option. 904 * If C flag is not set in the Binding Unique Identifier sub- 905 option, the care-of address must be taken from the Source 906 Address field of the IPv6 header. 908 * If C flag is not set and an alternate care-of address is 909 present, the care-of address is taken from the Alternate 910 Care-of address sub-option. 912 o Once the care-of address(es) has been retrieved from the Binding 913 Update, it starts registering binding(s). 915 * Only if O flag is set in the sub-option, the home agent first 916 removes all the existing bindings and registers the received 917 bindings. 919 * If the receiver has a regular binding which does not have BID 920 for the mobile node, it de-registers the regular binding and 921 registers a new binding including BID according to the Binding 922 Update. In this case, the receiver MUST return [MCOA BID 923 CONFLICT]. 925 * If the receiver node has already registered the binding which 926 BID is matched with requesting BID, then it MUST update the 927 binding with the Binding Update and returns [0 Binding Update 928 accepted]. 930 * If the receiver does not have a binding entry which BID is 931 matched with the requesting BID, it registers a new binding for 932 the BID and returns [0 Binding Update accepted]. 934 If all the above operations are successfully finished, the Binding 935 Acknowledgment containing the Binding Unique Identifier sub-options 936 MUST be replied to the mobile node if A flag is set in the Binding 937 Acknowledgment. Whenever a Binding Acknowledgment is returned, all 938 the Binding Unique Identifier sub-options stored in the Binding 939 Update MUST be copied to the Binding Acknowledgment. The Care-of 940 address field of each Binding Unique Identifier sub-option, however, 941 can be omitted, because the mobile node can match a corresponding 942 binding update list by using BID. 944 6.4. Sending Binding Refresh Request 946 When a node sends a Binding Refresh Request for a particular binding 947 registering with BID, the node SHOULD contain a Binding Unique 948 Identifier sub-option in the Binding Refresh Request. 950 6.5. Receiving Packets from Mobile Node 952 When a node receives packets with a Home Address destination option 953 from a mobile node, it MUST check that the care-of address appeared 954 in the Source Address field MUST be equal to one of the care-of 955 addresses in the binding cache entry. If no binding is found, the 956 packets MUST be silently discarded and MUST send a Binding Error 957 message according to RFC3775. This verification MUST NOT be done for 958 a Binding Update. 960 7. Network Mobility Applicability 962 Support of multihomed mobile routers is advocated in the NEMO working 963 group (see R12 "The solution MUST function for multihomed MR and 964 multihomed mobile networks" in [RFC-4886]. Issues regarding mobile 965 routers with multiple interfaces and other multihoming configurations 966 are documented in [RFC-4980]. 968 Since the binding management mechanisms are the same for a mobile 969 host operating Mobile IPv6 and for a mobile router operating NEMO 970 Basic Support (RFC 3963), our extensions can also be used to deal 971 with multiple care-of addresses registration sent from a multihomed 972 mobile router. Figure 5 shows the example format of a Binding Update 973 used by a mobile router. 975 IPv6 header (src=CoA, dst=HA) 976 IPv6 Home Address Option 977 ESP Header 978 Mobility header 979 -BU 980 Mobility Options 981 - Binding Unique Identifier sub-option 982 - Mobile Network Prefix sub-option 984 Figure 5: NEMO Binding Update 986 8. IPsec and IKEv2 interaction 988 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 989 use of IPsec to protect signaling messages like Binding Updates, 990 Binding Acknowledgments and return routability messages. IPsec may 991 also be used protect all reverse tunneled data traffic. The Mobile 992 IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used 993 to setup the required IPsec security associations. The following 994 assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 995 specification with respect to the use of IKEv2 and IPsec. 997 o There is only one primary care-of address per mobile node. 999 o The primary care-of address is stored in the IPsec database for 1000 tunnel encapsulation and decapsulation. 1002 o When the home agent receives a packet from the mobile node, the 1003 source address is verified against the care-of address in the 1004 corresponding binding cache entry. If the packet is a reverse 1005 tunneled packet from the mobile node, the care-of address check is 1006 done against the source address on the outer IPv6 header. The 1007 reverse tunnel packet could either be a tunneled HoTi message or 1008 tunneled data traffic to the correspondent node. 1010 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1011 the care-of address. The IKE SA is based on the care-of address 1012 of the mobile node. 1014 The above assumptions may not be valid when multiple care-of 1015 addresses are used by the mobile node. In the following sections, 1016 the main issues with the use of multiple care-of address with IPsec 1017 are addressed. 1019 8.1. Use of Care-of Address in the IKEv2 exchange 1021 For each home address the mobile node sets up security associations 1022 with the home agent, the mobile node must pick one care-of address 1023 and use that as the source address for all IKEv2 messages exchanged 1024 to create and maintain the IPsec security associations associated 1025 with the home address. The resultant IKEv2 security association is 1026 created based on this care-of address. 1028 If the mobile node needs to change the care-of address, it just sends 1029 a Binding Update with the care-of address it wants to use, with the 1030 corresponding Binding Unique Identifier sub-option, and with the 'K' 1031 bit set. This will force the home agent to update the IKEv2 security 1032 association to use the new care-of address. If the 'K' bit is not 1033 supported on the mobile node or the home agent, the mobile node MUST 1034 re-establish the IKEv2 security association with the new care-of 1035 address. This will also result in new IPsec security associations 1036 being setup for the home address. 1038 8.2. Transport Mode IPsec protected messages 1040 For Mobile IPv6 signaling message protected using IPsec in transport 1041 mode, the use of a particular care-of address among multiple care-of 1042 addresses does not matter for IPsec processing. 1044 For Mobile Prefix Discovery messages, [RFC-3775] requires the home 1045 agent to verify that the mobile node is using the care-of address 1046 that is in the binding cache entry that corresponds to the mobile 1047 node's home address. If a different address is used as the source 1048 address, the message is silently dropped by the home agent. This 1049 document requires the home agent implementation to process the 1050 message as long as the source address is is one of the care-of 1051 addresses in the binding cache entry for the mobile node. 1053 8.3. Tunnel Mode IPsec protected messages 1055 The use of IPsec in tunnel mode with multiple care-of address 1056 introduces a few issues that require changes to how the mobile node 1057 and the home agent send and receive tunneled traffic. The route 1058 optimization mechanism described in [RFC-3775] mandates the use of 1059 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1060 mobile node and the home agent may also choose to protect all reverse 1061 tunneled payload traffic with IPsec in tunnel mode. The following 1062 sections address multiple care-of address support for these two types 1063 of messages. 1065 8.3.1. Tunneled HoTi and HoT messages 1067 The mobile node MAY use the same care-of address for all HoTi 1068 messages sent reverse tunneled through the home agent. The mobile 1069 node may use the same care-of address irrespective of which 1070 correspondent node the HoTi message is being sent. RFC 3775 requires 1071 the home agent to verify that the mobile node is using the care-of 1072 address that is in the binding cache entry, when it receives a 1073 reverse tunneled HoTi message. If a different address is used as the 1074 source address, the message is silently dropped by the home agent. 1075 This document requires the home agent implementation to decapsulate 1076 and forward the HoTi message as long as the source address is one of 1077 the care-of addresses in the binding cache entry for the mobile node. 1079 When the home agent tunnels a HoT message to the mobile node, the 1080 care-of address used in the outer IPv6 header is not relevant to the 1081 HoT message. So regular IPsec tunnel encapsulation with the care-of 1082 address known to the IPsec implementation on the home agent is 1083 sufficient. 1085 8.3.2. Tunneled Payload Traffic 1087 When the mobile sends and receives multiple traffic flows protected 1088 by IPsec to different care-of addresses, the use of the correct 1089 care-of address for each flow becomes important. Support for this 1090 requires the following two considerations on the home agent. 1092 o When the home agent receives a reverse tunneled payload message 1093 protected by IPsec in tunnel mode, it must check that the care-of 1094 address is one of the care-of addresses in the binding cache 1095 entry. According to RFC 4306, the IPsec implementation on the 1096 home agent does not check the source address on the outer IPv6 1097 header. Therefore the care-of address used in the reverse 1098 tunneled traffic can be different from the care-of address used as 1099 the source address in the IKEv2 exchange. However, the Mobile 1100 IPv6 stack on the home agent MUST verify that the source address 1101 is one of the care-of addresses registered by the mobile node 1102 before decapsulating and forwarding the payload traffic towards 1103 the correspondent node. 1105 o For tunneled IPsec traffic from the home agent to the mobile node, 1106 The IPsec implementation on the home agent may not be aware of 1107 which care-of address to use when performing IPsec tunnel 1108 encapsulation. The Mobile IP stack on the home agent must specify 1109 the tunnel end point for the IPsec tunnel. This may require tight 1110 integration between the IPsec and Mobile IP implementations on the 1111 home agent. 1113 9. Security Considerations 1115 As shown in Section 8, the Multiple Care-of Addresses Registration 1116 requires IPsec protected all the signaling between a mobile node and 1117 its home agent. 1119 10. IANA Considerations 1121 The following Extension Types MUST be assigned by IANA: 1123 o Binding Unique Identifier sub-option type 1125 o New Status of Binding Acknowledgment 1127 * MCOA INCOMPLIANT (TBD) 1129 * MCOA BID CONFLICT (TBD) 1131 * MCOA PROHIBITED(TBD) 1133 * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 1135 * MCOA FLAG CONFLICTS (TBD) 1137 11. Acknowledgments 1139 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 1140 Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson), 1141 Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen 1142 (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki 1143 Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji 1144 Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) 1145 in alphabetical order, the Jun Murai Lab. at KEIO University. 1147 12. References 1149 12.1. Normative References 1151 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6 1152 (IPv6)", IETF RFC 2460, December 1998. 1154 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1155 in IPv6", RFC 3775, June 2004. 1157 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1158 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1159 January 2005. 1161 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1162 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1163 draft-ietf-monami6-mipv6-analysis-02 (work in progress), February 1164 2007. 1166 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, March 1997. 1169 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1170 RFC 3753, June 2004. 1172 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1173 Terminology", RFC 4885, July 2007. 1175 [RFC-4886] Ernst, T., "Network Mobility Support Goals and 1176 Requirements", RFC 4886, July 2007. 1178 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1179 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1181 12.2. Informative References 1183 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1184 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1185 Interfaces and Global Addresses", 1186 draft-ietf-monami6-multihoming-motivation-scenario-02 (work in 1187 progress), July 2007 1189 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1190 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1192 [ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of 1193 Proxy NDP from Home Agent Operations", 1194 draft-wakikawa-mip6-no-ndp-02.txt (work in progress), November 2007. 1196 Appendix A. Example Configurations 1198 In this section, we describe typical scenarios when a mobile node has 1199 multiple network interfaces and acquires multiple Care-of Addresses 1200 bound to a Home Address. The Home Address of the mobile node (MN in 1201 figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly 1202 acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns 1203 BID1, BID2 and BID3 to each care-of address. 1205 +----+ 1206 | CN | 1207 +--+-+ 1208 | 1209 +---+------+ +----+ 1210 +------+ Internet |----------+ HA | 1211 | +----+---+-+ +--+-+ 1212 CoA2| | | | Home Link 1213 +--+--+ | | ------+------ 1214 | MN +========+ | 1215 +--+--+ CoA1 | 1216 CoA3| | 1217 +---------------+ 1219 Binding Cache Database: 1220 home agent's binding (Proxy neighbor advertisement is active) 1221 binding [a:b:c:d::EUI care-of address1 BID1] 1222 binding [a:b:c:d::EUI care-of address2 BID2] 1223 binding [a:b:c:d::EUI care-of address3 BID3] 1224 correspondent node's binding 1225 binding [a:b:c:d::EUI care-of address1 BID1] 1226 binding [a:b:c:d::EUI care-of address2 BID2] 1227 binding [a:b:c:d::EUI care-of address3 BID3] 1229 Figure 6: Multiple Interfaces Attached to a Foreign Link 1231 Figure 6 depicts the scenario where all interfaces of the mobile node 1232 are attached to foreign links. After binding registrations, the home 1233 agent (HA) and the Correspondent Node (CN) have the binding entries 1234 listed in their binding cache database. The mobile node can utilize 1235 all the interfaces. 1237 +----+ 1238 | CN | 1239 +--+-+ 1240 | 1241 +---+------+ +----+ 1242 +------+ Internet |----------+ HA | 1243 | +--------+-+ +--+-+ 1244 CoA2| | | Home Link 1245 +--+--+ | --+---+------ 1246 | MN +========+ | | 1247 +--+--+ | | | 1248 CoA3| +---|-----------+ 1249 +---------------+ 1251 Binding Cache Database: 1252 home agent's binding (Proxy neighbor advertisement is inactive) 1253 none 1254 correspondent node's binding 1255 binding [a:b:c:d::EUI care-of address2 BID2] 1256 binding [a:b:c:d::EUI care-of address3 BID3] 1258 Figure 7: One of Interface Attached to Home Link and Returning Home 1260 Figure 7 depicts the scenario where MN returns home with one of its 1261 interfaces. After the successful de-registration of the binding to 1262 HA, HA and CN have the binding entries listed in their binding cache 1263 database of Figure 7. MN can communicate with the HA through only 1264 the interface attached to the home link. On the other hand, the 1265 mobile node can communicate with CN from the other interfaces 1266 attached to foreign links (i.e. route optimization). Even when MN is 1267 attached to the home link, it can still send Binding Updates for 1268 other active care-of addresses (CoA2 and CoA3). If CN has bindings, 1269 packets are routed to each Care-of Addresses directly. Any packet 1270 arrived at HA are routed to the primary interface. 1272 +----+ 1273 | CN | 1274 +--+-+ 1275 | 1276 +---+------+ +----+ 1277 +------+ Internet |----------+ HA | 1278 | +----+-----+ +--+-+ 1279 CoA2| | | Home Link 1280 +--+--+ | --+---+------ 1281 | MN +========+ | 1282 +--+--+ CoA1 | 1283 | | 1284 +---------------------------+ 1285 (Disable interface) 1287 Binding Cache Database: 1288 home agent's binding (Proxy neighbor advertisement is active) 1289 binding [a:b:c:d::EUI care-of address1 BID1] 1290 binding [a:b:c:d::EUI care-of address2 BID2] 1291 correspondent node's binding 1292 binding [a:b:c:d::EUI care-of address1 BID1] 1293 binding [a:b:c:d::EUI care-of address2 BID2] 1295 Figure 8: One of Interface Attached to Home Link and Not Returning 1296 Home 1298 Figure 8 depicts the scenario where MN disables the interface 1299 attached to the home link and communicates with the interfaces 1300 attached to foreign links. The HA and the CN have the binding 1301 entries listed in their binding cache database. MN disable the 1302 interface attached to the home link, because the HA still defends the 1303 home address of the MN by proxy neighbor advertisements. All packets 1304 routed to the home link are intercepted by the HA and tunneled to the 1305 other interfaces attached to the foreign link according to the 1306 binding entries. 1308 +----+ 1309 | CN | 1310 +--+-+ 1311 | 1312 +---+------+ +----+ 1313 +------+ Internet |----------+ HA | 1314 | +----------+ +--+-+ 1315 CoA2| | Home Link 1316 +--+--+ --+----+---+------ 1317 | MN +===================+ | 1318 +--+--+ | 1319 | | 1320 +---------------------------+ 1322 Binding Cache Database: 1323 home agent's binding (Proxy neighbor advertisement is inactive) 1324 none 1325 correspondent node's binding 1326 binding [a:b:c:d::EUI care-of address2 BID2] 1328 Figure 9: Several Interfaces Attached to Home Link and Returning Home 1330 Figure 9 depicts the scenario where multiple interfaces of MN are 1331 attached to the home link. The HA and CN have the binding entries 1332 listed in Figure 9 in their binding cache database. The MN can not 1333 use the interface attached to a foreign link unless a CN has a 1334 binding for the interface. All packets which arrive at the HA are 1335 routed to one of the MN's interfaces attached to the home link. 1337 Figure 10 depicts the scenario where interfaces of MN are attached to 1338 the foreign links. One of foreign link is managed by the home agent. 1339 The HA and CN have the binding entries listed in Figure 10 in their 1340 binding cache database. The home agent advertises a prefix which is 1341 other than home prefix. The mobile node will generate a care-of 1342 address from the prefix and registers it to the home agent. Even if 1343 the mobile node attaches to a foreign link, the link is managed by 1344 its home agent. It will tunnel the packets to the home agent, but 1345 the home agent is one-hop neighbor. The cost of tunnel is 1346 negligible. If the mobile node wants to utilize not only an 1347 interface attached to home but also interfaces attached to foreign 1348 link, it can use this foreign link of the home agent to return a one 1349 hop foreign link on behalf of a home link. This is different from 1350 the general returning home, but this enable the capability of using 1351 interfaces attached to both home and foreign link without any 1352 modifications to Mobile IPv6 and NEMO basic support. 1354 +----+ 1355 | CN | 1356 +--+-+ 1357 | 1358 +---+------+ +----+ 1359 +------+ Internet |----------+ HA | 1360 | +----+-----+ ++-+-+ 1361 CoA2| | | | Home Link 1362 +--+--+ | ----|-+------ 1363 | MN +========+ | 1364 +--+--+ CoA1 ---+-+------ 1365 CoA3 | | Foreign Link 1366 +---------------------------+ 1368 Binding Cache Database: 1369 home agent's binding (Proxy neighbor advertisement is active) 1370 binding [a:b:c:d::EUI care-of address1 BID1] 1371 binding [a:b:c:d::EUI care-of address2 BID2] 1372 binding [a:b:c:d::EUI care-of address3 BID3] 1373 correspondent node's binding 1374 binding [a:b:c:d::EUI care-of address1 BID1] 1375 binding [a:b:c:d::EUI care-of address2 BID2] 1376 binding [a:b:c:d::EUI care-of address3 BID3] 1378 Figure 10: Emulating to Utilize Interfaces Attached to both Home and 1379 Foreign Links 1381 Appendix B. Changes From Previous Versions 1383 Changes from draft-ietf-monami6-multiplecoa-03.txt 1385 o Change the handling of Status field. All the status value is 1386 defined for BA 1388 o Alternate CoA option is omitted, but using C flag is recommended. 1390 o Adding examples of BU 1392 o Many editorial updates 1394 Authors' Addresses 1396 Ryuji Wakikawa (Editor) 1397 Faculty of Environment and Information Studies, Keio University 1398 5322 Endo 1399 Fujisawa, Kanagawa 252-8520 1400 Japan 1402 Phone: +81-466-49-1100 1403 Fax: +81-466-49-1395 1404 Email: ryuji@sfc.wide.ad.jp 1405 URI: http://www.wakikawa.org/ 1407 Thierry Ernst 1408 INRIA 1409 INRIA Rocquencourt 1410 Domaine de Voluceau B.P. 105 1411 Le Chesnay, 78153 1412 France 1414 Phone: +33-1-39-63-59-30 1415 Fax: +33-1-39-63-54-91 1416 Email: thierry.ernst@inria.fr 1417 URI: http://www.nautilus6.org/~thierry 1418 Kenichi Nagami 1419 INTEC NetCore Inc. 1420 1-3-3, Shin-suna 1421 Koto-ku, Tokyo 135-0075 1422 Japan 1424 Phone: +81-3-5565-5069 1425 Fax: +81-3-5565-5094 1426 Email: nagami@inetcore.com 1428 Vijay Devarapalli 1429 Azaire Networks 1430 3121 Jay Street 1431 Santa Clara, CA 95054 1432 USA 1434 Email: vijay.devarapalli@azairenet.com 1436 Full Copyright Statement 1438 Copyright (C) The IETF Trust (2007). 1440 This document is subject to the rights, licenses and restrictions 1441 contained in BCP 78, and except as set forth therein, the authors 1442 retain all their rights. 1444 This document and the information contained herein are provided on an 1445 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1446 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1447 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1448 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1449 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1450 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1452 Intellectual Property 1454 The IETF takes no position regarding the validity or scope of any 1455 Intellectual Property Rights or other rights that might be claimed to 1456 pertain to the implementation or use of the technology described in 1457 this document or the extent to which any license under such rights 1458 might or might not be available; nor does it represent that it has 1459 made any independent effort to identify any such rights. Information 1460 on the procedures with respect to rights in RFC documents can be 1461 found in BCP 78 and BCP 79. 1463 Copies of IPR disclosures made to the IETF Secretariat and any 1464 assurances of licenses to be made available, or the result of an 1465 attempt made to obtain a general license or permission for the use of 1466 such proprietary rights by implementers or users of this 1467 specification can be obtained from the IETF on-line IPR repository at 1468 http://www.ietf.org/ipr. 1470 The IETF invites any interested party to bring to its attention any 1471 copyrights, patents or patent applications, or other proprietary 1472 rights that may cover technology that may be required to implement 1473 this standard. Please address the information to the IETF at 1474 ietf-ipr@ietf.org. 1476 Acknowledgment 1478 Funding for the RFC Editor function is provided by the IETF 1479 Administrative Support Activity (IASA).