idnits 2.17.1 draft-wakikawa-mobileip-multiplecoa-05.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 1227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1217. ** 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 6 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 211: '...a negative value MUST NOT be used. Af...' RFC 2119 keyword, line 214: '.... A mobile node MAY change the value ...' RFC 2119 keyword, line 237: '... interfaces, it MUST register these a...' RFC 2119 keyword, line 239: '...s home agent, it MUST generate a BID f...' RFC 2119 keyword, line 242: '...er sub-option. The BID MUST be put in...' (57 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 the home attached interface. In this case, the mobile node MUST de-register all the bindings by sending a Binding Update which 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 (February 2006) is 6645 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') -- No information found for draft-ietf-monami6-multihoming-motivations-scenarios - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-05 Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: August 5, 2006 T. Ernst 5 Keio University / WIDE 6 K. Nagami 7 INTEC NetCore 8 February 2006 10 Multiple Care-of Addresses Registration 11 draft-wakikawa-mobileip-multiplecoa-05 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 August 5, 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 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 . . . . . . . . . . . . . . . . . . . . 12 76 4.3.3. Binding Acknowledgment . . . . . . . . . . . . . . . . 13 78 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 79 5.1. Management of Care-of Addresses and Binding Unique 80 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.2. Sending Binding Update . . . . . . . . . . . . . . . . . . 14 82 5.3. Sending De-Registration Binding Update . . . . . . . . . . 15 83 5.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 15 84 5.5. Using Alternate Care-of Address . . . . . . . . . . . . . 16 85 5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 16 86 5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 17 87 5.8. Receiving Binding Error . . . . . . . . . . . . . . . . . 18 89 6. Home Agent and Correspondent Node Operation . . . . . . . . . 19 90 6.1. Searching Binding Cache with Binding Unique Identifier . . 19 91 6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 19 92 6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 21 93 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 21 94 6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 21 96 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 23 98 8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 24 100 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 108 Appendix A. Example Configurations . . . . . . . . . . . . . . . 27 110 Appendix B. Dynamic Home Agent Address Discovery . . . . . . . . 31 111 B.1. DHAAD Request . . . . . . . . . . . . . . . . . . . . . . 31 112 B.2. DHAAD Reply . . . . . . . . . . . . . . . . . . . . . . . 32 113 B.3. Home Agent Information Option . . . . . . . . . . . . . . 33 115 Appendix C. Change Log From Previous Versions . . . . . . . . . . 34 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 118 Intellectual Property and Copyright Statements . . . . . . . . . . 36 120 1. Introduction 122 Permanent Internet connectivity is required by some applications 123 while a mobile node moves across several access networks (i.e. ISPs, 124 hotspots, etc). Unfortunately, there is no network interfaces 125 assuring global scale connectivity. Therefore, a mobile node should 126 use various type of network interfaces to obtain durable and wide 127 area network connectivity [8]. For example, it is desirable to 128 maintain the Internet connectivity while an automobile running on a 129 freeway receives voice or video streaming data from different access 130 networks. Such scenarios and motivations for multiple points of 131 attachment, and benefits for doing it are discussed at large in [9]. 133 Once multiple interfaces are available to a mobile node, a backup 134 interface can be used to recover from the loss of Internet 135 connectivity on the other interface, therefrom maintaining Internet 136 connectivity of wide spread and reach. In addition, each 137 communication flow could be sent to a distinct network interface, 138 providing efficient network bandwidth consumption. It becomes 139 possible for users to select the most appropriate network interface 140 depending on a visiting network environment, since wireless networks 141 are mutable and less reliable than wired networks and since each 142 network interface has different cost, performance, bandwidth, access 143 range, and reliability. Users should also be able to select the most 144 appropriate interface per communication type. For example, TCP 145 traffic should be transmitted over the wireless interface, whereas 146 UDP traffic should be transmitted over the wired interface to avoid 147 disturbing TCP connections. 149 IPv6 [1] conceptually allows a node to have several addresses on a 150 given interface. Consequently, Mobile IPv6 [2] has mechanisms to 151 manage multiple ``Home Addresses'' based on home agent's managed 152 prefixes such as mobile prefix solicitation and mobile prefix 153 advertisement. But assigning a single Home Address to a given 154 network interface is more advantageous than assigning multiple Home 155 Addresses because applications do not need to be aware of the 156 multiplicity of Home Addresses. Of course, applications should be 157 aware of the active Home Address to be used for communicating. At 158 the TCP layer, TCP holds the Home Address as a source address of the 159 communication for connection management. Applications must be 160 restarted to reset the connection information when the mobile node 161 changes its active network interface (i.e. change the Home Address). 163 However, according to section 11.5.3 of the Mobile IPv6 164 specification, a mobile node is not allowed to register multiple 165 Care-of Addresses bound to a single Home Address. If a mobile node 166 sends Binding Updates for each Care-of Address, correspondent nodes 167 would always overwrite the Care-of Address recorded in the binding 168 cache with the one contained in the latest received binding update. 169 It is thus impossible for a mobile node to register multiple Care-of 170 Addresses in the correspondent node's binding cache. Moreover, since 171 NEMO Basic Support [3] is based on Mobile IPv6, the same issues 172 applies to a mobile node acting as mobile router. 174 Multihoming issues pertaining to mobile nodes operating Mobile IPv6 175 and mobile routers operating NEMO Basic Support are respectively 176 discussed [4] and [10]. 178 In this document, we thus propose a new identification number called 179 Binding Unique Identification number (BID) for each binding cache 180 entry to accommodate multiple bindings registration. We also propose 181 extension of binding cache management to store the BID and a new sub- 182 option for binding update to carry the BID. The BID is assigned to 183 either the interfaces or Care-of Addresses bound to a single home 184 address of a mobile node. The mobile node notifies the BID to both 185 its home agent and correspondent nodes by means of a Binding Update. 186 Correspondent nodes and the home agent record the BID into their 187 binding cache. The Home Address thus identifies a mobile node itself 188 whereas the BID identifies each binding registered by a mobile node. 189 By using the BID, multiple bindings can then be distinguished. 191 A user of a mobile node may be able to bind some policies to a BID. 192 The policy is used to divide flows to multiple network interfaces by 193 flow type, port number, or destination address, etc. How to 194 distribute or configure policies is not within the scope of this 195 document. 197 2. Terminology 199 Terms used in this draft are defined in [2], [5] and [6]. In 200 addition or in replacement of these, the following terms are defined 201 or redefined: 203 Binding Unique Identification number (BID) 205 The BID is an identification number used to distinguish multiple 206 bindings registered by the mobile node. Assignment of distinct 207 BID allows a mobile node to register multiple binding cache 208 entries for a given Home Address. The BID is generated to 209 register multiple bindings in the binding cache for a given 210 address in a way it cannot be duplicated with another BID. The 211 zero value and a negative value MUST NOT be used. After being 212 generated by the mobile node, the BID is stored in the Binding 213 Update List and is sent by the mobile node by means of a sub- 214 option of a Binding Update. A mobile node MAY change the value of 215 a BID at any time according to its administrative policy, for 216 instance to protect its privacy. 218 The BID can be assigned to either a Care-of Address or an 219 interface depending on implementation choices so as to keep using 220 the same BID for the same binding even when the status of the 221 binding is changed. More details can be found in Section 5.1. 223 Binding Unique Identifier sub-option 225 The Binding Unique Identifier sub-option is used to carry the BID. 227 3. Protocol Overview 229 We propose a new identification number (BID) to distinguish multiple 230 bindings pertaining to the same Home Address. The procedures for the 231 mobile node to register multiple bindings are described in the 232 paragraphs below. 234 3.1. Multiple Care-of Addresses Registration 236 Once a mobile node gets several IPv6 global addresses on distinct 237 interfaces, it MUST register these addresses with its home agent 238 (home registration). If the mobile node wants to register multiple 239 bindings to its home agent, it MUST generate a BID for each Care-of 240 Address and record it into the binding update list entry. The mobile 241 node then registers its Care-of Addresses by sending a Binding Update 242 with a Binding Unique Identifier sub-option. The BID MUST be put in 243 the Binding Unique Identifier sub-option. After receiving the 244 Binding Update, the home agent verifies the request and records the 245 binding in its binding cache. If the newly defined sub-option is 246 present in the Binding Update, the home agent MUST copy the BID from 247 the Binding Update to the corresponding field in the binding entry. 248 Even if there is already an entry for the mobile node, the home agent 249 MUST register a new binding entry for the BID stored in the Binding 250 Unique Identifier sub-option. The mobile node registers multiple 251 Care-of Addresses either independently (in individual BUs) or all at 252 once (in a single BU). 254 If the mobile node wishes to register its binding with a 255 correspondent node, it MUST start return routability operations 256 before sending a Binding Update. The mobile node MUST sends CoTI for 257 each Care-of Addresses and MUST receive CoT for each Care-of 258 Addresses. The mobile node also uses a BID generated for the home 259 registration to register them as individual bindings. The 260 registration step is the same as for the home registration except for 261 calculating authenticator by using Binding Unique Identifier sub- 262 option as well as the other sub-options specified in RFC 3775. 264 3.2. Multiple Bindings Management 266 The BID is used as a search key for a corresponding entry in the 267 binding cache in addition to the Home Address. When the home agent 268 checks the binding cache database for the mobile node, it searches a 269 corresponding binding entry with the Home Address and BID of the 270 desired binding. 272 The desired binding can be selected with policy and filter 273 information. If a mobile node registers a binding with priority 274 value, the priority can be a key to select a binding. The capability 275 of searching the desired binding enables load-sharing and QoS with 276 flow separation. However, this selection and flow separation are out 277 of scope in this document. 279 If there is no desired binding, it searches the binding cache 280 database with the Home Address as specified in Mobile IPv6. The 281 first matched binding entry may be found, although this is 282 implementation dependent. 284 If a node has multiple bindings and its packets meant for the mobile 285 node are not delivered correctly, the node can change the binding 286 entry for the mobile node so as to recover the connection 287 immediately. The node can detect a binding invalidation by packets 288 loss or ICMP error messages such as ICMP_UNREACHABLE. This provides 289 redundancy for Mobile IPv6. 291 When one of the care-of addresses is changed, the mobile node sends a 292 Binding Update with the new Care-of Address and the corresponding 293 BID. The receiver of the Binding Update updates the binding which 294 BID fits the BID contained in the received Binding Unique Identifier 295 sub-option. The mobile node can manage each binding independently 296 owing to BID. 298 If the mobile node decides to register only single binding, it just 299 sends a Binding Update without a Binding Unique Identifier sub-option 300 (i.e. normal Binding Update). The receiver of the Binding Update 301 registers only a single binding for the mobile node. If the receiver 302 has multiple bindings, one binding is registered without BID and the 303 rest of bindings are deleted. 305 3.3. Returning Home 307 When the mobile node returns home, there are two situations, since 308 the home agent defends the mobile node's Home Address by using the 309 proxy neighbor advertisement. It is impossible to utilize all the 310 interfaces when one interface is attached to the home link and the 311 others are attached to foreign links. If the proxy Neighbor 312 Advertisement for the Home Address is stopped, packets are always 313 routed to the interface attached to the home link. If proxy is not 314 stopped, packets are never routed to the interface attached to the 315 home link. The decision whether a mobile node returns home or not is 316 up to implementors. 318 The first situation is when a mobile node wants to return home with 319 the home attached interface. In this case, the mobile node MUST de- 320 register all the bindings by sending a Binding Update which lifetime 321 set to zero. The mobile node MAY NOT put any Binding Unique 322 Identifier sub-option in this packet. Then, the receiver deletes all 323 the bindings from its binding cache database. 325 The second situation is when a mobile node does not want to return 326 home, though one of its interfaces is attached to its home link. The 327 mobile node disables the interface attached to the home link and 328 keeps using the rest of interfaces attached to foreign links. In 329 this case, the mobile node sends a de-registration Binding Update for 330 the interface attached to the home link with the Binding Unique 331 Identifier sub-option. The receiver of the de-registration Binding 332 Update deletes only the correspondent binding entry from the binding 333 cache database. The home agent does not stop proxying neighbor 334 advertisement unless there are still bindings for the other 335 interfaces. 337 4. Mobile IPv6 Extensions 339 In this section are described the changes to Mobile IPv6 necessary to 340 manage multiple bindings bound to a same Home Address. 342 4.1. Binding Cache Structure and Management 344 The following additional items are required in the binding cache 345 structure, i.e.: 347 BID of the Binding Cache Entry 349 The BID is notified by the mobile node by means of a Binding 350 Unique Identifier sub-option. The value MUST be zero if the 351 Binding Unique identifier does not appear in a Binding Update. 353 Priority of the Binding Cache Entry 355 The priority is notified by the mobile node by means of a Binding 356 Unique Identifier sub-option. 358 4.2. Binding Update Structure and Management 360 The following additional items are required for the binding update 361 structure, i.e.: 363 BID 365 The BID MUST be generated whenever the mobile node registers 366 multiple bindings for its Home Address. 368 Priority 370 MUST be set if the priority field of a Binding Unique Identifier 371 is valid. 373 4.3. Message Format Changes 375 4.3.1. Binding Unique Identifier sub-option 377 If needed, the Binding Unique Identifier sub-option is included in 378 the Binding Update, Binding Acknowledgment, Binding Refresh Request, 379 or Binding Error messages. 381 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type = TBD | Length = 4 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Binding Unique ID (BID) | Priority |B| Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 389 Figure 1: BID Sub-Option 391 Type 393 Type value for Binding Unique Identifier will be assigned later. 395 Binding Unique ID (BID) 397 The BID which is assigned to the binding carried in the Binding 398 Update with this sub-option. BID is 16-bit unsigned integer. A 399 value of zero is reserved. 401 Priority 403 The priority is assigned to each binding. The receiver can 404 utilize this priority to determine which binding is used to 405 deliver packets. The priority is 8-bit unsigned integer. A value 406 of zero indicates No Priority. The higher value has higher 407 priority. 409 Bulk Registration (B) flag 411 When this flag is set, a mobile node can piggyback several Care-of 412 Addresses into a binding update. The mobile node must use a 413 Care-of Address stored in an alternate Care-of Address sub-option 414 followed by the Binding Unique Identifier sub-option. 416 Reserved 418 15 bits Reserved field. Reserved field must be set with all 0. 420 4.3.2. Binding Update 422 No modification to Binding Update. A mobile node stores a Binding 423 Unique Identifier option in the Mobility Options field of a Binding 424 Update. 426 4.3.3. Binding Acknowledgment 428 The message format of Binding Acknowledgment is not changed, but 429 operations listed below are added in this draft. 431 A receiver who gets a Binding Update with a binding unique identifier 432 option MUST reply with a Binding Acknowledgment if the 'A' flag is 433 also set or in case of a home registration. The receiver MUST also 434 send a Binding Acknowledgment with corresponding error codes if it 435 finds an error while processing the Binding Update and its sub-option 436 described in section Section 4.3. 438 If a Binding Update has a Binding Unique Identifier sub-option is 439 present, the receiver node MUST reply with a Binding Acknowledgment 440 containing the same Binding Unique Identifier sub-option. The mobile 441 node can process the Binding Acknowledgment for the particular 442 Care-of Address identified by the BID set in the Binding Unique 443 Identifier sub-option. 445 A new number is defined for handling the multiple Care-of Addresses 446 registration: 448 TBD (144) 450 It implies conflicting a regular binding and a binding that has 451 BID in binding cache. The regular binding indicates the binding 452 that does not have BID field. The status value is TBD. 454 TBD (145) 456 It implies that the bulk binding registration is failed. The 457 status value is TBD. 459 5. Mobile Node Operation 461 5.1. Management of Care-of Addresses and Binding Unique Identifier 463 There are two cases when a mobile node has several Care-of Addresses: 465 1. A mobile node uses several physical network interfaces and 466 acquires a Care-of Address on each of its interfaces. 468 2. A mobile node uses a single physical network interface, but 469 multiple prefixes are announced on the link the interface is 470 attached to. Several global addresses are configured on this 471 interface for each of the announced prefixes. 473 The difference between the above two cases is only a number of 474 physical network interfaces and therefore does not matter. The 475 Identification number is used to distinguish multiple bindings so 476 that the mobile node assigns an identification number for each 477 Care-of Addresses. How to assign an identification number is up to 478 implementors. 480 A mobile node assigns a BID to each Care-of Address when it wants to 481 simultaneously register with its Home Address. The value should be 482 generated from a value comprised between 1 to 65535. Zero and 483 negative value can not be taken as a BID. If a mobile node has only 484 one Care-of Address, the assignment of a BID is not needed until it 485 has multiple Care-of Addresses to register with. 487 5.2. Sending Binding Update 489 When a mobile node sends a Binding Update, it MUST decide whether it 490 registers multiple Care-of Addresses or not. However, this decision 491 is out-of scope in this document. If a mobile node decides not to 492 register multiple Care-of Addresses, it completely follows standard 493 RFC 3775 specification. 495 On the other hand, if the mobile node needs to register multiple 496 Care-of Addresses, it MUST use BIDs to identify a Care-of Address. 497 The mobile node puts a Binding Unique Identifier sub-option into the 498 Option field of the Binding Update. The BID is copied from a Binding 499 Update List to the Binding Unique Identifier sub-option. If the 500 mobile node registers bindings to a correspondent node, it MUST sends 501 multiple CoTI for multiple Care-of Addresses. After getting CoTs, it 502 sends Binding Updates with a Binding Unique Identifier sub-option for 503 all Care-of Addresses. In any case, the mobile node MUST set the 'A' 504 flag in Binding Updates and MUST wait for a Binding Acknowledgment to 505 confirm the registration was successful as described in section 506 Section 5.6. 508 Note that there is an optimization for registering multiple Care-of 509 Addresses by using a single Binding Update, although the current 510 Mobile IPv6 specification does not allow to send multiple bindings by 511 means of a single Binding Update. In this case, a mobile node sets 512 the B flag into a Binding Unique Identifier sub-option and stores the 513 particular Care-of Address in an alternate Care-of Address sub-option 514 followed by the Binding Unique Identifier sub-option. The mobile 515 node can store multiple sets of a Unique Binding Identifier sub- 516 option and an Alternate Care-of Address sub-option in a Binding 517 Update. All the other binding information such as Lifetime, Sequence 518 Number, binding Flags are shared among the bulk Care-of Addresses. 519 Whether a mobile node registers multiple Care-of Addresses 520 respectively or not is up to implementations. 522 5.3. Sending De-Registration Binding Update 524 When a mobile node decides to delete all bindings for its home 525 address, it sends a regular de-registration Binding Update (i.e. 526 exclusion of a Binding Unique Identifier sub-option). See 527 Section 6.2 for details. 529 If a mobile node wants to delete a particular binding from its home 530 agent and correspondent nodes (ex. from foreign link), it MUST sends 531 a Binding Update which lifetime is set to zero. If only single 532 Care-of Address is removed by a Binding Update, the mobile node 533 simply set zero lifetime in a Binding Update and contains the single 534 correspondent Unique Binding Identifier Sub-option (B flag must be 535 unset). The receiver will remove only the Care-of Address which is 536 retrieved from the Source Address field of the IPv6 header. On the 537 other hand, if the mobile node wants to remove multiple Care-of 538 Addresses at once, it stores multiple Unique Binding Identifier sub- 539 options and Alternate Care-of Address sub-options in a Binding 540 Update. The Care-of Addresses stored in the Alternate Care-of 541 Address sub-options will be all removed. 543 5.4. Returning Home 545 When a mobile node returns home, it MUST de-registers all the binding 546 from the Home Agent. 548 Although the mobile node MUST deletes the binding at correspondent 549 nodes as well, the node can still keep the binding of the other 550 interface active attached to foreign links at the correspondent 551 nodes. In such case, the mobile node still receives packets at the 552 other interface attached to a foreign link thanks to route 553 optimization. The mobile node also receives packets at the interface 554 attached to the home link when correspondent nodes does not use route 555 optimization. 557 Note that when the mobile node does not want to return home even if 558 one of interfaces is attached to the home link. the mobile node MUST 559 disable the interface. Otherwise, address duplication will be 560 observed because the home agent still defend the Home Address by the 561 proxy neighbor advertisement and the mobile node also enables the 562 same Home Address on the home link. After disabling the interface 563 attached to the home link, the mobile node MUST delete the binding 564 for the interface by sending de-registration binding update. The de- 565 registration binding update must be sent from one of active 566 interfaces attached to foreign links. As a result, the mobile node 567 no longer receives packets at the interface attached to the home 568 link. All packets are routed to other interfaces attached to a 569 foreign link. 571 5.5. Using Alternate Care-of Address 573 A mobile node can use an alternate Care-of Address in the following 574 situations. 576 o One Care-of Address becomes invalid (e.g because the link where it 577 is attached is no longer available) and MUST be deleted. In such 578 case, the mobile node can not sends a Binding Update from the 579 Care-of Address because the interface's link is lost. The mobile 580 node needs to de-register the remote binding of the Care-of 581 Address through one of its active Care-of Addresses. 583 o A mobile node has multiple interfaces, but it wants to sends 584 Binding Updates for all Care-of Addresses from a specific 585 interface which has wider bandwidth depending on interface's 586 characteristics. A mobile node does not want to send a lot of 587 control messages through an interface which bandwidth is scarce. 589 o A mobile node wants to register multiple Care-of Addresses in bulk 590 mode. The mobile node can store multiple Care-of Addresses with 591 correspondent BID into a Binding Update message. 593 In these cases, the mobile node sends a Binding Update with both 594 Alternate Care-of Address sub-option and Binding Unique Identifier 595 sub-option. If the B flag is unset in a Binding Unique Identifier 596 sub-option, the BID in a Binding Unique Identifier sub-option is 597 assigned for the Care-of Address in the Alternate Care-of Address 598 sub-option. If the B flag is set, the BID in a Binding Unique 599 Identifier sub-option is assigned for the Care-of Address in the 600 followed Alternate Care-of Address sub-option. 602 5.6. Receiving Binding Acknowledgment 604 The verification of a Binding Acknowledgment is the same as in Mobile 605 IPv6 (section 11.7.3 of RFC 3775). The operation for sending a 606 Binding Acknowledgment is described in Section 6.3. 608 If a mobile node sends a Binding Update with a Binding Unique 609 Identifier sub-option, a Binding Acknowledgment MUST have a Binding 610 Unique Identifier sub-option in the Mobility options field. If there 611 is no such sub-option, the originator node of this Binding 612 Acknowledgment might not recognize the Binding Unique Identifier sub- 613 option. The mobile node SHOULD stop registering multiple Care-of 614 Addresses by using a Binding Unique Identifier sub-option. If the 615 originator is the Home Agent, the mobile node MAY perform DHAAD to 616 discover a new Home Agent supporting the multiple Care-of Address 617 registration or give up the multiple Care-of Address registration. 619 If a Binding Unique Identifier sub-option is present, the mobile node 620 checks the Status field of the Binding Acknowledgment. If the status 621 code indicates successful registration (below 128), the originator 622 registers a binding information and BID for the mobile node 623 successfully. 625 If the status code is not zero regardless of Binding Unique 626 Identifier sub-option availability in Binding Acknowledgment, the 627 mobile node proceeds an relevant operations according to the status 628 code. 630 If the status code is 144, the mobile node has already registered a 631 regular binding before sending a Binding Update with a Binding Unique 632 Identifier sub-option. In such case, the mobile node SHOULD stop 633 sending Binding Updates without BID. 635 If the status code is 145, the mobile node should re-registers 636 multiple Care-of Addresses respectively. (i.e. not using the bulk 637 registration). 639 5.7. Receiving Binding Refresh Request 641 The verification of a Binding Refresh Request is the same as in 642 Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a 643 Binding Refresh Request is described in section Section 6.4. 645 If a mobile node receives a Binding Refresh Request with a Binding 646 Unique Identifier sub-option, this Binding Refresh Request requests a 647 binding indicated by the BID. The mobile node SHOULD update only the 648 respective binding. The mobile node MUST put a Binding Unique 649 Identifier sub-option into a Binding Update. 651 If no Binding Unique Identifier sub-option is present in a Binding 652 Refresh Request, the mobile node sends a Binding Update according to 653 its Binding Update List for the requesting node. On the other hand, 654 if the mobile node does not have any Binding Update List entry for 655 the requesting node, the mobile node needs to register either a 656 single binding or multiple bindings depending on its binding 657 management policy. 659 5.8. Receiving Binding Error 661 When a mobile node receives a Binding Error with a Binding Unique 662 Identifier sub-option, the message is for a binding indicated by the 663 BID in the Binding Unique Identifier sub-option. Further operations 664 except for the text below are identical as in RFC 3775. The 665 operation for sending BE is described in the section Section 6.5. 667 When a mobile node receives a Binding Error with Status field set to 668 2 (unrecognized MH Type value) , it MAY stop trying to register 669 multiple Care-of Addresses and registers only primary Care-of Address 670 as performed in Mobile IPv6. 672 6. Home Agent and Correspondent Node Operation 674 6.1. Searching Binding Cache with Binding Unique Identifier 676 If either a correspondent node or a home agent has multiple bindings 677 for a mobile node in its binding cache database, it can use any of 678 the bindings to communicate with the mobile node. How to select the 679 most suitable binding from the binding cache database is out of scope 680 in this document. 682 Whenever a correspondent node searches a binding cache for a home 683 address, it SHOULD uses both the Home Address and the BID as the 684 search key if it knows the corresponding BID. If the priority is 685 available for a binding cache entry, the priority can be used as 686 additional key to search a binding. In the below example, if a 687 correspondent node searches the binding with the Home Address and 688 BID2, it gets binding2 for this mobile node. 690 binding1 [a:b:c:d::EUI Care-of Address1 BID1] 691 binding2 [a:b:c:d::EUI Care-of Address2 BID2] 692 binding3 [a:b:c:d::EUI Care-of Address3 BID3] 694 Figure 2: Searching the Binding Cache 696 A correspondent node basically learns the BID when it receives a 697 Binding Unique Identifier sub-option. At the time, the correspondent 698 node MUST look up its binding cache database with the Home Address 699 and the BID retrieved from Binding Update. If the correspondent node 700 does not know the BID, it searches a binding with only a Home Address 701 as performed in Mobile IPv6. In such case, the first matched binding 702 is found. But which binding entry is returned for the normal search 703 depends on implementations. If the correspondent node does not 704 desire to use multiple bindings for a mobile node, it can simply 705 ignore the BID. 707 6.2. Receiving Binding Update 709 If a Binding Update does not have a Binding Unique Identifier, the 710 processing of the regular Binding Update is the same as in RFC 3775. 711 But if the receiver already has multiple bindings for the Home 712 Address, it MUST overwrite all existing bindings for the mobile node 713 with the received binding. As a result, the receiver node MUST have 714 only a binding for the mobile node. If the Binding Update is for de- 715 registration, the receiver MUST delete all existing bindings for the 716 mobile node. 718 On the other hand, if a Binding Update contains a Binding Unique 719 Identifier sub-option, a receiver node MUST operate additional 720 validations as follows: 722 o A receiver node MUST validate the Binding Update according to 723 section 9.5.1 of RFC 3775. 725 o If the Binding Unique Identifier sub-option is present, the 726 receiver node MUST process the Binding Update. 728 o If the Binding Unique Identifier sub-option has B flag set and no 729 alternate Care-of Address sub-option can be found, the receiver 730 node MUST send a binding acknowledgment with status code set to 731 145. 733 o If the Lifetime field is not zero, the receiver node registers a 734 binding that includes the BID as a mobile node's binding. 736 * If the B flag is set in the Binding Unique Identifier sub- 737 option, the Care-of Address must be taken from the followed 738 Alternate Care-of Address sub-option. 740 * If the B flag is not set in the Binding Unique Identifier sub- 741 option, the Care-of Address must be taken from the Source 742 Address field of the IPv6 header. 744 * If the receiver does not have any binding for the mobile node, 745 it registers a binding which includes BID field. 747 * If the receiver has a regular binding which does not have BID 748 for the mobile node, it de-registers the regular binding and 749 registers a new binding including BID according to the Binding 750 Update. In this case, the receiver MUST send Binding 751 Acknowledgment with status code set to 144. 753 * If the receiver node has already registered the binding which 754 BID is matched with requesting BID , then it MUST update the 755 binding up-to-date with the Binding Update. Meanwhile, if the 756 receiver does not have a binding entry which BID is matched 757 with the requesting BID, it registers a new binding for the 758 BID. 760 o If Lifetime field is zero, the receiver node deletes the 761 registering binding entry which BID is same as BID sent by the 762 Binding Unique Identifier sub-option. If the receiver node does 763 not have appropriate binding which BID is matched with the Binding 764 Update, it MUST reject this de-registration Binding Update. If 765 the receiver is a Home Agent, it SHOULD also return a Binding 766 Acknowledgment to the mobile node, in which the Status field is 767 set to 133 (not home agent for this mobile node). 769 6.3. Sending Binding Acknowledgment 771 If a Binding Update does not contain a Binding Unique Identifier sub- 772 option, the receiver, either a correspondent node or a home agent, 773 MUST reply with a Binding Acknowledgment according to section 9.5.4 774 of RFC 3775. Otherwise, whenever the BID sub-option is present, the 775 receiver MUST follow the additional procedure below. The receiver 776 MUST reply with a Binding Acknowledgment whether the 'A' flag is set 777 or not in the Binding Update. 779 If the receiver successfully registers a binding for the BID stored 780 in a Binding Unique Identifier sub-option, it returns a Binding 781 Acknowledgment with Status field set to successful value (0 to 128) 782 and a Binding Unique Identifier sub-option copied from the received 783 Binding Update. If the receiver deletes the existing binding which 784 does not have a BID and registers a new binding for the BID, it MUST 785 return a Binding Acknowledgment with Status field set to '144'. On 786 the other hand, if the node encounters an error during the processing 787 of a Binding Update, it must return a Binding Acknowledgment with an 788 appropriate error number as described in RFC 3775. The node SHOULD 789 put a Binding Unique Identifier sub-option if the BID is available 790 for the Binding Acknowledgment. 792 6.4. Sending Binding Refresh Request 794 When either a correspondent node or Home Agent notices that a 795 registered binding will be expired soon, it SHOULD send a Binding 796 Refresh Request. If the registered binding has BID, the 797 correspondent node SHOULD contain a Binding Unique Identifier sub- 798 option in the Binding Refresh Request. Then, the correspondent node 799 can receive a Binding Update with a Binding Unique Identifier sub- 800 option and can update only the particular binding. If the registered 801 binding does not have BID, then the correspondent node sends a 802 Binding Refresh Request without the sub-option. 804 6.5. Sending Binding Error 806 When a correspondent node sends a Binding Error with Status field set 807 to 2 (Unrecognized MH Type value), it MAY put a Binding Unique 808 Identifier sub-option into Mobility Options field if BID is available 809 in a received binding message. 811 When a correspondent node receives data packets with a home address 812 destination option, it verifies the IPv6 source address field. If 813 the source address is not registered in the correspondent node's 814 binding cache, the correspondent node MUST return a Binding Error to 815 the sender with the status set to zero (Unknown binding for Home 816 Address destination option). The correspondent node can not put a 817 Binding Unique Identifier sub-option, because there is no binding 818 cache entry for the source address. 820 7. Network Mobility Applicability 822 Support of multihomed mobile routers is advocated in the NEMO working 823 group (see R12 ``The solution MUST function for multihomed MR and 824 multihomed mobile networks'' in [7] 826 Issues regarding mobile routers with multiple interfaces and other 827 multihoming configurations are documented in [10]. 829 Since the binding management mechanisms are the same for a mobile 830 host operating Mobile IPv6 and for a mobile router operating NEMO 831 Basic Support (RFC 3963), our extensions can also be used to deal 832 with multiple Care-of Addresses registration sent from a multihomed 833 mobile router. 835 8. IPsec and IKE interaction 837 TBA 839 9. Conclusion 841 In this document, we propose a solution to achieve multihomed mobile 842 node on Mobile IPv6 and Network Mobility. A binding unique 843 identifier is introduced to register multiple care-of addresses to a 844 home agent and a correspondent node. Those care-of addresses are 845 bound to the same home address. A few modifications to Mobile IPv6 846 and NEMO are required to support multiple care-of address 847 registration. 849 10. Acknowledgments 851 The authors would like to thank Masafumi Aramoto (Sharp Corporation), 852 Julien Charbon, Susumu Koshiba, Romain Kuntz (Keio-U), Hiroki 853 Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji 854 Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) 855 in alphabetical order, the Jun Murai Lab. at KEIO University, and 856 WIDE project for their contributions. 858 11. References 860 11.1. Normative References 862 [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 863 IETF RFC 2460, December 1998. 865 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 866 IPv6", RFC 3775, June 2004. 868 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 869 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 870 January 2005. 872 [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 873 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 874 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 875 February 2006. 877 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 878 RFC 3753, June 2004. 880 [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 881 draft-ietf-nemo-terminology-05 (work in progress), 882 February 2006. 884 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 885 draft-ietf-nemo-requirements-05 (work in progress), 886 October 2005. 888 11.2. Informative References 890 [8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay 891 Networks", Journal Mobile Networks and Applications, vol. 3, 892 number 4, pages 335-350, 1998. 894 [9] Ernst, T., "Motivations and Scenarios for Using Multiple 895 Interfaces and Global Addresses", 896 draft-ietf-monami6-multihoming-motivations-scenarios-00 (work 897 in progress), February 2006. 899 [10] Ng, C., "Analysis of Multihoming in Network Mobility Support", 900 draft-ietf-nemo-multihoming-issues-05 (work in progress), 901 February 2006. 903 Appendix A. Example Configurations 905 In this section, we describe typical scenarios when a mobile node has 906 multiple network interfaces and acquires multiple Care-of Addresses 907 bound to a Home Address. 909 The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. 910 MN has 3 different interfaces and possibly acquires Care-of Addresses 911 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 912 Care-of Addresses. 914 Figure 3 depicts the scenario where all interfaces of the mobile node 915 are attached to foreign links. After binding registrations, the home 916 agent (HA) and the correspondent node (CN) have the binding entries 917 listed in their binding cache database. The mobile node can utilize 918 all the interfaces. 920 +----+ 921 | CN | 922 +--+-+ 923 | 924 +---+------+ +----+ 925 +------+ Internet |----------+ HA | 926 | +----+---+-+ +--+-+ 927 CoA2| | | | Home Link 928 +--+--+ | | ------+------ 929 | MN +========+ | 930 +--+--+ CoA1 | 931 CoA3| | 932 +---------------+ 934 Binding Cache Database: 935 Home Agent's binding (Proxy neighbor advertisement is active) 936 binding [a:b:c:d::EUI Care-of Address1 BID1] 937 binding [a:b:c:d::EUI Care-of Address2 BID2] 938 binding [a:b:c:d::EUI Care-of Address3 BID3] 939 Correspondent Node's binding 940 binding [a:b:c:d::EUI Care-of Address1 BID1] 941 binding [a:b:c:d::EUI Care-of Address2 BID2] 942 binding [a:b:c:d::EUI Care-of Address3 BID3] 944 Figure 3: Multiple Interfaces Attached to a Foreign Link 946 Figure 4 depicts the scenario where MN returns home by one of its 947 interfaces. After the successful de-registration of the binding to 948 HA, HA and CN have the binding entries listed in their binding cache 949 database of Figure 4. MN can communicate with the HA through only 950 the interface attached to the home link. On the other hand, the 951 mobile node can communicate with CN from the other interfaces 952 attached to foreign links (i.e. route optimization). Even when MN is 953 attached to the home link, it can still send Binding Updates for 954 other active Care-of Addresses (CoA2 and CoA3). If CN has bindings, 955 packets are routed to each Care-of Addresses directly. Any packet 956 arrived at HA are routed to the primary interface. 958 +----+ 959 | CN | 960 +--+-+ 961 | 962 +---+------+ +----+ 963 +------+ Internet |----------+ HA | 964 | +--------+-+ +--+-+ 965 CoA2| | | Home Link 966 +--+--+ | --+---+------ 967 | MN +========+ | | 968 +--+--+ | | | 969 CoA3| +---|-----------+ 970 +---------------+ 972 Binding Cache Database: 973 Home Agent's binding (Proxy neighbor advertisement is inactive) 974 none 975 Correspondent Node's binding 976 binding [a:b:c:d::EUI Care-of Address2 BID2] 977 binding [a:b:c:d::EUI Care-of Address3 BID3] 979 Figure 4: One of Interface Attached to Home Link and Returing Home 981 Figure 5 depicts the scenario where a MN disable the interface 982 attached to the home link and communicates with the interfaces 983 attached to foreign links. The HA and the CN have the binding 984 entries listed in their binding cache database. MN disable the 985 interface attached to the home link, because the HA still defends the 986 home address of the MN by proxy neighbor advertisements. All packets 987 routed to the home link are intercepted by the HA and tunneled to the 988 other interfaces attached to the foreign link according to the 989 binding entries. 991 +----+ 992 | CN | 993 +--+-+ 994 | 995 +---+------+ +----+ 996 +------+ Internet |----------+ HA | 997 | +----+-----+ +--+-+ 998 CoA2| | | Home Link 999 +--+--+ | --+---+------ 1000 | MN +========+ | 1001 +--+--+ CoA1 | 1002 | | 1003 +---------------------------+ 1004 (Disable interface) 1006 Binding Cache Database: 1007 Home Agent's binding (Proxy neighbor advertisement is active) 1008 binding [a:b:c:d::EUI Care-of Address1 BID1] 1009 binding [a:b:c:d::EUI Care-of Address2 BID2] 1010 Correspondent Node's binding 1011 binding [a:b:c:d::EUI Care-of Address1 BID1] 1012 binding [a:b:c:d::EUI Care-of Address2 BID2] 1014 Figure 5: One of Interface Attached to Home Link and Not Returing 1015 Home 1017 Figure 6 depicts the scenario where multiple interfaces of MN are 1018 attached to the home link. The HA and the CN have the binding 1019 entries listed in Figure 6 in their binding cache database. The MN 1020 can not use the interface attached to a foreign link unless a CN has 1021 a binding for the interface. All packets which arrive at the HA are 1022 routed to one of the MN's interfaces attached to the home link. 1024 +----+ 1025 | CN | 1026 +--+-+ 1027 | 1028 +---+------+ +----+ 1029 +------+ Internet |----------+ HA | 1030 | +----------+ +--+-+ 1031 CoA2| | Home Link 1032 +--+--+ --+----+---+------ 1033 | MN +===================+ | 1034 +--+--+ | 1035 | | 1036 +---------------------------+ 1038 Binding Cache Database: 1039 Home Agent's binding (Proxy neighbor advertisement is inactive) 1040 none 1041 Correspondent Node's binding 1042 binding [a:b:c:d::EUI Care-of Address2 BID2] 1044 Figure 6: Several Interfaces Attached to Home Link and Returning Home 1046 Appendix B. Dynamic Home Agent Address Discovery 1048 The Dynamic Home Agent Address Discovery (DHAAD) defined in RFC 3775 1049 is extended so that Mobile Nodes or Mobile Routers only register 1050 multiple Care-of Addresses with Home Agents that support multiple 1051 Care-of Addresses registration. This is optional operations. 1053 However, we do not provide a solution for Mobile Nodes that would 1054 like to register multiple Care-of Addresses only with Correspondent 1055 Nodes that support multiple Care-of Addresses registration. 1057 B.1. DHAAD Request 1059 A new 'B' flag is introduced in the DHAAD Request message in order to 1060 discover Home Agents supporting the multiple Care-of Address 1061 registration. 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type | Code | Checksum | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Identifier |R|B| Reserved | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 Figure 7: DHAAD Request 1073 Multiple Care-of Addresses (B) Flag 1075 This flag is set when the mobile node wants to discover Home 1076 Agents that support multiple Care-of Addresses registration. 1078 B.2. DHAAD Reply 1080 A new 'B' flag is introduced in the DHAAD Reply message. When a Home 1081 Agent receives a DHAAD Request message with the Multiple Care-of 1082 Addresses support Flag set, it MUST reply with a list of Home Agents 1083 supporting the multiple Care-of Addresses registration. The 'B' flag 1084 MUST be set in the DHAAD Reply. 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Type | Code | Checksum | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Identifier |R|B| Reserved | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | | 1094 + + 1095 . . 1096 . Home Agent Addresses . 1097 . . 1098 + + 1099 | | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Figure 8: DHAAD Reply 1103 Mobile Router (R) Flag 1105 This flag is used by NEMO Basic Support [3] 1107 Multiple Care-of Addresses (B) Flag 1109 This flag is set when the Home Agents listed in this message 1110 supports multiple Care-of Addresses registration. 1112 B.3. Home Agent Information Option 1114 A new 'B' flag is introduced in the Home Agent Information Option. 1115 The home agent SHOULD set the flag if it supports multiple Care-of 1116 Addresses registration. 1118 0 1 2 3 1119 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 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Type | Length |R|B| Reserved | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Home Agent Preference | Home Agent Lifetime | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Figure 9: Home Agent Information Option 1128 Mobile Router (R) Flag 1130 This flag is used by NEMO Basic Support [3] 1132 Multiple Care-of Addresses (B) Flag 1134 This flag is set when the Home Agents listed in this message 1135 supports multiple Care-of Addresses registration. 1137 Appendix C. Change Log From Previous Versions 1139 Changes from draft-wakikawa-mobileip-multiplecoa-04.txt 1141 o Updating packet formats. B flag in Binding Update is removed. 1143 o Updating packet formats. B flag in Unique Binding Identifier sub- 1144 option is introduced for bulk registration. 1146 o Bulk Registration is now supported. 1148 o The distinction of primary and non-primary is obsoleted. 1150 o IPsec and IKE interaction will be added shortly. 1152 o The priority is introduced instead of primary and non-primary. 1153 This priority is from comment by Monami6 WG. The specification 1154 may not be completed, but if the document become WG, we will 1155 complete the spec. 1157 o The DHAAD extension is optional extension. (moved to Appendix) 1159 Authors' Addresses 1161 Ryuji Wakikawa 1162 Keio University 1163 Department of Environmental Information, Keio University. 1164 5322 Endo 1165 Fujisawa, Kanagawa 252-8520 1166 Japan 1168 Phone: +81-466-49-1100 1169 Fax: +81-466-49-1395 1170 Email: ryuji@sfc.wide.ad.jp 1171 URI: http://www.wakikawa.org/ 1173 Thierry Ernst 1174 Keio University / WIDE 1175 Jun Murai Lab., Keio University. 1176 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1177 Kawasaki, Kanagawa 212-0054 1178 Japan 1180 Phone: +81-44-580-1600 1181 Fax: +81-44-580-1437 1182 Email: ernst@sfc.wide.ad.jp 1183 URI: http://www.sfc.wide.ad.jp/~ernst/ 1185 Kenichi Nagami 1186 INTEC NetCore Inc. 1187 1-3-3, Shin-suna 1188 Koto-ku, Tokyo 135-0075 1189 Japan 1191 Phone: +81-3-5565-5069 1192 Fax: +81-3-5565-5094 1193 Email: nagami@inetcore.com 1195 Intellectual Property Statement 1197 The IETF takes no position regarding the validity or scope of any 1198 Intellectual Property Rights or other rights that might be claimed to 1199 pertain to the implementation or use of the technology described in 1200 this document or the extent to which any license under such rights 1201 might or might not be available; nor does it represent that it has 1202 made any independent effort to identify any such rights. Information 1203 on the procedures with respect to rights in RFC documents can be 1204 found in BCP 78 and BCP 79. 1206 Copies of IPR disclosures made to the IETF Secretariat and any 1207 assurances of licenses to be made available, or the result of an 1208 attempt made to obtain a general license or permission for the use of 1209 such proprietary rights by implementers or users of this 1210 specification can be obtained from the IETF on-line IPR repository at 1211 http://www.ietf.org/ipr. 1213 The IETF invites any interested party to bring to its attention any 1214 copyrights, patents or patent applications, or other proprietary 1215 rights that may cover technology that may be required to implement 1216 this standard. Please address the information to the IETF at 1217 ietf-ipr@ietf.org. 1219 Disclaimer of Validity 1221 This document and the information contained herein are provided on an 1222 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1223 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1224 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1225 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1226 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1227 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1229 Copyright Statement 1231 Copyright (C) The Internet Society (2006). This document is subject 1232 to the rights, licenses and restrictions contained in BCP 78, and 1233 except as set forth therein, the authors retain all their rights. 1235 Acknowledgment 1237 Funding for the RFC Editor function is currently provided by the 1238 Internet Society.