idnits 2.17.1 draft-ietf-monami6-multiplecoa-06.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 1569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1593. 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 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 (February 24, 2008) is 5905 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 729, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 865, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 948, but not defined == Unused Reference: 'RFC-4980' is defined on line 1304, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-02 == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-04 == Outdated reference: A later version (-02) exists of draft-lim-mext-multiple-coa-verify-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa (Ed.) 3 Internet-Draft Keio University 4 Intended status: Standards Track T. Ernst 5 Expires: August 27, 2008 INRIA 6 K. Nagami 7 INTEC NetCore 8 V. Devarapalli (Ed.) 9 Azaire Networks 10 February 24, 2008 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-06.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 August 27, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 According to the current Mobile IPv6 specification, a mobile node may 47 have several care-of addresses, but only one, called the primary 48 care-of address, that can be registered with its home agent and the 49 correspondent nodes. However, for matters of cost, bandwidth, delay, 50 etc, it is useful for the mobile node to get Internet access through 51 multiple accesses simultaneously, in which case the mobile node would 52 be configured with multiple active IPv6 care-of addresses. This 53 document proposes extensions to the Mobile IPv6 protocol to register 54 and use multiple care-of addresses. The extensions proposed in this 55 document can be used by Mobile Routers using the NEMO (Network 56 Mobility) Basic Support protocol as well. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Binding Cache Structure and Binding Update List . . . . . 9 68 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 9 69 4.3. New Status Values for Binding Acknowledgement . . . . . . 11 71 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Management of Care-of Address(es) and Binding 73 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 75 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 76 5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 14 77 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 15 78 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16 79 5.6.1. Using only Interface attached to the Home Link . . . . 16 80 5.6.2. Using only Interface attached to the Visited Link . . 16 81 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17 82 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 19 83 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20 84 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 86 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 87 6.1. Searching Binding Cache with Binding Identifier . . . . . 21 88 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 89 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 90 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24 91 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 24 93 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 25 95 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 26 96 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 26 97 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 27 99 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28 100 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28 101 9.2. Transport Mode IPsec protected messages . . . . . . . . . 29 102 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29 103 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29 104 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 110 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 114 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 116 Appendix A. Example Configurations . . . . . . . . . . . . . . . 36 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 119 Intellectual Property and Copyright Statements . . . . . . . . . . 42 121 1. Introduction 123 A mobile node may use various types of network interfaces to obtain 124 durable and wide area network connectivity. This is increasingly 125 become true with mobile nodes having multiple interfaces such as 126 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for 127 and benefits of using multiple points of attachment are discussed in 128 [ID-MOTIVATION]. When a mobile node with multiple interfaces uses 129 Mobile IPv6 [RFC-3775] for mobility management, it cannot use its 130 multiple interfaces to send and receive packets while taking 131 advantage of session continuity provided by Mobile IPv6. This is 132 because Mobile IPv6 allows the mobile node to only bind one care-of 133 address at a time with its home address. 135 This document proposes extensions to Mobile IPv6 to allow a mobile 136 node to register multiple care-of addresses for a home address and 137 create multiple binding cache entries. A new Binding Identification 138 (BID) number is created for each binding the mobile node wants to 139 create and sent in the binding update. The home agent that receives 140 this Binding Update creates separate binding for each BID. The BID 141 information is stored in the corresponding binding cache entry. The 142 BID information can now be used to identify individual bindings. The 143 same extensions can also be used in Binding Updates sent to the 144 correspondent nodes. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC-2119]. 152 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 153 [RFC-4885]. In addition or in replacement of these, the following 154 terms are defined or redefined: 156 Binding Identification number (BID) 158 The BID is an identification number used to distinguish multiple 159 bindings registered by the mobile node. Assignment of distinct 160 BIDs allows a mobile node to register multiple binding cache 161 entries for a given home address. The BID MUST be unique for a 162 binding to a specific care-of address for a given home address and 163 care-of address pair. Zero and negative values MUST NOT be used. 164 Each BID is generated and managed by a mobile node. The BID is 165 stored in the Binding Update List and is sent by the mobile node 166 in the Binding Update. A mobile node MAY change the value of a 167 BID at any time according to its administrative policy, for 168 instance to protect its privacy. An implementation must carefully 169 assign the BID so as to keep using the same BID for the same 170 binding even when the status of the binding is changed. More 171 details can be found in Section 5.1. 173 Binding Identifier Mobility Option 175 The Binding Identifier mobility option is used to carry the BID 176 information. 178 Bulk Registration 180 A mobile node can register multiple bindings at once by sending a 181 single Binding Update. A mobile node can also replace some or all 182 the bindings available at the home agent with the new bindings by 183 using the bulk registration. Bulk registration is supported only 184 with the home agent as explained in Section 5.5. A mobile node 185 MUST NOT perform bulk registration with a correspondent node. 187 3. Protocol Overview 189 A new extension called the Binding identification number (BID) is 190 introduced to distinguish between multiple bindings pertaining to the 191 same home address. If a mobile node configures several IPv6 global 192 addresses on one or more of its interfaces, it can register these 193 addresses with its home agent as care-of addresses. If the mobile 194 node wants to register multiple bindings, it MUST generate a BID for 195 each care-of address and store the BID in the binding update list. A 196 mobile node can manipulate each binding independently by using the 197 BIDs. The mobile node then registers its care-of addresses by 198 sending a Binding Update with a Binding Identifier mobility option. 199 The BID is included in the Binding Identifier mobility option. After 200 receiving the Binding Update with a Binding Identifier mobility 201 option, the home agent MUST copy the BID from the Binding Identifier 202 mobility option to the corresponding field in the binding cache 203 entry. If there is an existing binding cache entry for the mobile 204 node, and if the BID in the Binding Update does not match the one 205 with the existing entry, the home agent MUST create a new binding 206 cache entry for the new care-of address and BID. The mobile node can 207 register multiple care-of addresses either independently in 208 individual Binding Updates or multiple at once in a single Binding 209 Update. 211 If the mobile host wishes to register its binding with a 212 correspondent node, it must perform return routability operations. 213 This includes managing a Care-of Keygen token per care-of address and 214 exchanging CoTi and CoT message with the correspondent node for each 215 care-of address. The mobile node MAY use the same BID that it used 216 with the home agent for a particular care-of address. For protocol 217 simplicity, bulk registration to correspondent nodes is not supported 218 in this document. This is because the Return Routability mechanism 219 introduced in [RFC-3775] cannot be easily extended to verify multiple 220 care-of addresses stored in a single Binding Update. 222 If the mobile node decides to act as a regular mobile node compliant 223 with [RFC-3775], it sends a Binding Update without any Binding 224 Identifier mobility options. The receiver of the Binding Update 225 deletes all the bindings registering with a BID and registers only a 226 single binding for the mobile node. Note that the mobile node can 227 continue using the BID even if it has only a single binding that is 228 active. 230 Binding cache lookup is done based on the home address and BID 231 information. This is different from RFC 3775, where only the home 232 address is used for binding cache lookup. The binding cache lookup 233 may also involve policy or flow filters in cases where some policy or 234 flow filters are used to direct certain packets or flows to a 235 particular care-of address. The binding cache lookup using policy or 236 flow filters is out of scope for this document. In case the binding 237 cache lookup, using the combination of home address and BID, does not 238 return a valid binding cache entry, the home agent MAY perform 239 another lookup based on only the home address. This is 240 implementation dependent and configurable on the home agent. 242 The mobile node may return to the home link through one of its 243 interfaces. There are three options possible for the mobile node 244 when its returns home. 246 1. The mobile node uses only the interface with which it attaches to 247 the home link. It de-registers all bindings related to all 248 care-of addresses. The interfaces still attached to the visited 249 link(s) are no longer going to be receiving any encapsulated 250 traffic from the home agent. 252 2. The mobile node uses only the interfaces still attached to the 253 visited link(s). The interface with which the mobile node 254 attaches to the home link is not used. 256 3. The mobile node may simultaneously use both the interface 257 attached to the home link and the interfaces still attached to 258 the visited link(s). 260 Section 5.6 describes the returning home procedures in more detail. 262 4. Mobile IPv6 Extensions 264 This section summarizes the extensions to Mobile IPv6 necessary for 265 manage multiple bindings. 267 4.1. Binding Cache Structure and Binding Update List 269 The BID is required to be stored in the binding cache and binding 270 update list structure. 272 4.2. Binding Identifier Mobility Option 274 The Binding Identifier mobility option is included in the Binding 275 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 276 Test Init and Care-of Test message. 278 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type = TBD | Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Binding ID (BID) | Status |C|O|H|D|Resrvd | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 285 + + 286 : IPv4 or IPv6 care-of address (CoA) : 287 + + 288 +---------------------------------------------------------------+ 290 Figure 1: BID Mobility Option 292 Type 294 Type value for Binding Identifier is TBD 296 Length 298 8-bit unsigned integer. Length of the option, in octets, 299 excluding the Type and Length fields. MUST be set to 4 when the 300 'C' flag is unset. Otherwise, the Length value MUST be set to 301 either 8 or 20 depending on the 'D' (DSMIPv6) flag. 303 Binding ID (BID) 305 The BID which is assigned to the binding indicated by the care-of 306 address in the Binding Update or the BID mobility option. The BID 307 is a 16-bit unsigned integer. The value of zero is reserved and 308 MUST NOT be used. 310 Status 312 When the Binding Identifier mobility option is included in a 313 Binding Acknowledgement, this field overwrites the status field in 314 the Binding Acknowledgement. If this field is zero, the receiver 315 MUST use the registration status stored in the Binding 316 Acknowledgement message. This Status field is also used to carry 317 error information related to the care-of address test in the 318 Care-of Test message. The status is 8-bit unsigned integer. The 319 possible status codes are the same as the status codes of Binding 320 Acknowledgement. 322 Care-of address (C) flag 324 When this flag is set, it indicates that a valid care-of address 325 is present in the care-of address field in the BID mobility 326 option. This flag MUST be set whenever the mobile node sends 327 multiple care-of addresses in a single Binding Update, i.e., bulk 328 registration. It MAY also used as a substitute for alternate 329 care-of address option even for Binding Updates that are sent only 330 for one care-of address. This flag is valid only for Binding 331 Update sent to the home agent. 333 Overwrite (O) flag 335 When this flag is set, a mobile node requests the recipient to 336 replace all the bindings to binding entries stored in a Binding 337 Update. 339 Simultaneous Home and Foreign Binding (H) flag 341 This flag indicates that the mobile node registers multiple 342 bindings to the home agent while is attached to the home link. 343 This flag is valid only for a Binding Update sent to the home 344 agent. 346 DSMIPv6 (D) flag 348 This flag indicates that the care-of address is an IPv4 address. 349 When this flag is set, the care-of address field MUST contain an 350 IPv4 address. 352 Reserved 354 5 bits Reserved field. The reserved field MUST be zero. 356 Care-of Address 358 This field has the variable length depending on the specified 359 flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 360 care-of address for the corresponding BID is stored in this field. 361 If both 'C' and 'D' flags are set, an IPv4 Care-of Address is 362 carried in this field. This field MUST NOT be used if a Binding 363 Identifier mobility option is included in any other message other 364 than a Binding Update or if the 'C' flag is not set. 366 4.3. New Status Values for Binding Acknowledgement 368 New status values for the status field in a Binding Acknowledgement 369 are defined for handling the multiple Care-of Addresses registration: 371 MCOA NOTCOMPLETE (TBD < 128) 373 In bulk registration, not all the binding identifier mobility 374 option are successfully registered. Some of them are rejected. 375 The error status value of the failed mobility option is 376 individually stored in the status field of the binding identifier 377 mobility option. 379 MCOA RETURNHOME WO/NDP (TBD < 128) 381 When a mobile node returns home, it MUST NOT use NDP for the home 382 address on the home link. This is explained in more detail in 383 Section 5.6 385 MCOA MALFORMED (TBD more than 128) 387 Registration failed because Binding Identifier mobility option was 388 not formatted correctly. 390 MCOA BID CONFLICT (TBD more than 128) 392 The home agent cannot cache both a regular binding and a BID 393 extended binding simultaneously. It returns this status value 394 when the received binding conflicts with the existing binding 395 cache entry(ies). 397 MCOA PROHIBITED(TBD more than 128) 399 It implies the multiple care-of address registration is 400 administratively prohibited. 402 MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) 404 Bulk binding registration is not supported. 406 5. Mobile Node Operation 408 5.1. Management of Care-of Address(es) and Binding Identifier(s) 410 There are two cases when a mobile node might acquire several care-of 411 addresses. Note that a mixture of the two cases is also possible. 413 1. A mobile node may be using several physical network interfaces 414 and acquires a care-of address on each of its interfaces. 416 2. A mobile node uses a single physical network interface, but 417 receives advertisements for multiple prefixes on the link the 418 interface is attached to. This will result in the mobile node 419 configuring several global addresses on the interface from each 420 of the announced prefixes. 422 The difference between the above two cases is only in the number of 423 physical network interfaces and therefore irrelevant in this 424 document. What is of significance is the fact that the mobile node 425 has several addresses it can use as care-of addresses. 427 A mobile node assigns a BID to each care-of address when it wants to 428 register them simultaneously with its home address. The BID MUST be 429 unique for a given home address and care-of address pair. The value 430 should be an integer between 1 and 65535. Zero and negative values 431 MUST NOT be used as BIDs. If a mobile node has only one care-of 432 address, the assignment of a BID is not needed until it has multiple 433 care-of addresses to register with, at which time all of the care-of 434 addresses MUST be mapped to BIDs. 436 5.2. Return Routability: Sending CoTI and Receiving CoT 438 When a mobile node wants to register multiple care-of address with a 439 correspondent node, it MUST have the valid Care-of Keygen token per 440 care-of address. The mobile node needs only one Home Keygen token 441 for its home address. 443 The mobile node MUST include a Binding Identifier mobility option in 444 the Care-of Test Init message. It MUST NOT set any flags in the 445 mobility option. The receiver (i.e. correspondent node) will 446 calculate a care-of Keygen token as specified in [RFC-3775] and reply 447 with a Care-of Test message, with the Binding Identifier mobility 448 option as described in Section 6.2. When the mobile node receives 449 the Care-of Test message, the message is verified as in [RFC-3775]. 450 If a Binding Identifier mobility option is not present in the CoT 451 message in reply to the CoTI message that included a Binding 452 Identifier mobility option, the mobile node must assume that the 453 correspondent node does not support Multiple Care-of Address 454 registration. Thus, the mobile node MUST NOT use a Binding 455 Identifier mobility option in any future Binding Updates to that 456 correspondent node. The mobile node MAY skip re-sending regular CoTI 457 message and keep the received care-of Keygen token for the regular 458 Binding Update. 460 5.3. Binding Registration 462 For the multiple Care-of Addresses registration, the mobile node MUST 463 include a Binding Identifier mobility option(s) in the Binding Update 464 as shown in Figure 2. The BID is copied from a corresponding Binding 465 Update List entry to the BID field of the Binding Identifier mobility 466 option. When IPsec ESP is used for protecting the Binding Update, 467 the care-of address can be carried in the Care-of Address field of 468 the Binding Identifier mobility option. If this is done, the 469 alternate care-of address option MUST NOT be included in the Binding 470 Update. For binding registration to a correspondent node, the mobile 471 node MUST have both active Home and Care-of Keygen tokens for Kbm 472 (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. 473 The care-of Keygen tokens MUST be maintained for each care-of address 474 that the mobile node wants to register to the correspondent node. 475 The Binding Update to the correspondent node is protected by the 476 Binding Authorization Data mobility option that is placed after the 477 Binding Identifier mobility option. 479 IPv6 header (src=CoA, dst=HA) 480 IPv6 Home Address Option 481 ESP Header (for home registration) 482 Mobility header 483 -BU 484 Mobility Options 485 - Binding Identifier mobility option 486 - Binding Authorization mobility option 487 (for Route Optimization) 489 Figure 2: Binding Update for Binding Registration 491 5.4. Bulk Registration 493 Bulk registration is an optimization for binding multiple care-of 494 addresses to a home address using a single Binding Update. This is 495 very useful if the mobile node, for instance, does not want to send a 496 lot of signaling messages through an interface where the bandwidth is 497 scarce. 499 To use bulk registration, the mobile node includes a Binding 500 Identifier Mobility option for each BID and Care-of address pair it 501 wants to register in the same Binding Update message. This is shown 502 in Figure 3. The rest of the fields and options in the Binding 503 Update such as Lifetime, Sequence Number, the flags in the Binding 504 Update are common across all care-of addresses. The alternate 505 care-of address option MUST NOT be used. 507 In the bulk registration, the Sequence Number field of a Binding 508 Update SHOULD be carefully configured. This is because all the bulk- 509 registered bindings use the same Sequence Number specified in the 510 Binding Update. If each binding uses different sequence number, a 511 mobile node MUST use the largest sequence number from the Binding 512 Update list entries used for the bulk registration. If the mobile 513 node cannot select a sequence number for all the bindings due to 514 sequence number out of window, it MUST NOT use the bulk registration 515 for the binding whose sequence number is out of window. A separate 516 Binding Update should be sent for the binding. 518 IPv6 header (src=CoA, dst=HA) 519 IPv6 Home Address Option 520 ESP Header 521 Mobility header 522 -BU 523 Mobility Options 524 - Binding Identifier mobility options 525 (C flag is set, O flag is optional, 526 BID and CoA are stored) 528 Figure 3: Binding Update for Bulk Registration 530 If the mobile node wants to replace existing registered bindings on 531 the home agent with the bindings in the sent Binding Update, it sets 532 the 'O' flag. Section 6.3 describes this registration procedure in 533 detail. 535 5.5. Binding De-Registration 537 When a mobile node decides to delete all the bindings for its home 538 address, it sends a regular de-registration Binding Update with 539 lifetime set to zero as defined in [RFC-3775]. The Binding 540 Identifier mobility option is not required. 542 If a mobile node wants to delete a particular binding(s) from its 543 home agent and correspondent nodes, the mobile node sends a Binding 544 Update with lifetime set to zero and includes a Binding Identifier 545 mobility option(s) with the BID(s) it wants to de-register. The 546 receiver will remove only the care-of address(es) that match(es) the 547 specified BID(s). The care-of addresses field in each mobility 548 option SHOULD be omitted by the sender and MUST be ignored by the 549 receiver. This is because the receiver will remove the binding that 550 matches the specified BID. 552 5.6. Returning Home 554 The mobile node may return to the home link, by attaching to the home 555 link through one of its interfaces. When the mobile node wants to 556 return home, it should be configured with information on what 557 interface it needs to use. The mobile node may use only the 558 interface with which it is attached to the home link, only the 559 interfaces still attached to the visited link or use both interfaces 560 attached to the home link and visited link simultaneously. The 561 following describes each option in more detail. 563 5.6.1. Using only Interface attached to the Home Link 565 The mobile node returns home and de-registers all the bindings as 566 shown in Figure 8 and as defined in [RFC-3775]. De-registering all 567 the bindings is the same as binding de-registration from foreign link 568 described in Section 5.5. After the de-registration step, all the 569 packets routed by the home agent are only forwarded to the interface 570 attached to the home link, even if there are other active interfaces 571 attached to the visited link. While the mobile node de-registers all 572 the bindings from the home agent, it may continue registering 573 bindings for interface attached to visited link to the correspondent 574 node as shown in Figure 8. 576 5.6.2. Using only Interface attached to the Visited Link 578 The mobile node returns home and shuts down the interface attached to 579 the home link as shown in Figure 9. Before shutting down the 580 interface, any binding for the care-of address previously associated 581 with the interface should be deleted. To delete the binding cache 582 entry, the mobile node SHOULD send a de-registration Binding Update 583 with the lifetime set to zero and include the corresponding BID 584 information. If the mobile node does not send a de-registration 585 Binding Update, the binding for the care-of address previously 586 assigned to the interface remains at the home agent. This binding is 587 deleted only when it expires. In order to avoid this, the mobile 588 node SHOULD send a de-registration binding update for the interface 589 attached to the home link. 591 This scenario is not the most efficient because all the traffic to 592 and from the mobile node is going through the bi-directional tunnel, 593 whereas the mobile node is now accessible at one hop on the home link 594 from its home agent. 596 5.6.3. Simultaneous Home and Visited Link Operation 598 In this case, the mobile node returns home and continues using all 599 the interfaces attached to both foreign and home links as shown in 600 Figure 10. The mobile node indicates this by setting the 'H' flag in 601 the BID mobility option as defined below. There are additional 602 requirements on the Returning Home procedures for possible ND 603 conflicts at the home link described below. 605 In [RFC-3775], the home agent intercepts packets meant for the mobile 606 node using proxy Neighbor Discovery while the mobile node is away 607 from the home link. When the mobile node returns home, the home 608 agent deletes the binding cache and stops proxying for the home 609 address so that a mobile node can configure its home address on the 610 interface attached to the home link. In this specification, a mobile 611 node may return home, configure the home address on the interface 612 attached to the home link, but still use the interfaces attached to 613 the foreign links. In this case, a possible conflict arises when the 614 both the home agent and the mobile node try to defend the home 615 address. If the home agent stops proxying for the home address, the 616 packets are always routed to the interface attached to the home link 617 and are never routed to the interfaces attached to the visited links. 618 It is required to avoid the conflict between the home agent and the 619 mobile node, while still allowing the simultaneous use of home and 620 foreign links. The following describes the mechanism for achieving 621 this. 623 In this specification, the home agent MUST intercept all the packets 624 meant for the mobile node and decide whether to send the traffic 625 directly to the home address on the link or tunnel to the care-of 626 address. The home agent intercepts all the packets even when the 627 mobile node is attached to the home link through one of its 628 interfaces. The home agent would make this decision based on the 629 type of packets and flows. How to make this decision is out of scope 630 in this document. The critical part would be to create a neighbor 631 cache entry for the mobile node so that the home agent can deliver 632 the packets on-link. The home agent would need to know the Layer-2 633 address of the interface with which the mobile node is attached to 634 the home link. In order to create the neighbor cache entry for the 635 mobile node, following operations are required. 637 The mobile node sends a de-registration Binding Update to the home 638 agent from the interface attached to the home link. In the Binding 639 Update, the BID mobility option must include the BID the mobile node 640 had previously associated with the interface attached to the home 641 link. The 'H' flag MUST be set in the BID mobility option. The 'C' 642 flag MUST NOT be set and the care-of address field MUST NOT be 643 included. When the 'H' flag is set, the home agent recognizes that 644 the mobile node wants to continue using interfaces attached to both 645 home and visited links. If the 'H' flag is unset, the home agent 646 deletes either all the bindings or the binding corresponding to the 647 BID included in the Binding Identifier mobility option. 649 When the home agent sends the Binding Acknowledgement, it MUST set 650 the status value to either 0 [Binding Update Accepted] or to 651 [MCOARETURNHOME WO/NDP (TBD)] in the BID mobility option depending on 652 home agent configuration at the home link. The new values are: 654 o Binding Update Accepted (0): NDP is permitted for the home address 655 at the home link. This is regular returning home operation of 656 [RFC-3775] 658 o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home 659 address at the home link 661 When the home agent is the only router at the home link, it can 662 intercept all the packets by normal IP routing without using proxying 663 for the home address. It stops proxy ND for the requested home 664 address and responds with the [Binding Update Accepted] status value 665 to the mobile node. The neighbor cache entry for the mobile node is 666 created by the regular exchange of Neighbor Solicitation and Neighbor 667 Advertisement. If the home agent is not the only router on the home 668 link, it MUST continue defending the home address by proxy neighbor 669 discovery in order to intercept the mobile node's traffic. The home 670 agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status 671 field of the BID mobility option. The home agent also learns the 672 mobile node's layer-2 address (i.e., MAC address) during this binding 673 de-registration. It stores the learnt layer-2 address in a neighbor 674 cache entry for the mobile node so that it can construct the layer-2 675 header for the packets meant for the mobile node and forwards them 676 directly to the mobile node's interface attached to the home link. 678 According to [RFC-3775], the mobile node MUST NOT assign the home 679 address to the interface attached to the home link and MUST NOT 680 attempt NDP operations for the home address before the completion of 681 binding de-registration. It MUST NOT send and reply to Neighbor 682 Solicitation for the home address. The home address MUST be 683 tentative address at this moment until it receives Binding 684 Acknowledgement with success status value. 686 When the mobile node receives the Binding Acknowledgement and BID 687 mobility option, it assigns home address to the interface attached to 688 the home link according to the status field of the BID. If the value 689 is [Binding Update Accepted], the mobile node can start defending the 690 home address using regular Neighbor Discovery. 692 If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT 693 defend its home address on the home link. When the mobile node sends 694 packets from the interface attached to the home link, it MUST learn 695 the layer 2 address (i.e., MAC address) of the next hop (i.e. default 696 router, it can be home agent) during the binding de- registration and 697 construct the packet including layer 2 header with the learnt layer-2 698 address of the default router or the home agent. 700 5.7. Receiving Binding Acknowledgement 702 The verification of a Binding Acknowledgement is the same as Mobile 703 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 704 Binding Acknowledgement is described in Section 6.3. 706 If a mobile node includes a Binding Identifier mobility option in a 707 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 708 carry a Binding Identifier mobility option. If no such mobility 709 option is included in the Binding Acknowledgement in response to a 710 Binding Update for multiple care-of address registration, this 711 indicates that the originating node of the Binding Acknowledgement 712 does not support processing the Binding Identifier mobility option. 713 The mobile node MUST then stop multiple care-of address registration 714 with that node. 716 If a Binding Identifier mobility option is present in the received 717 Binding Acknowledgement, the mobile node checks the status field in 718 the option. If the status value in the Binding Identifier mobility 719 option is zero, the mobile node uses the value in the Status field of 720 the Binding Acknowledgement. Otherwise, it uses the value in the 721 Status field of the Binding Identifier mobility option. 723 If the status code is greater than or equal to 128, the mobile node 724 starts relevant operations according to the error code. Otherwise, 725 the mobile node assumes that the originator (home agent or 726 correspondent node) successfully registered the binding information 727 and BID for the mobile node. 729 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 730 stop registering multiple bindings to the node that sent the 731 Binding Acknowledgement. 733 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 734 mobile node SHOULD stop using bulk registrations with the node 735 that sent the Binding Acknowledgement. 737 o If [MCOA MALFORMED] is specified, it indicates that the binding 738 identifier mobility option is formatted wrongly. 740 o If [MCOA BID CONFLICT] is specified, the binding entry specified 741 by the Binding Identifier mobility option is already registered as 742 a regular binding. In such case, the mobile node SHOULD stop 743 sending Binding Updates with BID, or SHOULD use the 'O' flag to 744 reset all the registered bindings. 746 5.8. Receiving Binding Refresh Request 748 The verification of a Binding Refresh Request is the same as in 749 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 750 a Binding Refresh Request is described in section Section 6.4. 752 If a mobile node receives a Binding Refresh Request with a Binding 753 Identifier mobility option, it indicates that the node sending the 754 Binding Refresh Request message is requesting the mobile node to send 755 a new Binding Update for the BID. The mobile node SHOULD then send a 756 Binding Update only for the respective binding. The mobile node MUST 757 include a Binding Identifier mobility option in the Binding Update. 759 If no Binding Identifier mobility option is present in a Binding 760 Refresh Request, the mobile node sends a Binding Update according to 761 its Binding Update List. On the other hand, if the mobile node does 762 not have any Binding Update List entry for the requesting node, the 763 mobile node needs to register either a single binding or multiple 764 bindings depending on its binding management policy. 766 5.9. Bootstrapping 768 When a mobile node bootstraps and registers multiple bindings for the 769 first time, it MUST set the 'O' flag in the Binding Identifier 770 mobility option. If old bindings still exists at the home agent, the 771 mobile node has no knowledge of which bindings still exist at the 772 home agent. This scenario happens when a mobile node reboots and 773 looses state regarding the registrations. If the 'O' flag is set, 774 all the bindings are replaced by the new binding(s). If the mobile 775 node receives the Binding Acknowledgement with the status code set to 776 135 [Sequence number out of window], it MUST retry sending a Binding 777 Update with the last accepted sequence number indicated in the 778 Binding Acknowledgement. 780 The 'O' flag can also be used in individual Binding Updates sent to 781 the correspondent nodes to override any existing binding cache 782 entries at the correspondent node. 784 6. Home Agent and Correspondent Node Operation 786 6.1. Searching Binding Cache with Binding Identifier 788 If either a correspondent node or a home agent has multiple bindings 789 for a mobile node in their binding cache database, it can use any of 790 the bindings to communicate with the mobile node. This section 791 explains how to retrieve the desired binding for the binding 792 management. This document does not provide any mechnaism to select 793 the suitable binding for forwarding data packets. 795 A correspondent node SHOULD use both the home address and the BID as 796 the search key of the binding cache if it knows the corresponding BID 797 (ex. when processing signaling messages). In the example below, if a 798 correspondent node searches the binding with the home address and 799 BID2, it gets binding2 for this mobile node. 801 binding1 [a:b:c:d::EUI, care-of address1, BID1] 802 binding2 [a:b:c:d::EUI, care-of address2, BID2] 803 binding3 [a:b:c:d::EUI, care-of address3, BID3] 805 Figure 4: Searching the Binding Cache 807 A correspondent node learns the BID when it receives a Binding 808 Identifier mobility option. At that time, the correspondent node 809 MUST look up its binding cache database with the home address and the 810 BID retrieved from the Binding Update. If the correspondent node 811 does not know the BID, it searches for a binding with only the home 812 address. In such a case, the first matched binding is found. If the 813 correspondent node does not desire to use multiple bindings for a 814 mobile node, it can simply ignore the BID. 816 6.2. Receiving CoTI and Sending CoT 818 When a correspondent node receives a CoTI message which contains a 819 Binding Identifier mobility option, it processes it as follows. 821 First, the CoTI message is verified as specified in [RFC-3775]. The 822 Binding Identifier mobility option is processed as follows: 824 o If a correspondent node does not understand a Binding Identifier 825 mobility option, it just ignores and skips processing the option. 826 The calculation of a care-of Keygen token will thus be done 827 without a BID value. The correspondent node returns a CoT message 828 without a Binding Identifier mobility option. The mobile node 829 knows whether the correspondent supports processing the Binding 830 Identifier mobility option, by checking if the option is present 831 in the CoT message. 833 o If either the 'C' or the 'O' flag is set in the Binding Identifier 834 mobility option, the correspondent Node SHOULD NOT calculate a 835 care-of Keygen token, but MUST include a Binding Identifier 836 mobility option with status value set to [MCOA MALFORMED] in the 837 Care-of Test message. 839 o Otherwise, the correspondent node MUST include a Binding 840 Identifier mobility option with status value set to zero (success) 841 in the Care-of Test message. 843 o The Care-of address field of each Binding Identifier mobility 844 option, can be omitted, because the mobile node can identify the 845 corresponding Binding Update list entry using the BID. 847 6.3. Processing Binding Update 849 If a Binding Update does not contain a Binding Identifier mobility 850 option, its processing is same as in [RFC-3775]. If the receiver 851 already has multiple bindings for the home address, it MUST replace 852 all the existing bindings by the received binding. As a result, the 853 receiver node MUST have only one binding cache entry for the mobile 854 node. If the Binding Update is for de-registration, the receiver 855 MUST delete all existing bindings from its Binding Cache. 857 If the Binding Update contains a Binding Identifier mobility 858 option(s), it is first validated according to section 9.5.1 of [RFC- 859 3775]. Then the receiver processes the Binding Identifier mobility 860 option(s) as described in the following steps. 862 o The length value is examined. The length value MUST be either 4, 863 8, or 20 depending on the 'C' and 'D' flags. If the length is 864 incorrect, the receiver MUST reject the Binding Update and returns 865 the status value set to [MCOA MALFORMED]. 867 o When the 'C' flag is set, the care-of address MUST be present in 868 the Binding Identifier mobility option. If the care-of address is 869 not present, the receiver MUST reject the Binding Identifier 870 mobility option and returns the status value set to [MCOA 871 MALFORMED]. The operation of 'D' flag is described in Section 8 873 o When multiple Binding Identifier mobility options are present in 874 the Binding Update, it is treated as bulk registration. If the 875 receiving node is a correspondent node, it MUST reject the Binding 876 Update and returns the status value in the binding acknowledgement 877 set to [MCOA BULK REGISTRATION NOT SUPPORT] 879 o If the Lifetime field in the Binding Update is set to zero, the 880 receiving node deletes the binding entry that corresponds to the 881 BID in the Binding Identifier mobility option. If the receiving 882 node does not have an appropriate binding for the BID, it MUST 883 reject the Binding Update and send a Binding Acknowledgement with 884 status set to 133 [not home agent for this mobile node]. 886 o If the 'O' flag is set in the de-registering Binding Update, it is 887 ignored. If the 'H' flag is set, the home agent stores a home 888 address in the Care-of Address field of the binding cache entry. 889 The home agent also stops performing proxy ND for the mobile 890 node's home address. 892 o If the Lifetime field is not set to zero, the receiving node 893 registers a binding with the specified BID as a mobile node's 894 binding. The Care-of address is obtained from the Binding Update 895 packet as follows: 897 * If the 'C' flag is set in the Binding Identifier mobility 898 option, the care-of address is copied from the care-of address 899 field in the Binding Identifier mobility option. 901 * If the 'C' flag is not set in the Binding Identifier mobility 902 option, the care-of address is copied from the source address 903 field of the IPv6 header. 905 * If the 'C' flag is not set and an alternate care-of address is 906 present, the care-of address is copied from the Alternate 907 Care-of address mobility option. 909 o Once the care-of address(es) have been retrieved from the Binding 910 Update, the receiving nodes creates new binding(s). 912 * If only the 'O' flag is set in the Binding Identifier mobility 913 option, the home agent removes all the existing bindings and 914 registers the received bindings. 916 * If the receiver has a regular binding which does not have BID 917 for the mobile node, it must not process the binding update. 918 The receiver should sent a binding acknowledgement with status 919 set to [MCOA BID CONFLICT]. 921 * If the receiver already has a binding with the same BID but 922 different care-of address, it MUST update the binding and 923 respond with a Binding Acknowledgement with status set to 0 924 [Binding Update accepted]. 926 * If the receiver does not have a binding entry for the BID, it 927 registers a new binding for the BID and responds with a Binding 928 Acknowledgement with status set to 0 [Binding Update accepted]. 930 If all the above operations are successfully completed, a Binding 931 Acknowledgement containing the Binding Identifier mobility options 932 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 933 is sent, all the Binding Identifier mobility options stored in the 934 Binding Update MUST be copied to the Binding Acknowledgement except 935 the status field. The Care-of address field in each Binding 936 Identifier mobility option, however, can be omitted, because the 937 mobile node can match a corresponding binding update list entry using 938 the BID. 940 When a correspondent node sends a Binding Acknowledgement, the status 941 value MUST be always stored in the Status field of the Binding 942 Acknowledgement and the Status field of Binding Identifier mobility 943 option set to zero. For the home agent, the status value can be 944 stored in the Status field of either a Binding Acknowledgement or a 945 Binding Identifier mobility option. If the status value is specific 946 to one of bindings in the bulk registration, the status value MUST be 947 stored in the Status field in the corresponding Binding Identifier 948 mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the 949 Status field of the Binding Acknowledgement so that the receiver can 950 examine the Status field of each Binding Identifier mobility option 951 for further operations. 953 6.4. Sending Binding Refresh Request 955 When a node (home agent or correspondent node) sends a Binding 956 Refresh Request for a particular binding created with the BID, the 957 node SHOULD include the Binding Identifier mobility option in the 958 Binding Refresh Request. If the mobile node had used bulk 959 registration, the sender SHOULD include all the Binding Identifier 960 mobility options. If the mobile node had not used bulk registration, 961 the sender includes the Binding Identifier mobility options only for 962 those bindings that need to be refreshed. 964 6.5. Receiving Packets from Mobile Node 966 When a node receives packets with a Home Address destination option 967 from a mobile node, it MUST check that the care-of address that 968 appears in the source address field of the IPv6 header MUST be equal 969 to one of the care-of addresses in the binding cache entry. If no 970 binding is found, the packets MUST be silently discarded. The node 971 MUST also send a Binding Error message as specified in [RFC-3775]. 972 This verification MUST NOT be done for a Binding Update. 974 7. Network Mobility Applicability 976 The binding management mechanisms are the same for a mobile host that 977 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 978 Support protocol [RFC-3963]. Therefore the extensions described in 979 this document can also be used to support a mobile router with 980 multiple care-of addresses. 982 8. DSMIPv6 Applicability 984 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 985 register an IPv4 care-of address instead of the IPv6 care-of address 986 when the mobile node is attached to an IPv4-only access network. It 987 also allows the mobile node to acquire an IPv4 home address in 988 addition to an IPv6 home address for use with IPv4-only correspondent 989 nodes. This section describes how multiple care-of address 990 registration works with IPv4 care-of and home addresses. 992 8.1. IPv4 Care-of Address Registration 994 The mobile node can use the extensions described in the document to 995 register multiple care-of addresses, even if some of the care-of 996 addresses are IPv4 address. 998 Bulk registration MUST NOT be used for the initial binding from an 999 IPv4 care-of address. This is because, the Binding Update and 1000 binding acknowledgement exchange is used to detect NAT on the path 1001 between the mobile node and the home agent. So the mobile node needs 1002 to check for a NAT between each IPv4 care-of address and the home 1003 agent. 1005 The Binding Update MUST be sent to the IPv4 home agent address by 1006 using UDP and IPv4 headers as shown in Figure 5. It is similar to 1007 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1008 used when the BID mobility option is used. 1010 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1011 UDP Header 1012 IPv6 header (src=V6HoA, dst=HAADDR) 1013 ESP Header 1014 Mobility header 1015 -BU 1016 Mobility Options 1017 - Binding Identifier (IPv4 CoA) 1019 Figure 5: Initial Binding Update for IPv4 Care-of Address 1021 If a NAT is not detected, the mobile node can update the IPv4 care-of 1022 address by using bulk registration. The mobile node can register the 1023 IPv4 care-of address along with other IPv4 and IPv6 care-of 1024 addresses. Figure 6 shows the Binding Update format when the mobile 1025 node sends a Binding Update from one of its IPv6 care-of addresses. 1026 If the mobile node sends a BU from IPv4 care-of address, it MUST 1027 follow the format described in Figure 5. Note that the IPv4 Care-of 1028 Address must be registered by non bulk Binding registration, whenever 1029 it is changed. 1031 IPv6 header (src=V6CoA, dst=HAADDR) 1032 IPv6 Home Address Option 1033 ESP Header 1034 Mobility header 1035 -BU 1036 Mobility Options 1037 - Binding Identifier (IPv6/v4 CoA) 1038 - Binding Identifier (IPv6/v4 CoA) 1039 - ... 1041 Figure 6: Binding Bulk Registration for IPv4 care-of address 1043 If the home agent rejects the IPv4 care-of address, it MUST store the 1044 error code value in the Status field of the BID mobility option. 1046 8.2. IPv4 HoA Management 1048 When the mobile node wants to configure an IPv4 home address in 1049 addition to the IPv6 home address, it can request for one using the 1050 IPv4 Home Address option in the Binding Update. If the home agent 1051 accepts the Binding Update, the mobile node can now register multiple 1052 care-of addresses for the IPv4 home address in addition to the IPv6 1053 home address. The same set of care-of addresses will be registered 1054 for both IPv6 and IPv4 home addresses. The mobile node cannot bind 1055 different set of care-of addresses to each home address. 1057 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1058 acknowledgement option in the Binding Acknowledgement only if the 1059 mobile node had requested for an IPv4 home address in the 1060 corresponding Binding Update. The IPv4 address acknowledgement 1061 option MUST be present before any BID option. The status field of 1062 the IPv4 address acknowledgement option contains only the error code 1063 corresponding to the IPv4 home address management. The error values 1064 related to the IPv4 care-of address registration MUST be stored in 1065 the BID mobility option. 1067 9. IPsec and IKEv2 interaction 1069 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1070 use of IPsec to protect signaling messages like Binding Updates, 1071 Binding Acknowledgements and return routability messages. IPsec may 1072 also be used protect all tunneled data traffic. The Mobile IPv6- 1073 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1074 setup the required IPsec security associations. The following 1075 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1076 respect to the use of IKEv2 and IPsec. 1078 o There is only one primary care-of address per mobile node. 1080 o The primary care-of address is stored in the IPsec database for 1081 tunnel encapsulation and decapsulation. 1083 o When the home agent receives a packet from the mobile node, the 1084 source address is verified against the care-of address in the 1085 corresponding binding cache entry. If the packet is a reverse 1086 tunneled packet from the mobile node, the care-of address check is 1087 done against the source address on the outer IPv6 header. The 1088 reverse tunnel packet could either be a tunneled HoTi message or 1089 tunneled data traffic to the correspondent node. 1091 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1092 the care-of address. The IKE SA is based on the care-of address 1093 of the mobile node. 1095 The above assumptions may not be valid when multiple care-of 1096 addresses are used by the mobile node. In the following sections, 1097 the main issues with the use of multiple care-of address with IPsec 1098 are addressed. 1100 9.1. Use of Care-of Address in the IKEv2 exchange 1102 For each home address the mobile node sets up security associations 1103 with the home agent, the mobile node must pick one care-of address 1104 and use that as the source address for all IKEv2 messages exchanged 1105 to create and maintain the IPsec security associations associated 1106 with the home address. The resultant IKEv2 security association is 1107 created based on this care-of address. 1109 If the mobile node needs to change the care-of address, it just sends 1110 a Binding Update with the care-of address it wants to use, with the 1111 corresponding Binding Identifier mobility option, and with the 'K' 1112 bit set. This will force the home agent to update the IKEv2 security 1113 association to use the new care-of address. If the 'K' bit is not 1114 supported on the mobile node or the home agent, the mobile node MUST 1115 re-establish the IKEv2 security association with the new care-of 1116 address. This will also result in new IPsec security associations 1117 being setup for the home address. 1119 9.2. Transport Mode IPsec protected messages 1121 For Mobile IPv6 signaling message protected using IPsec in transport 1122 mode, the use of a particular care-of address among multiple care-of 1123 addresses does not matter for IPsec processing. 1125 For Mobile Prefix Discovery messages, [RFC-3775] requires the home 1126 agent to verify that the mobile node is using the care-of address 1127 that is in the binding cache entry that corresponds to the mobile 1128 node's home address. If a different address is used as the source 1129 address, the message is silently dropped by the home agent. This 1130 document requires the home agent implementation to process the 1131 message as long as the source address is one of the care-of addresses 1132 in the binding cache entry for the mobile node. 1134 9.3. Tunnel Mode IPsec protected messages 1136 The use of IPsec in tunnel mode with multiple care-of address 1137 introduces a few issues that require changes to how the mobile node 1138 and the home agent send and receive tunneled traffic. The route 1139 optimization mechanism described in [RFC-3775] mandates the use of 1140 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1141 mobile node and the home agent may also choose to protect all reverse 1142 tunneled payload traffic with IPsec in tunnel mode. The following 1143 sections address multiple care-of address support for these two types 1144 of messages. 1146 9.3.1. Tunneled HoTi and HoT messages 1148 The mobile node MAY use the same care-of address for all HoTi 1149 messages sent reverse tunneled through the home agent. The mobile 1150 node may use the same care-of address irrespective of which 1151 correspondent node the HoTi message is being sent. RFC 3775 requires 1152 the home agent to verify that the mobile node is using the care-of 1153 address that is in the binding cache entry, when it receives a 1154 reverse tunneled HoTi message. If a different address is used as the 1155 source address, the message is silently dropped by the home agent. 1156 This document requires the home agent implementation to decapsulate 1157 and forward the HoTi message as long as the source address is one of 1158 the care-of addresses in the binding cache entry for the mobile node. 1160 When the home agent tunnels a HoT message to the mobile node, the 1161 care-of address used in the outer IPv6 header is not relevant to the 1162 HoT message. So regular IPsec tunnel encapsulation with the care-of 1163 address known to the IPsec implementation on the home agent is 1164 sufficient. 1166 9.3.2. Tunneled Payload Traffic 1168 When the mobile sends and receives multiple traffic flows protected 1169 by IPsec to different care-of addresses, the use of the correct 1170 care-of address for each flow becomes important. Support for this 1171 requires the following two considerations on the home agent. 1173 o When the home agent receives a reverse tunneled payload message 1174 protected by IPsec in tunnel mode, it must check that the care-of 1175 address is one of the care-of addresses in the binding cache 1176 entry. According to RFC 4306, the IPsec implementation on the 1177 home agent does not check the source address on the outer IPv6 1178 header. Therefore the care-of address used in the reverse 1179 tunneled traffic can be different from the care-of address used as 1180 the source address in the IKEv2 exchange. However, the Mobile 1181 IPv6 stack on the home agent MUST verify that the source address 1182 is one of the care-of addresses registered by the mobile node 1183 before decapsulating and forwarding the payload traffic towards 1184 the correspondent node. 1186 o For tunneled IPsec traffic from the home agent to the mobile node, 1187 The IPsec implementation on the home agent may not be aware of 1188 which care-of address to use when performing IPsec tunnel 1189 encapsulation. The Mobile IP stack on the home agent must specify 1190 the tunnel end point for the IPsec tunnel. This may require tight 1191 integration between the IPsec and Mobile IP implementations on the 1192 home agent. 1194 10. Security Considerations 1196 The security considerations for securing the Binding Update and 1197 binding acknowledgement messages with multiple care-of address are 1198 very similar to the security considerations for securing the Binding 1199 Update and binding acknowledgement. Please see [RFC-3775] for more 1200 information. The Binding Update and binding acknowledgement messages 1201 with multiple care-of addresses MUST be protected using IPsec as show 1202 in Section 9. Additional security considerations are described 1203 below. 1205 With simultaneous binding support, it is possible for a malicious 1206 mobile node to successfully bind a number of victims' addresses as 1207 valid care-of addresses for the mobile node with its home agent. 1208 Once these addresses have been bound, the malicious mobile node can 1209 perform a re-direction attack by instructing the home agent (e.g. 1210 setting filtering rules to direct a large file transfer) to tunnel 1211 packets to the victims' addresses. Such risk is highlighted in [ID- 1212 MIP6ANALYSIS]. These attacks are possible because the care-of 1213 addresses sent by the mobile node in the Binding Update messages are 1214 not verified by home agent, i.e., the home agent does not check if 1215 the mobile node is at the care-of address it is claiming to be. The 1216 security model for Mobile IPv6 assumes that there is a trust 1217 relationship between the mobile node and its home agent. Any 1218 malicious attack by the mobile node is traceable by the home agent. 1219 This acts as a deterrent for the mobile node to launch such attacks. 1221 Although such risk exists in Mobile IPv6, the risk level is escalated 1222 when simultaneous multiple care-of address bindings are performed. 1223 In Mobile IPv6, a mobile node can only have a single care-of address 1224 binding per home address at a given time. However, for simultaneous 1225 multiple care-of address bindings, a mobile node can have more than 1226 one care-of address binding per home address at a given time. This 1227 implies that a mobile node using simultaneous binding support can 1228 effectively bind more than a single victim's address. Another 1229 difference is the degree of risk involved. In the single care-of 1230 address binding case, once the re-direction attack is initiated, a 1231 malicious mobile node would be unable to use its home address for 1232 communications (such as to receive control packets pertaining to the 1233 file transfer). However, in the simultaneous binding support case, a 1234 malicious mobile node could bind a valid care-of address in addition 1235 to multiple victims addresses. This valid care-of address could then 1236 be used by the malicious mobile node to set up flow filtering rules 1237 at its home agent, thereby controlling and/or launching new re- 1238 direction attacks. 1240 Thus, in view of such risks, it is advisable for a home agent to 1241 employ some form of care-of address verification mechanism before 1242 using the care-of addresses as a valid routing path to a mobile node. 1243 Solutions related to this are described in [ID-COAVERIFY]. 1245 11. IANA Considerations 1247 The following Extension Types MUST be assigned by IANA: 1249 o Binding Identifier mobility option type: This must be assigned 1250 from the same space as mobility option in [RFC-3775]. 1252 o New Successful Status of Binding Acknowledgement: This status code 1253 must be assigned from the same space as binding acknowledgement 1254 status codes in [RFC-3775]. 1256 * MCOA NOTCOMPLETE (TBD) 1258 o New Unsuccessful Status of Binding Acknowledgement: These status 1259 codes must also be assigned from the same space as binding 1260 acknowledgement status codes in [RFC-3775]. 1262 * MCOA MALFORMED (TBD) 1264 * MCOA BID CONFLICT (TBD) 1266 * MCOA PROHIBITED(TBD) 1268 * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 1270 12. Acknowledgements 1272 The authors would like to thank Masafumi Aramoto, George Tsirtsis, 1273 Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Susumu 1274 Koshiba, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Hiroki 1275 Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, Keisuke 1276 Uehara, Masafumi Watari in alphabetical order, and the Jun Murai 1277 Laboratory at the KEIO University. 1279 13. References 1281 13.1. Normative References 1283 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1284 in IPv6", RFC 3775, June 2004. 1286 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1287 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1288 January 2005. 1290 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, March 1997. 1293 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1294 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1296 13.2. Informative References 1298 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1299 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1300 Interfaces and Global Addresses", 1301 draft-ietf-monami6-multihoming-motivation-scenario-02 (work in 1302 progress), July 2007 1304 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1305 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1307 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1308 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1309 draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver 1310 2007. 1312 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1313 RFC 3753, June 2004. 1315 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1316 Terminology", RFC 4885, July 2007. 1318 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1319 and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in 1320 progress), November 2007. 1322 [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of 1323 Addresses in Multiple Bindings Registration", 1324 draft-lim-mext-multiple-coa-verify-01 (work in progress), February 1325 2008. 1327 Appendix A. Example Configurations 1329 In this section, we describe typical scenarios when a mobile node has 1330 multiple network interfaces and acquires multiple Care-of Addresses 1331 bound to a home address. The home address of the mobile node (MN in 1332 figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly 1333 acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns 1334 BID1, BID2 and BID3 to each care-of address. 1336 +----+ 1337 | CN | 1338 +--+-+ 1339 | 1340 +---+------+ +----+ 1341 +------+ Internet |----------+ HA | 1342 | +----+---+-+ +--+-+ 1343 CoA2| | | | Home Link 1344 +--+--+ | | ------+------ 1345 | MN +========+ | 1346 +--+--+ CoA1 | 1347 CoA3| | 1348 +---------------+ 1350 Binding Cache Database: 1351 home agent's binding (Proxy neighbor advertisement is active) 1352 binding [a:b:c:d::EUI care-of address1 BID1] 1353 binding [a:b:c:d::EUI care-of address2 BID2] 1354 binding [a:b:c:d::EUI care-of address3 BID3] 1355 correspondent node's binding 1356 binding [a:b:c:d::EUI care-of address1 BID1] 1357 binding [a:b:c:d::EUI care-of address2 BID2] 1358 binding [a:b:c:d::EUI care-of address3 BID3] 1360 Figure 7: Multiple Interfaces Attached to a Foreign Link 1362 Figure 7 depicts the scenario where all interfaces of the mobile node 1363 are attached to foreign links. After binding registrations, the home 1364 agent (HA) and the correspondent node (CN) have the binding entries 1365 listed in their binding cache database. The mobile node can utilize 1366 all the interfaces. 1368 +----+ 1369 | CN | 1370 +--+-+ 1371 | 1372 +---+------+ +----+ 1373 +------+ Internet |----------+ HA | 1374 | +--------+-+ +--+-+ 1375 CoA2| | | Home Link 1376 +--+--+ | --+---+------ 1377 | MN +========+ | | 1378 +--+--+ | | | 1379 CoA3| +---|-----------+ 1380 +---------------+ 1382 Binding Cache Database: 1383 home agent's binding 1384 none 1385 correspondent node's binding 1386 binding [a:b:c:d::EUI care-of address2 BID2] 1387 binding [a:b:c:d::EUI care-of address3 BID3] 1389 Figure 8: One of Interface Attached to Home Link and Returning Home 1391 Figure 8 depicts the scenario where MN returns home with one of its 1392 interfaces. After the successful de-registration of the binding to 1393 HA, HA and CN have the binding entries listed in their binding cache 1394 database of Figure 8. After de-registration, the ND state of the 1395 home address is managed by the MN. MN can communicate with the HA 1396 through only the interface attached to the home link. On the other 1397 hand, the mobile node can communicate with CN from the other 1398 interfaces attached to foreign links (i.e. route optimization). Even 1399 if MN is attached to the home link, it can still send Binding Updates 1400 for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has 1401 bindings, packets are routed to each Care-of Addresses directly. Any 1402 packet arrived at HA are routed to the interface attached to the home 1403 link. 1405 +----+ 1406 | CN | 1407 +--+-+ 1408 | 1409 +---+------+ +----+ 1410 +------+ Internet |----------+ HA | 1411 | +----+-----+ +--+-+ 1412 CoA2| | | Home Link 1413 +--+--+ | --+---+------ 1414 | MN +========+ | 1415 +--+--+ CoA1 | 1416 | | 1417 +---------------------------+ 1418 (Disable interface) 1420 Binding Cache Database: 1421 home agent's binding 1422 binding [a:b:c:d::EUI care-of address1 BID1] 1423 binding [a:b:c:d::EUI care-of address2 BID2] 1424 correspondent node's binding 1425 binding [a:b:c:d::EUI care-of address1 BID1] 1426 binding [a:b:c:d::EUI care-of address2 BID2] 1428 Figure 9: One of Interface Attached to Home Link and Not Returning 1429 Home 1431 Figure 9 depicts the scenario where MN disables the interface 1432 attached to the home link and communicates with the interfaces 1433 attached to foreign links. HA continues managing the ND state of the 1434 home address by Proxy neighbor advertisement. The HA and the CN have 1435 the binding entries listed in their binding cache database. All 1436 packets routed to the home link are intercepted by the HA and 1437 tunneled to the other interfaces attached to the foreign link 1438 according to the binding entries. 1440 Topology-a) 1441 +----+ 1442 | CN | 1443 +--+-+ 1444 | 1445 +---+------+ +----+ 1446 +------+ Internet |----------+ HA | 1447 | +----+-----+ +--+-+ 1448 CoA2| | | Home Link 1449 +--+--+ | --+---+------ 1450 | MN +========+ | 1451 +--+--+ CoA1 | 1452 CoA3 | | 1453 +---------------------------+ 1455 Topology-b) 1456 +----+ 1457 | CN | 1458 +--+-+ 1459 | 1460 +---+------+ Router +----+ 1461 +------+ Internet |-------R | HA | 1462 | +----+-----+ | +--+-+ 1463 CoA2| | | | Home Link 1464 +--+--+ | --+-+-------+------ 1465 | MN +========+ | 1466 +--+--+ CoA1 | 1467 CoA3 | | 1468 +---------------------------+ 1470 Binding Cache Database: 1471 home agent's binding 1472 binding [a:b:c:d::EUI care-of address1 BID1] 1473 binding [a:b:c:d::EUI care-of address2 BID2] 1474 correspondent node's binding 1475 binding [a:b:c:d::EUI care-of address1 BID1] 1476 binding [a:b:c:d::EUI care-of address2 BID2] 1477 binding [a:b:c:d::EUI care-of address3 BID3] 1479 Figure 10: Utilize Interfaces Attached to both Home and Foreign Links 1481 Figure 10 depicts the scenario where interfaces of MN are attached to 1482 both the home and foreign links. There are two possible topologies 1483 whether the HA is single router at the home link or not. The 1484 operation of ND is different in two topologies. The HA and CN have 1485 the binding entries listed in Figure 10 in their binding cache 1486 database regardless of topologies. The HA also knows that the MN has 1487 attached to the home link. All the traffic from the Internet are 1488 intercepted by the HA and routed to either the interface attached to 1489 the home link or the interfaces attached to the foreign links. How 1490 to make the decision is out of scope in this document. 1492 There are two different treatments of the ND state of the home 1493 address. 1495 o MN defends the home address by regular ND (topology-a) 1497 o HA defends the home address by Proxy ND (topology-b) 1499 The first case is required that the HA is the single exit router to 1500 the Internet and is capable of intercepting packets without relying 1501 on proxy ND. The MN can manage the ND of the home address on the 1502 home link. In the second case, the HA is not only router at the home 1503 link and cannot intercept all the packets meant for the MN by IP 1504 routing. The HA needs to run Proxy ND to intercept all the packets 1505 at the home link. Since the MN cannot operate the ND of its home 1506 address at the home link, HA cannot resolve the layer-2 address of 1507 the MN at the home link. The HA MUST learn and record the layer-2 1508 address (MAC address) of the MN's interface attached to the home link 1509 to forward packets. The packets forwarding is achieved without ND 1510 cache. The MN is also required to learn and record the layer-2 1511 address of the HA's interface to send packets from the home link. 1513 Authors' Addresses 1515 Ryuji Wakikawa (Editor) 1516 Faculty of Environment and Information Studies, Keio University 1517 5322 Endo 1518 Fujisawa, Kanagawa 252-8520 1519 Japan 1521 Phone: +81-466-49-1100 1522 Fax: +81-466-49-1395 1523 Email: ryuji@sfc.wide.ad.jp 1524 URI: http://www.wakikawa.org/ 1525 Thierry Ernst 1526 INRIA 1527 INRIA Rocquencourt 1528 Domaine de Voluceau B.P. 105 1529 Le Chesnay, 78153 1530 France 1532 Phone: +33-1-39-63-59-30 1533 Fax: +33-1-39-63-54-91 1534 Email: thierry.ernst@inria.fr 1535 URI: http://www.nautilus6.org/~thierry 1537 Kenichi Nagami 1538 INTEC NetCore Inc. 1539 1-3-3, Shin-suna 1540 Koto-ku, Tokyo 135-0075 1541 Japan 1543 Phone: +81-3-5565-5069 1544 Fax: +81-3-5565-5094 1545 Email: nagami@inetcore.com 1547 Vijay Devarapalli 1548 Azaire Networks 1549 3121 Jay Street 1550 Santa Clara, CA 95054 1551 USA 1553 Email: vijay.devarapalli@azairenet.com 1555 Full Copyright Statement 1557 Copyright (C) The IETF Trust (2008). 1559 This document is subject to the rights, licenses and restrictions 1560 contained in BCP 78, and except as set forth therein, the authors 1561 retain all their rights. 1563 This document and the information contained herein are provided on an 1564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1566 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1567 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1568 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1571 Intellectual Property 1573 The IETF takes no position regarding the validity or scope of any 1574 Intellectual Property Rights or other rights that might be claimed to 1575 pertain to the implementation or use of the technology described in 1576 this document or the extent to which any license under such rights 1577 might or might not be available; nor does it represent that it has 1578 made any independent effort to identify any such rights. Information 1579 on the procedures with respect to rights in RFC documents can be 1580 found in BCP 78 and BCP 79. 1582 Copies of IPR disclosures made to the IETF Secretariat and any 1583 assurances of licenses to be made available, or the result of an 1584 attempt made to obtain a general license or permission for the use of 1585 such proprietary rights by implementers or users of this 1586 specification can be obtained from the IETF on-line IPR repository at 1587 http://www.ietf.org/ipr. 1589 The IETF invites any interested party to bring to its attention any 1590 copyrights, patents or patent applications, or other proprietary 1591 rights that may cover technology that may be required to implement 1592 this standard. Please address the information to the IETF at 1593 ietf-ipr@ietf.org. 1595 Acknowledgment 1597 Funding for the RFC Editor function is provided by the IETF 1598 Administrative Support Activity (IASA).