idnits 2.17.1 draft-ietf-monami6-multiplecoa-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1263. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 7 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '...a negative value MUST NOT be used. Af...' RFC 2119 keyword, line 211: '.... A mobile node MAY change the value ...' RFC 2119 keyword, line 244: '...s Home Agent, it MUST generate a BID f...' RFC 2119 keyword, line 247: '...ub-option. The BID MUST be put in the...' RFC 2119 keyword, line 251: '..., the Home Agent MUST copy the BID fro...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The first situation is when a mobile node wants to return home with interface attached to the home link. In this case, the mobile node MUST de-register all the bindings by sending a Binding Update with lifetime set to zero. The mobile node MAY NOT put any Binding Unique Identifier sub-option in this packet. Then, the receiver deletes all the bindings from its binding cache database. -- 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 (Oct 2006) is 6402 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) ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-00 ** Downref: Normative reference to an Informational draft: draft-ietf-monami6-mipv6-analysis (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-00 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-05 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-02 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Monami6 Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Expires: April 4, 2007 T. Ernst 5 Keio University / WIDE 6 K. Nagami 7 INTEC NetCore 8 Oct 2006 10 Multiple Care-of Addresses Registration 11 draft-ietf-monami6-multiplecoa-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 4, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 According to the current Mobile IPv6 specification, a mobile node may 45 have several Care-of Addresses, but only one, termed the primary 46 Care-of Address, can be registered with its Home Agent and the 47 Correspondent Nodes. However, for matters of cost, bandwidth, delay, 48 etc, it is useful for the mobile node to get Internet access through 49 multiple access media simultaneously, in which case multiple active 50 IPv6 Care-of Addresses would be assigned to the mobile node. We thus 51 propose Mobile IPv6 extensions designed to register multiple Care-of 52 Addresses bound to a single Home Address instead of the sole primary 53 Care-of Address. For doing so, a new identification number must be 54 carried in each binding for the receiver to distinguish between the 55 bindings corresponding to the same Home Address. Those extensions 56 are targeted to NEMO (Network Mobility) Basic Support as well as to 57 Mobile IPv6. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8 67 3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 8 68 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Binding Cache Structure and Management . . . . . . . . . . 11 72 4.2. Binding Update List Structure and Management . . . . . . . 11 73 4.3. Message Format Changes . . . . . . . . . . . . . . . . . . 11 74 4.3.1. Binding Unique Identifier sub-option . . . . . . . . . 11 75 4.3.2. Binding Update . . . . . . . . . . . . . . . . . . . . 13 76 4.3.3. Binding Acknowledgment . . . . . . . . . . . . . . . . 13 78 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Management of Care-of Addresses and Binding Unique 80 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15 82 5.3. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 83 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 16 84 5.5. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 85 5.6. Using Alternate Care-of Address . . . . . . . . . . . . . 17 86 5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 87 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 18 88 5.9. Receiving Binding Error . . . . . . . . . . . . . . . . . 19 90 6. Home Agent and Correspondent Node Operation . . . . . . . . . 20 91 6.1. Searching Binding Cache with Binding Unique Identifier . . 20 92 6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 20 93 6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 22 94 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 23 95 6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 23 97 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 24 99 8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 25 101 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 109 Appendix A. Example Configurations . . . . . . . . . . . . . . . 28 111 Appendix B. Changes From Previous Versions . . . . . . . . . . . 34 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 114 Intellectual Property and Copyright Statements . . . . . . . . . . 36 116 1. Introduction 118 Permanent Internet connectivity is required by some applications 119 while a mobile node moves across several access networks (i.e. ISPs, 120 hotspots, etc). Unfortunately, there is no network interfaces 121 assuring global scale connectivity. Therefore, a mobile node should 122 use various type of network interfaces to obtain durable and wide 123 area network connectivity [8]. For example, it is desirable to 124 maintain the Internet connectivity while an automobile running on a 125 freeway receives voice or video streaming data from different access 126 networks. Such scenarios and motivations for multiple points of 127 attachment, and benefits for doing it are discussed at large in [9]. 129 Once multiple interfaces are available to a mobile node, a backup 130 interface can be used to recover from the loss of Internet 131 connectivity on the other interface, therefrom maintaining Internet 132 connectivity of wide spread and reach. In addition, each 133 communication flow could be sent to a distinct network interface, 134 providing efficient network bandwidth consumption. It becomes 135 possible for users to select the most appropriate network interface 136 depending on a visiting network environment, since wireless networks 137 are mutable and less reliable than wired networks and since each 138 network interface has different cost, performance, bandwidth, access 139 range, and reliability. Users should also be able to select the most 140 appropriate interface per communication type. For example, TCP 141 traffic should be transmitted over the wireless interface, whereas 142 UDP traffic should be transmitted over the wired interface to avoid 143 disturbing TCP connections. 145 IPv6 [1] conceptually allows a node to have several addresses on a 146 given interface. Consequently, Mobile IPv6 [2] has mechanisms to 147 manage multiple ``Home Addresses'' based on Home Agent's managed 148 prefixes such as mobile prefix solicitation and mobile prefix 149 advertisement. But assigning a single Home Address to a given 150 network interface is more advantageous than assigning multiple Home 151 Addresses because applications do not need to be aware of the 152 multiplicity of Home Addresses. Of course, applications should be 153 aware of the active Home Address to be used for communicating. At 154 the TCP layer, TCP holds the Home Address as a source address of the 155 communication for connection management. Applications must be 156 restarted to reset the connection information when the mobile node 157 changes its active network interface (i.e. change the Home Address). 159 However, according to section 11.5.3 of the Mobile IPv6 160 specification, a mobile node is not allowed to register multiple 161 Care-of Addresses bound to a single Home Address. If a mobile node 162 sends Binding Updates for each Care-of Address, Correspondent Nodes 163 would always overwrite the Care-of Address recorded in the binding 164 cache with the one contained in the latest received binding update. 165 It is thus impossible for a mobile node to register multiple Care-of 166 Addresses in the Correspondent Node's binding cache. Moreover, since 167 NEMO Basic Support [3] is based on Mobile IPv6, the same issues 168 applies to a mobile node acting as mobile router. 170 Multihoming issues pertaining to mobile nodes operating Mobile IPv6 171 and mobile routers operating NEMO Basic Support are respectively 172 discussed [4] and [10] in Monami6 and NEMO Working Group. 174 In this document, we thus propose a new identification number called 175 Binding Unique Identification (BID) number for each binding cache 176 entry to accommodate multiple bindings registration. We also propose 177 extension of binding cache management to store the BID and a new sub- 178 option for binding update to carry the BID. The BID is assigned to 179 either the interfaces or Care-of Addresses bound to a single home 180 address of a mobile node. The mobile node notifies the BID to both 181 its Home Agent and Correspondent Nodes by means of a Binding Update. 182 Correspondent nodes and the Home Agent record the BID into their 183 binding cache. The Home Address thus identifies a mobile node itself 184 whereas the BID identifies each binding registered by a mobile node. 185 By using the BID, multiple bindings can then be distinguished. 187 A user of a mobile node may be able to bind some policies to a BID. 188 The policy is used to divide flows to multiple network interfaces by 189 flow type, port number, or destination address, etc. How to 190 distribute or configure policies is not within the scope of this 191 document. There are solutions available in Monami6 WG, for example 192 [11]. 194 2. Terminology 196 Terms used in this draft are defined in [2], [5] and [6]. In 197 addition or in replacement of these, the following terms are defined 198 or redefined: 200 Binding Unique Identification number (BID) 202 The BID is an identification number used to distinguish multiple 203 bindings registered by the mobile node. Assignment of distinct 204 BID allows a mobile node to register multiple binding cache 205 entries for a given Home Address. The BID is generated to 206 register multiple bindings in the binding cache for a given 207 address in a way it cannot be duplicated with another BID. The 208 zero value and a negative value MUST NOT be used. After being 209 generated by the mobile node, the BID is stored in the Binding 210 Update List and is sent by the mobile node by means of a sub- 211 option of a Binding Update. A mobile node MAY change the value of 212 a BID at any time according to its administrative policy, for 213 instance to protect its privacy. 215 The BID is conceptually assigned to a binding. An implementation 216 must carefully assign the BID so as to keep using the same BID for 217 the same binding even when the status of the binding is changed. 218 More details can be found in Section 5.1. 220 Binding Unique Identifier sub-option 222 The Binding Unique Identifier sub-option is used to carry the BID. 224 Bulk Registration 226 A mobile node can register multiple bindings by sending a binding 227 update. Several care-of addresses can be stored in a Binding 228 Update. The bulk registration is supported only for home 229 registration. Note that a mobile node should not try to perform 230 bulk registration with Correspondent Nodes. 232 3. Protocol Overview 234 We propose a new identification number (BID) to distinguish multiple 235 bindings pertaining to the same Home Address. The procedures for the 236 mobile node to register multiple bindings are described in the 237 paragraphs below. 239 3.1. Multiple Care-of Addresses Registration 241 Once a mobile node gets several IPv6 global addresses on interfaces, 242 it can register these addresses with its Home Agent (home 243 registration). If the mobile node wants to register multiple 244 bindings to its Home Agent, it MUST generate a BID for each Care-of 245 Address and record it into the binding update list. The mobile node 246 then registers its Care-of Addresses by sending a Binding Update with 247 a Binding Unique Identifier sub-option. The BID MUST be put in the 248 Binding Unique Identifier sub-option. After receiving the Binding 249 Update, the Home Agent verifies the request and records the binding 250 in its binding cache. If the newly defined sub-option is present in 251 the Binding Update, the Home Agent MUST copy the BID from the Binding 252 Update to the corresponding field in the binding entry. Even if 253 there is already an entry for the mobile node, the Home Agent MUST 254 register a new binding entry for the BID stored in the Binding Unique 255 Identifier sub-option. The mobile node registers multiple Care-of 256 Addresses either independently (in individual BUs) or multiple at 257 once (in a single BU). 259 If the mobile node wishes to register its binding with a 260 Correspondent Node, it MUST start return routability operations 261 before sending a Binding Update. The mobile node MUST sends CoTI for 262 each Care-of Addresses and MUST receive CoT for each Care-of 263 Addresses. The mobile node also uses a BID generated for the home 264 registration to register them as individual bindings. The 265 registration step is the same as for the home registration except for 266 calculating authenticator by using Binding Unique Identifier sub- 267 option as well as the other sub-options specified in RFC 3775. Since 268 return routability cannot be verified with multiple care-of addresses 269 in a binding update, bulk registration is not supported with 270 Correspondent Nodes in this document. 272 3.2. Multiple Bindings Management 274 The BID is used as a search key for a corresponding entry in the 275 binding cache in addition to the Home Address. When the Home Agent 276 checks the binding cache database for the mobile node, it searches a 277 corresponding binding entry with the Home Address and BID of the 278 desired binding. 280 The desired binding can be selected with policy and filter 281 information. If a mobile node registers a binding with priority 282 value, the priority can be a key to select a binding. The capability 283 of searching the desired binding enables load-sharing and QoS with 284 flow separation. However, this selection and flow separation are 285 outside the scope of this document. 287 If there is no desired binding, it searches the binding cache 288 database with the Home Address as specified in Mobile IPv6. The 289 first matched binding entry may be found, although this is 290 implementation dependent. 292 If a node has multiple bindings and its packets meant for the mobile 293 node are not delivered correctly, the node can change the binding 294 entry for the mobile node so as to recover the connection 295 immediately. The node can detect a binding invalidation by packets 296 loss or ICMP error messages such as ICMP_UNREACHABLE. This provides 297 redundancy for Mobile IPv6. 299 When one of the care-of addresses is changed, the mobile node sends a 300 Binding Update with the new Care-of Address and the corresponding 301 BID. The receiver of the Binding Update updates the binding which 302 BID fits the BID contained in the received Binding Unique Identifier 303 sub-option. The mobile node can manage each binding independently 304 owing to BID. 306 If the mobile node decides to register only single binding, it just 307 sends a Binding Update without a Binding Unique Identifier sub-option 308 (i.e. normal Binding Update). The receiver of the Binding Update 309 registers only a single binding for the mobile node. If the receiver 310 has multiple bindings, one binding is registered without BID and the 311 rest of bindings are deleted. 313 3.3. Returning Home 315 When the mobile node returns home, there are two situations, since 316 the Home Agent defends the mobile node's Home Address by using the 317 proxy neighbor advertisement. It is impossible to utilize all the 318 interfaces when one interface is attached to the home link and the 319 others are attached to foreign links. If the proxy Neighbor 320 Advertisement for the Home Address is stopped, packets are always 321 routed to the interface attached to the home link. If proxy is not 322 stopped, packets are never routed to the interface attached to the 323 home link. The decision whether a mobile node returns home or not is 324 up to implementers. 326 The first situation is when a mobile node wants to return home with 327 interface attached to the home link. In this case, the mobile node 328 MUST de-register all the bindings by sending a Binding Update with 329 lifetime set to zero. The mobile node MAY NOT put any Binding Unique 330 Identifier sub-option in this packet. Then, the receiver deletes all 331 the bindings from its binding cache database. 333 The second situation is when a mobile node does not want to return 334 home, though one of its interfaces is attached to its home link. The 335 mobile node disables the interface attached to the home link and 336 keeps using the rest of interfaces attached to foreign links. In 337 this case, the mobile node sends a de-registration Binding Update for 338 the interface attached to the home link with the Binding Unique 339 Identifier sub-option. The receiver of the de-registration Binding 340 Update deletes only the correspondent binding entry from the binding 341 cache database. The Home Agent does not stop proxying neighbor 342 advertisement as long as there are still bindings for the other 343 interfaces. 345 In the above two cases, a mobile node cannot use interfaces attached 346 to both home and foreign links simultaneously. If this is what a 347 mobile node wants, a home agent can set up another link other than 348 home link and uses the link for the mobile node to return virtually 349 to home network. The detail can be found in Figure 7 351 4. Mobile IPv6 Extensions 353 In this section are described the changes to Mobile IPv6 necessary to 354 manage multiple bindings bound to a same Home Address. 356 4.1. Binding Cache Structure and Management 358 The following additional items are required in the binding cache 359 structure, i.e.: 361 BID of the Binding Cache Entry 363 The BID is notified by the mobile node by means of a Binding 364 Unique Identifier sub-option. The value MUST be zero if the 365 Binding Unique identifier does not appear in a Binding Update. 367 Priority of the Binding Cache Entry 369 The priority is notified by the mobile node by means of a Binding 370 Unique Identifier sub-option. 372 4.2. Binding Update List Structure and Management 374 The following additional items are required for the binding update 375 structure, i.e.: 377 BID 379 The BID MUST be generated whenever the mobile node registers 380 multiple bindings for its Home Address. 382 Priority 384 MUST be set if the priority field of a Binding Unique Identifier 385 is valid. 387 4.3. Message Format Changes 389 4.3.1. Binding Unique Identifier sub-option 391 If needed, the Binding Unique Identifier sub-option is included in 392 the Binding Update, Binding Acknowledgment, Binding Refresh Request, 393 or Binding Error messages. 395 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = TBD | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Binding Unique ID (BID) |Priority/Status|C|R| Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 402 + + 403 + Care-of Address (CoA) + 404 + + 405 +---------------------------------------------------------------+ 407 Figure 1: BID Sub-Option 409 Type 411 Type value for Binding Unique Identifier will be assigned later. 413 Length 415 Length value is 4 when the C flag is unset. Length value is 20 416 when the C flag is set. 418 Binding Unique ID (BID) 420 The BID which is assigned to the binding carried in the Binding 421 Update with this sub-option. BID is 16-bit unsigned integer. A 422 value of zero is reserved. 424 Priority/Status 426 When the Binding Unique Identifier sub-option is included in a 427 Binding Update, this field indicates the priority field assigned 428 to each binding. The receiver can utilize this priority to 429 determine which binding is used to deliver packets. The priority 430 is 8-bit unsigned integer. The higher value has higher priority. 431 Values of zero and 255 are reserved for specific meaning. 433 A value of zero indicates No Priority. A value of 255 indicates 434 that the binding corresponding to this BID is a default of this 435 mobile node. This default binding is used by the flow binding 436 scheme [11]. If the receiver cannot recognize 255, it MUST ignore 437 this field. 439 When the Binding Unique Identifier sub-option is included in a 440 Binding Acknowledgment, this field indicates the status 441 correspondent to each binding in a bulk registration mode. The 442 mobile node can know the registration status of each binding. The 443 status is 8-bit unsigned integer. The possible status codes are 444 listed below. If the status field is below 128, it indicates that 445 the binding registration was successful. 447 ACCEPTING BID SUBOPTION (0) 449 The registration of the correspond binding is successfully 450 operated. 452 INCOMPLIANT BID SUBOPTION (128) 454 Registration failed because Binding Unique Identifier sub- 455 option is not compliant. 457 Care-of Address (C) flag 459 When this flag is set, a mobile node can store a Care-of Address 460 correspondent to BID in the Binding Unique Identifier sub-option. 461 This flag must be used whenever a mobile node sends multiple 462 bindings in a single Binding Update, i.e. bulk registration. 464 Removable (R) flag 466 When this flag is set, a mobile node request a Home Agent to 467 remove the binding correspondent to BID, even if the binding 468 update is not for de-registration. This flag is valid only when 469 bulk registration is used (C flag is set). 471 Reserved 473 6 bits Reserved field. Reserved field must be set with all 0. 475 4.3.2. Binding Update 477 No modification to Binding Update. A mobile node stores a Binding 478 Unique Identifier option in the Mobility Options field of a Binding 479 Update. 481 4.3.3. Binding Acknowledgment 483 The message format of Binding Acknowledgment is not changed, but 484 operations listed below are added in this draft. 486 A receiver who gets a Binding Update with a Binding Unique Identifier 487 option MUST reply with a Binding Acknowledgment if the A flag is also 488 set. The receiver MUST also send a Binding Acknowledgment with 489 corresponding error codes if it finds an error while processing the 490 Binding Update and its sub-option described in section Section 4.3. 492 If a Binding Update has a Binding Unique Identifier sub-option is 493 present, the receiver node MUST reply with a Binding Acknowledgment 494 containing the same Binding Unique Identifier sub-option(s). There 495 are two status fields of multiple care-of address registration: one 496 in Binding Acknowledgment and another in Binding Unique Identifier 497 sub-option. The first field indicates the general registration 498 status and the latter field gives detail registration information for 499 each binding. The latter field is often used to indicate status 500 information for multiple bindings stored in a single binding update 501 (i.e. bulk registration). New status values for the status field in 502 Binding Acknowledgment are defined for handling the multiple Care-of 503 Addresses registration: 505 MCOA CONFLICT(144) 507 It implies conflicting a regular binding and a binding that has 508 BID in binding cache. The regular binding indicates the binding 509 that does not have BID field. The status value is TBD. 511 BULK REGISTRATION FAIL (145) 513 It implies that the bulk binding registration is failed. The 514 correspondent status which is defined in RFC3775 is stored in each 515 Binding Unique Identifier sub-option. The status value is TBD. 517 BULK REGISTRATION NOT SUPPORT (146) 519 It implies that the bulk binding registration is not supported. 521 The mobile node can process the Binding Acknowledgment for the 522 particular Care-of Address identified by the BID set in the Binding 523 Unique Identifier sub-option. 525 5. Mobile Node Operation 527 5.1. Management of Care-of Addresses and Binding Unique Identifier 529 There are two cases when a mobile node has several Care-of Addresses: 531 1. A mobile node uses several physical network interfaces and 532 acquires a Care-of Address on each of its interfaces. 534 2. A mobile node uses a single physical network interface, but 535 multiple prefixes are announced on the link the interface is 536 attached to. Several global addresses are configured on this 537 interface for each of the announced prefixes. 539 The difference between the above two cases is only a number of 540 physical network interfaces and therefore does not matter in this 541 document. The Identification number is used to identify a binding. 542 To implement this, a mobile node MAY assign an identification number 543 for each Care-of Addresses. How to assign an identification number 544 is up to implementers. 546 A mobile node assigns a BID to each Care-of Address when it wants to 547 simultaneously register with its Home Address. The value should be 548 generated from a value comprised between 1 to 65535. Zero and 549 negative value MUST NOT be taken as a BID. If a mobile node has only 550 one Care-of Address, the assignment of a BID is not needed until it 551 has multiple Care-of Addresses to register with. 553 5.2. Binding Registration 555 When a mobile node sends a Binding Update, it MUST decide whether it 556 registers multiple Care-of Addresses or not. However, this decision 557 is out-of scope in this document. If a mobile node decides not to 558 register multiple Care-of Addresses, it completely follows standard 559 RFC 3775 specification. 561 If the mobile node needs to register multiple Care-of Addresses, it 562 MUST use BIDs to identify a Care-of Address. The mobile node puts a 563 Binding Unique Identifier sub-option into the Option field of the 564 Binding Update. The BID is copied from a Binding Update List to the 565 Binding Unique Identifier sub-option. No flag in the Binding Unique 566 Identifier sub-option should be set for independent binding 567 registration. 569 If the mobile node registers bindings to a Correspondent Node, it 570 MUST sends multiple CoTIs for multiple Care-of Addresses. After 571 getting CoTs, it sends Binding Updates with a Binding Unique 572 Identifier sub-option for all Care-of Addresses. In any case, the 573 mobile node MUST set the A flag in Binding Updates and MUST wait for 574 a Binding Acknowledgment to confirm the registration was successful 575 as described in section Section 5.7. 577 5.3. Binding Bulk Registration 579 This bulk registration is an optimization for registering multiple 580 Care-of Addresses only to a Home Agent by using a single Binding 581 Update, although the current Mobile IPv6 specification does not allow 582 to send multiple bindings by means of a single Binding Update. In 583 this case, a mobile node sets the C flag into a Binding Unique 584 Identifier sub-option and stores the particular Care-of Address in 585 the Binding Unique Identifier sub-option. The mobile node can store 586 multiple sets of a Unique Binding Identifier sub-option in a Binding 587 Update. All the other binding information such as Lifetime, Sequence 588 Number, binding Flags are shared among the bulk Care-of Addresses. 589 Whether a mobile node registers multiple Care-of Addresses separately 590 or not is up to implementations. 592 If one of Care-of Address should be removed while the other Care-of 593 Address must be updated, a mobile node can set the R flag in a 594 Binding Unique Identifier sub-option correspondent to the removed 595 Care-of Address. When the R flag is set, the binding will be removed 596 from the binding cache of the Home Agent. Other bindings for which R 597 flag is unset will be registered or updated accordingly. 599 5.4. Binding De-Registration 601 When a mobile node decides to delete all bindings for its home 602 address, it sends a regular de-registration Binding Update (i.e. 603 exclusion of a Binding Unique Identifier sub-option). See 604 Section 6.2 for details. 606 If a mobile node wants to delete a particular binding from its Home 607 Agent and Correspondent Nodes (e.g. from foreign link), it MUST send 608 a Binding Update with lifetime is set to zero. If only single 609 Care-of Address is removed by a Binding Update, the mobile node 610 simply sets zero lifetime in a Binding Update and contains the single 611 correspondent Unique Binding Identifier Sub-option (C flag must be 612 unset). The receiver will remove only the Care-of Address which is 613 retrieved from the Source Address field of the IPv6 header. On the 614 other hand, if the mobile node wants to remove multiple Care-of 615 Addresses at once, it stores multiple Unique Binding Identifier sub- 616 options which C flag is set in a Binding Update. The Care-of 617 Addresses stored in the Binding Unique Identifier sub-options will 618 all be removed. 620 If a mobile node wants to remove a binding while it registers the 621 other valid bindings, it can use R flag in a Binding Unique 622 Identifier sub-option. The detailed operation can be found in 623 Section 5.3. 625 5.5. Returning Home 627 When a mobile node returns home, it MUST de-register all bindings 628 with the Home Agent. 630 Although the mobile node MUST delete the bindings with Correspondent 631 Nodes as well, the node can still keep the binding of the other 632 interface active attached to foreign links at the Correspondent 633 Nodes. In such case, the mobile node still receives packets at the 634 other interface attached to a foreign link thanks to route 635 optimization. The mobile node also receives packets at the interface 636 attached to the home link when Correspondent Nodes does not use route 637 optimization. 639 Note that when the mobile node does not want to return home even if 640 one of interfaces is attached to the home link, the mobile node MUST 641 disable the interface. Otherwise, address duplication will be 642 observed because the Home Agent still defend the Home Address by the 643 proxy neighbor advertisement and the mobile node also enables the 644 same Home Address on the home link. After disabling the interface 645 attached to the home link, the mobile node MUST delete the binding 646 for the interface by sending a de-registration binding update. The 647 de-registration binding update must be sent from one of active 648 interfaces attached to foreign links. As a result, the mobile node 649 no longer receives packets at the interface attached to the home 650 link. All packets are routed to other interfaces attached to a 651 foreign link. 653 5.6. Using Alternate Care-of Address 655 A mobile node can use an alternate Care-of Address in the following 656 situations. 658 o One Care-of Address becomes invalid (e.g because the link where it 659 is attached to is no longer available) and MUST be deleted. In 660 such case, the mobile node can not send a Binding Update from the 661 Care-of Address because the interface's link is lost. The mobile 662 node needs to de-register the remote binding of the Care-of 663 Address through one of its active Care-of Addresses. 665 o A mobile node has multiple interfaces, but it wants to send 666 Binding Updates for all Care-of Addresses from a specific 667 interface which has wider bandwidth depending on interface's 668 characteristics. A mobile node does not want to send a lot of 669 control messages through an interface which bandwidth is scarce. 671 In these cases, the mobile node sends a Binding Update with both 672 Alternate Care-of Address sub-option and Binding Unique Identifier 673 sub-option. 675 5.7. Receiving Binding Acknowledgment 677 The verification of a Binding Acknowledgment is the same as in Mobile 678 IPv6 (section 11.7.3 of RFC 3775). The operation for sending a 679 Binding Acknowledgment is described in Section 6.3. 681 If a mobile node sends a Binding Update with a Binding Unique 682 Identifier sub-option, a Binding Acknowledgment MUST have a Binding 683 Unique Identifier sub-option in the Mobility options field. If there 684 is no such sub-option, the originator node of this Binding 685 Acknowledgment might not recognize the Binding Unique Identifier sub- 686 option. The mobile node SHOULD stop registering multiple Care-of 687 Addresses by using a Binding Unique Identifier sub-option. If the 688 originator is the Home Agent, the mobile node MAY try to discover a 689 new Home Agent supporting the multiple Care-of Address registration 690 or give up with the multiple Care-of Address registration. 692 If a Binding Unique Identifier sub-option is present, the mobile node 693 checks the Status field of the Binding Acknowledgment. If the status 694 code indicates successful registration (below 128), the originator 695 successfully registered the binding information and BID for the 696 mobile node. 698 If the status code is not zero and Binding Unique Identifier sub- 699 option is in the Binding Acknowledgment, the mobile node proceeds 700 with relevant operations according to the status code. 702 If the status code is 144, the mobile node has already registered a 703 regular binding before sending a Binding Update with a Binding Unique 704 Identifier sub-option. In such case, the mobile node SHOULD stop 705 sending Binding Updates without BID or SHOULD stop sending Binding 706 Updates with BID. 708 If the status code is 145, the mobile node should check the status 709 field of Binding Unique Identifier sub-option for the detail 710 information. After correcting errors, the mobile node can re- 711 register only the failed binding in separate registration or bulk 712 registration mode. 714 5.8. Receiving Binding Refresh Request 716 The verification of a Binding Refresh Request is the same as in 717 Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a 718 Binding Refresh Request is described in section Section 6.4. 720 If a mobile node receives a Binding Refresh Request with a Binding 721 Unique Identifier sub-option, this Binding Refresh Request requests a 722 binding indicated by the BID. The mobile node SHOULD update only the 723 respective binding. The mobile node MUST put a Binding Unique 724 Identifier sub-option into a Binding Update. 726 If no Binding Unique Identifier sub-option is present in a Binding 727 Refresh Request, the mobile node sends a Binding Update according to 728 its Binding Update List for the requesting node. On the other hand, 729 if the mobile node does not have any Binding Update List entry for 730 the requesting node, the mobile node needs to register either a 731 single binding or multiple bindings depending on its binding 732 management policy. 734 5.9. Receiving Binding Error 736 When a mobile node receives a Binding Error with a Binding Unique 737 Identifier sub-option, the message is for a binding indicated by the 738 BID in the Binding Unique Identifier sub-option. Further operations 739 except for the text below are identical as in RFC 3775. The 740 operation for sending BE is described in the section Section 6.5. 742 When a mobile node receives a Binding Error with Status field set to 743 2 (Unrecognized MH Type value), it MAY stop trying to register 744 multiple Care-of Addresses and registers only primary Care-of Address 745 as performed in Mobile IPv6. 747 6. Home Agent and Correspondent Node Operation 749 6.1. Searching Binding Cache with Binding Unique Identifier 751 If either a Correspondent Node or a Home Agent has multiple bindings 752 for a mobile node in their binding cache database, it can use any of 753 the bindings to communicate with the mobile node. How to select the 754 most suitable binding from the binding cache database is out of scope 755 in this document. 757 Whenever a Correspondent Node searches a binding cache for a home 758 address, it SHOULD uses both the Home Address and the BID as the 759 search key if it knows the corresponding BID. If the priority is 760 available for a binding cache entry, the priority can be used as 761 additional key to search a binding. In the example below, if a 762 Correspondent Node searches the binding with the Home Address and 763 BID2, it gets binding2 for this mobile node. 765 binding1 [a:b:c:d::EUI, Care-of Address1, BID1] 766 binding2 [a:b:c:d::EUI, Care-of Address2, BID2] 767 binding3 [a:b:c:d::EUI, Care-of Address3, BID3] 769 Figure 2: Searching the Binding Cache 771 A Correspondent Node basically learns the BID when it receives a 772 Binding Unique Identifier sub-option. At the time, the Correspondent 773 Node MUST look up its binding cache database with the Home Address 774 and the BID retrieved from Binding Update. If the Correspondent Node 775 does not know the BID, it searches for a binding with only a Home 776 Address as performed in Mobile IPv6. In such case, the first matched 777 binding is found. But which binding entry is returned for the normal 778 search depends on implementations. If the Correspondent Node does 779 not desire to use multiple bindings for a mobile node, it can simply 780 ignore the BID. 782 6.2. Receiving Binding Update 784 If a Binding Update does not have a Binding Unique Identifier, the 785 processing of the regular Binding Update is the same as in RFC 3775. 786 But if the receiver already has multiple bindings for the Home 787 Address, it MUST overwrite all existing bindings for the mobile node 788 with the received binding. As a result, the receiver node MUST have 789 only a binding for the mobile node. If the Binding Update is for de- 790 registration, the receiver MUST delete all existing bindings for the 791 mobile node. 793 On the other hand, if a Binding Update contains a Binding Unique 794 Identifier sub-option(s), a receiver node MUST perform additional 795 validations as follows: 797 o A receiver node MUST validate the Binding Update according to 798 section 9.5.1 of RFC 3775. 800 o If a Binding Unique Identifier sub-option(s) is present, the 801 receiver node MUST process the sub-option. 803 o If the C flag is unset in a Binding Unique Identifier sub- 804 option(s), the length field MUST be 4. Otherwise, the receiver 805 MUST return the error code 128 in the status field of the Binding 806 Unique Identifier sub-option and send a Binding Acknowledgment 807 with status code set to 145 with the Binding Unique Identifier 808 sub-option. When the length field is more than 4, the receiver 809 MAY process this sub-option by ignoring the rest of field beyond 810 the 4 octets (i.e. after Reserved field). 812 o If the Binding Unique Identifier sub-option is with the C flag set 813 and no care-of address is present in the sub-option, the receiver 814 node MUST set 128 in the Status field of the Binding Unique 815 Identifier sub-option and send a Binding Acknowledgment with 816 status code set to 145 with the Binding Unique Identifier sub- 817 option. If either a Correspondent Node or a Home Agent not 818 supporting bulk registration receives the Binding Unique 819 Identifier sub-option with C flag set, it MUST return the error 820 code 146 in a Binding Acknowledgment. 822 o If the Lifetime field is not zero, the receiver node registers a 823 binding that includes the BID as a mobile node's binding. 825 * If the C flag is set in the Binding Unique Identifier sub- 826 option, the Care-of Address must be taken from the Care-of 827 Address in the Binding Unique Identifier sub-option. 829 * If the C flag is not set in the Binding Unique Identifier sub- 830 option, the Care-of Address must be taken from the Source 831 Address field of the IPv6 header. 833 * If the C flag is not set and an alternate care-of address is 834 present, the care-of address is taken from the Alternate 835 Care-of Address sub-option. 837 * If the receiver does not have any binding for the mobile node, 838 it registers a binding which includes BID field. 840 * If the receiver has a regular binding which does not have BID 841 for the mobile node, it de-registers the regular binding and 842 registers a new binding including BID according to the Binding 843 Update. In this case, the receiver MUST send Binding 844 Acknowledgment with status code set to 144. 846 * If the receiver node has already registered the binding which 847 BID is matched with requesting BID, then it MUST update the 848 binding with the Binding Update. Meanwhile, if the receiver 849 does not have a binding entry which BID is matched with the 850 requesting BID, it registers a new binding for the BID. 852 * If the receiver node found R flag in a Binding Unique 853 Identifier sub-option, the C flag must be set. Otherwise, it 854 replies with 128 in a Binding Unique Identifier sub-option and 855 set 145 in a Binding Acknowledgment. The receiver node must 856 remove the binding correspondent to the Binding Unique 857 Identifier sub-option for which R flag is set. 859 o If Lifetime field is zero, the receiver node deletes the 860 registering binding entry which BID is same as BID sent by the 861 Binding Unique Identifier sub-option. If the receiver node does 862 not have appropriate binding which BID is matched with the Binding 863 Update, it MUST reject this de-registration Binding Update. If 864 the receiver is a Home Agent, it SHOULD also return a Binding 865 Acknowledgment to the mobile node, in which the Status field is 866 set to 133 (not Home Agent for this mobile node). 868 6.3. Sending Binding Acknowledgment 870 If a Binding Update does not contain a Binding Unique Identifier sub- 871 option, the receiver, either a Correspondent Node or a Home Agent, 872 MUST reply with a Binding Acknowledgment according to section 9.5.4 873 of RFC 3775. Otherwise, whenever the Binding Unique Identifier sub- 874 option is present, the receiver MUST follow the additional procedure 875 below. The receiver MUST reply with a Binding Acknowledgment whether 876 the A flag is set or not in the Binding Update. 878 If the receiver successfully registers a binding for the BID stored 879 in a Binding Unique Identifier sub-option, it returns a Binding 880 Acknowledgment with Status field set to successful value (0 to 128) 881 and a Binding Unique Identifier sub-option copied from the received 882 Binding Update. If the receiver deletes an existing binding which 883 does not have a BID and registers a new binding for the BID, it MUST 884 return a Binding Acknowledgment with Status field set to 144. On the 885 other hand, if the node encounters an error during the processing of 886 a Binding Update, it must return a Binding Acknowledgment with an 887 appropriate error number as described in RFC 3775. The node SHOULD 888 put a Binding Unique Identifier sub-option if the BID is available 889 for the Binding Acknowledgment. 891 6.4. Sending Binding Refresh Request 893 When either a Correspondent Node or Home Agent notices that a 894 registered binding will be expired soon, it MAY send a Binding 895 Refresh Request. If the registered binding has BID, the 896 Correspondent Node SHOULD contain a Binding Unique Identifier sub- 897 option in the Binding Refresh Request. Then, the Correspondent Node 898 can receive a Binding Update with a Binding Unique Identifier sub- 899 option and can update only the particular binding. If the registered 900 binding does not have BID, then the Correspondent Node sends a 901 Binding Refresh Request without the sub-option. 903 6.5. Sending Binding Error 905 When a Correspondent Node sends a Binding Error with Status field set 906 to 2 (Unrecognized MH Type value), it MAY put a Binding Unique 907 Identifier sub-option into Mobility Options field if BID is available 908 in a received binding message. 910 When a Correspondent Node receives data packets with a home address 911 destination option, it verifies the IPv6 source address field. If 912 the source address is not registered in the Correspondent Node's 913 binding cache, the Correspondent Node MUST return a Binding Error to 914 the sender with the status set to zero (Unknown binding for Home 915 Address destination option). The Correspondent Node MUST NOT put a 916 Binding Unique Identifier sub-option, because there is no binding 917 cache entry for the source address. 919 7. Network Mobility Applicability 921 Support of multihomed mobile routers is advocated in the NEMO working 922 group (see R12 "The solution MUST function for multihomed MR and 923 multihomed mobile networks" in [7] 925 Issues regarding mobile routers with multiple interfaces and other 926 multihoming configurations are documented in [10]. 928 Since the binding management mechanisms are the same for a mobile 929 host operating Mobile IPv6 and for a mobile router operating NEMO 930 Basic Support (RFC 3963), our extensions can also be used to deal 931 with multiple Care-of Addresses registration sent from a multihomed 932 mobile router. 934 8. IPsec and IKE interaction 936 TBA 938 9. Conclusion 940 In this document, we propose a solution to achieve multihomed mobile 941 node on Mobile IPv6 and Network Mobility. A binding unique 942 identifier is introduced to register multiple care-of addresses to a 943 Home Agent and a Correspondent Node. Those care-of addresses are 944 bound to the same home address. A few modifications to Mobile IPv6 945 and NEMO are required to support multiple care-of address 946 registration. 948 10. Acknowledgments 950 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 951 Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti 952 Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen 953 (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), 954 Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), 955 Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab. 956 at KEIO University, and WIDE project for their contributions. 958 11. References 960 11.1. Normative References 962 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 963 IETF RFC 2460, December 1998. 965 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 966 IPv6", RFC 3775, June 2004. 968 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 969 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 970 January 2005. 972 [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 973 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 974 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 975 February 2006. 977 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 978 RFC 3753, June 2004. 980 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 981 draft-ietf-nemo-terminology-05 (work in progress), 982 February 2006. 984 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 985 draft-ietf-nemo-requirements-05 (work in progress), 986 October 2005. 988 11.2. Informative References 990 [8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay 991 Networks", Journal Mobile Networks and Applications, vol. 3, 992 number 4, pages 335-350, 1998. 994 [9] Ernst, T., "Motivations and Scenarios for Using Multiple 995 Interfaces and Global Addresses", 996 draft-ietf-monami6-multihoming-motivation-scenario-00 (work in 997 progress), February 2006. 999 [10] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1000 draft-ietf-nemo-multihoming-issues-05 (work in progress), 1001 February 2006. 1003 [11] Soliman, H., "Flow Bindings in Mobile IPv6", 1004 draft-soliman-monami6-flow-binding-02 (work in progress), 1005 September 2006. 1007 Appendix A. Example Configurations 1009 In this section, we describe typical scenarios when a mobile node has 1010 multiple network interfaces and acquires multiple Care-of Addresses 1011 bound to a Home Address. 1013 The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. 1014 MN has 3 different interfaces and possibly acquires Care-of Addresses 1015 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 1016 Care-of Addresses. 1018 Figure 3 depicts the scenario where all interfaces of the mobile node 1019 are attached to foreign links. After binding registrations, the Home 1020 Agent (HA) and the Correspondent Node (CN) have the binding entries 1021 listed in their binding cache database. The mobile node can utilize 1022 all the interfaces. 1024 +----+ 1025 | CN | 1026 +--+-+ 1027 | 1028 +---+------+ +----+ 1029 +------+ Internet |----------+ HA | 1030 | +----+---+-+ +--+-+ 1031 CoA2| | | | Home Link 1032 +--+--+ | | ------+------ 1033 | MN +========+ | 1034 +--+--+ CoA1 | 1035 CoA3| | 1036 +---------------+ 1038 Binding Cache Database: 1039 Home Agent's binding (Proxy neighbor advertisement is active) 1040 binding [a:b:c:d::EUI Care-of Address1 BID1] 1041 binding [a:b:c:d::EUI Care-of Address2 BID2] 1042 binding [a:b:c:d::EUI Care-of Address3 BID3] 1043 Correspondent Node's binding 1044 binding [a:b:c:d::EUI Care-of Address1 BID1] 1045 binding [a:b:c:d::EUI Care-of Address2 BID2] 1046 binding [a:b:c:d::EUI Care-of Address3 BID3] 1048 Figure 3: Multiple Interfaces Attached to a Foreign Link 1050 Figure 4 depicts the scenario where MN returns home with one of its 1051 interfaces. After the successful de-registration of the binding to 1052 HA, HA and CN have the binding entries listed in their binding cache 1053 database of Figure 4. MN can communicate with the HA through only 1054 the interface attached to the home link. On the other hand, the 1055 mobile node can communicate with CN from the other interfaces 1056 attached to foreign links (i.e. route optimization). Even when MN is 1057 attached to the home link, it can still send Binding Updates for 1058 other active Care-of Addresses (CoA2 and CoA3). If CN has bindings, 1059 packets are routed to each Care-of Addresses directly. Any packet 1060 arrived at HA are routed to the primary interface. 1062 +----+ 1063 | CN | 1064 +--+-+ 1065 | 1066 +---+------+ +----+ 1067 +------+ Internet |----------+ HA | 1068 | +--------+-+ +--+-+ 1069 CoA2| | | Home Link 1070 +--+--+ | --+---+------ 1071 | MN +========+ | | 1072 +--+--+ | | | 1073 CoA3| +---|-----------+ 1074 +---------------+ 1076 Binding Cache Database: 1077 Home Agent's binding (Proxy neighbor advertisement is inactive) 1078 none 1079 Correspondent Node's binding 1080 binding [a:b:c:d::EUI Care-of Address2 BID2] 1081 binding [a:b:c:d::EUI Care-of Address3 BID3] 1083 Figure 4: One of Interface Attached to Home Link and Returing Home 1085 Figure 5 depicts the scenario where MN disables the interface 1086 attached to the home link and communicates with the interfaces 1087 attached to foreign links. The HA and the CN have the binding 1088 entries listed in their binding cache database. MN disable the 1089 interface attached to the home link, because the HA still defends the 1090 home address of the MN by proxy neighbor advertisements. All packets 1091 routed to the home link are intercepted by the HA and tunneled to the 1092 other interfaces attached to the foreign link according to the 1093 binding entries. 1095 +----+ 1096 | CN | 1097 +--+-+ 1098 | 1099 +---+------+ +----+ 1100 +------+ Internet |----------+ HA | 1101 | +----+-----+ +--+-+ 1102 CoA2| | | Home Link 1103 +--+--+ | --+---+------ 1104 | MN +========+ | 1105 +--+--+ CoA1 | 1106 | | 1107 +---------------------------+ 1108 (Disable interface) 1110 Binding Cache Database: 1111 Home Agent's binding (Proxy neighbor advertisement is active) 1112 binding [a:b:c:d::EUI Care-of Address1 BID1] 1113 binding [a:b:c:d::EUI Care-of Address2 BID2] 1114 Correspondent Node's binding 1115 binding [a:b:c:d::EUI Care-of Address1 BID1] 1116 binding [a:b:c:d::EUI Care-of Address2 BID2] 1118 Figure 5: One of Interface Attached to Home Link and Not Returing 1119 Home 1121 Figure 6 depicts the scenario where multiple interfaces of MN are 1122 attached to the home link. The HA and CN have the binding entries 1123 listed in Figure 6 in their binding cache database. The MN can not 1124 use the interface attached to a foreign link unless a CN has a 1125 binding for the interface. All packets which arrive at the HA are 1126 routed to one of the MN's interfaces attached to the home link. 1128 +----+ 1129 | CN | 1130 +--+-+ 1131 | 1132 +---+------+ +----+ 1133 +------+ Internet |----------+ HA | 1134 | +----------+ +--+-+ 1135 CoA2| | Home Link 1136 +--+--+ --+----+---+------ 1137 | MN +===================+ | 1138 +--+--+ | 1139 | | 1140 +---------------------------+ 1142 Binding Cache Database: 1143 Home Agent's binding (Proxy neighbor advertisement is inactive) 1144 none 1145 Correspondent Node's binding 1146 binding [a:b:c:d::EUI Care-of Address2 BID2] 1148 Figure 6: Several Interfaces Attached to Home Link and Returning Home 1150 Figure 7 depicts the scenario where interfaces of MN are attached to 1151 the foreign links. One of foreign link is managed by the home agent. 1152 The HA and CN have the binding entries listed in Figure 7 in their 1153 binding cache database. The home agent advertises a prefix which is 1154 other than home prefix. The mobile node will generate a care-of 1155 address from the prefix and registers it to the home agent. Even if 1156 the mobile node attaches to a foreign link, the link is managed by 1157 its home agent. It will tunnel the packets to the home agent, but 1158 the home agent is one-hop neighbor. The cost of tunnel is 1159 negligible. If the mobile node wants to utilize not only an 1160 interface attached to home but also interfaces attached to foreign 1161 link, it can use this foreign link of the home agent to return home. 1162 This is different from the general returning home, but this enable 1163 the capability of using interfaces attached to both home and foreign 1164 link without any modifications to Mobile IPv6 and NEMO basic support. 1166 +----+ 1167 | CN | 1168 +--+-+ 1169 | 1170 +---+------+ +----+ 1171 +------+ Internet |----------+ HA | 1172 | +----+-----+ ++-+-+ 1173 CoA2| | | | Home Link 1174 +--+--+ | ----|-+------ 1175 | MN +========+ | 1176 +--+--+ CoA1 ---+-+------ 1177 CoA3 | | Foreign Link 1178 +---------------------------+ 1179 (Disable interface) 1181 Binding Cache Database: 1182 Home Agent's binding (Proxy neighbor advertisement is active) 1183 binding [a:b:c:d::EUI Care-of Address1 BID1] 1184 binding [a:b:c:d::EUI Care-of Address2 BID2] 1185 binding [a:b:c:d::EUI Care-of Address3 BID3] 1186 Correspondent Node's binding 1187 binding [a:b:c:d::EUI Care-of Address1 BID1] 1188 binding [a:b:c:d::EUI Care-of Address2 BID2] 1189 binding [a:b:c:d::EUI Care-of Address3 BID3] 1191 Figure 7: Emulating to Utilize Interfaces Attached to both Home and 1192 Foreign Links 1194 Appendix B. Changes From Previous Versions 1196 Changes from draft-ietf-monami6-multiplecoa-00.txt 1198 o Adding a default value for the BID priority field. This default 1199 value is used by the flow binding scheme [11]. 1201 o Updating the text of BID definition. The older text was unclear 1202 whether a BID is assigned to a binding or a interface. It is now 1203 clearly defined that BID is assigned to each binding. 1205 Authors' Addresses 1207 Ryuji Wakikawa 1208 Keio University 1209 Department of Environmental Information, Keio University. 1210 5322 Endo 1211 Fujisawa, Kanagawa 252-8520 1212 Japan 1214 Phone: +81-466-49-1100 1215 Fax: +81-466-49-1395 1216 Email: ryuji@sfc.wide.ad.jp 1217 URI: http://www.wakikawa.org/ 1219 Thierry Ernst 1220 Keio University / WIDE 1221 Jun Murai Lab., Keio University. 1222 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1223 Kawasaki, Kanagawa 212-0054 1224 Japan 1226 Phone: +81-44-580-1600 1227 Fax: +81-44-580-1437 1228 Email: ernst@sfc.wide.ad.jp 1229 URI: http://www.sfc.wide.ad.jp/~ernst/ 1231 Kenichi Nagami 1232 INTEC NetCore Inc. 1233 1-3-3, Shin-suna 1234 Koto-ku, Tokyo 135-0075 1235 Japan 1237 Phone: +81-3-5565-5069 1238 Fax: +81-3-5565-5094 1239 Email: nagami@inetcore.com 1241 Intellectual Property Statement 1243 The IETF takes no position regarding the validity or scope of any 1244 Intellectual Property Rights or other rights that might be claimed to 1245 pertain to the implementation or use of the technology described in 1246 this document or the extent to which any license under such rights 1247 might or might not be available; nor does it represent that it has 1248 made any independent effort to identify any such rights. Information 1249 on the procedures with respect to rights in RFC documents can be 1250 found in BCP 78 and BCP 79. 1252 Copies of IPR disclosures made to the IETF Secretariat and any 1253 assurances of licenses to be made available, or the result of an 1254 attempt made to obtain a general license or permission for the use of 1255 such proprietary rights by implementers or users of this 1256 specification can be obtained from the IETF on-line IPR repository at 1257 http://www.ietf.org/ipr. 1259 The IETF invites any interested party to bring to its attention any 1260 copyrights, patents or patent applications, or other proprietary 1261 rights that may cover technology that may be required to implement 1262 this standard. Please address the information to the IETF at 1263 ietf-ipr@ietf.org. 1265 Disclaimer of Validity 1267 This document and the information contained herein are provided on an 1268 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1269 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1270 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1271 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1272 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1273 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1275 Copyright Statement 1277 Copyright (C) The Internet Society (2006). This document is subject 1278 to the rights, licenses and restrictions contained in BCP 78, and 1279 except as set forth therein, the authors retain all their rights. 1281 Acknowledgment 1283 Funding for the RFC Editor function is currently provided by the 1284 Internet Society.