idnits 2.17.00 (12 Aug 2021) /tmp/idnits1239/draft-wakikawa-mobileip-multiplecoa-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1248. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) ** 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 219: '...a negative value MUST NOT be used. Af...' RFC 2119 keyword, line 222: '...ding Update. A mobile node MAY change...' RFC 2119 keyword, line 240: '... A mobile node MUST have a primary c...' RFC 2119 keyword, line 242: '... node MUST reselect a primary ...' RFC 2119 keyword, line 249: '... MUST re-select a primary inte...' (78 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 the primary interface is attached to the home link. 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-options in this packet. Then, the receiver deletes all the bindings from its binding cache database. On the other hand, if the mobile node wants to delete binding entries respectively, it sends multiple de-registration Binding Updates for all BID (that is all registered care-of addresses). In those Binding Updates, the mobile node MUST store a Binding Unique Identifier sub-option. Only when the care-of address is the primary one and the destination is the home agent, the mobile node also set the 'P' flag in the Binding Unique Identifier sub-option to indicates stop proxying for the mobile node to the home agent. The 'P' flag is valid only when the destination of a Binding Update is a home agent. == Unrecognized Status in 'Category: Individual', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (20 Jun 2005) is 6178 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 1171 looks like a reference -- Missing reference section? '7' on line 1184 looks like a reference -- Missing reference section? '9' on line 1194 looks like a reference -- Missing reference section? '1' on line 1158 looks like a reference -- Missing reference section? '5' on line 1176 looks like a reference -- Missing reference section? '6' on line 1180 looks like a reference -- Missing reference section? '2' on line 1162 looks like a reference -- Missing reference section? '3' on line 1167 looks like a reference -- Missing reference section? '8' on line 1189 looks like a reference -- Missing reference section? '10' on line 1198 looks like a reference -- Missing reference section? '11' on line 1203 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Ryuji Wakikawa 3 INTERNET DRAFT Keisuke Uehara 4 Category: Individual Thierry Ernst 5 Expire:20 Dec 2005 Keio Univ./WIDE 6 Kenichi Nagami 7 INTEC Netcore 8 20 Jun 2005 10 Multiple Care-of Addresses Registration 11 draft-wakikawa-mobileip-multiplecoa-04.txt 13 Status of This Memo 15 This document is a submission to the MIP6 Working Group of the 16 Internet Engineering Task Force (IETF). Comments should be submitted 17 to the mip6@ietf.org mailing list. 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at 31 any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as ``work in progress.'' 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 20, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 According to the current Mobile IPv6 specification, a mobile node 49 may have several care-of addresses, but only one, termed the primary 50 care-of address, can be registered with its home agent and the 51 correspondent nodes. However, for matters of cost, bandwidth, delay, 52 etc, it is useful for the mobile node to get Internet access through 53 multiple access media simultaneously, in which case multiple active 54 IPv6 care-of addresses would be assigned to the mobile node. We thus 55 propose Mobile IPv6 extensions designed to register multiple care-of 56 addresses bound to a single home address instead of the sole primary 57 care-of address. For doing so, a new identification number must be 58 carried in each binding for the receiver to distinguish between the 59 bindings corresponding to the same home address. Those extensions 60 are targeted to NEMO (Network Mobility) Basic Support as well as to 61 Mobile IPv6. 63 Contents 65 Status of This Memo 1 67 Copyright Notice 1 69 Abstract 2 71 1. Introduction 4 73 2. Terminology 6 75 3. Protocol Overview 8 76 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8 77 3.2. Multiple Bindings Management . . . . . . . . . . . . . . 9 78 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . 9 80 4. Mobile IPv6 Extensions 10 81 4.1. Binding Cache Structure and Management . . . . . . . . . 10 82 4.2. Binding Update Structure and Management . . . . . . . . . 10 83 4.3. Messages Format Changes . . . . . . . . . . . . . . . . . 11 84 4.3.1. Binding Unique Identifier sub-option . . . . . . 11 85 4.3.2. Binding Update . . . . . . . . . . . . . . . . . 12 86 4.3.3. Binding Acknowledgment . . . . . . . . . . . . . 12 87 4.4. Dynamic Home Agent Address Discovery . . . . . . . . . . 13 88 4.4.1. DHAAD Request . . . . . . . . . . . . . . . . . . 13 89 4.4.2. DHAAD Reply . . . . . . . . . . . . . . . . . . . 13 90 4.4.3. Home Agent Information Option . . . . . . . . . . 14 92 5. Mobile Node Operation 15 93 5.1. Management of care-of addresses and Binding Unique 94 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.2. Sending Binding Update . . . . . . . . . . . . . . . . . 15 96 5.3. De-registration . . . . . . . . . . . . . . . . . . . . . 16 97 5.4. Using Alternate Care-of Address . . . . . . . . . . . . . 17 98 5.5. Receiving Binding Acknowledgment . . . . . . . . . . . . 17 99 5.6. Receiving Binding Refresh Request . . . . . . . . . . . . 18 100 5.7. Receiving Binding Error . . . . . . . . . . . . . . . . . 18 102 6. Home Agent and Correspondent Node Operation 19 103 6.1. Searching Binding Cache with Binding Unique Identification 104 Number . . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 19 106 6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 21 107 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 21 108 6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 21 110 7. Network Mobility Applicability 22 112 Appendices 23 114 A. A Scenario: Access both Carrier Packet Network and the Internet 23 116 B. Example Configurations 24 118 C. Changes 27 120 References 28 122 Authors' Addresses 29 123 1. Introduction 125 Permanent Internet connectivity is required by some applications 126 while a mobile node moves across several access networks (i.e. 127 ISPs, hotspots, etc). For example, it is desirable to maintain 128 the Internet connectivity while an automobile running on a freeway 129 receives voice or video streaming data from different access 130 networks. Such motivations for multiple points of attachment, and 131 benefits for doing it are discussed at large in [4]. The problem 132 statement of multihomed mobile node is summarized in [7]. 134 Unfortunately, there is no network interfaces assuring global scale 135 connectivity. Therefore, a mobile node should use various type of 136 network interfaces to obtain wide area network connectivity [9]. In 137 addition, users should select the most appropriate network interface 138 depending on a visiting network environment, since wireless networks 139 are mutable and less reliable than wired networks and since each 140 network interface has different cost, performance, bandwidth, access 141 range, and reliability. Users should also be able to select the 142 most appropriate interface per communication type. For example, TCP 143 traffic should be transmitted over the wireless interface, whereas 144 UDP traffic should be transmitted over the wired interface to avoid 145 disturbing TCP connections. 147 Associating multiple care-of addresses to a single home address would 148 allow durable Internet connectivity. For example, when a mobile node 149 loses its Internet connectivity at one of its interface, the second 150 interface can be used as a backup interface therefrom maintaining 151 Internet connectivity. In addition, the mobile node can send each 152 communication flow to a distinct network interface. This provides 153 efficient network bandwidth consumption. A user can select the most 154 suitable network interface per application. Correspondent nodes can 155 also re-select a binding of the mobile node to recover communication 156 when one of mobile node's bindings becomes invalid. To enable a 157 binding selection policy, a mobile node can use the particular 158 binding for specified communication type. If a mobile node does 159 not have enough bandwidth for communications, it can utilize both 160 bindings to gain network bandwidth. Furthermore, a mobile node may 161 bicast packets of a particular flow through all available network 162 interfaces. 164 IPv6 [1] conceptually allows a node to have several addresses on a 165 given interface. Consequently, Mobile IPv6 [5] has mechanisms to 166 manage multiple ``home addresses'' based on home agent's managed 167 prefixes such as mobile prefix solicitation and mobile prefix 168 advertisement. But assigning a single home address to a given 169 network interface is more advantageous than assigning multiple 170 home addresses because applications do not need to be aware of the 171 multiplicity of home addresses. Of course, applications should be 172 aware of the active home address to be used for communicating. At 173 the TCP layer, TCP holds the home address as a source address of 174 the communication for connection management. Applications must be 175 restarted to reset the connection information when the mobile node 176 changes its active network interface (i.e. change the home address). 178 However, according to section 11.5.3 of the Mobile IPv6 specification 179 [5], a mobile node is not allowed to register multiple care-of 180 addresses bound to a single home address. If a mobile node sends 181 Binding Updates for each care-of address, correspondent nodes would 182 always overwrite the care-of address recorded in the binding cache 183 with the one contained in the latest received binding update. It 184 is thus impossible for a mobile node to register multiple care-of 185 addresses in the correspondent node's binding cache. 187 In this document, we thus propose a new identification number called 188 Binding Unique Identification number (BID) for each binding cache 189 entry to accommodate multiple bindings registration. We also propose 190 extension of binding cache management to store the BID and a new 191 sub-option for binding update to carry the BID. The BID is assigned 192 to either the interfaces or care-of addresses bound to a single home 193 address of a mobile node. The mobile node notifies the BID to both 194 its home agent and correspondent nodes by means of a Binding Update. 195 Correspondent nodes and the home agent record the BID into their 196 binding cache. The home address thus identifies a mobile node itself 197 whereas the BID identifies each binding registered by a mobile node. 198 By using the BID, multiple bindings can then be distinguished. 200 A user of a mobile node may be able to bind some policies to a BID. 201 The policy is used to divide flows to multiple network interfaces 202 by flow type, port number, or destination address, etc. How to 203 distribute or configure policies is not within the scope of this 204 document. 206 2. Terminology 208 Terms used in this draft are defined in [5] and [6]. We define or 209 redefine the following ones: 211 Binding Unique Identification number (BID) 213 The BID is an identification number used to distinguish 214 multiple bindings registered by the mobile node. Assignment of 215 distinct BID allows a mobile node to register multiple binding 216 cache entries for a given home address. The BID is generated 217 to register multiple bindings in the binding cache for a given 218 addess in a way it cannot be duplicated with another BID. 219 The zero value and a negative value MUST NOT be used. After 220 being generated by the mobile node, the BID is stored in the 221 Binding Update List and is sent by the mobile node by means of 222 a sub-option of a Binding Update. A mobile node MAY change 223 the value of a BID at any time according to its administrative 224 policy, for instance to protect its privacy. 226 The BID can be assigned to either a care-of address or an 227 interface depending on implementation choices so as to keep 228 using the same BID for the same binding even when the status 229 of the binding is changed. More details can be found in 230 Section 5.1. 232 Primary care-of address 234 In [5], the primary care-of address is defined as ``the care-of 235 address registered with the mobile node's home agent is called 236 its ``primary'' care-of address''. In this present document, 237 the term is refined as ``the care-of address which is primarily 238 associated with a home address''. 240 A mobile node MUST have a primary care-of address all the time. 241 Once the primary care-of address becomes invalid, the mobile 242 node MUST reselect a primary care-of-address from the set of 243 other care-of addresses that it may also own at that time. 245 Primary Interface 247 The interface on which the primary care-of address is assigned. 248 Once the primary interface becomes invalid, the mobile node 249 MUST re-select a primary interface from the set of interfaces 250 installed in the mobile node. 252 Binding Unique Identifier sub-option 254 The Binding Unique Identifier sub-option is used to carry the 255 BID. 257 Multiple Care-of Addresses Flag (B flag) 259 This flag indicates that a Binding Unique Identifier sub-option 260 is included in the Binding Update Mobility Option field. 262 3. Protocol Overview 264 We propose a new identification number to distinguish multiple 265 bindings pertaining to the same home address. The procedures for 266 the mobile node to register multiple bindings are described in the 267 paragraphs below. 269 3.1. Multiple Care-of Addresses Registration 271 Once a mobile node gets several IPv6 global addresses on distinct 272 interfaces, it MUST select a primary care-of address from the active 273 addresses as specified in Section 11.5.3 [5]. After the selection, 274 the interface which has the primary care-of address becomes the 275 primary interface for the mobile node. 277 After selecting the primary care-of address, the mobile node MUST 278 register it with its home agent (home registration). If the mobile 279 node wants to register multiple bindings to its home agent, it MUST 280 generate a BID for the primary care-of address and record it into 281 the binding update list entry. The mobile node then registers its 282 primary care-of address by sending a Binding Update with a Binding 283 Unique Identifier sub-option. The B flag MUST be set in the Flag 284 field of the Binding Update and the BID MUST be put in the Binding 285 Unique Identifier sub-option. After receiving the Binding Update, 286 the home agent verifies the request and records the binding in its 287 binding cache. If the newly defined sub-option is present in the 288 Binding Update, the home agent MUST copy the BID from the Binding 289 Update to the corresponding field in the binding entry. 291 After this home registration, the mobile node SHOULD register the 292 rest of care-of addresses to its Home Agent. Even if there is 293 already an entry for the mobile node, the home agent MUST registers a 294 new binding entry for the BID stored in the Binding Unique Identifier 295 sub-option. The registration process is the same as for the 296 registration of the primary care-of address. The mobile node MUST 297 register multiple care-of addresses independently. 299 If the mobile node wish to register its binding with a correspondent 300 node, it MUST starts return routability operations before sending a 301 Binding Update. The mobile node MUST sends CoTI for each care-of 302 addresses and MUST receive CoT for each care-of addresses. The 303 mobile node also generates a BID for each care-of addresses to 304 register them as individual bindings. The registration step 305 is the same as for the home registration except for calculating 306 authenticator by using Binding Unique Identifier sub-option as well 307 as the other sub-options specified in [5]. 309 3.2. Multiple Bindings Management 311 The BID is used as a search key for a corresponding entry in the 312 binding cache in addition to the home address. When the home agent 313 checks the binding cache database for the mobile node, it searches 314 a corresponding binding entry with the home address and BID of the 315 desired binding. The desired binding can be selected with policy 316 and filter information. The capability of searching the desired 317 binding enables load-sharing and QoS with flow separation. But this 318 selection and flow separation are out of scope in this draft. If 319 there is no desired binding, it search the binding cache database 320 with the home address as well as Mobile IPv6. The first matched 321 binding entry may be found, but it searches the binding cache with 322 the home address as it would for Mobile IPv6 324 If a node has multiple bindings and its packets meant for the 325 mobile node are not delivered correctly, the node can change the 326 binding entry for the mobile node so as to recover the connection 327 immediately. The node can detect a binding invalidation by packets 328 loss or ICMP error messages such as ICMP_UNREACHABLE. This provides 329 redundancy for Mobile IPv6. 331 When one of the care-of addresses is changed, the mobile node sends 332 a Binding Update with the new care-of address and the corresponding 333 BID. The receiver of the Binding Update updates the binding which 334 BID fits the BID contained in the received Binding Unique Identifier 335 sub-option. The mobile node can manage each binding independently 336 owing to BID. 338 If the mobile node decides to register only one binding, it just 339 sends a Binding Update without B flag and without a Binding Unique 340 Identifier sub-option (i.e. normal Binding Update). The receiver 341 of the Binding Update registers only a single binding for the 342 mobile node. If the receiver has multiple bindings, one binding is 343 registered without BID and the rest of bindings are deleted. 345 3.3. Returning Home 347 When the mobile node returns home, there are two situations, since 348 the home agent defends the mobile node's home address by using 349 proxy neighbor advertisement. It is impossible to utilize all the 350 interfaces when one interface is attached to the home link and the 351 others are attached to foreign link. If proxy Neighbor Advertisement 352 for the home address is stopped, packets are always routed to the 353 interface attached to the home link. If proxy is not stopped, 354 packets are never routed to the interface attached to the home link. 356 The first situation is when the primary interface is attached to the 357 home link. In this case, the mobile node MUST de-register all the 358 bindings by sending a Binding Update which lifetime set to zero. The 359 mobile node MAY NOT put any Binding Unique Identifier sub-options 360 in this packet. Then, the receiver deletes all the bindings from 361 its binding cache database. On the other hand, if the mobile node 362 wants to delete binding entries respectively, it sends multiple 363 de-registration Binding Updates for all BID (that is all registered 364 care-of addresses). In those Binding Updates, the mobile node MUST 365 store a Binding Unique Identifier sub-option. Only when the care-of 366 address is the primary one and the destination is the home agent, the 367 mobile node also set the 'P' flag in the Binding Unique Identifier 368 sub-option to indicates stop proxying for the mobile node to the home 369 agent. The 'P' flag is valid only when the destination of a Binding 370 Update is a home agent. 372 The second situation is when a non-primary interface is attached to 373 the home link. The primary care-of address takes precedence over 374 the rest of addresses. The mobile node stops using the interface 375 attached to the home link and keeps using the rest of interfaces 376 attached to foreign links. In this case, the mobile node sends 377 de-registration Binding Update with the Binding Unique Identifier 378 sub-option. The mobile node stores the BID of the binding and MUST 379 NOT set the 'P' flag in the sub-option regardless of home agent or 380 not. Therefore, the receiver of the de-registration Binding Update 381 deletes only the binding entry from the binding cache database. The 382 home agent does not stop proxying neighbor advertisement. 384 4. Mobile IPv6 Extensions 386 In this section are described the changes to allow Mobile IPv6 to 387 manage multiple bindings bound to a same home address. 389 4.1. Binding Cache Structure and Management 391 Additional items are required in the binding cache structure, which 392 are: 394 - BID of the binding cache entry. The BID is notified by the 395 mobile node by means of a Binding Update sub-option. The value 396 MUST be zero if the Binding Update does not contain a BID. 398 4.2. Binding Update Structure and Management 400 Additional items are required for the binding update structure, which 401 are: 403 - BID: MUST be generated whenever the mobile node registers 404 multiple bindings for its home address. 406 - Primary flag: MUST be set if the care-of address is primary. 408 4.3. Messages Format Changes 410 4.3.1. Binding Unique Identifier sub-option 412 The Binding Unique Identifier sub-option is included in Binding 413 Update, Binding Acknowledgment, Binding Refresh Request, Binding 414 Error if needed. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type = TBD | Length = 4 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Binding Unique ID (BID) |P| Reserved | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 424 Type 425 Type value for Binding Unique Identifier will be assigned 426 later. 428 Length 429 The value MUST be always 4. 431 Binding Unique ID (BID) 432 The BID which is assigned to the binding carried in 433 the Binding Update with this sub-option. BID is 16-bit 434 unsigned integer. A value of zero is reserved. 436 Flag 438 Stop Proxy Neighbor Advertisement (P) Flag 440 When this flag is set, the home agent MUST stop 441 proxy neighbor advertisement for a mobile node. 442 This flag is checked only when a Binding Update 443 is for de-registration and the destination of a 444 Binding Update is mobile node's home agent (i.e. 445 home de-registration). Otherwise, this flag MUST be 446 ignored 448 Reserved 449 15 bit Reserved field. Reserved field must be set with all 450 0. 452 4.3.2. Binding Update 454 The 'B' flag MUST be set and a Binding Unique Identifier sub-option 455 MUST be included if the mobile node wants to bind multiple care-of 456 address to a given home address. 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Sequence # | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |A|H|L|K|M|R|B| Reserved | Lifetime | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 . . 465 . Mobility options . 466 . . 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Multiple Care-of Addresses Flag (B) 471 This flag is used for multiple care-of addresses 472 registration. 474 Reserved 475 Reserved field is reduced to 9 bits. 477 4.3.3. Binding Acknowledgment 479 The message format of Binding Acknowledgment is not changed, but 480 operations listed below are added in this draft. 482 A receiver who gets a Binding Update with the 'B' flag set MUST reply 483 with a Binding Acknowledgment if the 'A' flag is also set or in 484 case of a home registration. The receiver MUST also send a Binding 485 Acknowledgment with corresponding error codes if it finds an error 486 while processing the Binding Update and its sub-option described in 487 section 4.3.2. 489 If a Binding Update has the 'B' flag set and a Binding Unique 490 Identifier sub-option is present, the receiver node MUST reply with a 491 Binding Acknowledgment containing the same Binding Unique Identifier 492 sub-option. The mobile node can process the Binding Acknowledgment 493 for the particular care-of address identified by the BID set in the 494 Binding Unique Identifier sub-option. 496 A new number is defined for handling the 'B' flag: 498 - TBD (144) 499 It implies conflicting a regular binding and a binding that has 500 BID in binding cache. The regular binding indicates the binding 501 that does not have BID field. The status value is TBD. 503 4.4. Dynamic Home Agent Address Discovery 505 The Dynamic Home Agent Address Discovery (DHAAD) defined in 506 RFC3775 [5] is extended so that Mobile Nodes or Mobile Routers only 507 register multiple care-of addresses with Home Agents that support 508 multiple care-of addresses registration. 510 However, we do not provide a solution for Mobile Nodes that would 511 like to register multiple care-of addresses only with Correspondant 512 Nodes that support multiple care-of addresses registration. 514 4.4.1. DHAAD Request 516 A new 'B' flag is introduced in the DHAAD Request message in order 517 to discover Home Agents supporting the multiple care-of address 518 registration. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Code | Checksum | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Identifier |R|B| Reserved | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Multiple Care-of Addresses Flag (B) 529 This flag is set when the mobile node wants to discover Home 530 Agents that support multiple care-of addresses registration. 532 4.4.2. DHAAD Reply 534 A new 'B' flag is introduced in the DHAAD Reply message. When a Home 535 Agent receives a DHAAD Request message with the Multiple Care-of 536 Addresses support Flag set, it MUST reply with a list of Home Agents 537 supporting the multiple care-of addresses registration. The 'B' flag 538 MUST be set in the DHAAD Reply. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Code | Checksum | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Identifier |R|B| Reserved | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 + + 549 . . 550 . Home Agent Addresses . 551 . . 552 + + 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Mobile Router Flag (R) 557 This flag is proposed by the NEMO working group [2]. 559 Multiple Care-of Addresses Flag (B) 560 This flag is set when the Home Agents listed in this message 561 support the multiple care-of addresses registration. 563 4.4.3. Home Agent Information Option 565 A new 'B' flag is introduced in the Home Agent Information Option. 566 The home agent SHOULD set the flag if it supports multiple care-of 567 addresses registration. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length |R|B| Reserved | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Home Agent Preference | Home Agent Lifetime | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Mobile Router Flag (R) 578 This flag is proposed by the NEMO working group [2]. 580 Multiple Care-of Addresses Flag (B) 581 This flag is set when the Home Agent supports multiple 582 care-of addresses registration. 584 5. Mobile Node Operation 586 5.1. Management of care-of addresses and Binding Unique Identifier 588 There are two cases when a mobile node has several care-of addresses: 590 - A mobile node uses several physical network interfaces and 591 acquires a care-of address on each of its interfaces. 593 - A mobile node uses a single physical network interface, but 594 multiple prefixes are announced on the link the interface is 595 attached to. Several global addresses are configured on this 596 interface for each of the announced prefixes. 598 The difference between the above two cases is only a number of 599 physical network interfaces and therefore does not matter. The 600 Identification number is used to distinguish multiple bindings so 601 that the mobile node assigns an identification number for each 602 care-of addresses. How to assign an identification number is up to 603 implementors. 605 A mobile node assigns a BID to each care-of address when it wants 606 to simultaneously register with its home address. The value should 607 be generated from a value comprised between 1 to 65535. Zero and 608 negative value can not be taken as a BID. If a mobile node has only 609 one care-of address, the assignment of a BID is not needed until it 610 has multiple care-of addresses to register with. 612 5.2. Sending Binding Update 614 When a mobile node sends a Binding Update to its home agent (i.e. 615 home registration) and the Binding Update is aimed to de-register 616 the binding, the mobile node MUST check whether the care-of address 617 contained in the Binding Update is primary or not. If the care-of 618 address is a primary one, it MUST set the 'P' flag in the Binding 619 Unique Identifier sub-option. More description about the 'P' flag 620 can be found in Section 5.3. 622 When a mobile node sends a Binding Update, it MUST decide whether it 623 registers multiple care-of addresses or not. However, this decision 624 is out-of scope in this document. If a mobile node decides not to 625 register multiple care-of addresses, it completely follows standard 626 Mobile IPv6 [5]. 628 On the other hand, if the mobile node needs to register multiple 629 care-of addresses, it MUST use BIDs all the time. The mobile node 630 sets B flag in a Binding Update and puts a Binding Unique Identifier 631 sub-option into the Option field of the Binding Update. The BID is 632 copied from a Binding Update List to the Binding Unique Identifier 633 sub-option. If the mobile node registers bindings to a correspondent 634 node, it MUST sends multiple CoTI for multiple care-of addresses. 635 After getting CoTs, it sends Binding Updates with the 'B' flag set 636 and a Binding Unique Identifier sub-option for all care-of addresses, 637 one by one. In any case, the mobile node MUST set the 'A' flag in 638 Binding Updates and MUST wait for a Binding Acknowledgment to confirm 639 the registration was successful as described in section 5.5. 641 Note that there is no optimization such as registering multiple 642 care-of addresses by using a single Binding Update, because the 643 current Mobile IPv6 specification does not allow to send multiple 644 bindings by means of a single Binding Update. 646 5.3. De-registration 648 When a mobile node decides to delete all bindings for its home 649 address, it sends a regular de-registration Binding Update (i.e. 650 unset of 'B' flag and exclusion of a Binding Unique Identifier 651 sub-option). See Section 6.2 for details. 653 If a mobile node wants to delete a particular binding from its home 654 agent and correspondent nodes, it follows the operations below. 656 When a mobile node is attached to its home link by one of its network 657 interfaces, it MUST de-register an appropriate binding. If a binding 658 of a primary care-of address becomes invalid after the mobile node 659 returns home, it MUST set the 'P' flag in a Binding Unique Identifier 660 sub-option. Otherwise, the 'P' flag MUST NOT be set. If the 'P' 661 flag is set, the home agent stop proxy neighbor advertisement for the 662 mobile node. The 'P' flag is ignored if the receiver is not the home 663 agent. 665 When the mobile node's primary interface gets attached to the home 666 link (see Figure 3 and Figure 5 in Appendix B), the Mobile Node MUST 667 start de-registration processing to its home agent as indicated in 668 Mobile IPv6. The home agent deletes all bindings for the mobile node 669 and stops intercepting packets meant for the mobile node. Although 670 the mobile node MUST deletes the binding at correspondent nodes 671 as well, the node can still keep the binding of the non-primary 672 interface active at the correspondent nodes. In such case, the 673 mobile node still receives packets at a non-primary interface 674 attached to a foreign link thanks to route optimization. The mobile 675 node also receives packets at the primary interface attached to the 676 home link when correspondent nodes does not use route optimization. 678 On the other hand, when the mobile node's non-primary interface 679 gets attached back to the home link (see Figure 4 in Appendix B), 680 the mobile node MUST delete only the particular binding from its 681 home agent and correspondent nodes. The home agent does not delete 682 all bindings and does not stop proxy neighbor advertisement for the 683 mobile node. Therefore, the mobile node no longer receives packets 684 at the non-primary interface attached to the home link. All packets 685 are routed to other interfaces attached to a foreign link. If the 686 mobile node is eager to receive packets at the non-primary interface 687 at the home link, it MUST re-select the interface as the primary one. 689 5.4. Using Alternate Care-of Address 691 A mobile node can use an alternate care-of address in the following 692 situations. 694 - One care-of address becomes invalid (e.g because the link where 695 it is attached is no longer available) and MUST be deleted. 696 In such case, the mobile node can not sends a Binding Update 697 from the care-of address because the interface's link is lost. 698 The mobile node needs to de-register the remote binding of the 699 care-of address through one of its active care-of addresses. 701 - A mobile node has multiple interfaces, but it wants to sends 702 Binding Updates for all care-of addresses from a specific 703 interface which has wider bandwidth depending on interface's 704 characteristics. A mobile node does not want to send a lot of 705 control messages through an interface which bandwidth is scarce. 707 In these cases, the mobile node sends a Binding Update with both 708 Alternate Care-of Address sub-option and Binding Unique Identifier 709 sub-option. The processing of Alternate Care-of Address sub-option 710 is described in the Mobile IPv6 specification. If there is an 711 Alternate Care-of Address sub-option, the BID in a Binding Unique 712 Identifier sub-option is assigned for the care-of address in the 713 Alternate Care-of Address sub-option. 715 5.5. Receiving Binding Acknowledgment 717 The verification of a Binding Acknowledgment is the same as in Mobile 718 IPv6 (section 11.7.3 of [5]). The operation for sending a Binding 719 Acknowledgment is described in 6.3. 721 If a mobile node sends a Binding Update with a Binding Unique 722 Identifier sub-option, a Binding Acknowledgment MUST have a Binding 723 Unique Identifier sub-option in the Mobility options field. If 724 there is no such sub-option, the originator node of this Binding 725 Acknowledgment might not recognize the Binding Unique Identifier 726 sub-option. The mobile node SHOULD stop registering multiple care-of 727 addresses by using a Binding Unique Identifier sub-option. If the 728 originator is the Home Agent, the mobile node MAY perform DHAAD to 729 discover a new Home Agent supporting the multiple care-of address 730 registration. 732 If a Binding Unique Identifier sub-option is present, the mobile 733 node checks the Status field of the Binding Acknowledgment. If 734 the status code indicates successful registration (below 128), the 735 originator registers a binding information and BID for the mobile 736 node successfully. 738 If the status code is not zero regardless of Binding Unique 739 Identifier sub-option availability in BA, the mobile node proceeds an 740 relevant operations according to the status code. 742 If the status code is 144, the mobile node has already registered a 743 regular binding before sending a Binding Update with a Binding Unique 744 Identifier sub-option. In such case, the mobile node SHOULD stop 745 sending Binding Updates without BID. 747 5.6. Receiving Binding Refresh Request 749 The verification of a Binding Refresh Request is the same as in 750 Mobile IPv6 (section 11.7.4 of [5]). The operation of sending a 751 Binding Refresh Request is described in section 6.4. 753 If a mobile node receives a Binding Refresh Request with a Binding 754 Unique Identifier sub-option, this Binding Refresh Request requests 755 a binding indicated by the BID. The mobile node SHOULD update only 756 the respective binding. The mobile node MUST put a Binding Unique 757 Identifier sub-option into a Binding Update. 759 If no Binding Unique Identifier sub-option is present in a Binding 760 Refresh Request, the mobile node sends a Binding Update according 761 to its Binding Update List for the requesting node. On the other 762 hand, if the mobile node does not have any Binding Update List entry 763 for the requesting node, the mobile node needs to register either 764 a single binding or multiple bindings depending on its binding 765 management policy. 767 5.7. Receiving Binding Error 769 When a mobile node receives a Binding Error with a Binding Unique 770 Identifier sub-option, the message is for a binding indicated by the 771 BID in the Binding Unique Identifier sub-option. Further operations 772 except for the text below are identical as in [5]. The operation for 773 sending BE is described in the section 6.5. 775 When a mobile node receives a Binding Error with Status field set 776 to 2 (unrecognized MH Type value) , it MAY stop trying to register 777 multiple care-of addresses and registers only primary care-of address 778 as performed in Mobile IPv6. 780 6. Home Agent and Correspondent Node Operation 782 6.1. Searching Binding Cache with Binding Unique Identification 783 Number 785 If a correspondent node has multiple bindings for a mobile node 786 in its binding cache database, it can use any of the bindings to 787 communicate with the mobile node. How to select the most suitable 788 binding from the binding cache database is out of scope in this 789 document. 791 Whenever a correspondent node searches a binding cache for a home 792 address, it SHOULD uses both the home address and the BID as the 793 search key if it knows the corresponding BID. Below is an example of 794 multiple bindings for a home address in the binding cache database. 795 If a correspondent node searches the binding with the home address 796 and BID2, it gets binding2 for this mobile node. 798 binding1 [a:b:c:d::EUI care-of address1 BID1] 799 binding2 [a:b:c:d::EUI care-of address2 BID2] 800 binding3 [a:b:c:d::EUI care-of address3 BID3] 802 A correspondent node basically learns the BID when it receives a 803 Binding Unique Identifier sub-option. At the time, the correspondent 804 node MUST look up its binding cache database with the home address 805 and the BID retrieved from Binding Update. If the correspondent 806 node does not know the BID, it searches a binding with only a home 807 address as performed in Mobile IPv6. In such case, the first matched 808 binding is found. But which binding entry is returned for the normal 809 search depends on implementations. If the correspondent node does 810 not desire to use multiple bindings for a mobile node, it can simply 811 ignore the BID. 813 6.2. Receiving Binding Update 815 If a Binding Update has neither 'B' flag set nor a Binding Unique 816 Identifier, the processing of the regular Binding Update is the same 817 as in [5]. But if the receiver already has multiple bindings for the 818 home address, it MUST overwrite all existing bindings for the mobile 819 node with the received binding. As a result, the receiver node MUST 820 have only a binding for the mobile node. If the Binding Update is 821 for de-registration, the receiver MUST delete all existing bindings 822 for the mobile node. 824 On the other hand, if a Binding Update contains a Binding Unique 825 Identifier sub-option or the 'B' flag is set, a receiver node MUST 826 operate additional validations as follows: 828 - A receiver node MUST validate the Binding Update according to 829 section 9.5.1 of [5]. 831 - If the Binding Update has the 'B' flag set at the Flag field, a 832 Binding Unique Identifier sub-option MUST be present in Mobility 833 options field of the Binding Update. 835 - If there is no Binding Unique Identifier sub-option with the 836 'B' flag set, the receiver node MUST silently drop the Binding 837 Update. 839 - If the Binding Unique Identifier sub-option is present, the 840 receiver node MUST process the Binding Update. 842 - If the Lifetime field is not zero, the receiver node registers a 843 binding that includes the BID as a mobile node's binding. 845 * If the receiver does not have any binding for the mobile 846 node, it registers a binding which includes BID field. 848 * If the receiver has a regular binding which does not have 849 BID for the mobile node, it de-registers the regular binding 850 and registers a new binding including BID according to the 851 Binding Update. In this case, the receiver MUST send Binding 852 Acknowledgment with status code set to 144. 854 * If the receiver node has already registered the binding which 855 BID is matched with requesting BID , then it MUST update 856 the binding up-to-date with the Binding Update. Meanwhile, 857 if the receiver does not have a binding entry which BID is 858 matched with the requesting BID, it registers a new binding 859 for the BID. 861 - If Lifetime field is zero, the receiver node deletes the 862 registering binding entry which BID is same as BID sent by the 863 Binding Unique Identifier sub-option. If the receiver node 864 does not have appropriate binding which BID is matched with the 865 Binding Update, it MUST reject this de-registration Binding 866 Update. If the receiver is a Home Agent, it SHOULD also return a 867 Binding Acknowledgement to the mobile node, in which the Status 868 field is set to 133 (not home agent for this mobile node). 870 Note if the mobile node sends multiple Binding Updates with a 871 different BID but for same care-of address (i.e. same home address, 872 same care-of address, and different BID) , the receiver SHOULD 873 register both bindings into its binding cache. 875 6.3. Sending Binding Acknowledgment 877 If a Binding Update does not contain a Binding Unique Identifier 878 sub-option, the receiver, either a correspondent node or a home 879 agent, MUST reply with a Binding Acknowledgment according to section 880 9.5.4 of [5]. Otherwise, whenever the BID sub-option is present, the 881 receiver MUST follow the additional procedure below. The receiver 882 MUST reply with a Binding Acknowledgment whether the 'A' flag is set 883 or not in the Binding Update. 885 If the receiver successfully registers a binding for the BID stored 886 in a Binding Unique Identifier sub-option, it returns a Binding 887 Acknowledgment with Status field set to successful value (0 to 128) 888 and a Binding Unique Identifier sub-option copied from the received 889 Binding Update. If the receiver deletes the existing binding which 890 does not have a BID and registers a new binding for the BID, it MUST 891 return a Binding Acknowledgment with Status field set to '144'. On 892 the other hand, if the node encounters an error during the processing 893 of a Binding Update, it must return a Binding Acknowledgment with an 894 appropriate error number as described in [5]. The node SHOULD put a 895 Binding Unique Identifier sub-option if the BID is available for the 896 Binding Acknowledgment. 898 6.4. Sending Binding Refresh Request 900 When either a correspondent node or Home Agent notices that 901 a registered binding will be expired soon, it SHOULD send a 902 Binding Refresh Request. If the registered binding has BID, the 903 correspondent node SHOULD contain a Binding Unique Identifier 904 sub-option in the Binding Refresh Request. Then, the correspondent 905 node can receive a Binding Update with a Binding Unique Identifier 906 sub-option and can update only the particular binding. If the 907 registered binding does not have BID, then the correspondent node 908 sends a Binding Refresh Request without the sub-option. 910 6.5. Sending Binding Error 912 When a correspondent node sends a Binding Error with Status field 913 set to 2 (Unrecognized MH Type value), it MAY put a Binding Unique 914 Identifier sub-option into Mobility Options field if BID is available 915 in a received binding message. 917 When a correspondent node receives data packets with a home address 918 destination option, it verifies the IPv6 source address field. If 919 the source address is not registered in the correspondent node's 920 binding cache, the correspondent node MUST return a Binding Error 921 to the sender with the status set to zero (Unknown binding for Home 922 Address destination option). The correspondent node can not put a 923 Binding Unique Identifier sub-option, because there is no binding 924 cache entry for the source address. 926 7. Network Mobility Applicability 928 Support of multihomed mobile routers is advocated in the NEMO working 929 group (see R12 ``The solution MUST function for multihomed MR and 930 multihomed mobile networks'' in [3]). 932 Issues regarding mobile routers with multiple interfaces and other 933 multihoming configurations are documented in [8]. 935 Since the binding management mechanisms are the same for a mobile 936 host operating Mobile IPv6 and for a mobile router operating NEMO 937 Basic Support [2], our extensions can also be used to deal with 938 multiple care-of addresses registration sent from a multihomed mobile 939 router. 941 A mobile router MUST NOT use the 'P' flag when its home agent does 942 not use proxy neighbor advertisement to intercept packets destined 943 to the mobile router. This situation occurrs when the home link 944 is configured as a virtual home link as detailed in extended home 945 address described in [10]. 947 A. A Scenario: Access both Carrier Packet Network and the Internet 949 This scheme can be applied to many scenarios such as described 950 in [4]. Additionally, there is a specific scenario where this scheme 951 is specially required. 953 A carrier often provides an independent networks from the Internet. 954 For example, a Japanese carrier, NTT, provides a Flet's network 955 for ADSL and FTTH users. The Flet's network is isolated from the 956 Internet and is independent from the ISP, but can be accessed only 957 from the NTT's ADSL and the FTTH physical lines. 959 Similar services are well expected to mobile wireless services. When 960 a mobile node has a W-CDMA and a 802.11b interfaces with the network 961 topology described in Figure 1, application servers limit connection 962 only from the W-CDMA celluler network. 964 In such case, even if a mobile node is armed with Mobile IPv6, the 965 application servers will reject the connection from 802.11b. If the 966 mobile node intelligently selects the W-CDMA for the application 967 servers, the mobile node can use 802.11b for other traffic. The 968 mobile node simply uses this scheme. 970 +-------------------------+ 971 | +-------------+ | 972 | |appl. servers| | 973 | +------+------+ | 974 +----+ | | | 975 | CN | | service networks | 976 +--+-+ | ---------------- | 977 | | | | 978 +---+------+ | +--+-+ | 979 +------+ Internet |--+---+---+ HA +--+ | 980 802.11b| +----------+ | | +----+ | | 981 CoA2| | | Home Link | 982 +--+--+ | + ---+------ | 983 | MN +=============Access Servers | 984 +-----+ CoA1 | | 985 W-CDMA +-------------------------+ 986 W-CDMA Packet Network 988 Figure 1: Service operated by a combination of a Packet 989 Network and the Internet. 991 B. Example Configurations 993 In this section, we describe typical scenarios when a mobile node has 994 multiple network interfaces and acquires multiple care-of addresses 995 bound to a home address. 997 The home address of the mobile node (MN in figures) is a:b:c:d::EUI. 998 MN has 3 different interfaces and possibly acquires care-of addresses 999 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each 1000 care-of addresses. 1002 Figure 2 depicts the scenario where all interfaces of the mobile node 1003 are attached to foreign links. After binding registrations, the home 1004 agent (HA) and the correspondent node (CN) have the binding entries 1005 listed in Figure 2 in their binding cache database. The mobile node 1006 can utilize all the interfaces. 1008 +----+ 1009 | CN | 1010 +--+-+ 1011 | 1012 +---+------+ +----+ 1013 +------+ Internet |----------+ HA | 1014 | +----+---+-+ +--+-+ 1015 CoA2| | | | Home Link 1016 +--+--+ | | ------+------ 1017 | MN +========+ | 1018 +--+--+ CoA1 | 1019 CoA3| | 1020 +---------------+ 1022 Binding Cache Database: 1023 Home Agent's binding (Proxy neighbor advertisement is active) 1024 binding [a:b:c:d::EUI care-of address1 BID1] 1025 binding [a:b:c:d::EUI care-of address2 BID2] 1026 binding [a:b:c:d::EUI care-of address3 BID3] 1027 Correspondent Node's binding 1028 binding [a:b:c:d::EUI care-of address1 BID1] 1029 binding [a:b:c:d::EUI care-of address2 BID2] 1030 binding [a:b:c:d::EUI care-of address3 BID3] 1032 Figure 2: Multiple Interfaces are attached to Foreign Link 1034 Figure 3 depicts the scenario where the primary interface of MN is 1035 attached to the home link. 1037 After the successful registration of the binding, HA and CN have the 1038 binding entries listed in Figure 3 in their binding cache database. 1039 MN can communicate with the HA through only the primary interface 1040 attached to the home link. On the other hand, the mobile node can 1041 communicate with CN by using route optimization. Even when MN is 1042 attached to the home link, it can still send Binding Updates for 1043 other active care-of addresses (CoA2 and CoA3). If CN has bindings, 1044 packets are routed to each care-of addresses directly. Any packet 1045 arrived at HA are routed to the primary interface. 1047 +----+ 1048 | CN | 1049 +--+-+ 1050 | 1051 +---+------+ +----+ 1052 +------+ Internet |----------+ HA | 1053 | +--------+-+ +--+-+ 1054 CoA2| | | Home Link 1055 +--+--+ | --+---+------ 1056 | MN +========+ | | 1057 +--+--+ | | | 1058 CoA3| +---|-----------+ 1059 +---------------+ 1061 Binding Cache Database: 1062 Home Agent's binding (Proxy neighbor advertisement is inactive) 1063 none 1064 Correspondent Node's binding 1065 binding [a:b:c:d::EUI care-of address2 BID2] 1066 binding [a:b:c:d::EUI care-of address3 BID3] 1068 Figure 3: Primary Interface is attached to Home Link 1070 Figure 4 depicts the scenario where a non-primary interface of a MN 1071 is attached to the home link. 1073 The HA and the CN have the binding entries listed in Figure 4 in 1074 their binding cache database. MN can not utilize the non-primary 1075 interface attached to the home link, because the HA still defends the 1076 home address of the MN by proxy neighbor advertisements. All packets 1077 routed to the home link are intercepted by the HA and tunneled to 1078 the other interfaces attached to the foreign link according to the 1079 binding entries. 1081 Figure 5 depicts the scenario where primary and a non-primary 1082 interface of MN are attached to the home link. The HA and the CN 1083 +----+ 1084 | CN | 1085 +--+-+ 1086 | 1087 +---+------+ +----+ 1088 +------+ Internet |----------+ HA | 1089 | +----+-----+ +--+-+ 1090 CoA2| | | Home Link 1091 +--+--+ | --+---+------ 1092 | MN +========+ | 1093 +--+--+ CoA1 | 1094 | | 1095 +---------------------------+ 1097 Binding Cache Database: 1098 Home Agent's binding (Proxy neighbor advertisement is active) 1099 binding [a:b:c:d::EUI care-of address1 BID1] 1100 binding [a:b:c:d::EUI care-of address2 BID2] 1101 Correspondent Node's binding 1102 binding [a:b:c:d::EUI care-of address1 BID1] 1103 binding [a:b:c:d::EUI care-of address2 BID2] 1105 Figure 4: One of Non-Primary Interfaces is attached to Home Link 1107 have the binding entries listed in Figure 5 in their binding cache 1108 database. The MN can not use the non-primary interface attached to a 1109 foreign link unless a CN has a binding for the non-primary interface. 1110 All packets which arrive at the HA are routed to one of interfaces 1111 attached to the MN. The HA decides an interface anyway, for example, 1112 by using policy and filters. 1114 +----+ 1115 | CN | 1116 +--+-+ 1117 | 1118 +---+------+ +----+ 1119 +------+ Internet |----------+ HA | 1120 | +----------+ +--+-+ 1121 CoA2| | Home Link 1122 +--+--+ --+----+---+------ 1123 | MN +===================+ | 1124 +--+--+ | 1125 | | 1126 +---------------------------+ 1128 Binding Cache Database: 1129 Home Agent's binding (Proxy neighbor advertisement is inactive) 1130 none 1131 Correspondent Node's binding 1132 binding [a:b:c:d::EUI care-of address2 BID2] 1134 Figure 5: Primary and Non-Primary Interfaces are 1135 attached to Home Link 1137 C. Changes 1139 - Updating packet formats. M flag is re-named to B flag as 1140 suggested by [11]. 1142 - Adding extended operations for DHAAD packets in terms of finding 1143 Home Agent supporting multiple CoAs registration. 1145 Acknowledgments 1147 The authors would like to thank Julien Charbon, Susumu Koshiba, 1148 Hiroki Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, 1149 Masafumi Watari (in alphabetical order), the Jun Murai Lab. at KEIO 1150 University, and WIDE project for their contributions. 1152 The authors acknowledge Romain Kuntz from Keio University and WIDE 1153 for providing the texts of the DHAAD operation and reviewing this 1154 draft. 1156 References 1158 [1] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 1159 Specification. Request for Comments (Draft Standard) 2460, 1160 Internet Engineering Task Force, December 1998. 1162 [2] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert. 1163 Network Mobility (NEMO) Basic Support Protocol. Request for 1164 Comments (Standards Track) 3963, Internet Engineering Task 1165 Force, January 2005. 1167 [3] T. Ernst. Network Mobility Support Goals and Requirements (work 1168 in progress). Internet Draft (draft-ietf-nemo-requirements-04), 1169 Internet Engineering Task Force, February 2005. 1171 [4] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng, 1172 K. Kuladinithi, and T. Noel. Goals and Benefits of Multihoming 1173 (work in progress, draft-ernst-generic-goals-and-benefits-01). 1174 Internet Draft, Internet Engineering Task Force, February 2005. 1176 [5] D. Johnson, C. Perkins, and J. Arkko. Mobility support in 1177 IPv6. Request for Comments (Standards Track) 3775, Internet 1178 Engineering Task Force, June 2004. 1180 [6] J. Manner and M. Kojo. Mobility Related Terminology. Request 1181 for Comments (Informational) 3753, Internet Engineering Task 1182 Force, June 2004. 1184 [7] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, and C. Ng. 1185 Problem Statement for multihomed Mobile Nodes (work in progress, 1186 draft-montavont-mobileip-multihoming-pb-statement-03.txt). 1187 Internet Draft, Internet Engineering Task Force, January 2005. 1189 [8] C. Ng, E. Paik, and T. Ernst. Analysis of Multihoming 1190 in Network Mobility Support (work in progress, 1191 draft-ietf-nemo-multihoming-issues-xx.txt). Internet 1192 Draft, Internet Engineering Task Force, July 2004. 1194 [9] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay 1195 networks. Mobile Networks and Applications, 3(4):335--350, 1196 1998. 1198 [10] P. Thubert, R. Wakikawa, and V. Devarapalli. NEMO Home 1199 Network models (work in progress). Internet Draft 1200 (draft-ietf-nemo-home-network-models-03.txt), Internet 1201 Engineering Task Force, March 2005. 1203 [11] P. Valitalo. Multihoming of (1,1,*) configured 1204 networks in Network Mobility Support (work in progress, 1205 draft-valitalo-nemo-multihoming-00.txt). Internet Draft, 1206 Internet Engineering Task Force, March 2005. 1208 Authors' Addresses 1210 Ryuji Wakikawa Thierry Ernst 1211 Keio University and WIDE Keio University and WIDE 1212 5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa 1213 252 JAPAN 252 JAPAN 1214 Phone: +81-466-49-1394 Phone: +81-466-49-1394 1215 EMail: ryuji@sfc.wide.ad.jp EMail: ernst@sfc.wide.ad.jp 1216 Fax: +81-466-49-1395 Fax: +81-466-49-1395 1218 Keisuke Uehara Kenichi Nagami 1219 Keio University and WIDE INTEC NetCore 1220 5322 Endo Fujisawa Kanagawa 1-3-3 Shinsuna Koto-ku Tokyo 1221 252 JAPAN 135-0075 JAPAN 1222 Phone: +81-466-49-1394 Phone: +81-3-5665-5069 1223 EMail: kei@wide.ad.jp EMail: nagami@inetcore.com 1224 Fax: +81-466-49-1395 FAX : +81-3-5665-5094 1226 Intellectual Property Statement 1228 The IETF takes no position regarding the validity or scope of any 1229 Intellectual Property Rights or other rights that might be claimed to 1230 pertain to the implementation or use of the technology described in 1231 this document or the extent to which any license under such rights 1232 might or might not be available; nor does it represent that it has 1233 made any independent effort to identify any such rights. Information 1234 on the procedures with respect to rights in RFC documents can be 1235 found in BCP 78 and BCP 79. 1237 Copies of IPR disclosures made to the IETF Secretariat and any 1238 assurances of licenses to be made available, or the result of an 1239 attempt made to obtain a general license or permission for the 1240 use of such proprietary rights by implementers or users of this 1241 specification can be obtained from the IETF on-line IPR repository at 1242 http://www.ietf.org/ipr. 1244 The IETF invites any interested party to bring to its attention any 1245 copyrights, patents or patent applications, or other proprietary 1246 rights that may cover technology that may be required to implement 1247 this standard. Please address the information to the IETF at 1248 ietf-ipr@ietf.org. 1250 Disclaimer of Validity 1252 This document and the information contained herein are provided on 1253 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1254 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1255 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1256 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1257 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1260 Copyright Statement 1262 Copyright (C) The Internet Society (2005). This document is subject 1263 to the rights, licenses and restrictions contained in BCP 78, and 1264 except as set forth therein, the authors retain all their rights. 1266 Acknowledgment 1268 Funding for the RFC Editor function is currently provided by the 1269 Internet Society.