idnits 2.17.1 draft-wakikawa-mobileip-multiplecoa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 Internet-Drafts being working documents. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 243: '... MN MUST reselect primary inte...' RFC 2119 keyword, line 259: '...ed to a P-IF. MN MUST have PCoA all th...' RFC 2119 keyword, line 260: '...goes invalid, MN MUST reselect PCoA fr...' RFC 2119 keyword, line 281: '... distinct interfaces, it MUST select a...' RFC 2119 keyword, line 288: '... SHOULD notify all of them to CN. Ev...' (63 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-00 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '4') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-23 ** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Ryuji Wakikawa 3 INTERNET DRAFT Keisuke Uehara 4 24 June 2003 Thierry Ernst 5 Keio University/WIDE project 7 Multiple Care-of Address Registration on Mobile IPv6 8 draft-wakikawa-mobileip-multiplecoa-01.txt 10 Status of This Memo 12 This document is a submission to the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@sunroof.eng.sun.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This draft proposes extensions of Mobile IPv6 in order to register 37 multiple care-of addresses to a home agent and correspondent nodes. 38 This draft also targets Network Mobility (NEMO). According to the 39 current specification of Mobile IPv6, a mobile node can register only 40 one of care-of addresses as its primary care-of address even if the 41 mobile node has multiple active care-of address. However, it is 42 useful to get Internet access through multiple access media (i.e. 43 care-of addresses) simultaneously in terms of bandwidth, delay, 44 and etc. Our extensions are thus designed to register multiple 45 care-of addresses bound to a single home address to a home agent and 46 correspondent nodes. For doing so, we propose a new identification 47 number for each interface of a mobile node. The mobile node 48 registers a care-of address with the identification number so that 49 the receiver can distinguish the binding. 51 Contents 53 Status of This Memo 1 55 Abstract 1 57 1. Introduction 3 59 2. Multiple Network Interface vs Multiple Care-of Address 5 61 3. Terminology 5 63 4. Protocol Overview 6 65 5. Mobile IPv6 Extension 7 66 5.1. Binding Cache Structure and Management . . . . . . . . . 8 67 5.2. Binding Update Structure and Management . . . . . . . . . 8 68 5.3. Messages Format Changes . . . . . . . . . . . . . . . . . 9 69 5.3.1. CoA InFormation sub-option . . . . . . . . . . . 9 70 5.3.2. Binding Update . . . . . . . . . . . . . . . . . 9 71 5.3.3. Binding Acknowledgment . . . . . . . . . . . . . 10 73 6. Return Routability Procedure 10 75 7. Mobile Node Operation 12 76 7.1. Management of care-of addresses . . . . . . . . . . . . . 12 77 7.2. Management of Multiple Care-of addresses on the interface 13 78 7.3. Sending Binding Update . . . . . . . . . . . . . . . . . 13 79 7.4. Receiving Binding Acknowledgment with CoAINFO sub-option 14 80 7.5. Receiving Binding Refresh Request with CoAINFO sub-option 15 81 7.6. Receiving Binding Error . . . . . . . . . . . . . . . . . 15 82 7.7. De-registration of one of care-of addresses . . . . . . . 15 83 7.8. Movement Detection . . . . . . . . . . . . . . . . . . . 16 85 8. Correspondent Node Operation 16 86 8.1. Selection of care-of address for outgoing packets . . . . 16 87 8.2. How to search the binding cache . . . . . . . . . . . . . 16 88 8.3. Receiving Binding Update . . . . . . . . . . . . . . . . 16 89 8.4. Sending Binding Acknowledgment . . . . . . . . . . . . . 17 90 8.5. Sending Binding Refresh Request . . . . . . . . . . . . . 17 91 8.6. Sending Binding Error . . . . . . . . . . . . . . . . . . 18 93 9. Network Mobility Applicability 18 95 10. Security Consideration 18 96 11. Changes from the version 00 19 98 Acknowledgments 19 100 References 19 102 Authors' Addresses 20 104 1. Introduction 106 Permanent Internet connectivity is required by some applications 107 while a mobile node (MN) moves across several access networks (i.e. 108 ISPs, hotspots, etc). For example, it is desirable to maintain 109 the Internet connectivity while an automobile running on a freeway 110 receives voice or video streaming data from different access network. 112 Unfortunately, there is no network interface assuring global scale 113 connectivity. Therefore, the MN should use various type of network 114 interfaces to obtain wide areas network connectivity [8]. In 115 addition, users should select the most appropriate network interface 116 depending on the visiting network environment, since wireless 117 networks is mutable and less reliable than wired networks and 118 each network interface has different cost, performance, bandwidth, 119 access range, and reliability. A user should also select the most 120 appropriate interface per communication. For example, TCP [7] 121 communication should be transmitted over wireless interface, but UDP 122 communication should be sent over wired interface not to disturb TCP 123 connections. 125 Associating multiple care-of addresses to a home address would 126 enable durable Internet connectivity [9] [1] [10]. For example, 127 when a MN loses its Internet connectivity at one of the interface, 128 it can use the second interface as a backup interface and still 129 keeps connectivity to the network. In addition, the MN can send 130 each communication flow to a distinct network interface. This 131 provides efficient network bandwidth consumption. A user can 132 select the most suitable network interface per application. 133 Correspondent Nodes (CNs) can also re-select a binding of MN to 134 recover communication when one of MN's CoA becomes invalid. To put 135 binding selection policy to each binding, MN can use a binding for 136 specified communication type. If MN does not have enough bandwidth 137 for communications, it can utilize both of bindings to gain network 138 bandwidth. Furthermore, MN may bicast packets through every network 139 interfaces for some flow. 141 IPv6 [2] conceptually allows a node to have several addresses 142 on an interface. On the other hand, according to section 11.5.3 143 of [6], current Mobile IPv6 [6] does not allow a MN to register 144 multiple care-of addresses bound to a single home address. If a MN 145 sends Binding Update (BU) for each care-of addresses , CNs always 146 overwrites the existing binding to the received binding update. It 147 is impossible for a MN to register multiple care-of addresses in CN's 148 binding cache. 150 Mobile IPv6 [6] has mechanisms to manage multiple ``home addresses'' 151 based on home agent's managed prefixes such as mobile prefix 152 solicitation, mobile prefix advertisement. The advantage of using 153 single home address compared to multiple home addresses assigned to 154 each network interface is that applications do not need to be aware 155 of the difference in home addresses. Of course, a MN can assign 156 multiple home addresses per network interfaces, but applications 157 should be aware of the active home address for communication. At 158 the TCP layer, TCP holds the home address as a source address of the 159 communication for connection managements. Thus, applications must 160 reboot to reset the connection information when the the MN changes 161 the active network interface (i.e. change the home address). 163 In this document, we thus propose a new identification number called 164 IFID and a priority value (IFPRI) for each interface to accommodate 165 multiple care-of addresses. We also propose extension of binding 166 cache management to store IFID, new sub-options for binding update 167 to carry IFID. MN assigns an IFID and an IFPRI to either a single 168 or multiple network interfaces bound to a single home address in 169 Mobile IPv6. MN notifies the IFID and the IFPRI to both HA and CN 170 by BU. CN and HA record the IFID and the IFPRI into their binding 171 cache database. Therefore, CNs and HA distinguish multiple care-of 172 addresses by using the IFID. A home address identifies a mobile node 173 itself and the IFID identifies each network interfaces installed in 174 a mobile node. A user of a mobile node may be able to bind some 175 policies to the IFID. The policy is used to divide flow to multiple 176 network interfaces by flow type, port number, or destination address, 177 etc. How to distribute or configure policy is currently out of scope 178 in this draft. 180 The multiple care-of address extensions specified in this draft also 181 target Network Mobility (NEMO) support based on Mobile IPv6 [3]. 182 Our extensions can indeed be applied to either a mobile host 183 (Mobile IPv6) or a mobile router (MR, see [5]). Network Mobility 184 Support must allow multihoming so as to provide robustness, better 185 performance, etc described in [4]. Multihoming include in particular 186 the ability to switch from one egress interface to another. 188 2. Multiple Network Interface vs Multiple Care-of Address 190 There are two cases when a MN has several care-of addresses. 192 - MN uses several physical network interfaces to acquire a care-of 193 address. 195 - MN uses single physical network interface, but it acquires 196 several addresses from the attached network. Since IPv6 allows 197 to have several addresses on single network interface, it is 198 possible to get several global address with a network interface 199 at the attached network. 201 The difference between above two cases is a number of physical 202 network interfaces. This draft basically handles the several network 203 interfaces. To accommodate the second situation, this document 204 treats single interface as MN pseudoly having multiple network 205 interfaces. (i.e. if MN has multiple care-of addresses at the 206 single interface, Mobile IPv6 treats each care-of address is assigned 207 to each pseudo interface.) For example, MN obtained care-of address1 208 and care-of address2 at interface-A, MN treats this like: care-of 209 address1 is assigned to interface-A and care-of address2 is assigned 210 to pseudo-interface-B. If care-of address1 is deleted due to the 211 expiration of router lifetime, MN removes the pseudo interface-B. The 212 more protocol operation is described in the section 7.2. 214 3. Terminology 216 Most of terms used in this draft are defined in [6]. 218 InterFace IDentification number (IFID) 220 The identification number which is used to distinguish 221 each interface on MN. IFID is assigned to each interface, 222 and generated randomly not to duplicate each other. If an 223 interface has multiple care-of addresses, then MN can assign 224 IFID to a pseudo interface. MN has to assign different IFID 225 for each destination node. This is for security policy. If MN 226 uses same IFID to all destination nodes, it will always reveal 227 all interface information to all nodes. MN sometime hides some 228 of interface from specific destination nodes. 230 InterFace PRIority (IFPRI) 232 The priority value can be used to select a care-of address 233 on CN. The care-of address which has the highest priority is 234 the primary care-of address. Lower value indicates higher 235 priority. Zero indicates primary interface. If an interface 236 has multiple care-of addresses, then MN can assign IFPRI to 237 each care-of address. 239 Primary InterFace (P-IF) 241 The interface which is assigned a primary care-of address. 242 Once the primary interface goes invalid due to movements, 243 MN MUST reselect primary interface from set of interfaces 244 installed in MN. 246 Non-Primary InterFace(NP-IF) 248 The interface which is NOT assigned the primary care-of 249 address. 251 Primary care-of address (P-CoA) 253 The primary care-of address is defined as ``the care-of address 254 registered with the MN's home agent is called its ``primary'' 255 care-of address'' in [6]. 257 In this draft, the definition is extended as follows. The 258 care-of address which is primary associated with a home address 259 and is assigned to a P-IF. MN MUST have PCoA all the time. 260 Once PCoA goes invalid, MN MUST reselect PCoA from the multiple 261 care-of addresses that a MN may have at any given time. 263 Non-Primary care-of address (NP-CoA) 265 The care-of address which is NOT selected as primary (i.e. 266 ``non-primary'' CoA). 268 Care-of Address Information sub-option (CoAINFO) 270 The CoA information sub-option is used to notify IFID and IFPRI 271 with BU. 273 Multiple Care-of Addresses Flag (M flag) 275 A flag which indicated a CoAINFO sub-option is included in the 276 BU's mobility option field. 278 4. Protocol Overview 280 We propose a new identification number (IFID) for each interface. 281 Once a MN gets several CoAs on distinct interfaces, it MUST select a 282 primary CoA from active CoAs as specified in Section 11.5.3 of [6]. 284 After the selection, the interface which has the primary CoA becomes 285 the primary interface on the MN. 287 When a MN acquires multiple care-of addresses for a home address, it 288 SHOULD notify all of them to CN. Even when a CoA goes invalid, CN 289 still have another registered CoA for the MN. Thus, CN can switch 290 to an active CoA as soon as it detects CoA's invalidation. CN can 291 detect CoA's invalidation by packets loss or ICMP error messages 292 such as ICMP_UNREACHABLE. If the MN does not have enough bandwidth 293 for outgoing packets, the MN can utilize multiple network interfaces 294 simultaneously, and divide flow to each network interface. 296 The MN registers only its primary CoA to its Home Agent (HA) as the 297 home registration. After the home registration, the MN MAY send BU 298 to CNs through Return Routability (RR) procedure. The MN starts 299 to send HoTI and CoTI for the primary CoA. If the MN has another 300 non-primary CoA, it also sends CoTI for the non-primary CoA which can 301 be assigned to any interface. This CoTI is sent with the non-primary 302 CoA set to the source address field of the IPv6 header. The MN MUST 303 add CoAINFO sub-option containing IFID and IFPRI of the interface 304 which is assigned to the target CoA in each CoTI message. These 305 values are securely notified to CNs by RR operations. After getting 306 HoT and CoT for either primary CoA or non-primary CoA, the MN sends 307 BU with IFID and IFPRI for the CoA which is authenticated by CoT. To 308 register both CoAs to CNs, the MN MUST sends BUs for each CoA. 310 When a CN receives a BU with a CoAINFO sub-option containing an IFID 311 and an IFPRI, it checks binding cache for the home address and the 312 IFID stored in the CoAINFO sub-option. If both are matched, the CN 313 updates the binding with the new CoA (stored in the BU). Otherwise, 314 it creates new binding for the home address and the IFID even if it 315 has already had a binding for the same home address, because the 316 recorded IFID is different from the requesting IFID. 318 Whenever the MN moves and changes the CoA for a given interface, it 319 MUST send BU with the IFID of the changed interface. MN can always 320 update the particular CoA with the IFID. When the MN returns home, it 321 MUST de-register all the bindings by BU which lifetime set to zero 322 regardless of availability of another care-of addresses. When MN 323 detects that the primary interface is attached to the home link, it 324 indicates MN's returning home. 326 5. Mobile IPv6 Extension 328 Mobile IPv6 should be able to manage multiple care-of addresses. The 329 changes are described in this section. 331 5.1. Binding Cache Structure and Management 333 This document requires to have additional items for the binding cache 334 structure, which are 336 - IFID 337 The IFID of the registered care-of address. The IFID is notified 338 by BU sent by MN. The IFID is protected by return routability 339 procedure described in section 6. 341 - IFPRI 342 The IFPRI of the registered care-of address. The priority is 343 notified by BU. Whenever a BU is received, the priority value 344 MUST be overwritten to newest one. The IFPRI is also protected 345 by return routability procedure described in section 6. 347 If a node gets a BU with a CoAINFO defined at 5.3.1, it searches 348 Binding Cache entries with the set of the home address and the IFID. 349 If both does match with the registered binding, the node MUST update 350 the CoA and the IFID into the matched binding. Otherwise, the node 351 MUST register a new binding for the CoA and the IFID, even if there 352 are already the other binding for the MN's home address. 354 5.2. Binding Update Structure and Management 356 This document requires to have additional items for binding update 357 structure, which are 359 - IFID 360 The IFID of the care-of address MUST be recorded in the binding 361 update list. 363 - IFPRI 364 The priority of the care-of address MUST be recorded in the 365 binding update list. 367 If MN has multiple care-of addresses at a time, it SHOULD assign a 368 IFID and a IFPRI to each care-of address. The IFID and the IFPRI 369 should be recorded in the binding update list. MN SHOULD update 370 the value of the IFID periodically not to be discovered by a third 371 person. The value of IFPRI can be changed at any time. 373 5.3. Messages Format Changes 375 5.3.1. CoA InFormation sub-option 377 The CoAINFO sub-option can be included in Binding Update, Binding 378 Acknowledgment, Binding Refresh Request, Binding Error if needed. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type = TBD | Length = 2 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | IF ID | IFPRI | Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 388 Type 389 Type value for CoAINFO will be assigned later. 391 Length 392 The value MUST be always 2. 394 IFID 395 The IFID of the care-of address which is notified by this 396 BU with CoAINFO. 398 IFPRI 399 The IFPRI of the care-of address which is notified by this 400 BU with CoAINFO. 402 Reserved 403 16 bit Reserved field. Reserved field must be set with all 404 0. 406 5.3.2. Binding Update 408 If MN wants to register several CoAs which would be bound to a 409 home address, MN MUST set 'M' flag and include the CoA information 410 sub-option. The sub-option is constructed according to the binding 411 update list. 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Sequence # | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |A|H|L|K|R|M| Reserved | Lifetime | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 . . 420 . Mobility options . 421 . . 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Mobile Router Flag (R) 426 This flag is proposed by the NEMO working group [3]. 428 Multiple Care-of Addresses Flag (M) 429 This flag is used for multiple care-of address registration. 431 Reserved 432 Reserved field is reduced to 11 bits. 434 5.3.3. Binding Acknowledgment 436 The message format of Binding Acknowledgment is not changed, but 437 operations listed below are added in this draft. 439 The receiver who gets binding update with 'M' flag MUST reply BA if 440 'A' flag is set or BU is for home registration. The receiver MUST 441 also reply BA with correspondent error number if it finds some error 442 during processing BU and its sub-option described in section 5.3.2. 444 If a BU has 'M' flag and a CoAINFO sub-option, a CN MUST reply 445 BA containing the CoAINFO sub-option. To include the CoAINFO 446 sub-option, the sender (i.e. MN) can process the BA for the target 447 CoA specified by the CoAINFO sub-option. 449 This document defines new number for 'M' flag handling. 451 1 Successful registration of NP-CoA 453 6. Return Routability Procedure 455 The CoTI and CoT messages transaction must be modified to secure the 456 CoAINFO sub-option. Therefore, this draft describes only CoTI and 457 CoT, because both HoTI and HoT are not modified at all. Processing 458 of HoTI and HoT can be found at [6]. 460 Mobile node Home agent Correspondent node 461 | | 462 | 1b. | 463 | Care-of Test Init(CoTI) | 464 | Src = care-of address | 465 | Dst = correspondent | 466 | Parameters: | 467 | - care-of init cookie | 468 | - care-of address ID | 469 | - care-of address Priority | 470 |---------------------------------------------------->| 471 | | 472 | 2b. | 473 | Care-of Test(CoT) | 474 | Src = correspondent, | 475 | Dst = care-of address | 476 | Parameters: | 477 | - care-of init cookie | 478 | - care-of keygen token | 479 | - care-of nonce index | 480 |<----------------------------------------------------| 481 | | 483 1b. Care-of Test Init 484 The MN sends a Care-of Test Init message to the correspondent 485 node to acquire the care-of keygen token. The contents of this 486 message can be summarized as follows: 488 Src = care-of address 490 Dst = correspondent 492 Parameters: 494 + care-of init cookie 496 + care-of address ID (IFID) 498 + care-of address Priority (IFPRI) 500 The second message conveys the MN's care-of address to the 501 correspondent node. The MN also sends along a care-of init 502 cookie that the correspondent node must return later. The 503 Care-of Test Init message is sent directly to the correspondent 504 node. 506 2b. Care-of Test 507 This message is sent in response to a Care-of Test Init message. 508 The contents of the message are: 510 Src = correspondent 512 Dst = care-of address 514 Parameters: 516 + care-of init cookie 518 + care-of keygen token 520 + care-of nonce index 522 The correspondent node also sends a challenge to the MN's care-of 523 address. When the correspondent node receives the Care-of Test 524 Init message, it generates a care-of keygen token as follows: 526 care-of keygen token = First (64, MAC (Kcn, (care-of address 527 | IFID | IFPRI | nonce))) 529 The keygen token is formed from the first 64 bits of the MAC 530 result, and sent directly to the MN at its care-of address. The 531 care-of init cookie from the from Care-of Test Init message is 532 returned to ensure that the message comes from a node on the 533 route to the correspondent node. 535 The care-of nonce index is provided to identify the nonce used 536 for the care-of keygen token. The home and care-of nonce indices 537 are often the same in the Home and Care-of Test messages. 539 7. Mobile Node Operation 541 7.1. Management of care-of addresses 543 A MN assigns IFPRI to each interface according to user's policy or 544 administrative policy. If the MN has only single interface, it 545 assigns ``zero value'' to the interface as P-IF. 547 A MN also assigns IFID to each interface. The value should be 548 randomly generated and assigned to each interface. If the MN has 549 single interface, assignment of IFID to the interface is not needed 550 until it has multiple interfaces. 552 A MN MUST handle P-CoA normally as described in base Mobile IPv6 553 [6]. For example, ``home registration to HA'' and ``returning home'' 554 is proceeded without any changes to Mobile IPv6 (i.e. same as the 555 section 11.7.1 and the section 11.5.4 of [6]). P-CoA MUST be the 556 care-of address on P-IF all the time. 558 A MN MUST manage multiple NP-CoA per NP-IF. Whenever the MN detects 559 the change of a NP-CoA by the prefix comparison between the NP-CoA 560 and received router advertisements sent by routers, it MUST start 561 appropriate operations such as updating the binding, de-registering 562 the binding, etc. 564 7.2. Management of Multiple Care-of addresses on the interface 566 If MN obtains several care-of address on an interface, MN has to 567 select an address as the P-CoA from the set of addresses. If MN 568 wants to register several care-of address on the same interface, 569 MN has to assign the ID to each of care-of address temporarily and 570 register the address by BU with CoAINFO sub-option. Once the address 571 is deleted from the interface, MN MUST de-register the address by 572 sending BU with lifetime zero and correspond CoAINFO sub-option. The 573 ID assigned to a CoA is available until the CoA is active. Whenever, 574 the CoA changed, the MN MUST de-register the older CoA and the older 575 ID and MUST assign a new ID for the new CoA. 577 7.3. Sending Binding Update 579 When a MN sends a BU to its home agent (i.e. home registration), the 580 MN should choose the P-CoA for home registration. The MN SHOULD NOT 581 register multiple CoAs to the HA with CoAINFO sub-options. The MN 582 SHOULD operate the home registration as Mobile IPv6 described in [6]. 584 When the MN sends a BU to CNs, it MUST decide whether it registers 585 multiple CoAs to the CN or not. However, this decision is out-of 586 scope in this document. 588 - General Mobile IPv6 589 If the MN decides not to register multiple CoAs to the CN, it 590 just starts RR and sends BU using the home-registered P-CoA 591 according to [6]. 593 - RR procedure for P-CoA 594 On the other hand, if the MN need to register multiple CoAs 595 to the CN, the MN first attempts to process registration of 596 its P-CoA to the CN. The MN sends HoTI, and CoTI with CoAINFO 597 sub-option. In the CoAINFO sub-option, the MN puts a randomly 598 generated IFID and a IFPRI set to zero (to indicate primary). 600 These values MUST be recorded into the binding update list. An 601 IFID and an IFPRI for each interface MAY be configured beforehand 602 by users. 604 - Registration of P-CoA to a CN 605 Once the MN receives HoT and CoT from the CN, it prepares 606 for the BU. The BU must be constructed with 'M' flag and 607 contain a CoAINFO sub-option. The detail of BU is described in 608 section 5.3.2. The value of CoAINFO sub-option is copied from 609 the binding update list. Finally, the MN sends the BU to the 610 CN. The MN MUST wait a BA from the CN to confirm successfully 611 registration as described in section 7.4 613 - Registration of NP-CoAs to the CN 614 After registration of the P-CoA, the MN start processes of NP-CoA 615 registration. It sends CoTI with a CoAINFO sub-option and MAY 616 send HoTI as well. Since the MN has already received HoT from 617 the CN, sending HoTI CAN be skipped. When the value of the 618 CoAINFO sub-option for CoT is set, these values MUST be recorded 619 to the binding update list. After receiving CoT, it makes BU 620 including CoAINFO sub-option and 'M' flag. The value of CoAINFO 621 sub-option is copied from the binding update list. The MN MUST 622 wait a BA from the CN as described in section 7.4. The MN repeat 623 this operations for all possible care-of addresses. 625 7.4. Receiving Binding Acknowledgment with CoAINFO sub-option 627 Verification of Binding Acknowledgment is same as Mobile IPv6 628 (section 11.7.3 of [6]). The operation except for the text below 629 is described in the [6]. The operation of sending BA is described 630 in 8.4. 632 If MN sends BU with a CoAINFO sub-option, BA MUST contain the CoAINFO 633 sub-option. If BA does not have the CoAINFO sub-option, the CN might 634 not recognize CoAINFO sub-option. The MN SHOULD stop registering 635 multiple care-of addresses by CoAINFO sub-option. 637 If BA has the CoAINFO sub-option and the success status value (i.e. 638 1), it indicates successful registration of the care-of address which 639 IFID is in the CoAINFO sub-option. 641 If the BA's status code is zero (indicating successfully registration 642 in Mobile IPv6 [6]) regardless of CoAINFO sub-option availability in 643 BA, the MN MAY stop attempting multiple binding registration to the 644 CN. The successful status code is ``1'' on this document, therefore 645 the CN may not registered multiple care-of addresses respectively. 646 (i.e. CN overwrites the existing binding to the received BU) 647 If the status field does not indicate success registration (i.e. 648 more than 128), it SHOULD stop registering the care-of address which 649 IFID is in the CoAINFO sub-option. 651 7.5. Receiving Binding Refresh Request with CoAINFO sub-option 653 Verification of Binding Refresh Request is same as Mobile IPv6 654 (section 11.7.4 of [6]). Operation except for text below is 655 described in the [6]. The operation of Sending Binding Refresh 656 Request (BRR) is described in the section 8.5. 658 If CN receives a BRR with a CoAINFO sub-option, this BRR indicates 659 BRR for the interface of IFID stored in the CoAINFO sub-option. The 660 MN MAY send BU for the care-of address which is assigned to the 661 interface. 663 If BRR does not contain a CoAINFO sub-option and if the MN has 664 the binding update list for the requesting node, the MN sends BU 665 according to the binding update list. On the other had, if the MN 666 does not have any binding update list for the requesting node, the MN 667 sends BU according to the section 7.3. 669 7.6. Receiving Binding Error 671 When a MN receives BE with a CoAINFO sub-option, the BE is for the 672 interface which IFID is stored in the CoAINFO sub-option. Further 673 operations except for the text below are same as [6]. The operation 674 of sending BE is described in the section 8.6. 676 If the message Status field is 2 (unrecognized MH Type value) 677 regardless of CoAINFO sub-option availability, the MN should stop 678 sending CoAINFO sub-option to the CN. Instead, the MN should register 679 only P-CoA to the CN. 681 7.7. De-registration of one of care-of addresses 683 When a MN need to de-register one of care-of address, it sends a BU 684 with a CoAINFO sub-option to the CN. The BU MUST contain the lifetime 685 specified as zero and specify a Care-of address that matches the 686 home address for the binding. The CoAINFO sub-option MUST contain 687 IFID and IFPRI of the target interface. Otherwise, the CN can not 688 determine which binding should be deleted for this de-registration if 689 there are multiple bindings for the home address. 691 If a MN decided to delete all the binding from the CN, it sends 692 normal de-registration BU to the CN (i.e. exclusion of the CoAINFO 693 sub-option from the above operation). see the section 8.3 for 694 details. 696 7.8. Movement Detection 698 If the new visiting network is not the home link, the MN just updates 699 the CoA (either P-CoA or NP-CoA). If one of the interface changes the 700 attached network and gets a different CoA regardless of primary or 701 not, MN must register the new CoA to CNs with a CoAINFO sub-option. 703 Whenever the P-IF is attached to the home link, the MN sends BU for 704 de-registration to the HA and CNs. If the NP-IF is attached to the 705 home link, MN de-register NP-CoAs attached to the information of 706 NP-IF to CNs, but it SHOULD NOT de-register the binding for the P-CoA 707 to the HA and CNs. 709 8. Correspondent Node Operation 711 8.1. Selection of care-of address for outgoing packets 713 If the CN registers multiple care-of addressed for a home address 714 in its binding cache, it can use any of the binding for outgoing 715 communication to the registering MN. 717 The selection of the best CoA is out of scope in the present 718 document. However, the CN MAY decide to choose the best binding by 719 the comparison of each registered priority value. 721 8.2. How to search the binding cache 723 Whenever the CN searches the binding cache for the home address, it 724 SHOULD uses both the home address and an IFID as a key of search if 725 it knows IFID. The CN basically knows an IFID when it receives an 726 CoAINFO sub-option. At the time, the CN MUST look up the binding 727 cache with the home address and the IFID retrieved from the CoAINFO 728 sub-option. 730 If the CN does not know the IFID, the CN search the binding with only 731 the home address as well as base Mobile IPv6. The CN can ignore the 732 knowing IFID, if it does not desire to use. 734 8.3. Receiving Binding Update 736 If the received a BU does not contain a CoAINFO sub-option or does 737 not have 'M' flag set, the processing of the BU is same as [6]. But 738 if the CN has already registered multiple care-of addresses for the 739 home address, the CN MUST overwrite the binding for the home address 740 with the received BU. After receiving the BU which does not contain 741 a CoAINFO sub-option, the CN MUST have only a binding for the home 742 address. 744 The CN MUST validate the BU and the CoAINFO sub-option according 745 to the section 9.5.1 of [6]. If the received a BU contain a 746 CoAINFO sub-option or has 'M' flag set, the receiving node MUST 747 operate additional validation for the BU and the CoAINFO sub-option 748 additionally. 750 If the BU has 'M' flag at the flag field, it MUST contain a CoAINFO 751 sub-option. If it does not contains a CoAINFO sub-option, the CN 752 MUST silently drop the BU. If the CoAINFO sub-option is present, the 753 CN MUST register the IFID and the IFPRI to the MN's binding. 755 If the CN has already registered the binding for the home address and 756 IFID, then it MUST update the care-of address of the binding and the 757 IFPRI. 759 8.4. Sending Binding Acknowledgment 761 After processing the BU described in 8.3, the CN MUST reply BA either 762 when the 'A' bit is set to the BU or when the CN find an error during 763 processing BU described in [6]. 765 If the BU does not contain a CoAINFO sub-option, the CN MUST reply BA 766 according to the section 9.5.4 of [6]. Otherwise, the CN MUST follow 767 the procedure below. 769 If the CN successfully registered the care-of address which 770 identified in CoAINFO sub-option, it returns BA with status set to 771 '1' (Successfully registration of NP-CoA) and the CoAINFO sub-option 772 copied from the BU. 774 If the CN encountered an error during processing BU, it must returns 775 BA with appropriate error number described in [6]. The CN MAY attach 776 the CoAINFO sub-option to notify the dropped interface to the MN. 778 8.5. Sending Binding Refresh Request 780 When a CN notices that the registered binding will expire soon, it 781 SHOULD send BRR. If the registered binding has IFPRI and IFID, the CN 782 SHOULD contain CoAINFO sub-option in BRR. Then, the CN can receive BU 783 with CoAINFO sub-option and update only the target binding. If the 784 registered binding does not have IFPRI and IFID, then the CN sends 785 normal BRR. 787 8.6. Sending Binding Error 789 When a CN receives BU with an CoAINFO sub-option, it verifies the BU 790 according to the [6]. If the CN does not understand either the 'M' 791 flag or CoAINFO sub-option, it MUST return BE to the sender MN with 792 the status specified to '1'(Unrecognized MH Type value). 794 If the CN receives data packets with the home address destination 795 option, it MUST verify the IPv6 source address field. If the source 796 address is not registered in the CN's binding cache, the CN MUST 797 return BE to the sender MN with the status set to zero (Unknown 798 binding for Home Address destination option). Then, the MN MAY send 799 BU (with a CoAINFO sub-option) to register the new binding. 801 9. Network Mobility Applicability 803 This draft can be applied to the basic network mobility support 804 protocol [3] proposed in the NEMO working group. Multihoming is 805 required as R12 (The solution MUST function for multihomed MR and 806 multihomed mobile networks...) in [4]. Since binding managements 807 are same as Mobile IPv6, both a mobile router and a home agent 808 can support this draft to deal with multiple care-of addresses 809 registration in terms of a multihomed mobile router. 811 10. Security Consideration 813 The information of a CoAINFO can be protected by RR procedure. MN 814 adds the CoAINFO in CoTI. CN calculates a CoA keygen token based on 815 the MN's care-of address, the information of the CoAINFO (IFID and 816 IFPRI), and the CN's nonce. CN sends the CoA keygen token by CoT. 817 MN uses the CoA keygen token to calculate the authentication data 818 and puts the data to the authentication data sub-option. CN always 819 verify the information of the CoAINFO by comparison of authentication 820 data sub-option. 822 11. Changes from the version 00 824 - Corrected composition and grammatical errors. 826 - Update the packet format of Binding Update due to R-bit proposed 827 by NEMO basic support. 829 - Clarify to support a NEMO Mobile Router, too. 831 Acknowledgments 833 The authors would like to thank Julien Charbon, Susumu Koshiba, 834 Hiroki Matutani, Koshiro Mitsuya, Masafumi Watari (in alphabetical 835 order), nacm group at KEIO University, and WIDE project for their 836 contributions. 838 References 840 [1] M. Baker, X. Zhao, S. Cheshire, and J. Stone. Supporting 841 mobility in mosquitonet. In Proceedings of the 1996 USENIX 842 Conference, Jan. 1996. 844 [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 845 Specification. Request for Comments (Draft Standard) 2460, 846 Internet Engineering Task Force, December 1998. 848 [3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo 849 Basic Support Protocol (work in progress). Internet Draft 850 (draft-ietf-nemo-basic-support-00), Internet Engineering Task 851 Force, June 2003. 853 [4] T. Ernst. Nemo Mobility Support Goals and Requirements (work in 854 progress). Internet Draft (draft-ietf-nemo-requirements-01), 855 Internet Engineering Task Force, May 2003. 857 [5] T. Ernst and H. Lach. Nemo Mobility Support Terminology (work 858 in progress). Internet Draft (draft-ietf-nemo-terminology-00), 859 Internet Engineering Task Force, May 2003. 861 [6] D. Johnson, C. Perkins, and J. Arkko. Mobility 862 support in IPv6 (work in progress). Internet Draft, 863 (draft-ietf-mobileip-ipv6-23.txt), Internet Engineering Task 864 Force, May 2003. 866 [7] J. Postel. Transmission Control Protocol. Request for Comments 867 (Standard) 793, Internet Engineering Task Force, September 1981. 869 [8] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay 870 networks. Mobile Networks and Applications, 3(4):335--350, 871 1998. 873 [9] R. Wakikawa, K. Uehara, and J. Murai. Multiple Network 874 Interfaces Support by Policy-Based Routing on Mobile IPv6. 875 In The 2002 International Conference on Wireless Networks, 876 ICWN2002, Jul. 2002. 878 [10] X. Zhao, C. Castelluccia, and M. Baker. Flexible network 879 support for mobility. In The Second Annual International 880 Conference on Mobile Computing and Networking, Nov. 1998. 882 Authors' Addresses 884 Ryuji Wakikawa 885 Keio University and WIDE 886 5322 Endo Fujisawa Kanagawa 887 252 JAPAN 888 Phone: +81-466-49-1394 Thierry Ernst 889 EMail: ryuji@sfc.wide.ad.jp Keio University and WIDE 890 Fax: +81-466-49-1395 5322 Endo Fujisawa Kanagawa 891 252 JAPAN 892 Keisuke Uehara Phone: +81-466-49-1394 893 Keio University and WIDE EMail: ernst@sfc.wide.ad.jp 894 5322 Endo Fujisawa Kanagawa Fax: +81-466-49-1395 895 252 JAPAN 896 Phone: +81-466-49-1394 897 EMail: kei@wide.ad.jp 898 Fax: +81-466-49-1395