idnits 2.17.1 draft-ietf-monami6-multiplecoa-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (April 30, 2008) is 5840 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: 'MCOA PROHIBITED' is mentioned on line 976, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1111, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1194, but not defined == Unused Reference: 'RFC-2464' is defined on line 1539, but no explicit reference was found in the text == Unused Reference: 'RFC-4980' is defined on line 1560, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-02 == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-04 -- No information found for draft-ietf-mext-v4traversal - is the name correct? == Outdated reference: A later version (-02) exists of draft-lim-mext-multiple-coa-verify-01 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa (Ed.) 3 Internet-Draft Toyota ITC/Keio Univ. 4 Intended status: Standards Track T. Ernst 5 Expires: November 1, 2008 INRIA 6 K. Nagami 7 INTEC NetCore 8 V. Devarapalli (Ed.) 9 Wichorus 10 April 30, 2008 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-07.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 1, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 According to the current Mobile IPv6 specification, a mobile node may 47 have several care-of addresses, but only one, called the primary 48 care-of address, that can be registered with its home agent and the 49 correspondent nodes. However, for matters of cost, bandwidth, delay, 50 etc, it is useful for the mobile node to get Internet access through 51 multiple accesses simultaneously, in which case the mobile node would 52 be configured with multiple active IPv6 care-of addresses. This 53 document proposes extensions to the Mobile IPv6 protocol to register 54 and use multiple care-of addresses. The extensions proposed in this 55 document can be used by Mobile Routers using the NEMO (Network 56 Mobility) Basic Support protocol as well. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12 67 4.1. Binding Cache Structure and Binding Update List . . . . . 12 68 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 12 69 4.3. New Status Values for Binding Acknowledgement . . . . . . 14 71 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 16 72 5.1. Management of Care-of Address(es) and Binding 73 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 16 74 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 16 75 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 17 76 5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 17 77 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 18 78 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 18 79 5.6.1. Using only Interface attached to the Home Link . . . . 19 80 5.6.2. Using only Interface attached to the Visited Link . . 19 81 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 19 82 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24 83 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25 84 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 25 86 6. Home Agent and Correspondent Node Operation . . . . . . . . . 27 87 6.1. Searching Binding Cache with Binding Identifier . . . . . 27 88 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 27 89 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 28 90 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 30 91 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 30 93 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32 95 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33 96 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33 97 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 34 99 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35 100 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35 101 9.2. Transport Mode IPsec protected messages . . . . . . . . . 36 102 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36 103 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 36 104 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 110 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 114 13.2. Informative References . . . . . . . . . . . . . . . . . . 41 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 117 Intellectual Property and Copyright Statements . . . . . . . . . . 44 119 1. Introduction 121 A mobile node may use various types of network interfaces to obtain 122 durable and wide area network connectivity. This is increasingly 123 become true with mobile nodes having multiple interfaces such as 124 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for 125 and benefits of using multiple points of attachment are discussed in 126 [ID-MOTIVATION]. When a mobile node with multiple interfaces uses 127 Mobile IPv6 [RFC-3775] for mobility management, it cannot use its 128 multiple interfaces to send and receive packets while taking 129 advantage of session continuity provided by Mobile IPv6. This is 130 because Mobile IPv6 allows the mobile node to only bind one care-of 131 address at a time with its home address. 133 This document proposes extensions to Mobile IPv6 to allow a mobile 134 node to register multiple care-of addresses for a home address and 135 create multiple binding cache entries. A new Binding Identification 136 (BID) number is created for each binding the mobile node wants to 137 create and sent in the binding update. The home agent that receives 138 this Binding Update creates separate binding for each BID. The BID 139 information is stored in the corresponding binding cache entry. The 140 BID information can now be used to identify individual bindings. The 141 same extensions can also be used in Binding Updates sent to the 142 correspondent nodes. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC-2119]. 150 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 151 [RFC-4885]. In addition or in replacement of these, the following 152 terms are defined or redefined: 154 Binding Identification number (BID) 156 The BID is an identification number used to distinguish multiple 157 bindings registered by the mobile node. Assignment of distinct 158 BIDs allows a mobile node to register multiple binding cache 159 entries for a given home address. The BID MUST be unique for a 160 binding to a specific care-of address for a given home address and 161 care-of address pair. Zero and negative values MUST NOT be used. 162 Each BID is generated and managed by a mobile node. The BID is 163 stored in the Binding Update List and is sent by the mobile node 164 in the Binding Update. A mobile node MAY change the value of a 165 BID at any time according to its administrative policy, for 166 instance to protect its privacy. An implementation must carefully 167 assign the BID so as to keep using the same BID for the same 168 binding even when the status of the binding is changed. More 169 details can be found in Section 5.1. 171 Binding Identifier Mobility Option 173 The Binding Identifier mobility option is used to carry the BID 174 information. 176 Bulk Registration 178 A mobile node can register multiple bindings at once by sending a 179 single Binding Update. A mobile node can also replace some or all 180 the bindings available at the home agent with the new bindings by 181 using the bulk registration. Bulk registration is supported only 182 for home registration (i.e. with the home agent) as explained in 183 Section 5.4. A mobile node MUST NOT perform bulk registration 184 with a correspondent node. 186 3. Protocol Overview 188 A new extension called the Binding identification number (BID) is 189 introduced to distinguish between multiple bindings pertaining to the 190 same home address. If a mobile node configures several IPv6 global 191 addresses on one or more of its interfaces, it can register these 192 addresses with its home agent as care-of addresses. If the mobile 193 node wants to register multiple bindings, it MUST generate a BID for 194 each care-of address and store the BID in the binding update list. A 195 mobile node can manipulate each binding independently by using the 196 BIDs. The mobile node then registers its care-of addresses by 197 sending a Binding Update with a Binding Identifier mobility option. 198 The BID is included in the Binding Identifier mobility option. After 199 receiving the Binding Update with a Binding Identifier mobility 200 option, the home agent MUST copy the BID from the Binding Identifier 201 mobility option to the corresponding field in the binding cache 202 entry. If there is an existing binding cache entry for the mobile 203 node, and if the BID in the Binding Update does not match the one 204 with the existing entry, the home agent MUST create a new binding 205 cache entry for the new care-of address and BID. The mobile node can 206 register multiple care-of addresses either independently in 207 individual Binding Updates or multiple at once in a single Binding 208 Update. 210 If the mobile host wishes to register its binding with a 211 correspondent node, it must perform return routability operations. 212 This includes managing a Care-of Keygen token per care-of address and 213 exchanging CoTi and CoT message with the correspondent node for each 214 care-of address. The mobile node MAY use the same BID that it used 215 with the home agent for a particular care-of address. For protocol 216 simplicity, bulk registration to correspondent nodes is not supported 217 in this document. This is because the Return Routability mechanism 218 introduced in [RFC-3775] cannot be easily extended to verify multiple 219 care-of addresses stored in a single Binding Update. 221 Figure 1 illustrates the configuration where the mobile node obtains 222 multiple care-of addresses at foreign links. The mobile node can 223 utilize all the care-of address. In Figure 1, the home address of 224 the mobile node (MN) is a:b:c:d::EUI. The mobile node has 3 225 different interfaces and possibly acquires care-of addresses 1-3 226 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to 227 each care-of address. 229 +----+ 230 | CN | 231 +--+-+ 232 | 233 +---+------+ +----+ 234 +------+ Internet |----------+ HA | 235 | +----+---+-+ +--+-+ 236 CoA2| | | | Home Link 237 +--+--+ | | ------+------ 238 | MN +========+ | 239 +--+--+ CoA1 | 240 CoA3| | 241 +---------------+ 243 Binding Cache Database: 244 home agent's binding (Proxy neighbor advertisement is active) 245 binding [a:b:c:d::EUI care-of address1 BID1] 246 binding [a:b:c:d::EUI care-of address2 BID2] 247 binding [a:b:c:d::EUI care-of address3 BID3] 248 correspondent node's binding 249 binding [a:b:c:d::EUI care-of address1 BID1] 250 binding [a:b:c:d::EUI care-of address2 BID2] 251 binding [a:b:c:d::EUI care-of address3 BID3] 253 Figure 1: Multiple Care-of Address Registration 255 If the mobile node decides to act as a regular mobile node compliant 256 with [RFC-3775], it sends a Binding Update without any Binding 257 Identifier mobility options. The receiver of the Binding Update 258 deletes all the bindings registering with a BID and registers only a 259 single binding for the mobile node. Note that the mobile node can 260 continue using the BID even if it has only a single binding that is 261 active. 263 Binding cache lookup is done based on the home address and BID 264 information. This is different from RFC 3775, where only the home 265 address is used for binding cache lookup. The binding cache lookup 266 may also involve policy or flow filters in cases where some policy or 267 flow filters are used to direct certain packets or flows to a 268 particular care-of address. The binding cache lookup using policy or 269 flow filters is out of scope for this document. In case the binding 270 cache lookup, using the combination of home address and BID, does not 271 return a valid binding cache entry, the home agent MAY perform 272 another lookup based on only the home address. This is 273 implementation dependent and configurable on the home agent. 275 The mobile node may return to the home link through one of its 276 interfaces. There are three options possible for the mobile node 277 when its returns home. Section 5.6 describes the returning home 278 procedures in more detail. 280 1. The mobile node uses only the interface with which it attaches to 281 the home link. This is illustrated in Figure 2. It de-registers 282 all bindings with the home agent related to all care-of 283 addresses. The interfaces still attached to the visited link(s) 284 are no longer going to be receiving any encapsulated traffic from 285 the home agent. On the other hand, the mobile node can continue 286 communicating with the correspondent node from the other 287 interfaces attached to foreign links by using route optimization. 288 Even if the mobile node is attached to the home link, it can 289 still send Binding Updates for other active care-of addresses 290 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 291 node has bindings, packets are routed to each Care-of Addresses 292 directly. 294 +----+ 295 | CN | 296 +--+-+ 297 | 298 +---+------+ +----+ 299 +------+ Internet |----------+ HA | 300 | +----+-----+ +--+-+ 301 CoA2| | | Home Link 302 +--+--+ | --+---+------ 303 | MN +========+ | 304 +--+--+ CoA1 | 305 | | 306 +---------------------------+ 308 Binding Cache Database: 309 home agent's binding 310 none 311 correspondent node's binding 312 binding [a:b:c:d::EUI care-of address1 BID1] 313 binding [a:b:c:d::EUI care-of address2 BID2] 315 Figure 2: Using only Interface Attached to Home Link 317 2. The mobile node uses only the interfaces still attached to the 318 visited link(s) as shown in Figure 3. The interface with which 319 the mobile node attaches to the home link is not used. 321 +----+ 322 | CN | 323 +--+-+ 324 | 325 +---+------+ +----+ 326 +------+ Internet |----------+ HA | 327 | +----+-----+ +--+-+ 328 CoA2| | | Home Link 329 +--+--+ | --+---+------ 330 | MN +========+ | 331 +--+--+ CoA1 | 332 | | 333 +---------------------------+ 334 (Disable interface) 336 Binding Cache Database: 337 home agent's binding 338 binding [a:b:c:d::EUI care-of address1 BID1] 339 binding [a:b:c:d::EUI care-of address2 BID2] 340 correspondent node's binding 341 binding [a:b:c:d::EUI care-of address1 BID1] 342 binding [a:b:c:d::EUI care-of address2 BID2] 344 Figure 3: Using only interface attached to the visited link 346 3. The mobile node may simultaneously use both the interface 347 attached to the home link and the interfaces still attached to 348 the visited link(s) as shown in Figure 4. There are two possible 349 topologies depending on whether the home agent is only router on 350 the home link or not. The operation of Neighbor Discovery [RFC- 351 2461] is different in the two topologies. The home agent and the 352 correspondent node have the binding entries listed in Figure 4 in 353 their binding cache database in both topologies. The home agent 354 also knows that the mobile node has attached to the home link. 355 All the traffic from the Internet is intercepted by the home 356 agent first and routed to either the interface attached to the 357 home link or the one of the foreign links. How the home agent 358 decides to route a particular flow to the interface attached to 359 the home link or foreign link is out of scope in this document. 361 Topology-a) 362 +----+ 363 | CN | 364 +--+-+ 365 | 366 +---+------+ +----+ 367 +------+ Internet |----------+ HA | 368 | +----+-----+ +--+-+ 369 CoA2| | | Home Link 370 +--+--+ | --+---+------ 371 | MN +========+ | 372 +--+--+ CoA1 | 373 | | 374 +---------------------------+ 376 Topology-b) 377 +----+ 378 | CN | 379 +--+-+ 380 | 381 +---+------+ Router +----+ 382 +------+ Internet |-------R | HA | 383 | +----+-----+ | +--+-+ 384 CoA2| | | | Home Link 385 +--+--+ | --+-+-------+------ 386 | MN +========+ | 387 +--+--+ CoA1 | 388 | | 389 +---------------------------+ 391 Binding Cache Database: 392 home agent's binding 393 binding [a:b:c:d::EUI care-of address1 BID1] 394 binding [a:b:c:d::EUI care-of address2 BID2] 395 correspondent node's binding 396 binding [a:b:c:d::EUI care-of address1 BID1] 397 binding [a:b:c:d::EUI care-of address2 BID2] 399 Figure 4: Simultaneous Home and Visited Link Operation 401 4. Mobile IPv6 Extensions 403 This section summarizes the extensions to Mobile IPv6 necessary for 404 manage multiple bindings. 406 4.1. Binding Cache Structure and Binding Update List 408 The BID is required to be stored in the binding cache and binding 409 update list structure. 411 The sequence number value SHOULD be shared among all the binding 412 update list entries related to binding updates sent to a particular 413 home agent or correspondent node. Whenever a mobile node sends 414 either individual or bulk binding update, the sequence number is 415 incremented. On the other hand, if a mobile node manages an 416 individual sequence value per binding update list, a mobile node 417 SHOULD carefully select the sequence number value for the bulk 418 binding update. This is because all the bulk-registered bindings use 419 the same Sequence Number specified in the Binding Update. If each 420 binding uses different sequence number, a mobile node MUST use the 421 largest sequence number from the Binding Update list entries used for 422 the bulk registration. If the mobile node cannot select a sequence 423 number for all the bindings due to sequence number out of window, it 424 MUST NOT use the bulk registration for the binding whose sequence 425 number is out of window. A separate Binding Update should be sent 426 for the binding. 428 4.2. Binding Identifier Mobility Option 430 The Binding Identifier mobility option is included in the Binding 431 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 432 Test Init and Care-of Test message. 434 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type = TBD | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Binding ID (BID) | Status |O|H| Reserved | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 441 + + 442 : IPv4 or IPv6 care-of address (CoA) : 443 + + 444 +---------------------------------------------------------------+ 446 Figure 5: BID Mobility Option 448 Type 450 Type value for Binding Identifier is TBD 452 Length 454 8-bit unsigned integer. Length of the option, in octets, 455 excluding the Type and Length fields. It MUST be set to either 4, 456 12, or 20 depending on the care-of address field. When the 457 care-of address is not carried by this option, the length value 458 MUST be set to 4. If the IPv4 care-of address is stored in the 459 care-of address field, the length MUST be 12. Otherwise, the 460 Length value MUST be set to 20 for IPv6 care-of address. 462 Binding ID (BID) 464 The BID which is assigned to the binding indicated by the care-of 465 address in the Binding Update or the BID mobility option. The BID 466 is a 16-bit unsigned integer. The value of zero is reserved and 467 MUST NOT be used. 469 Status 471 When the Binding Identifier mobility option is included in a 472 Binding Acknowledgement, this field overwrites the status field in 473 the Binding Acknowledgement. If this field is zero, the receiver 474 MUST use the registration status stored in the Binding 475 Acknowledgement message. This Status field is also used to carry 476 error information related to the care-of address test in the 477 Care-of Test message. The status is 8-bit unsigned integer. The 478 possible status codes are the same as the status codes of Binding 479 Acknowledgement. 481 Overwrite (O) flag 483 When this flag is set, a mobile node requests the recipient to 484 replace all the bindings to binding entries stored in a Binding 485 Update. 487 Simultaneous Home and Foreign Binding (H) flag 489 This flag indicates that the mobile node registers multiple 490 bindings to the home agent while is attached to the home link. 491 This flag is valid only for a Binding Update sent to the home 492 agent. 494 Reserved 496 5 bits Reserved field. The reserved field MUST be zero. 498 Care-of Address 500 This field has the variable length depending on the specified 501 flags. Either IPv4 or IPv6 care-of address for the corresponding 502 BID can be stored in this field. This field MUST NOT be used if a 503 Binding Identifier mobility option is included in any other 504 message other than a Binding Update. 506 4.3. New Status Values for Binding Acknowledgement 508 New status values for the status field in a Binding Acknowledgement 509 are defined for handling the multiple Care-of Addresses registration: 511 MCOA NOTCOMPLETE (TBD < 128) 513 In bulk registration, not all the binding identifier mobility 514 option are successfully registered. Some of them are rejected. 515 The error status value of the failed mobility option is 516 individually stored in the status field of the binding identifier 517 mobility option. 519 MCOA RETURNHOME WO/NDP (TBD < 128) 521 When a mobile node returns home, it MUST NOT use NDP for the home 522 address on the home link. This is explained in more detail in 523 Section 5.6 525 MCOA MALFORMED (TBD more than 128) 527 Registration failed because Binding Identifier mobility option was 528 not formatted correctly. 530 MCOA BID CONFLICT (TBD more than 128) 532 The home agent cannot cache both a regular binding and a BID 533 extended binding simultaneously. It returns this status value 534 when the received binding conflicts with the existing binding 535 cache entry(ies). 537 MCOA PROHIBITED(TBD more than 128) 538 It implies the multiple care-of address registration is 539 administratively prohibited. 541 MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) 543 Bulk binding registration is not supported. 545 5. Mobile Node Operation 547 5.1. Management of Care-of Address(es) and Binding Identifier(s) 549 There are two cases when a mobile node might acquire several care-of 550 addresses. Note that a mixture of the two cases is also possible. 552 1. A mobile node may be using several physical network interfaces 553 and acquires a care-of address on each of its interfaces. 555 2. A mobile node uses a single physical network interface, but 556 receives advertisements for multiple prefixes on the link the 557 interface is attached to. This will result in the mobile node 558 configuring several global addresses on the interface from each 559 of the announced prefixes. 561 The difference between the above two cases is only in the number of 562 physical network interfaces and therefore irrelevant in this 563 document. What is of significance is the fact that the mobile node 564 has several addresses it can use as care-of addresses. 566 A mobile node assigns a BID to each care-of address when it wants to 567 register them simultaneously with its home address. The BID MUST be 568 unique for a given home address and care-of address pair. The value 569 should be an integer between 1 and 65535. Zero and negative values 570 MUST NOT be used as BIDs. If a mobile node has only one care-of 571 address, the assignment of a BID is not needed until it has multiple 572 care-of addresses to register with, at which time all of the care-of 573 addresses MUST be mapped to BIDs. 575 5.2. Return Routability: Sending CoTI and Receiving CoT 577 When a mobile node wants to register multiple care-of address with a 578 correspondent node, it MUST have the valid Care-of Keygen token per 579 care-of address. The mobile node needs only one Home Keygen token 580 for its home address. 582 The mobile node MUST include a Binding Identifier mobility option in 583 the Care-of Test Init message. It MUST NOT set any flags in the 584 mobility option. The receiver (i.e. correspondent node) will 585 calculate a care-of Keygen token as specified in [RFC-3775] and reply 586 with a Care-of Test message, with the Binding Identifier mobility 587 option as described in Section 6.2. When the mobile node receives 588 the Care-of Test message, the message is verified as in [RFC-3775]. 589 If a Binding Identifier mobility option is not present in the CoT 590 message in reply to the CoTI message that included a Binding 591 Identifier mobility option, the mobile node must assume that the 592 correspondent node does not support Multiple Care-of Address 593 registration. Thus, the mobile node MUST NOT use a Binding 594 Identifier mobility option in any future Binding Updates to that 595 correspondent node. The mobile node MAY skip re-sending regular CoTI 596 message and keep the received care-of Keygen token for the regular 597 Binding Update. 599 5.3. Binding Registration 601 For the multiple Care-of Addresses registration, the mobile node MUST 602 include a Binding Identifier mobility option(s) in the Binding Update 603 as shown in Figure 6. The BID is copied from a corresponding Binding 604 Update List entry to the BID field of the Binding Identifier mobility 605 option. When IPsec ESP is used for protecting the Binding Update, 606 the care-of address can be carried in the Care-of Address field of 607 the Binding Identifier mobility option. If this is done, the 608 alternate care-of address option MUST NOT be included in the Binding 609 Update. For binding registration to a correspondent node, the mobile 610 node MUST have both active Home and Care-of Keygen tokens for Kbm 611 (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. 612 The care-of Keygen tokens MUST be maintained for each care-of address 613 that the mobile node wants to register to the correspondent node. 614 The Binding Update to the correspondent node is protected by the 615 Binding Authorization Data mobility option that is placed after the 616 Binding Identifier mobility option. 618 IPv6 header (src=CoA, dst=HA) 619 IPv6 Home Address Option 620 ESP Header (for home registration) 621 Mobility header 622 -Binding Update 623 Mobility Options 624 - Binding Identifier mobility option 625 - Binding Authorization mobility option 626 (for Route Optimization) 628 Figure 6: Binding Update for Binding Registration 630 5.4. Bulk Registration 632 Bulk registration is an optimization for binding multiple care-of 633 addresses to a home address using a single Binding Update. This is 634 very useful if the mobile node, for instance, does not want to send a 635 lot of signaling messages through an interface where the bandwidth is 636 scarce. This document specifies bulk registration only for the 637 mobile node's home registration. A mobile node performing bulk 638 registration with a correspondent node is out of scope. 640 To use bulk registration, the mobile node includes a Binding 641 Identifier Mobility option for each BID and Care-of address pair it 642 wants to register in the same Binding Update message. This is shown 643 in Figure 7. The rest of the fields and options in the Binding 644 Update such as Lifetime, Sequence Number, and the flags in the 645 Binding Update are common across all care-of addresses. The 646 alternate care-of address option MUST NOT be used. 648 IPv6 header (src=CoA, dst=HA) 649 IPv6 Home Address Option 650 ESP Header 651 Mobility header 652 -Binding Update 653 Mobility Options 654 - Binding Identifier mobility options (CoA) 656 Figure 7: Binding Update for Bulk Registration 658 If the mobile node wants to replace existing registered bindings on 659 the home agent with the bindings in the sent Binding Update, it sets 660 the 'O' flag. Section 6.3 describes this registration procedure in 661 detail. 663 5.5. Binding De-Registration 665 When a mobile node decides to delete all the bindings for its home 666 address, it sends a regular de-registration Binding Update with 667 lifetime set to zero as defined in [RFC-3775]. The Binding 668 Identifier mobility option is not required. 670 If a mobile node wants to delete a particular binding(s) from its 671 home agent and correspondent nodes, the mobile node sends a Binding 672 Update with lifetime set to zero and includes a Binding Identifier 673 mobility option(s) with the BID(s) it wants to de-register. The 674 receiver will remove only the care-of address(es) that match(es) the 675 specified BID(s). The care-of addresses field in each mobility 676 option SHOULD be omitted by the sender and MUST be ignored by the 677 receiver. This is because the receiver will remove the binding that 678 matches the specified BID. 680 5.6. Returning Home 682 The mobile node may return to the home link, by attaching to the home 683 link through one of its interfaces. When the mobile node wants to 684 return home, it should be configured with information on what 685 interface it needs to use. The mobile node may use only the 686 interface with which it is attached to the home link, only the 687 interfaces still attached to the visited link(s) or use both 688 interfaces attached to the home link and visited link(s) 689 simultaneously. The following describes each option in more detail. 691 5.6.1. Using only Interface attached to the Home Link 693 The mobile node returns home and de-registers all the bindings as 694 shown in Figure 2 and as defined in [RFC-3775]. De-registering all 695 the bindings is the same as binding de-registration from foreign link 696 described in Section 5.5. After the de-registration step, all the 697 packets routed by the home agent are only forwarded to the interface 698 attached to the home link, even if there are other active interfaces 699 attached to the visited link(s). While the mobile node de-registers 700 all the bindings from the home agent, it may continue registering 701 bindings for interface(s) attached to visited link(s) to the 702 correspondent node as shown in Figure 2. 704 5.6.2. Using only Interface attached to the Visited Link 706 The mobile node returns home and shuts down the interface attached to 707 the home link as shown in Figure 3. Before shutting down the 708 interface, any binding for the care-of address previously associated 709 with the interface should be deleted. To delete the binding cache 710 entry, the mobile node SHOULD send a de-registration Binding Update 711 with the lifetime set to zero and include the corresponding BID 712 information. If the mobile node does not send a de-registration 713 Binding Update, the binding for the care-of address previously 714 assigned to the interface remains at the home agent until its 715 lifetime expires. 717 In this scenario, despite the fact that the mobile node is connected 718 to its home link, all of its traffic is sent and received via the 719 home agent and its foreign links. 721 5.6.3. Simultaneous Home and Visited Link Operation 723 [Problems of Simultaneous Home and Foreign Attachments] 725 The mobile node returns home and continues using all the interfaces 726 attached to both foreign and home links as shown in Figure 4. The 727 mobile node indicates this by setting the 'H' flag in the BID 728 mobility option as defined below. There are additional requirements 729 on the Returning Home procedures for possible Neighbor Discovery 730 states conflicts at the home link. 732 In [RFC-3775], the home agent intercepts packets meant for the mobile 733 node using the Proxy Neighbor Discovery [RFC-2461] while the mobile 734 node is away from the home link. When the mobile node returns home, 735 the home agent deletes the binding cache and stops proxying for the 736 home address so that a mobile node can configure its home address on 737 the interface attached to the home link. In this specification, a 738 mobile node may return home, configure the home address on the 739 interface attached to the home link, but still use the interfaces 740 attached to the foreign links. In this case, a possible conflict 741 arises when the both the home agent and the mobile node try to defend 742 the home address. If the home agent stops proxying for the home 743 address, the packets are always routed to the interface attached to 744 the home link and are never routed to the interfaces attached to the 745 visited links. It is required to avoid the conflict between the home 746 agent and the mobile node, while still allowing the simultaneous use 747 of home and foreign links. The following describes the mechanism for 748 achieving this. 750 [Overview and Approach] 752 In this specification, the home agent MUST intercept all the packets 753 meant for the mobile node and decide whether to send the traffic 754 directly to the home address on the link or tunnel to the care-of 755 address. The home agent intercepts all the packets even when the 756 mobile node is attached to the home link through one of its 757 interfaces. The home agent would make this decision based on the 758 type of flow. How to make this decision is out of scope in this 759 document. 761 Two scenarios are illustrated in Figure 4, depending on whether the 762 Home Agent is the only router at the home link or not. The 763 difference is on who defends the home address by (Proxy) Neighbor 764 Discovery on the home link. 766 1. Mobile node defends the home address by the regular Neighbor 767 Discovery Protocol (illustrated as topology-a in Figure 4). The 768 home agent is the only router on the home link. Therefore the 769 home agent is capable of intercepting packets without relying on 770 the proxy Neighbor Discovery protocol and the mobile node can 771 manage the Neighbor Cache entry of the home address on the home 772 link as a regular IPv6 node. 774 2. If there are other routers on the home link apart from the home 775 agent, then it cannot be guaranteed that all packets meant for 776 the mobile node are routed to the home agent. In this case, the 777 mobile node MUST NOT operate Neighbor Discovery protocol for the 778 home address on the home link. This allows the home agent to 779 keep using proxy neighbor discovery and thus it keeps receiving 780 all the packets sent to the mobile node's home address. If the 781 home agent, according to its local policy, needs to deliver 782 packets to the mobile node over the home link, an issue arises 783 with respect to how the home agent discovers the mobile node's 784 link local address. This specification uses Link-layer Address 785 (LLA) Option defined in [RFC-4068bis] in order to carry the 786 mobile node's link-layer address in the Binding Update. 787 Likewise, the mobile node would also know the link-layer address 788 of the default router address to send packets from the home link 789 without Neighbor Discovery. The link-layer address is used to 790 transmit packets from and to the mobile node on the home link. 791 The packets are transmitted without the Neighbor Discovery 792 protocol by constructing the link-layer header manually. This 793 operation is similar to Mobile IPv6 [RFC-3775] when a mobile node 794 sends a deregistration binding update to the home agent's link- 795 layer address in returning home operation. 797 [Sending Deregistration Binding Update] 799 o As soon as a mobile node returns home, it sends a de-registration 800 Binding Update to the home agent from the interface attached to 801 the home link. 803 o The mobile node MUST include the BID mobility option specifying 804 the BID the mobile node had previously associated with the 805 interface attached to the home link. The 'H' flag MUST be set in 806 the BID mobility option. Any address MUST NOT be set in the 807 Care-of Address field in the BID mobility option. When the 'H' 808 flag is set, the home agent recognizes that the mobile node wants 809 to continue using interfaces attached to both home and visited 810 links. Note that H flag MUST be set for all the binding updates 811 sent from the mobile node (ex. Binding Update for the 812 interface(s) attached to the foreign link(s)). 814 o The mobile node SHOULD include the Link-layer Address (LLA) Option 815 [RFC-4068bis] to notify the mobile node's link-layer address to 816 the home agent, too. The option code of the Link-layer Address 817 (LLA) option MUST be set to '2' (Link-layer Address of the mobile 818 node). This link-layer address is required for the home agent to 819 send the Binding Acknowledgement and to forward the mobile node's 820 packet. 822 o According to [RFC-3775], the mobile node MUST start responding to 823 Neighbor Solicitation for its home address right after it sends 824 the deregistration Binding Update to the home agent. However, in 825 this specification, the mobile node MUST NOT respond to Neighbor 826 Solicitation before receiving a Binding Acknowledgement, since the 827 home agent may continue proxying for the home address. If the 828 mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value 829 in the received Binding Acknowledgment, it MUST NOT respond to 830 Neighbor Solicitation even after the Binding Acknowledgement. 832 [Sending Binding Acknowledgement] 834 o When the home agent sends the Binding Acknowledgement after 835 successfully processing the binding de-registration, it MUST set 836 the status value to either 0 [Binding Update Accepted] or to [MCOA 837 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 838 Acknowledgment depending on home agent configuration at the home 839 link. The new values are: 841 * Binding Update Accepted (0): NDP is permitted for the home 842 address at the home link. This is regular returning home 843 operation of [RFC-3775] 845 * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home 846 address at the home link 848 If the binding update is rejected, the appropriate error value 849 MUST be set to the status field. In this case, the home agent 850 operation is same as [RFC-3775]. 852 o If the home agent is the only router at the home link, it stops 853 proxy Neighbor Discover for the requested home address and 854 responds with the [Binding Update Accepted] status value to the 855 mobile node. Since the mobile node will not reply to Neighbor 856 Solicitation for the home address before receiving the Binding 857 Acknowledgement, the home agent SHOULD use the link-layer address 858 carried by the Link Layer Address option [RFC-4068bis] in the 859 received Binding Update. After the completion of the binding 860 deregistration, the mobile node starts regular Neighbor Discovery 861 operations for the home address on the home link. The neighbor 862 cache entry for the home address is created by the regular 863 exchange of Neighbor Solicitation and Neighbor Advertisement. 865 o On the other hand, if the home agent is not the only router on the 866 home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status 867 field of the BID mobility option. The home agent learns the 868 mobile node's link-layer address by receiving the link-layer 869 address option carried by the Binding Update. It stores the link- 870 layer address as a neighbor cache entry for the mobile node so 871 that it can send the packets to the mobile node's link-layer 872 address. 874 o Note that the use of proxy Neighbor Discovery is easier way to 875 intercept the mobile nodes' packets instead of IP routing in some 876 deployment scenarios. Therefore, even if a home agent is the only 877 router, it is an implementation and operational choice whether the 878 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 879 WO/NDP]. 881 o If BID option is not included in the Binding Acknowledgement, the 882 home agent might not recognize the simultaneous home and foreign 883 attachment. The home agent might have processed the de- 884 registration Binding Update as a regular de-registration as 885 described in [RFC-3775] and deletes all the registered binding 886 cache entries for the mobile node. Thus, the mobile node SHOULD 887 stop using the interface attached to foreign link and use only the 888 interface attached to the home link. 890 [Sending Packets from the Home Link] 892 o When the mobile node receives the Binding Acknowledgement with the 893 status value 'Binding Update Accepted' and the BID option, it can 894 configure its home address to the interface attached to the home 895 link and start operating Neighbor Discovery for the home address 896 on the home link. Packets can be transmitted from and to the 897 mobile node as if the mobile node is a regular IPv6 node. 899 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 900 the Binding Acknowledgement, it MUST NOT operate Neighbor 901 Discovery for the home address. When the mobile node sends 902 packets from the interface attached to the home link, it MUST 903 learn the link-layer address of the next hop (i.e. default router 904 of the mobile node). A mobile node learns the default router's 905 link-layer address from a Source Link-Layer Address option in 906 Router Advertisements. The mobile node sends packets directly to 907 the default router's link-layer address. This is done by 908 constructing the packet including link-layer header with the 909 learned link-layer address of the default router. The home agent 910 also forwards the packet to the mobile node on the home link by 911 using the mobile node's link-layer address. The link-layer 912 address SHOULD be cached when the home agent received the 913 deregistration Binding Update message. 915 [Leaving from the Home Link] 917 o When the mobile node detaches from the home link, it SHOULD 918 immediately send a binding update for one of active care-of 919 address with H flag unset. When the 'H' flag of BID option is 920 unset in any Binding Update, the home agent stop forwarding the 921 mobile node's packet to the home link. 923 o On the other hand, if the mobile node does not have any active 924 care-of address to send a Binding Update and leaves the home link 925 (i.e. the mobile node is completely disconnected), the home agent 926 continues forwarding packets to the mobile node until the 927 expiration of all the binding cache entries for the home address. 928 Once all the bindings are expired, the mobile node is assumed to 929 be disconnected completely from networks. 931 [Changing Behavior during the attachment to the home link] 933 If a mobile node decides to return home completely without any active 934 foreign link attachment, it simply sends a deregistration binding 935 update as described in Section 5.6.1. Once the home agent receives 936 such de-registration binding update, the home agent clears all the 937 binding and states for the mobile node. 939 If a mobile node decides to stop using the interface attached to the 940 home link, it simply sends a binding update from the one of active 941 care-of address. In the Binding Update, the mobile node should 942 include the BID option for the care-of address and unset the H flag 943 of BID option. The home agent clears the states of the mobile node 944 for the interface attached to the home link and stop forwarding the 945 packets to the mobile node on the home link. 947 5.7. Receiving Binding Acknowledgement 949 The verification of a Binding Acknowledgement is the same as Mobile 950 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 951 Binding Acknowledgement is described in Section 6.3. 953 If a mobile node includes a Binding Identifier mobility option in a 954 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 955 carry a Binding Identifier mobility option. If no such mobility 956 option is included in the Binding Acknowledgement in response to a 957 Binding Update for multiple care-of address registration, this 958 indicates that the originating node of the Binding Acknowledgement 959 does not support processing the Binding Identifier mobility option. 960 The mobile node MUST then stop multiple care-of address registration 961 with that node. 963 If a Binding Identifier mobility option is present in the received 964 Binding Acknowledgement, the mobile node checks the status field in 965 the option. If the status value in the Binding Identifier mobility 966 option is zero, the mobile node uses the value in the Status field of 967 the Binding Acknowledgement. Otherwise, it uses the value in the 968 Status field of the Binding Identifier mobility option. 970 If the status code is greater than or equal to 128, the mobile node 971 starts relevant operations according to the error code. Otherwise, 972 the mobile node assumes that the originator (home agent or 973 correspondent node) successfully registered the binding information 974 and BID for the mobile node. 976 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 977 stop registering multiple bindings to the node that sent the 978 Binding Acknowledgement. 980 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 981 mobile node SHOULD stop using bulk registrations with the node 982 that sent the Binding Acknowledgement. 984 o If [MCOA MALFORMED] is specified, it indicates that the binding 985 identifier mobility option is formatted wrongly. 987 o If [MCOA BID CONFLICT] is specified, the binding entry specified 988 by the Binding Identifier mobility option is already registered as 989 a regular binding. In such case, the mobile node SHOULD stop 990 sending Binding Updates with BID, or SHOULD use the 'O' flag to 991 reset all the registered bindings. 993 5.8. Receiving Binding Refresh Request 995 The verification of a Binding Refresh Request is the same as in 996 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 997 a Binding Refresh Request is described in section Section 6.4. 999 If a mobile node receives a Binding Refresh Request with a Binding 1000 Identifier mobility option, it indicates that the node sending the 1001 Binding Refresh Request message is requesting the mobile node to send 1002 a new Binding Update for the BID. The mobile node SHOULD then send a 1003 Binding Update only for the respective binding. The mobile node MUST 1004 include a Binding Identifier mobility option in the Binding Update. 1006 5.9. Bootstrapping 1008 When a mobile node bootstraps and registers multiple bindings for the 1009 first time, it MUST set the 'O' flag in the Binding Identifier 1010 mobility option. If old bindings still exists at the home agent, the 1011 mobile node has no knowledge of which bindings still exist at the 1012 home agent. This scenario happens when a mobile node reboots and 1013 looses state regarding the registrations. If the 'O' flag is set, 1014 all the bindings are replaced by the new binding(s). If the mobile 1015 node receives the Binding Acknowledgement with the status code set to 1016 135 [Sequence number out of window], it MUST retry sending a Binding 1017 Update with the last accepted sequence number indicated in the 1018 Binding Acknowledgement. 1020 The 'O' flag can also be used in individual Binding Updates sent to 1021 the correspondent nodes to override any existing binding cache 1022 entries at the correspondent node. 1024 6. Home Agent and Correspondent Node Operation 1026 6.1. Searching Binding Cache with Binding Identifier 1028 If either a correspondent node or a home agent has multiple bindings 1029 for a mobile node in their binding cache database, it can use any of 1030 the bindings to communicate with the mobile node. This section 1031 explains how to retrieve the desired binding for the binding 1032 management. This document does not provide any mechanism to select 1033 the suitable binding for forwarding data packets. 1035 A correspondent node SHOULD use both the home address and the BID as 1036 the search key of the binding cache if it knows the corresponding BID 1037 (ex. when processing signaling messages). In the example below, if a 1038 correspondent node searches the binding with the home address and 1039 BID2, it gets binding2 for this mobile node. 1041 binding1 [a:b:c:d::EUI, care-of address1, BID1] 1042 binding2 [a:b:c:d::EUI, care-of address2, BID2] 1043 binding3 [a:b:c:d::EUI, care-of address3, BID3] 1045 Figure 8: Searching the Binding Cache 1047 A correspondent node learns the BID when it receives a Binding 1048 Identifier mobility option. At that time, the correspondent node 1049 MUST look up its binding cache database with the home address and the 1050 BID retrieved from the Binding Update. If the correspondent node 1051 does not know the BID, it searches for a binding with only the home 1052 address. In such a case, the first matched binding is found. If the 1053 correspondent node does not desire to use multiple bindings for a 1054 mobile node, it can simply ignore the BID. 1056 6.2. Receiving CoTI and Sending CoT 1058 When a correspondent node receives a CoTI message which contains a 1059 Binding Identifier mobility option, it processes it as follows. 1061 First, the CoTI message is verified as specified in [RFC-3775]. The 1062 Binding Identifier mobility option is processed as follows: 1064 o If a correspondent node does not understand a Binding Identifier 1065 mobility option, it just ignores and skips processing the option. 1066 The calculation of a care-of Keygen token will thus be done 1067 without a BID value. The correspondent node returns a CoT message 1068 without a Binding Identifier mobility option. The mobile node 1069 knows whether the correspondent supports processing the Binding 1070 Identifier mobility option, by checking if the option is present 1071 in the CoT message. 1073 o If either the 'C' or the 'O' flag is set in the Binding Identifier 1074 mobility option, the correspondent Node SHOULD NOT calculate a 1075 care-of Keygen token, but MUST include a Binding Identifier 1076 mobility option with status value set to [MCOA MALFORMED] in the 1077 Care-of Test message. 1079 o Otherwise, the correspondent node MUST include a Binding 1080 Identifier mobility option with status value set to zero (success) 1081 in the Care-of Test message. 1083 o The Care-of address field of each Binding Identifier mobility 1084 option, can be omitted, because the mobile node can identify the 1085 corresponding Binding Update list entry using the BID. 1087 6.3. Processing Binding Update 1089 If a Binding Update does not contain a Binding Identifier mobility 1090 option, its processing is same as in [RFC-3775]. If the receiver 1091 already has multiple bindings for the home address, it MUST replace 1092 all the existing bindings by the received binding. As a result, the 1093 receiver node MUST have only one binding cache entry for the mobile 1094 node. If the Binding Update is for de-registration, the receiver 1095 MUST delete all existing bindings from its Binding Cache. 1097 If the Binding Update contains a Binding Identifier mobility 1098 option(s), it is first validated according to section 9.5.1 of [RFC- 1099 3775]. Then the receiver processes the Binding Identifier mobility 1100 option(s) as described in the following steps. 1102 o The length value is examined. The length value MUST be either 4, 1103 8, or 20 depending on the Care-of Address field. If the length is 1104 incorrect, the receiver MUST reject the Binding Update and returns 1105 the status value set to [MCOA MALFORMED]. 1107 o When the Length value is either 12 or 20, the care-of address MUST 1108 be present in the Binding Identifier mobility option. If the 1109 care-of address is not present, the receiver MUST reject the 1110 Binding Identifier mobility option and returns the status value 1111 set to [MCOA MALFORMED]. If the Length value is 12, an IPv4 valid 1112 address MUST be present. Otherwise, an IPv6 address MUST be 1113 stored in the Binding Identifier mobility option. 1115 o When multiple Binding Identifier mobility options are present in 1116 the Binding Update, it is treated as bulk registration. If the 1117 receiving node is a correspondent node, it MUST reject the Binding 1118 Update and returns the status value in the binding acknowledgement 1119 set to [MCOA BULK REGISTRATION NOT SUPPORT] 1121 o If the Lifetime field in the Binding Update is set to zero, the 1122 receiving node deletes the binding entry that corresponds to the 1123 BID in the Binding Identifier mobility option. If the receiving 1124 node does not have an appropriate binding for the BID, it MUST 1125 reject the Binding Update and send a Binding Acknowledgement with 1126 status set to 133 [not home agent for this mobile node]. 1128 o If the 'O' flag is set in the de-registering Binding Update, it is 1129 ignored. If the 'H' flag is set, the home agent stores a home 1130 address in the Care-of Address field of the binding cache entry. 1131 The home agent also stops performing proxy ND for the mobile 1132 node's home address. 1134 o If the Lifetime field is not set to zero, the receiving node 1135 registers a binding with the specified BID as a mobile node's 1136 binding. The Care-of address is obtained from the Binding Update 1137 packet as follows: 1139 * If the Length value of the Binding Identifier mobility option 1140 is 20, the care-of address is copied the IPv6 address from the 1141 care-of address field in the Binding Identifier mobility 1142 option. When the Length value is 12, the address MUST be the 1143 IPv4 valid address. Detail information can be found in 1144 Section 8. 1146 * If the Length value of the Binding Identifier mobility option 1147 is 4, the care-of address is copied from the source address 1148 field of the IPv6 header. 1150 * If the Length value of the Binding Identifier mobility option 1151 is 4 and an alternate care-of address is present, the care-of 1152 address is copied from the Alternate Care-of address mobility 1153 option. 1155 o Once the care-of address(es) have been retrieved from the Binding 1156 Update, the receiving nodes creates new binding(s). 1158 * If only the 'O' flag is set in the Binding Identifier mobility 1159 option, the home agent removes all the existing bindings and 1160 registers the received bindings. 1162 * If the receiver has a regular binding which does not have BID 1163 for the mobile node, it must not process the binding update. 1164 The receiver should sent a binding acknowledgement with status 1165 set to [MCOA BID CONFLICT]. 1167 * If the receiver already has a binding with the same BID but 1168 different care-of address, it MUST update the binding and 1169 respond with a Binding Acknowledgement with status set to 0 1170 [Binding Update accepted]. 1172 * If the receiver does not have a binding entry for the BID, it 1173 registers a new binding for the BID and responds with a Binding 1174 Acknowledgement with status set to 0 [Binding Update accepted]. 1176 If all the above operations are successfully completed, a Binding 1177 Acknowledgement containing the Binding Identifier mobility options 1178 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 1179 is sent, all the Binding Identifier mobility options stored in the 1180 Binding Update MUST be copied to the Binding Acknowledgement except 1181 the status field. The Care-of address field in each Binding 1182 Identifier mobility option, however, can be omitted, because the 1183 mobile node can match a corresponding binding update list entry using 1184 the BID. 1186 When a correspondent node sends a Binding Acknowledgement, the status 1187 value MUST be always stored in the Status field of the Binding 1188 Acknowledgement and the Status field of Binding Identifier mobility 1189 option set to zero. For the home agent, the status value can be 1190 stored in the Status field of either a Binding Acknowledgement or a 1191 Binding Identifier mobility option. If the status value is specific 1192 to one of bindings in the bulk registration, the status value MUST be 1193 stored in the Status field in the corresponding Binding Identifier 1194 mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the 1195 Status field of the Binding Acknowledgement so that the receiver can 1196 examine the Status field of each Binding Identifier mobility option 1197 for further operations. 1199 6.4. Sending Binding Refresh Request 1201 When a node (home agent or correspondent node) sends a Binding 1202 Refresh Request for a particular binding created with the BID, the 1203 node SHOULD include the Binding Identifier mobility option in the 1204 Binding Refresh Request. If the mobile node had used bulk 1205 registration, the sender SHOULD include all the Binding Identifier 1206 mobility options. If the mobile node had not used bulk registration, 1207 the sender includes the Binding Identifier mobility options only for 1208 those bindings that need to be refreshed. 1210 6.5. Receiving Packets from Mobile Node 1212 When a node receives packets with a Home Address destination option 1213 from a mobile node, it MUST check that the care-of address that 1214 appears in the source address field of the IPv6 header MUST be equal 1215 to one of the care-of addresses in the binding cache entry. If no 1216 binding is found, the packets MUST be silently discarded. The node 1217 MUST also send a Binding Error message as specified in [RFC-3775]. 1218 This verification MUST NOT be done for a Binding Update. 1220 7. Network Mobility Applicability 1222 The binding management mechanisms are the same for a mobile host that 1223 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1224 Support protocol [RFC-3963]. Therefore the extensions described in 1225 this document can also be used to support a mobile router with 1226 multiple care-of addresses. 1228 8. DSMIPv6 Applicability 1230 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1231 register an IPv4 care-of address instead of the IPv6 care-of address 1232 when the mobile node is attached to an IPv4-only access network. It 1233 also allows the mobile node to acquire an IPv4 home address in 1234 addition to an IPv6 home address for use with IPv4-only correspondent 1235 nodes. This section describes how multiple care-of address 1236 registration works with IPv4 care-of and home addresses. 1238 8.1. IPv4 Care-of Address Registration 1240 The mobile node can use the extensions described in the document to 1241 register multiple care-of addresses, even if some of the care-of 1242 addresses are IPv4 address. 1244 Bulk registration MUST NOT be used for the initial binding from an 1245 IPv4 care-of address. This is because, the Binding Update and 1246 binding acknowledgement exchange is used to detect NAT on the path 1247 between the mobile node and the home agent. So the mobile node needs 1248 to check for a NAT between each IPv4 care-of address and the home 1249 agent. 1251 The Binding Update MUST be sent to the IPv4 home agent address by 1252 using UDP and IPv4 headers as shown in Figure 9. It is similar to 1253 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1254 used when the BID mobility option is used. 1256 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1257 UDP Header 1258 IPv6 header (src=V6HoA, dst=HAADDR) 1259 ESP Header 1260 Mobility header 1261 -Binding Update 1262 Mobility Options 1263 - Binding Identifier (IPv4 CoA) 1265 Figure 9: Initial Binding Update for IPv4 Care-of Address 1267 If a NAT is not detected, the mobile node can update the IPv4 care-of 1268 address by using bulk registration. The mobile node can register the 1269 IPv4 care-of address along with other IPv4 and IPv6 care-of 1270 addresses. Figure 10 shows the Binding Update format when the mobile 1271 node sends a Binding Update from one of its IPv6 care-of addresses. 1272 If the mobile node sends a Binding Update from IPv4 care-of address, 1273 it MUST follow the format described in Figure 9. Note that the IPv4 1274 Care-of Address must be registered by non bulk Binding registration, 1275 whenever it is changed. 1277 IPv6 header (src=V6CoA, dst=HAADDR) 1278 IPv6 Home Address Option 1279 ESP Header 1280 Mobility header 1281 -Binding Update 1282 Mobility Options 1283 - Binding Identifier (IPv6/v4 CoA) 1284 - Binding Identifier (IPv6/v4 CoA) 1285 - ... 1287 Figure 10: Binding Bulk Registration for IPv4 care-of address 1289 If the home agent rejects the IPv4 care-of address, it MUST store the 1290 error code value in the Status field of the BID mobility option. 1292 8.2. IPv4 HoA Management 1294 When the mobile node wants to configure an IPv4 home address in 1295 addition to the IPv6 home address, it can request for one using the 1296 IPv4 Home Address option in the Binding Update. If the home agent 1297 accepts the Binding Update, the mobile node can now register multiple 1298 care-of addresses for the IPv4 home address in addition to the IPv6 1299 home address. The same set of care-of addresses will be registered 1300 for both IPv6 and IPv4 home addresses. The mobile node cannot bind 1301 different set of care-of addresses to each home address. 1303 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1304 acknowledgement option in the Binding Acknowledgement only if the 1305 mobile node had requested for an IPv4 home address in the 1306 corresponding Binding Update. The IPv4 address acknowledgement 1307 option MUST be present before any BID option. The status field of 1308 the IPv4 address acknowledgement option contains only the error code 1309 corresponding to the IPv4 home address management. The error values 1310 related to the IPv4 care-of address registration MUST be stored in 1311 the BID mobility option. 1313 9. IPsec and IKEv2 interaction 1315 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1316 use of IPsec to protect signaling messages like Binding Updates, 1317 Binding Acknowledgements and return routability messages. IPsec may 1318 also be used protect all tunneled data traffic. The Mobile IPv6- 1319 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1320 setup the required IPsec security associations. The following 1321 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1322 respect to the use of IKEv2 and IPsec. 1324 o There is only one primary care-of address per mobile node. 1326 o The primary care-of address is stored in the IPsec database for 1327 tunnel encapsulation and decapsulation. 1329 o When the home agent receives a packet from the mobile node, the 1330 source address is verified against the care-of address in the 1331 corresponding binding cache entry. If the packet is a reverse 1332 tunneled packet from the mobile node, the care-of address check is 1333 done against the source address on the outer IPv6 header. The 1334 reverse tunnel packet could either be a tunneled HoTi message or 1335 tunneled data traffic to the correspondent node. 1337 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1338 the care-of address. The IKE SA is based on the care-of address 1339 of the mobile node. 1341 The above assumptions may not be valid when multiple care-of 1342 addresses are used by the mobile node. In the following sections, 1343 the main issues with the use of multiple care-of address with IPsec 1344 are addressed. 1346 9.1. Use of Care-of Address in the IKEv2 exchange 1348 For each home address the mobile node sets up security associations 1349 with the home agent, the mobile node must pick one care-of address 1350 and use that as the source address for all IKEv2 messages exchanged 1351 to create and maintain the IPsec security associations associated 1352 with the home address. The resultant IKEv2 security association is 1353 created based on this care-of address. 1355 If the mobile node needs to change the care-of address, it just sends 1356 a Binding Update with the care-of address it wants to use, with the 1357 corresponding Binding Identifier mobility option, and with the 'K' 1358 bit set. This will force the home agent to update the IKEv2 security 1359 association to use the new care-of address. If the 'K' bit is not 1360 supported on the mobile node or the home agent, the mobile node MUST 1361 re-establish the IKEv2 security association with the new care-of 1362 address. This will also result in new IPsec security associations 1363 being setup for the home address. 1365 9.2. Transport Mode IPsec protected messages 1367 For Mobile IPv6 signaling message protected using IPsec in transport 1368 mode, the use of a particular care-of address among multiple care-of 1369 addresses does not matter for IPsec processing. 1371 For Mobile Prefix Discovery messages, [RFC-3775] requires the home 1372 agent to verify that the mobile node is using the care-of address 1373 that is in the binding cache entry that corresponds to the mobile 1374 node's home address. If a different address is used as the source 1375 address, the message is silently dropped by the home agent. This 1376 document requires the home agent implementation to process the 1377 message as long as the source address is one of the care-of addresses 1378 in the binding cache entry for the mobile node. 1380 9.3. Tunnel Mode IPsec protected messages 1382 The use of IPsec in tunnel mode with multiple care-of address 1383 introduces a few issues that require changes to how the mobile node 1384 and the home agent send and receive tunneled traffic. The route 1385 optimization mechanism described in [RFC-3775] mandates the use of 1386 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1387 mobile node and the home agent may also choose to protect all reverse 1388 tunneled payload traffic with IPsec in tunnel mode. The following 1389 sections address multiple care-of address support for these two types 1390 of messages. 1392 9.3.1. Tunneled HoTi and HoT messages 1394 The mobile node MAY use the same care-of address for all HoTi 1395 messages sent reverse tunneled through the home agent. The mobile 1396 node may use the same care-of address irrespective of which 1397 correspondent node the HoTi message is being sent. RFC 3775 requires 1398 the home agent to verify that the mobile node is using the care-of 1399 address that is in the binding cache entry, when it receives a 1400 reverse tunneled HoTi message. If a different address is used as the 1401 source address, the message is silently dropped by the home agent. 1402 This document requires the home agent implementation to decapsulate 1403 and forward the HoTi message as long as the source address is one of 1404 the care-of addresses in the binding cache entry for the mobile node. 1406 When the home agent tunnels a HoT message to the mobile node, the 1407 care-of address used in the outer IPv6 header is not relevant to the 1408 HoT message. So regular IPsec tunnel encapsulation with the care-of 1409 address known to the IPsec implementation on the home agent is 1410 sufficient. 1412 9.3.2. Tunneled Payload Traffic 1414 When the mobile sends and receives multiple traffic flows protected 1415 by IPsec to different care-of addresses, the use of the correct 1416 care-of address for each flow becomes important. Support for this 1417 requires the following two considerations on the home agent. 1419 o When the home agent receives a reverse tunneled payload message 1420 protected by IPsec in tunnel mode, it must check that the care-of 1421 address is one of the care-of addresses in the binding cache 1422 entry. According to RFC 4306, the IPsec implementation on the 1423 home agent does not check the source address on the outer IPv6 1424 header. Therefore the care-of address used in the reverse 1425 tunneled traffic can be different from the care-of address used as 1426 the source address in the IKEv2 exchange. However, the Mobile 1427 IPv6 stack on the home agent MUST verify that the source address 1428 is one of the care-of addresses registered by the mobile node 1429 before decapsulating and forwarding the payload traffic towards 1430 the correspondent node. 1432 o For tunneled IPsec traffic from the home agent to the mobile node, 1433 The IPsec implementation on the home agent may not be aware of 1434 which care-of address to use when performing IPsec tunnel 1435 encapsulation. The Mobile IP stack on the home agent must specify 1436 the tunnel end point for the IPsec tunnel. This may require tight 1437 integration between the IPsec and Mobile IP implementations on the 1438 home agent. 1440 10. Security Considerations 1442 The security considerations for securing the Binding Update and 1443 binding acknowledgement messages with multiple care-of address are 1444 very similar to the security considerations for securing the Binding 1445 Update and binding acknowledgement. Please see [RFC-3775] for more 1446 information. The Binding Update and binding acknowledgement messages 1447 with multiple care-of addresses MUST be protected using IPsec as show 1448 in Section 9. Additional security considerations are described 1449 below. 1451 With simultaneous binding support, it is possible for a malicious 1452 mobile node to successfully bind a number of victims' addresses as 1453 valid care-of addresses for the mobile node with its home agent. 1454 Once these addresses have been bound, the malicious mobile node can 1455 perform a re-direction attack by instructing the home agent (e.g. 1456 setting filtering rules to direct a large file transfer) to tunnel 1457 packets to the victims' addresses. Such risk is highlighted in [ID- 1458 MIP6ANALYSIS]. These attacks are possible because the care-of 1459 addresses sent by the mobile node in the Binding Update messages are 1460 not verified by home agent, i.e., the home agent does not check if 1461 the mobile node is at the care-of address it is claiming to be. The 1462 security model for Mobile IPv6 assumes that there is a trust 1463 relationship between the mobile node and its home agent. Any 1464 malicious attack by the mobile node is traceable by the home agent. 1465 This acts as a deterrent for the mobile node to launch such attacks. 1467 Although such risk exists in Mobile IPv6, the risk level is escalated 1468 when simultaneous multiple care-of address bindings are performed. 1469 In Mobile IPv6, a mobile node can only have a single care-of address 1470 binding per home address at a given time. However, for simultaneous 1471 multiple care-of address bindings, a mobile node can have more than 1472 one care-of address binding per home address at a given time. This 1473 implies that a mobile node using simultaneous binding support can 1474 effectively bind more than a single victim's address. Another 1475 difference is the degree of risk involved. In the single care-of 1476 address binding case, once the re-direction attack is initiated, a 1477 malicious mobile node would be unable to use its home address for 1478 communications (such as to receive control packets pertaining to the 1479 file transfer). However, in the simultaneous binding support case, a 1480 malicious mobile node could bind a valid care-of address in addition 1481 to multiple victims addresses. This valid care-of address could then 1482 be used by the malicious mobile node to set up flow filtering rules 1483 at its home agent, thereby controlling and/or launching new re- 1484 direction attacks. 1486 Thus, in view of such risks, it is advisable for a home agent to 1487 employ some form of care-of address verification mechanism before 1488 using the care-of addresses as a valid routing path to a mobile node. 1489 Solutions related to this are described in [ID-COAVERIFY]. 1491 11. IANA Considerations 1493 The following Extension Types MUST be assigned by IANA: 1495 o Binding Identifier mobility option type: This must be assigned 1496 from the same space as mobility option in [RFC-3775]. 1498 o New Successful Status of Binding Acknowledgement: This status code 1499 must be assigned from the same space as binding acknowledgement 1500 status codes in [RFC-3775]. 1502 * MCOA NOTCOMPLETE (TBD) 1504 * MCOA RETURNHOME WO/NDP (TBD) 1506 o New Unsuccessful Status of Binding Acknowledgement: These status 1507 codes must also be assigned from the same space as binding 1508 acknowledgement status codes in [RFC-3775]. 1510 * MCOA MALFORMED (TBD) 1512 * MCOA BID CONFLICT (TBD) 1514 * MCOA PROHIBITED(TBD) 1516 * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 1518 12. Acknowledgements 1520 The authors would like to special thank George Tsirtsis for thorough 1521 review and suggestions. The authors would also like to thank 1522 Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin 1523 Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas 1524 Montavont for their discussions and inputs. Thanks to Susumu 1525 Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke 1526 Uehara, Masafumi Watari and Jun Murai for earlier work on this 1527 subject. 1529 13. References 1531 13.1. Normative References 1533 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1534 Requirement Levels", BCP 14, RFC 2119, March 1997. 1536 [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1537 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 1539 [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1540 Networks", RFC 2464, December 1998. 1542 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1543 in IPv6", RFC 3775, June 2004. 1545 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1546 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1547 January 2005. 1549 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1550 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1552 13.2. Informative References 1554 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1555 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1556 Interfaces and Global Addresses", 1557 draft-ietf-monami6-multihoming-motivation-scenario-02 (work in 1558 progress), July 2007 1560 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1561 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1563 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1564 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1565 draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver 1566 2007. 1568 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1569 RFC 3753, June 2004. 1571 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1572 Terminology", RFC 4885, July 2007. 1574 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1575 and Routers (DSMIPv6)", draft-ietf-mext-v4traversal-01 (work in 1576 progress), February 2008. 1578 [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of 1579 Addresses in Multiple Bindings Registration", 1580 draft-lim-mext-multiple-coa-verify-01 (work in progress), February 1581 2008. 1583 [RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers", 1584 draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April 1585 2008. 1587 Authors' Addresses 1589 Ryuji Wakikawa 1590 Toyota ITC / Keio University 1591 6-6-20 Akasaka, Minato-ku 1592 Tokyo 107-0052 1593 Japan 1595 Phone: +81-3-5561-8276 1596 Fax: +81-3-5561-8292 1597 Email: ryuji@jp.toyota-itc.com 1599 Thierry Ernst 1600 INRIA 1601 INRIA Rocquencourt 1602 Domaine de Voluceau B.P. 105 1603 Le Chesnay, 78153 1604 France 1606 Phone: +33-1-39-63-59-30 1607 Fax: +33-1-39-63-54-91 1608 Email: thierry.ernst@inria.fr 1609 URI: http://www.nautilus6.org/~thierry 1611 Kenichi Nagami 1612 INTEC NetCore Inc. 1613 1-3-3, Shin-suna 1614 Koto-ku, Tokyo 135-0075 1615 Japan 1617 Phone: +81-3-5565-5069 1618 Fax: +81-3-5565-5094 1619 Email: nagami@inetcore.com 1621 Vijay Devarapalli 1622 Wichorus 1623 3590 North First St 1624 San Jose, CA 95134 1625 USA 1627 Email: vijay@wichorus.com 1629 Full Copyright Statement 1631 Copyright (C) The IETF Trust (2008). 1633 This document is subject to the rights, licenses and restrictions 1634 contained in BCP 78, and except as set forth therein, the authors 1635 retain all their rights. 1637 This document and the information contained herein are provided on an 1638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1640 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1641 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1645 Intellectual Property 1647 The IETF takes no position regarding the validity or scope of any 1648 Intellectual Property Rights or other rights that might be claimed to 1649 pertain to the implementation or use of the technology described in 1650 this document or the extent to which any license under such rights 1651 might or might not be available; nor does it represent that it has 1652 made any independent effort to identify any such rights. Information 1653 on the procedures with respect to rights in RFC documents can be 1654 found in BCP 78 and BCP 79. 1656 Copies of IPR disclosures made to the IETF Secretariat and any 1657 assurances of licenses to be made available, or the result of an 1658 attempt made to obtain a general license or permission for the use of 1659 such proprietary rights by implementers or users of this 1660 specification can be obtained from the IETF on-line IPR repository at 1661 http://www.ietf.org/ipr. 1663 The IETF invites any interested party to bring to its attention any 1664 copyrights, patents or patent applications, or other proprietary 1665 rights that may cover technology that may be required to implement 1666 this standard. Please address the information to the IETF at 1667 ietf-ipr@ietf.org. 1669 Acknowledgment 1671 Funding for the RFC Editor function is provided by the IETF 1672 Administrative Support Activity (IASA).