idnits 2.17.1 draft-ietf-monami6-multiplecoa-00.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 1261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1251. ** 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 207: '...a negative value MUST NOT be used. Af...' RFC 2119 keyword, line 210: '.... A mobile node MAY change the value ...' RFC 2119 keyword, line 243: '...s Home Agent, it MUST generate a BID f...' RFC 2119 keyword, line 246: '...ub-option. The BID MUST be put in the...' RFC 2119 keyword, line 250: '..., the Home Agent MUST copy the BID fro...' (55 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 (June 12, 2006) is 6528 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 Summary: 12 errors (**), 0 flaws (~~), 9 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: December 14, 2006 T. Ernst 5 Keio University / WIDE 6 K. Nagami 7 INTEC NetCore 8 June 12, 2006 10 Multiple Care-of Addresses Registration 11 draft-ietf-monami6-multiplecoa-00.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 December 14, 2006. 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 . . . . . . . . . . . . . 22 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. 193 2. Terminology 195 Terms used in this draft are defined in [2], [5] and [6]. In 196 addition or in replacement of these, the following terms are defined 197 or redefined: 199 Binding Unique Identification number (BID) 201 The BID is an identification number used to distinguish multiple 202 bindings registered by the mobile node. Assignment of distinct 203 BID allows a mobile node to register multiple binding cache 204 entries for a given Home Address. The BID is generated to 205 register multiple bindings in the binding cache for a given 206 address in a way it cannot be duplicated with another BID. The 207 zero value and a negative value MUST NOT be used. After being 208 generated by the mobile node, the BID is stored in the Binding 209 Update List and is sent by the mobile node by means of a sub- 210 option of a Binding Update. A mobile node MAY change the value of 211 a BID at any time according to its administrative policy, for 212 instance to protect its privacy. 214 The BID can be assigned to either a Care-of Address or an 215 interface depending on implementation choices so as to keep using 216 the same BID for the same binding even when the status of the 217 binding is changed. More details can be found in Section 5.1. 219 Binding Unique Identifier sub-option 221 The Binding Unique Identifier sub-option is used to carry the BID. 223 Bulk Registration 225 A mobile node can register multiple bindings by sending a binding 226 update. Several care-of addresses can be stored in a Binding 227 Update. The bulk registration is supported only for home 228 registration. Note that a mobile node should not try to perform 229 bulk registration with Correspondent Nodes. 231 3. Protocol Overview 233 We propose a new identification number (BID) to distinguish multiple 234 bindings pertaining to the same Home Address. The procedures for the 235 mobile node to register multiple bindings are described in the 236 paragraphs below. 238 3.1. Multiple Care-of Addresses Registration 240 Once a mobile node gets several IPv6 global addresses on interfaces, 241 it can register these addresses with its Home Agent (home 242 registration). If the mobile node wants to register multiple 243 bindings to its Home Agent, it MUST generate a BID for each Care-of 244 Address and record it into the binding update list. The mobile node 245 then registers its Care-of Addresses by sending a Binding Update with 246 a Binding Unique Identifier sub-option. The BID MUST be put in the 247 Binding Unique Identifier sub-option. After receiving the Binding 248 Update, the Home Agent verifies the request and records the binding 249 in its binding cache. If the newly defined sub-option is present in 250 the Binding Update, the Home Agent MUST copy the BID from the Binding 251 Update to the corresponding field in the binding entry. Even if 252 there is already an entry for the mobile node, the Home Agent MUST 253 register a new binding entry for the BID stored in the Binding Unique 254 Identifier sub-option. The mobile node registers multiple Care-of 255 Addresses either independently (in individual BUs) or multiple at 256 once (in a single BU). 258 If the mobile node wishes to register its binding with a 259 Correspondent Node, it MUST start return routability operations 260 before sending a Binding Update. The mobile node MUST sends CoTI for 261 each Care-of Addresses and MUST receive CoT for each Care-of 262 Addresses. The mobile node also uses a BID generated for the home 263 registration to register them as individual bindings. The 264 registration step is the same as for the home registration except for 265 calculating authenticator by using Binding Unique Identifier sub- 266 option as well as the other sub-options specified in RFC 3775. Since 267 return routability cannot be verified with multiple care-of addresses 268 in a binding update, bulk registration is not supported with 269 Correspondent Nodes in this document. 271 3.2. Multiple Bindings Management 273 The BID is used as a search key for a corresponding entry in the 274 binding cache in addition to the Home Address. When the Home Agent 275 checks the binding cache database for the mobile node, it searches a 276 corresponding binding entry with the Home Address and BID of the 277 desired binding. 279 The desired binding can be selected with policy and filter 280 information. If a mobile node registers a binding with priority 281 value, the priority can be a key to select a binding. The capability 282 of searching the desired binding enables load-sharing and QoS with 283 flow separation. However, this selection and flow separation are 284 outside the scope of this document. 286 If there is no desired binding, it searches the binding cache 287 database with the Home Address as specified in Mobile IPv6. The 288 first matched binding entry may be found, although this is 289 implementation dependent. 291 If a node has multiple bindings and its packets meant for the mobile 292 node are not delivered correctly, the node can change the binding 293 entry for the mobile node so as to recover the connection 294 immediately. The node can detect a binding invalidation by packets 295 loss or ICMP error messages such as ICMP_UNREACHABLE. This provides 296 redundancy for Mobile IPv6. 298 When one of the care-of addresses is changed, the mobile node sends a 299 Binding Update with the new Care-of Address and the corresponding 300 BID. The receiver of the Binding Update updates the binding which 301 BID fits the BID contained in the received Binding Unique Identifier 302 sub-option. The mobile node can manage each binding independently 303 owing to BID. 305 If the mobile node decides to register only single binding, it just 306 sends a Binding Update without a Binding Unique Identifier sub-option 307 (i.e. normal Binding Update). The receiver of the Binding Update 308 registers only a single binding for the mobile node. If the receiver 309 has multiple bindings, one binding is registered without BID and the 310 rest of bindings are deleted. 312 3.3. Returning Home 314 When the mobile node returns home, there are two situations, since 315 the Home Agent defends the mobile node's Home Address by using the 316 proxy neighbor advertisement. It is impossible to utilize all the 317 interfaces when one interface is attached to the home link and the 318 others are attached to foreign links. If the proxy Neighbor 319 Advertisement for the Home Address is stopped, packets are always 320 routed to the interface attached to the home link. If proxy is not 321 stopped, packets are never routed to the interface attached to the 322 home link. The decision whether a mobile node returns home or not is 323 up to implementors. 325 The first situation is when a mobile node wants to return home with 326 interface attached to the home link. In this case, the mobile node 327 MUST de-register all the bindings by sending a Binding Update with 328 lifetime set to zero. The mobile node MAY NOT put any Binding Unique 329 Identifier sub-option in this packet. Then, the receiver deletes all 330 the bindings from its binding cache database. 332 The second situation is when a mobile node does not want to return 333 home, though one of its interfaces is attached to its home link. The 334 mobile node disables the interface attached to the home link and 335 keeps using the rest of interfaces attached to foreign links. In 336 this case, the mobile node sends a de-registration Binding Update for 337 the interface attached to the home link with the Binding Unique 338 Identifier sub-option. The receiver of the de-registration Binding 339 Update deletes only the correspondent binding entry from the binding 340 cache database. The Home Agent does not stop proxying neighbor 341 advertisement unless there are still bindings for the other 342 interfaces. 344 In the above two cases, a mobile node cannot use interfaces attached 345 to both home and foreign links simultaneously. If this is what a 346 mobile node wants, a home agent can set up another link other than 347 home link and uses the link for the mobile node to return virtually 348 to home network. The detail can be found in Figure 7 350 4. Mobile IPv6 Extensions 352 In this section are described the changes to Mobile IPv6 necessary to 353 manage multiple bindings bound to a same Home Address. 355 4.1. Binding Cache Structure and Management 357 The following additional items are required in the binding cache 358 structure, i.e.: 360 BID of the Binding Cache Entry 362 The BID is notified by the mobile node by means of a Binding 363 Unique Identifier sub-option. The value MUST be zero if the 364 Binding Unique identifier does not appear in a Binding Update. 366 Priority of the Binding Cache Entry 368 The priority is notified by the mobile node by means of a Binding 369 Unique Identifier sub-option. 371 4.2. Binding Update List Structure and Management 373 The following additional items are required for the binding update 374 structure, i.e.: 376 BID 378 The BID MUST be generated whenever the mobile node registers 379 multiple bindings for its Home Address. 381 Priority 383 MUST be set if the priority field of a Binding Unique Identifier 384 is valid. 386 4.3. Message Format Changes 388 4.3.1. Binding Unique Identifier sub-option 390 If needed, the Binding Unique Identifier sub-option is included in 391 the Binding Update, Binding Acknowledgment, Binding Refresh Request, 392 or Binding Error messages. 394 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type = TBD | Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Binding Unique ID (BID) |Priority/Status|C|R| Reserved | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 401 + + 402 + Care-of Address (CoA) + 403 + + 404 +---------------------------------------------------------------+ 406 Figure 1: BID Sub-Option 408 Type 410 Type value for Binding Unique Identifier will be assigned later. 412 Length 414 Length value is 4 when the C flag is unset. Length value is 20 415 when the C flag is set. 417 Binding Unique ID (BID) 419 The BID which is assigned to the binding carried in the Binding 420 Update with this sub-option. BID is 16-bit unsigned integer. A 421 value of zero is reserved. 423 Priority/Status 425 When the Binding Unique Identifier sub-option is included in a 426 Binding Update, this field indicates the priority field assigned 427 to each binding. The receiver can utilize this priority to 428 determine which binding is used to deliver packets. The priority 429 is 8-bit unsigned integer. A value of zero indicates No Priority. 430 The higher value has higher priority. 432 When the Binding Unique Identifier sub-option is included in a 433 Binding Acknowledgment, this field indicates the status 434 correspondent to each binding in a bulk registration mode. The 435 mobile node can know the registration status of each binding. The 436 status is 8-bit unsigned integer. The possible status codes are 437 listed below. If the status field is below 128, it indicates that 438 the binding registration was successful. 440 ACCEPTING BID SUBOPTION (0) 442 The registration of the correspond binding is successfully 443 operated. 445 INCOMPLIANT BID SUBOPTION (128) 447 Registration failed because Binding Unique Identifier sub- 448 option is not compliant. 450 Care-of Address (C) flag 452 When this flag is set, a mobile node can store a Care-of Address 453 correspondent to BID in the Binding Unique Identifier sub-option. 454 This flag must be used whenever a mobile node sends multiple 455 bindings in a single Binding Update, i.e. bulk registration. 457 Removable (R) flag: TBD 459 When this flag is set, a mobile node request a Home Agent to 460 remove the binding correspondent to BID, even if the binding 461 update is not for de-registration. This flag is valid only when 462 bulk registration is used (C flag is set). This option may be 463 obsolete in the future revision. 465 Reserved 467 6 bits Reserved field. Reserved field must be set with all 0. 469 4.3.2. Binding Update 471 No modification to Binding Update. A mobile node stores a Binding 472 Unique Identifier option in the Mobility Options field of a Binding 473 Update. 475 4.3.3. Binding Acknowledgment 477 The message format of Binding Acknowledgment is not changed, but 478 operations listed below are added in this draft. 480 A receiver who gets a Binding Update with a Binding Unique Identifier 481 option MUST reply with a Binding Acknowledgment if the A flag is also 482 set. The receiver MUST also send a Binding Acknowledgment with 483 corresponding error codes if it finds an error while processing the 484 Binding Update and its sub-option described in section Section 4.3. 486 If a Binding Update has a Binding Unique Identifier sub-option is 487 present, the receiver node MUST reply with a Binding Acknowledgment 488 containing the same Binding Unique Identifier sub-option(s). There 489 are two status fields of multiple care-of address registration: one 490 in Binding Acknowledgment and another in Binding Unique Identifier 491 sub-option. The first field indicates the general registration 492 status and the latter field gives detail registration information for 493 each binding. The latter field is often used to indicate status 494 information for multiple bindings stored in a single binding update 495 (i.e. bulk registration). New status values for the status field in 496 Binding Acknowledgment are defined for handling the multiple Care-of 497 Addresses registration: 499 MCOA CONFLICT(144) 501 It implies conflicting a regular binding and a binding that has 502 BID in binding cache. The regular binding indicates the binding 503 that does not have BID field. The status value is TBD. 505 BULK REGISTRATION FAIL (145) 507 It implies that the bulk binding registration is failed. The 508 correspondent status which is defined in RFC3775 is stored in each 509 Binding Unique Identifier sub-option. The status value is TBD. 511 BULK REGISTRATION NOT SUPPORT (146) 513 It implies that the bulk binding registration is not supported. 515 The mobile node can process the Binding Acknowledgment for the 516 particular Care-of Address identified by the BID set in the Binding 517 Unique Identifier sub-option. 519 5. Mobile Node Operation 521 5.1. Management of Care-of Addresses and Binding Unique Identifier 523 There are two cases when a mobile node has several Care-of Addresses: 525 1. A mobile node uses several physical network interfaces and 526 acquires a Care-of Address on each of its interfaces. 528 2. A mobile node uses a single physical network interface, but 529 multiple prefixes are announced on the link the interface is 530 attached to. Several global addresses are configured on this 531 interface for each of the announced prefixes. 533 The difference between the above two cases is only a number of 534 physical network interfaces and therefore does not matter. The 535 Identification number is used to distinguish multiple bindings so 536 that the mobile node assigns an identification number for each 537 Care-of Addresses. How to assign an identification number is up to 538 implementors. 540 A mobile node assigns a BID to each Care-of Address when it wants to 541 simultaneously register with its Home Address. The value should be 542 generated from a value comprised between 1 to 65535. Zero and 543 negative value can not be taken as a BID. If a mobile node has only 544 one Care-of Address, the assignment of a BID is not needed until it 545 has multiple Care-of Addresses to register with. 547 5.2. Binding Registration 549 When a mobile node sends a Binding Update, it MUST decide whether it 550 registers multiple Care-of Addresses or not. However, this decision 551 is out-of scope in this document. If a mobile node decides not to 552 register multiple Care-of Addresses, it completely follows standard 553 RFC 3775 specification. 555 If the mobile node needs to register multiple Care-of Addresses, it 556 MUST use BIDs to identify a Care-of Address. The mobile node puts a 557 Binding Unique Identifier sub-option into the Option field of the 558 Binding Update. The BID is copied from a Binding Update List to the 559 Binding Unique Identifier sub-option. No flag in the Binding Unique 560 Identifier sub-option should be set for independent binding 561 registration. 563 If the mobile node registers bindings to a Correspondent Node, it 564 MUST sends multiple CoTIs for multiple Care-of Addresses. After 565 getting CoTs, it sends Binding Updates with a Binding Unique 566 Identifier sub-option for all Care-of Addresses. In any case, the 567 mobile node MUST set the A flag in Binding Updates and MUST wait for 568 a Binding Acknowledgment to confirm the registration was successful 569 as described in section Section 5.7. 571 5.3. Binding Bulk Registration 573 This bulk registration is an optimization for registering multiple 574 Care-of Addresses only to a Home Agent by using a single Binding 575 Update, although the current Mobile IPv6 specification does not allow 576 to send multiple bindings by means of a single Binding Update. In 577 this case, a mobile node sets the C flag into a Binding Unique 578 Identifier sub-option and stores the particular Care-of Address in 579 the Binding Unique Identifier sub-option. The mobile node can store 580 multiple sets of a Unique Binding Identifier sub-option in a Binding 581 Update. All the other binding information such as Lifetime, Sequence 582 Number, binding Flags are shared among the bulk Care-of Addresses. 583 Whether a mobile node registers multiple Care-of Addresses separately 584 or not is up to implementations. 586 If one of Care-of Address should be removed while the other Care-of 587 Address must be updated, a mobile node can set the R flag in a 588 Binding Unique Identifier sub-option correspondent to the removed 589 Care-of Address. When the R flag is set, the binding will be removed 590 from the binding cache of the Home Agent. Other bindings for which R 591 flag is unset will be registered or updated accordingly. 593 5.4. Binding De-Registration 595 When a mobile node decides to delete all bindings for its home 596 address, it sends a regular de-registration Binding Update (i.e. 597 exclusion of a Binding Unique Identifier sub-option). See 598 Section 6.2 for details. 600 If a mobile node wants to delete a particular binding from its Home 601 Agent and Correspondent Nodes (e.g. from foreign link), it MUST send 602 a Binding Update with lifetime is set to zero. If only single 603 Care-of Address is removed by a Binding Update, the mobile node 604 simply sets zero lifetime in a Binding Update and contains the single 605 correspondent Unique Binding Identifier Sub-option (C flag must be 606 unset). The receiver will remove only the Care-of Address which is 607 retrieved from the Source Address field of the IPv6 header. On the 608 other hand, if the mobile node wants to remove multiple Care-of 609 Addresses at once, it stores multiple Unique Binding Identifier sub- 610 options which C flag is set in a Binding Update. The Care-of 611 Addresses stored in the Binding Unique Identifier sub-options will 612 all be removed. 614 If a mobile node wants to remove a binding while it registers the 615 other valid bindings, it can use R flag in a Binding Unique 616 Identifier sub-option. The detailed operation can be found in 617 Section 5.3. 619 5.5. Returning Home 621 When a mobile node returns home, it MUST de-register all bindings 622 with the Home Agent. 624 Although the mobile node MUST delete the bindings with Correspondent 625 Nodes as well, the node can still keep the binding of the other 626 interface active attached to foreign links at the Correspondent 627 Nodes. In such case, the mobile node still receives packets at the 628 other interface attached to a foreign link thanks to route 629 optimization. The mobile node also receives packets at the interface 630 attached to the home link when Correspondent Nodes does not use route 631 optimization. 633 Note that when the mobile node does not want to return home even if 634 one of interfaces is attached to the home link, the mobile node MUST 635 disable the interface. Otherwise, address duplication will be 636 observed because the Home Agent still defend the Home Address by the 637 proxy neighbor advertisement and the mobile node also enables the 638 same Home Address on the home link. After disabling the interface 639 attached to the home link, the mobile node MUST delete the binding 640 for the interface by sending a de-registration binding update. The 641 de-registration binding update must be sent from one of active 642 interfaces attached to foreign links. As a result, the mobile node 643 no longer receives packets at the interface attached to the home 644 link. All packets are routed to other interfaces attached to a 645 foreign link. 647 5.6. Using Alternate Care-of Address 649 A mobile node can use an alternate Care-of Address in the following 650 situations. 652 o One Care-of Address becomes invalid (e.g because the link where it 653 is attached to is no longer available) and MUST be deleted. In 654 such case, the mobile node can not send a Binding Update from the 655 Care-of Address because the interface's link is lost. The mobile 656 node needs to de-register the remote binding of the Care-of 657 Address through one of its active Care-of Addresses. 659 o A mobile node has multiple interfaces, but it wants to send 660 Binding Updates for all Care-of Addresses from a specific 661 interface which has wider bandwidth depending on interface's 662 characteristics. A mobile node does not want to send a lot of 663 control messages through an interface which bandwidth is scarce. 665 In these cases, the mobile node sends a Binding Update with both 666 Alternate Care-of Address sub-option and Binding Unique Identifier 667 sub-option. 669 5.7. Receiving Binding Acknowledgment 671 The verification of a Binding Acknowledgment is the same as in Mobile 672 IPv6 (section 11.7.3 of RFC 3775). The operation for sending a 673 Binding Acknowledgment is described in Section 6.3. 675 If a mobile node sends a Binding Update with a Binding Unique 676 Identifier sub-option, a Binding Acknowledgment MUST have a Binding 677 Unique Identifier sub-option in the Mobility options field. If there 678 is no such sub-option, the originator node of this Binding 679 Acknowledgment might not recognize the Binding Unique Identifier sub- 680 option. The mobile node SHOULD stop registering multiple Care-of 681 Addresses by using a Binding Unique Identifier sub-option. If the 682 originator is the Home Agent, the mobile node MAY try to discover a 683 new Home Agent supporting the multiple Care-of Address registration 684 or give up with the multiple Care-of Address registration. 686 If a Binding Unique Identifier sub-option is present, the mobile node 687 checks the Status field of the Binding Acknowledgment. If the status 688 code indicates successful registration (below 128), the originator 689 successfully registered the binding information and BID for the 690 mobile node. 692 If the status code is not zero and Binding Unique Identifier sub- 693 option is in the Binding Acknowledgment, the mobile node proceeds 694 with relevant operations according to the status code. 696 If the status code is 144, the mobile node has already registered a 697 regular binding before sending a Binding Update with a Binding Unique 698 Identifier sub-option. In such case, the mobile node SHOULD stop 699 sending Binding Updates without BID or SHOULD stop sending Binding 700 Updates with BID. 702 If the status code is 145, the mobile node should check the status 703 field of Binding Unique Identifier sub-option for the detail 704 information. After correcting errors, the mobile node can re- 705 register only the failed binding in separate registration or bulk 706 registration mode. 708 5.8. Receiving Binding Refresh Request 710 The verification of a Binding Refresh Request is the same as in 711 Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a 712 Binding Refresh Request is described in section Section 6.4. 714 If a mobile node receives a Binding Refresh Request with a Binding 715 Unique Identifier sub-option, this Binding Refresh Request requests a 716 binding indicated by the BID. The mobile node SHOULD update only the 717 respective binding. The mobile node MUST put a Binding Unique 718 Identifier sub-option into a Binding Update. 720 If no Binding Unique Identifier sub-option is present in a Binding 721 Refresh Request, the mobile node sends a Binding Update according to 722 its Binding Update List for the requesting node. On the other hand, 723 if the mobile node does not have any Binding Update List entry for 724 the requesting node, the mobile node needs to register either a 725 single binding or multiple bindings depending on its binding 726 management policy. 728 5.9. Receiving Binding Error 730 When a mobile node receives a Binding Error with a Binding Unique 731 Identifier sub-option, the message is for a binding indicated by the 732 BID in the Binding Unique Identifier sub-option. Further operations 733 except for the text below are identical as in RFC 3775. The 734 operation for sending BE is described in the section Section 6.5. 736 When a mobile node receives a Binding Error with Status field set to 737 2 (Unrecognized MH Type value), it MAY stop trying to register 738 multiple Care-of Addresses and registers only primary Care-of Address 739 as performed in Mobile IPv6. 741 6. Home Agent and Correspondent Node Operation 743 6.1. Searching Binding Cache with Binding Unique Identifier 745 If either a Correspondent Node or a Home Agent has multiple bindings 746 for a mobile node in their binding cache database, it can use any of 747 the bindings to communicate with the mobile node. How to select the 748 most suitable binding from the binding cache database is out of scope 749 in this document. 751 Whenever a Correspondent Node searches a binding cache for a home 752 address, it SHOULD uses both the Home Address and the BID as the 753 search key if it knows the corresponding BID. If the priority is 754 available for a binding cache entry, the priority can be used as 755 additional key to search a binding. In the example below, if a 756 Correspondent Node searches the binding with the Home Address and 757 BID2, it gets binding2 for this mobile node. 759 binding1 [a:b:c:d::EUI, Care-of Address1, BID1] 760 binding2 [a:b:c:d::EUI, Care-of Address2, BID2] 761 binding3 [a:b:c:d::EUI, Care-of Address3, BID3] 763 Figure 2: Searching the Binding Cache 765 A Correspondent Node basically learns the BID when it receives a 766 Binding Unique Identifier sub-option. At the time, the Correspondent 767 Node MUST look up its binding cache database with the Home Address 768 and the BID retrieved from Binding Update. If the Correspondent Node 769 does not know the BID, it searches for a binding with only a Home 770 Address as performed in Mobile IPv6. In such case, the first matched 771 binding is found. But which binding entry is returned for the normal 772 search depends on implementations. If the Correspondent Node does 773 not desire to use multiple bindings for a mobile node, it can simply 774 ignore the BID. 776 6.2. Receiving Binding Update 778 If a Binding Update does not have a Binding Unique Identifier, the 779 processing of the regular Binding Update is the same as in RFC 3775. 780 But if the receiver already has multiple bindings for the Home 781 Address, it MUST overwrite all existing bindings for the mobile node 782 with the received binding. As a result, the receiver node MUST have 783 only a binding for the mobile node. If the Binding Update is for de- 784 registration, the receiver MUST delete all existing bindings for the 785 mobile node. 787 On the other hand, if a Binding Update contains a Binding Unique 788 Identifier sub-option(s), a receiver node MUST perform additional 789 validations as follows: 791 o A receiver node MUST validate the Binding Update according to 792 section 9.5.1 of RFC 3775. 794 o If a Binding Unique Identifier sub-option(s) is present, the 795 receiver node MUST process the sub-option. 797 o If the Binding Unique Identifier sub-option is with C flag set and 798 no care-of address is present in the sub-option, the receiver node 799 MUST set 128 in the Status field of the Binding Unique Identifier 800 sub-option and send a Binding Acknowledgment with status code set 801 to 145 with the Binding Unique Identifier sub-option. If either a 802 Correspondent Node or a Home Agent not supporting bulk 803 registration receives the Binding Unique Identifier sub-option 804 with C flag set, it MUST return the error code 146 in a Binding 805 Acknowledgment. 807 o If the Lifetime field is not zero, the receiver node registers a 808 binding that includes the BID as a mobile node's binding. 810 * If the C flag is set in the Binding Unique Identifier sub- 811 option, the Care-of Address must be taken from the Care-of 812 Address in the Binding Unique Identifier sub-option. 814 * If the C flag is not set in the Binding Unique Identifier sub- 815 option, the Care-of Address must be taken from the Source 816 Address field of the IPv6 header. 818 * If the C flag is not set and an alternate care-of address is 819 present, the care-of address is taken from the Alternate 820 Care-of Address sub-option. 822 * If the receiver does not have any binding for the mobile node, 823 it registers a binding which includes BID field. 825 * If the receiver has a regular binding which does not have BID 826 for the mobile node, it de-registers the regular binding and 827 registers a new binding including BID according to the Binding 828 Update. In this case, the receiver MUST send Binding 829 Acknowledgment with status code set to 144. 831 * If the receiver node has already registered the binding which 832 BID is matched with requesting BID, then it MUST update the 833 binding with the Binding Update. Meanwhile, if the receiver 834 does not have a binding entry which BID is matched with the 835 requesting BID, it registers a new binding for the BID. 837 * If the receiver node found R flag in a Binding Unique 838 Identifier sub-option, the C flag must be set. Otherwise, it 839 replies with 128 in a Binding Unique Identifier sub-option and 840 set 145 in a Binding Acknowledgment. The receiver node must 841 remove the binding correspondent to the Binding Unique 842 Identifier sub-option for which R flag is set. 844 o If Lifetime field is zero, the receiver node deletes the 845 registering binding entry which BID is same as BID sent by the 846 Binding Unique Identifier sub-option. If the receiver node does 847 not have appropriate binding which BID is matched with the Binding 848 Update, it MUST reject this de-registration Binding Update. If 849 the receiver is a Home Agent, it SHOULD also return a Binding 850 Acknowledgment to the mobile node, in which the Status field is 851 set to 133 (not Home Agent for this mobile node). 853 6.3. Sending Binding Acknowledgment 855 If a Binding Update does not contain a Binding Unique Identifier sub- 856 option, the receiver, either a Correspondent Node or a Home Agent, 857 MUST reply with a Binding Acknowledgment according to section 9.5.4 858 of RFC 3775. Otherwise, whenever the Binding Unique Identifier sub- 859 option is present, the receiver MUST follow the additional procedure 860 below. The receiver MUST reply with a Binding Acknowledgment whether 861 the A flag is set or not in the Binding Update. 863 If the receiver successfully registers a binding for the BID stored 864 in a Binding Unique Identifier sub-option, it returns a Binding 865 Acknowledgment with Status field set to successful value (0 to 128) 866 and a Binding Unique Identifier sub-option copied from the received 867 Binding Update. If the receiver deletes an existing binding which 868 does not have a BID and registers a new binding for the BID, it MUST 869 return a Binding Acknowledgment with Status field set to 144. On the 870 other hand, if the node encounters an error during the processing of 871 a Binding Update, it must return a Binding Acknowledgment with an 872 appropriate error number as described in RFC 3775. The node SHOULD 873 put a Binding Unique Identifier sub-option if the BID is available 874 for the Binding Acknowledgment. 876 6.4. Sending Binding Refresh Request 878 When either a Correspondent Node or Home Agent notices that a 879 registered binding will be expired soon, it MAY send a Binding 880 Refresh Request. If the registered binding has BID, the 881 Correspondent Node SHOULD contain a Binding Unique Identifier sub- 882 option in the Binding Refresh Request. Then, the Correspondent Node 883 can receive a Binding Update with a Binding Unique Identifier sub- 884 option and can update only the particular binding. If the registered 885 binding does not have BID, then the Correspondent Node sends a 886 Binding Refresh Request without the sub-option. 888 6.5. Sending Binding Error 890 When a Correspondent Node sends a Binding Error with Status field set 891 to 2 (Unrecognized MH Type value), it MAY put a Binding Unique 892 Identifier sub-option into Mobility Options field if BID is available 893 in a received binding message. 895 When a Correspondent Node receives data packets with a home address 896 destination option, it verifies the IPv6 source address field. If 897 the source address is not registered in the Correspondent Node's 898 binding cache, the Correspondent Node MUST return a Binding Error to 899 the sender with the status set to zero (Unknown binding for Home 900 Address destination option). The Correspondent Node MUST NOT put a 901 Binding Unique Identifier sub-option, because there is no binding 902 cache entry for the source address. 904 7. Network Mobility Applicability 906 Support of multihomed mobile routers is advocated in the NEMO working 907 group (see R12 "The solution MUST function for multihomed MR and 908 multihomed mobile networks" in [7] 910 Issues regarding mobile routers with multiple interfaces and other 911 multihoming configurations are documented in [10]. 913 Since the binding management mechanisms are the same for a mobile 914 host operating Mobile IPv6 and for a mobile router operating NEMO 915 Basic Support (RFC 3963), our extensions can also be used to deal 916 with multiple Care-of Addresses registration sent from a multihomed 917 mobile router. 919 8. IPsec and IKE interaction 921 TBA 923 9. Conclusion 925 In this document, we propose a solution to achieve multihomed mobile 926 node on Mobile IPv6 and Network Mobility. A binding unique 927 identifier is introduced to register multiple care-of addresses to a 928 Home Agent and a Correspondent Node. Those care-of addresses are 929 bound to the same home address. A few modifications to Mobile IPv6 930 and NEMO are required to support multiple care-of address 931 registration. 933 10. Acknowledgments 935 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 936 Julien Charbon, Susumu Koshiba, Martti Kuparinen (Ericsson), Romain 937 Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki Matutani 938 (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji Okada 939 (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) in 940 alphabetical order, the Jun Murai Lab. at KEIO University, and WIDE 941 project for their contributions. 943 11. References 945 11.1. Normative References 947 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 948 IETF RFC 2460, December 1998. 950 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 951 IPv6", RFC 3775, June 2004. 953 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 954 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 955 January 2005. 957 [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 958 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 959 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 960 February 2006. 962 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 963 RFC 3753, June 2004. 965 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 966 draft-ietf-nemo-terminology-05 (work in progress), 967 February 2006. 969 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 970 draft-ietf-nemo-requirements-05 (work in progress), 971 October 2005. 973 11.2. Informative References 975 [8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay 976 Networks", Journal Mobile Networks and Applications, vol. 3, 977 number 4, pages 335-350, 1998. 979 [9] Ernst, T., "Motivations and Scenarios for Using Multiple 980 Interfaces and Global Addresses", 981 draft-ietf-monami6-multihoming-motivation-scenario-00 (work in 982 progress), February 2006. 984 [10] Ng, C., "Analysis of Multihoming in Network Mobility Support", 985 draft-ietf-nemo-multihoming-issues-05 (work in progress), 986 February 2006. 988 Appendix A. Example Configurations 990 In this section, we describe typical scenarios when a mobile node has 991 multiple network interfaces and acquires multiple Care-of Addresses 992 bound to a Home Address. 994 The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. 995 MN has 3 different interfaces and possibly acquires Care-of Addresses 996 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 997 Care-of Addresses. 999 Figure 3 depicts the scenario where all interfaces of the mobile node 1000 are attached to foreign links. After binding registrations, the Home 1001 Agent (HA) and the Correspondent Node (CN) have the binding entries 1002 listed in their binding cache database. The mobile node can utilize 1003 all the interfaces. 1005 +----+ 1006 | CN | 1007 +--+-+ 1008 | 1009 +---+------+ +----+ 1010 +------+ Internet |----------+ HA | 1011 | +----+---+-+ +--+-+ 1012 CoA2| | | | Home Link 1013 +--+--+ | | ------+------ 1014 | MN +========+ | 1015 +--+--+ CoA1 | 1016 CoA3| | 1017 +---------------+ 1019 Binding Cache Database: 1020 Home Agent's binding (Proxy neighbor advertisement is active) 1021 binding [a:b:c:d::EUI Care-of Address1 BID1] 1022 binding [a:b:c:d::EUI Care-of Address2 BID2] 1023 binding [a:b:c:d::EUI Care-of Address3 BID3] 1024 Correspondent Node's binding 1025 binding [a:b:c:d::EUI Care-of Address1 BID1] 1026 binding [a:b:c:d::EUI Care-of Address2 BID2] 1027 binding [a:b:c:d::EUI Care-of Address3 BID3] 1029 Figure 3: Multiple Interfaces Attached to a Foreign Link 1031 Figure 4 depicts the scenario where MN returns home with one of its 1032 interfaces. After the successful de-registration of the binding to 1033 HA, HA and CN have the binding entries listed in their binding cache 1034 database of Figure 4. MN can communicate with the HA through only 1035 the interface attached to the home link. On the other hand, the 1036 mobile node can communicate with CN from the other interfaces 1037 attached to foreign links (i.e. route optimization). Even when MN is 1038 attached to the home link, it can still send Binding Updates for 1039 other active Care-of Addresses (CoA2 and CoA3). If CN has bindings, 1040 packets are routed to each Care-of Addresses directly. Any packet 1041 arrived at HA are routed to the primary interface. 1043 +----+ 1044 | CN | 1045 +--+-+ 1046 | 1047 +---+------+ +----+ 1048 +------+ Internet |----------+ HA | 1049 | +--------+-+ +--+-+ 1050 CoA2| | | Home Link 1051 +--+--+ | --+---+------ 1052 | MN +========+ | | 1053 +--+--+ | | | 1054 CoA3| +---|-----------+ 1055 +---------------+ 1057 Binding Cache Database: 1058 Home Agent's binding (Proxy neighbor advertisement is inactive) 1059 none 1060 Correspondent Node's binding 1061 binding [a:b:c:d::EUI Care-of Address2 BID2] 1062 binding [a:b:c:d::EUI Care-of Address3 BID3] 1064 Figure 4: One of Interface Attached to Home Link and Returing Home 1066 Figure 5 depicts the scenario where MN disables the interface 1067 attached to the home link and communicates with the interfaces 1068 attached to foreign links. The HA and the CN have the binding 1069 entries listed in their binding cache database. MN disable the 1070 interface attached to the home link, because the HA still defends the 1071 home address of the MN by proxy neighbor advertisements. All packets 1072 routed to the home link are intercepted by the HA and tunneled to the 1073 other interfaces attached to the foreign link according to the 1074 binding entries. 1076 +----+ 1077 | CN | 1078 +--+-+ 1079 | 1080 +---+------+ +----+ 1081 +------+ Internet |----------+ HA | 1082 | +----+-----+ +--+-+ 1083 CoA2| | | Home Link 1084 +--+--+ | --+---+------ 1085 | MN +========+ | 1086 +--+--+ CoA1 | 1087 | | 1088 +---------------------------+ 1089 (Disable interface) 1091 Binding Cache Database: 1092 Home Agent's binding (Proxy neighbor advertisement is active) 1093 binding [a:b:c:d::EUI Care-of Address1 BID1] 1094 binding [a:b:c:d::EUI Care-of Address2 BID2] 1095 Correspondent Node's binding 1096 binding [a:b:c:d::EUI Care-of Address1 BID1] 1097 binding [a:b:c:d::EUI Care-of Address2 BID2] 1099 Figure 5: One of Interface Attached to Home Link and Not Returing 1100 Home 1102 Figure 6 depicts the scenario where multiple interfaces of MN are 1103 attached to the home link. The HA and CN have the binding entries 1104 listed in Figure 6 in their binding cache database. The MN can not 1105 use the interface attached to a foreign link unless a CN has a 1106 binding for the interface. All packets which arrive at the HA are 1107 routed to one of the MN's interfaces attached to the home link. 1109 +----+ 1110 | CN | 1111 +--+-+ 1112 | 1113 +---+------+ +----+ 1114 +------+ Internet |----------+ HA | 1115 | +----------+ +--+-+ 1116 CoA2| | Home Link 1117 +--+--+ --+----+---+------ 1118 | MN +===================+ | 1119 +--+--+ | 1120 | | 1121 +---------------------------+ 1123 Binding Cache Database: 1124 Home Agent's binding (Proxy neighbor advertisement is inactive) 1125 none 1126 Correspondent Node's binding 1127 binding [a:b:c:d::EUI Care-of Address2 BID2] 1129 Figure 6: Several Interfaces Attached to Home Link and Returning Home 1131 Figure 6 depicts the scenario where interfaces of MN are attached to 1132 the foreign links. One of foreign link is managed by the home agent. 1133 The HA and CN have the binding entries listed in Figure 6 in their 1134 binding cache database. The home agent advertises a prefix which is 1135 other than home prefix. The mobile node will generate a care-of 1136 address from the prefix and registers it to the home agent. Even if 1137 the mobile node attaches to a foreign link, the link is managed by 1138 its home agent. It will tunnel the packets to the home agent, but 1139 the home agent is one-hop neighbor. The cost of tunnel is 1140 negligible. If the mobile node wants to utilize not only an 1141 interface attached to home but also interfaces attached to foreign 1142 link, it can use this foreign link of the home agent to return home. 1143 This is different from the general returning home, but this enable 1144 the capability of using interfaces attached to both home and foreign 1145 link without any modifications to Mobile IPv6 and Nemo basic support. 1147 +----+ 1148 | CN | 1149 +--+-+ 1150 | 1151 +---+------+ +----+ 1152 +------+ Internet |----------+ HA | 1153 | +----+-----+ ++-+-+ 1154 CoA2| | | | Home Link 1155 +--+--+ | ----|-+------ 1156 | MN +========+ | 1157 +--+--+ CoA1 ---+-+------ 1158 CoA3 | | Foreign Link 1159 +---------------------------+ 1160 (Disable interface) 1162 Binding Cache Database: 1163 Home Agent's binding (Proxy neighbor advertisement is active) 1164 binding [a:b:c:d::EUI Care-of Address1 BID1] 1165 binding [a:b:c:d::EUI Care-of Address2 BID2] 1166 binding [a:b:c:d::EUI Care-of Address3 BID3] 1167 Correspondent Node's binding 1168 binding [a:b:c:d::EUI Care-of Address1 BID1] 1169 binding [a:b:c:d::EUI Care-of Address2 BID2] 1170 binding [a:b:c:d::EUI Care-of Address3 BID3] 1172 Figure 7: Emulating to Utilize Interfaces Attached to both Home and 1173 Foreign Links 1175 Appendix B. Changes From Previous Versions 1177 Changes from draft-wakikawa-mobileip-multiplecoa-05.txt 1179 o Updating packet formats. B flag in Binding Unique Identifier sub- 1180 option is removed. 1182 o Updating packet formats. C and R flags in Unique Binding 1183 Identifier sub-option are introduced for bulk registration. 1185 o Bulk Registration for home registration is now supported. Bulk 1186 Registartion to Correspondent Node is not supported in this 1187 document. 1189 o IPsec and IKE interaction will be added shortly. 1191 o The DHAAD extension is removed. 1193 Authors' Addresses 1195 Ryuji Wakikawa 1196 Keio University 1197 Department of Environmental Information, Keio University. 1198 5322 Endo 1199 Fujisawa, Kanagawa 252-8520 1200 Japan 1202 Phone: +81-466-49-1100 1203 Fax: +81-466-49-1395 1204 Email: ryuji@sfc.wide.ad.jp 1205 URI: http://www.wakikawa.org/ 1207 Thierry Ernst 1208 Keio University / WIDE 1209 Jun Murai Lab., Keio University. 1210 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1211 Kawasaki, Kanagawa 212-0054 1212 Japan 1214 Phone: +81-44-580-1600 1215 Fax: +81-44-580-1437 1216 Email: ernst@sfc.wide.ad.jp 1217 URI: http://www.sfc.wide.ad.jp/~ernst/ 1219 Kenichi Nagami 1220 INTEC NetCore Inc. 1221 1-3-3, Shin-suna 1222 Koto-ku, Tokyo 135-0075 1223 Japan 1225 Phone: +81-3-5565-5069 1226 Fax: +81-3-5565-5094 1227 Email: nagami@inetcore.com 1229 Intellectual Property Statement 1231 The IETF takes no position regarding the validity or scope of any 1232 Intellectual Property Rights or other rights that might be claimed to 1233 pertain to the implementation or use of the technology described in 1234 this document or the extent to which any license under such rights 1235 might or might not be available; nor does it represent that it has 1236 made any independent effort to identify any such rights. Information 1237 on the procedures with respect to rights in RFC documents can be 1238 found in BCP 78 and BCP 79. 1240 Copies of IPR disclosures made to the IETF Secretariat and any 1241 assurances of licenses to be made available, or the result of an 1242 attempt made to obtain a general license or permission for the use of 1243 such proprietary rights by implementers or users of this 1244 specification can be obtained from the IETF on-line IPR repository at 1245 http://www.ietf.org/ipr. 1247 The IETF invites any interested party to bring to its attention any 1248 copyrights, patents or patent applications, or other proprietary 1249 rights that may cover technology that may be required to implement 1250 this standard. Please address the information to the IETF at 1251 ietf-ipr@ietf.org. 1253 Disclaimer of Validity 1255 This document and the information contained herein are provided on an 1256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1263 Copyright Statement 1265 Copyright (C) The Internet Society (2006). This document is subject 1266 to the rights, licenses and restrictions contained in BCP 78, and 1267 except as set forth therein, the authors retain all their rights. 1269 Acknowledgment 1271 Funding for the RFC Editor function is currently provided by the 1272 Internet Society.