idnits 2.17.1 draft-ietf-monami6-multiplecoa-08.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 1654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1678. 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 (May 30, 2008) is 5808 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 988, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1123, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1206, but not defined == Unused Reference: 'RFC-2464' is defined on line 1551, but no explicit reference was found in the text == Unused Reference: 'RFC-4980' is defined on line 1572, 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 (-10) exists of draft-ietf-mext-nemo-v4traversal-03 == Outdated reference: A later version (-02) exists of draft-lim-mext-multiple-coa-verify-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 7 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 V. Devarapalli (Ed.) 5 Expires: December 1, 2008 Wichorus 6 T. Ernst 7 INRIA 8 K. Nagami 9 INTEC NetCore 10 May 30, 2008 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-08.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 December 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. See [ID-MIP6ANALYSIS] on a 132 further analysis of using multiple interfaces and addresses with 133 Mobile IPv6. 135 This document proposes extensions to Mobile IPv6 to allow a mobile 136 node to register multiple care-of addresses for a home address and 137 create multiple binding cache entries. A new Binding Identification 138 (BID) number is created for each binding the mobile node wants to 139 create and sent in the binding update. The home agent that receives 140 this Binding Update creates separate binding for each BID. The BID 141 information is stored in the corresponding binding cache entry. The 142 BID information can now be used to identify individual bindings. The 143 same extensions can also be used in Binding Updates sent to the 144 correspondent nodes. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC-2119]. 152 Terms used in this draft are defined in [RFC-3775], [RFC-3753] and 153 [RFC-4885]. In addition or in replacement of these, the following 154 terms are defined or redefined: 156 Binding Identification number (BID) 158 The BID is an identification number used to distinguish multiple 159 bindings registered by the mobile node. Assignment of distinct 160 BIDs allows a mobile node to register multiple binding cache 161 entries for a given home address. The BID MUST be unique for a 162 binding to a specific care-of address for a given home address and 163 care-of address pair. Zero and negative values MUST NOT be used. 164 Each BID is generated and managed by a mobile node. The BID is 165 stored in the Binding Update List and is sent by the mobile node 166 in the Binding Update. A mobile node MAY change the value of a 167 BID at any time according to its administrative policy, for 168 instance to protect its privacy. An implementation must carefully 169 assign the BID so as to keep using the same BID for the same 170 binding even when the status of the binding is changed. More 171 details can be found in Section 5.1. 173 Binding Identifier Mobility Option 175 The Binding Identifier mobility option is used to carry the BID 176 information. 178 Bulk Registration 180 A mobile node can register multiple bindings at once by sending a 181 single Binding Update. A mobile node can also replace some or all 182 the bindings available at the home agent with the new bindings by 183 using the bulk registration. Bulk registration is supported only 184 for home registration (i.e. with the home agent) as explained in 185 Section 5.4. A mobile node MUST NOT perform bulk registration 186 mechanism described in this specification with a correspondent 187 node. 189 3. Protocol Overview 191 A new extension called the Binding identification number (BID) is 192 introduced to distinguish between multiple bindings pertaining to the 193 same home address. If a mobile node configures several IPv6 global 194 addresses on one or more of its interfaces, it can register these 195 addresses with its home agent as care-of addresses. If the mobile 196 node wants to register multiple bindings, it MUST generate a BID for 197 each care-of address and store the BID in the binding update list. A 198 mobile node can manipulate each binding independently by using the 199 BIDs. The mobile node then registers its care-of addresses by 200 sending a Binding Update with a Binding Identifier mobility option. 201 The BID is included in the Binding Identifier mobility option. After 202 receiving the Binding Update with a Binding Identifier mobility 203 option, the home agent MUST copy the BID from the Binding Identifier 204 mobility option to the corresponding field in the binding cache 205 entry. If there is an existing binding cache entry for the mobile 206 node, and if the BID in the Binding Update does not match the one 207 with the existing entry, the home agent MUST create a new binding 208 cache entry for the new care-of address and BID. The mobile node can 209 register multiple care-of addresses either independently in 210 individual Binding Updates or multiple at once in a single Binding 211 Update. 213 If the mobile host wishes to register its binding with a 214 correspondent node, it must perform return routability operations. 215 This includes managing a Care-of Keygen token per care-of address and 216 exchanging CoTi and CoT message with the correspondent node for each 217 care-of address. The mobile node MAY use the same BID that it used 218 with the home agent for a particular care-of address. For protocol 219 simplicity, bulk registration to correspondent nodes is not supported 220 in this document. This is because the Return Routability mechanism 221 introduced in [RFC-3775] cannot be easily extended to verify multiple 222 care-of addresses stored in a single Binding Update. 224 Figure 1 illustrates the configuration where the mobile node obtains 225 multiple care-of addresses at foreign links. The mobile node can 226 utilize all the care-of addresses. In Figure 1, the home address of 227 the mobile node (MN) is a:b:c:d::EUI. The mobile node has 3 228 different interfaces and possibly acquires care-of addresses 1-3 229 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to 230 each care-of address. 232 +----+ 233 | CN | 234 +--+-+ 235 | 236 +---+------+ +----+ 237 +------+ Internet |----------+ HA | 238 | +----+---+-+ +--+-+ 239 CoA2| | | | Home Link 240 +--+--+ | | ------+------ 241 | MN +========+ | 242 +--+--+ CoA1 | 243 CoA3| | 244 +---------------+ 246 Binding Cache Database: 247 home agent's binding (Proxy neighbor advertisement is active) 248 binding [a:b:c:d::EUI care-of address1 BID1] 249 binding [a:b:c:d::EUI care-of address2 BID2] 250 binding [a:b:c:d::EUI care-of address3 BID3] 251 correspondent node's binding 252 binding [a:b:c:d::EUI care-of address1 BID1] 253 binding [a:b:c:d::EUI care-of address2 BID2] 254 binding [a:b:c:d::EUI care-of address3 BID3] 256 Figure 1: Multiple Care-of Address Registration 258 If the mobile node decides to act as a regular mobile node compliant 259 with [RFC-3775], it sends a Binding Update without any Binding 260 Identifier mobility options. The receiver of the Binding Update 261 deletes all the bindings registering with a BID and registers only a 262 single binding for the mobile node. Note that the mobile node can 263 continue using the BID even if it has only a single binding that is 264 active. 266 Binding cache lookup is done based on the home address and BID 267 information. This is different from RFC 3775, where only the home 268 address is used for binding cache lookup. The binding cache lookup 269 may also involve policy or flow filters in cases where some policy or 270 flow filters are used to direct certain packets or flows to a 271 particular care-of address. The binding cache lookup using policy or 272 flow filters is out of scope for this document. In case the binding 273 cache lookup, using the combination of home address and BID, does not 274 return a valid binding cache entry, the home agent MAY perform 275 another lookup based on only the home address. This is 276 implementation dependent and configurable on the home agent. 278 The mobile node may return to the home link through one of its 279 interfaces. There are three options possible for the mobile node 280 when its returns home. Section 5.6 describes the returning home 281 procedures in more detail. 283 1. The mobile node uses only the interface with which it attaches to 284 the home link. This is illustrated in Figure 2. It de-registers 285 all bindings with the home agent related to all care-of 286 addresses. The interfaces still attached to the visited link(s) 287 are no longer going to be receiving any encapsulated traffic from 288 the home agent. On the other hand, the mobile node can continue 289 communicating with the correspondent node from the other 290 interfaces attached to foreign links by using route optimization. 291 Even if the mobile node is attached to the home link, it can 292 still send Binding Updates for other active care-of addresses 293 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 294 node has bindings, packets are routed to each Care-of Addresses 295 directly. 297 +----+ 298 | CN | 299 +--+-+ 300 | 301 +---+------+ +----+ 302 +------+ Internet |----------+ HA | 303 | +----+-----+ +--+-+ 304 CoA2| | | Home Link 305 +--+--+ | --+---+------ 306 | MN +========+ | 307 +--+--+ CoA1 | 308 | | 309 +---------------------------+ 311 Binding Cache Database: 312 home agent's binding 313 none 314 correspondent node's binding 315 binding [a:b:c:d::EUI care-of address1 BID1] 316 binding [a:b:c:d::EUI care-of address2 BID2] 318 Figure 2: Using only Interface Attached to Home Link 320 2. The mobile node uses only the interfaces still attached to the 321 visited link(s) as shown in Figure 3. The interface with which 322 the mobile node attaches to the home link is not used. 324 +----+ 325 | CN | 326 +--+-+ 327 | 328 +---+------+ +----+ 329 +------+ Internet |----------+ HA | 330 | +----+-----+ +--+-+ 331 CoA2| | | Home Link 332 +--+--+ | --+---+------ 333 | MN +========+ | 334 +--+--+ CoA1 | 335 | | 336 +---------------------------+ 337 (Disable interface) 339 Binding Cache Database: 340 home agent's binding 341 binding [a:b:c:d::EUI care-of address1 BID1] 342 binding [a:b:c:d::EUI care-of address2 BID2] 343 correspondent node's binding 344 binding [a:b:c:d::EUI care-of address1 BID1] 345 binding [a:b:c:d::EUI care-of address2 BID2] 347 Figure 3: Using only interface attached to the visited link 349 3. The mobile node may simultaneously use both the interface 350 attached to the home link and the interfaces still attached to 351 the visited link(s) as shown in Figure 4. There are two possible 352 topologies depending on whether the home agent is only router on 353 the home link or not. The operation of Neighbor Discovery [RFC- 354 2461] is different in the two topologies. The home agent and the 355 correspondent node have the binding entries listed in Figure 4 in 356 their binding cache database in both topologies. The home agent 357 also knows that the mobile node has attached to the home link. 358 All the traffic from the Internet is intercepted by the home 359 agent first and routed to either the interface attached to the 360 home link or the one of the foreign links. How the home agent 361 decides to route a particular flow to the interface attached to 362 the home link or foreign link is out of scope in this document. 364 Topology-a) 365 +----+ 366 | CN | 367 +--+-+ 368 | 369 +---+------+ +----+ 370 +------+ Internet |----------+ HA | 371 | +----+-----+ +--+-+ 372 CoA2| | | Home Link 373 +--+--+ | --+---+------ 374 | MN +========+ | 375 +--+--+ CoA1 | 376 | | 377 +---------------------------+ 379 Topology-b) 380 +----+ 381 | CN | 382 +--+-+ 383 | 384 +---+------+ Router +----+ 385 +------+ Internet |-------R | HA | 386 | +----+-----+ | +--+-+ 387 CoA2| | | | Home Link 388 +--+--+ | --+-+-------+------ 389 | MN +========+ | 390 +--+--+ CoA1 | 391 | | 392 +---------------------------+ 394 Binding Cache Database: 395 home agent's binding 396 binding [a:b:c:d::EUI care-of address1 BID1] 397 binding [a:b:c:d::EUI care-of address2 BID2] 398 correspondent node's binding 399 binding [a:b:c:d::EUI care-of address1 BID1] 400 binding [a:b:c:d::EUI care-of address2 BID2] 402 Figure 4: Simultaneous Home and Visited Link Operation 404 4. Mobile IPv6 Extensions 406 This section summarizes the extensions to Mobile IPv6 necessary for 407 manage multiple bindings. 409 4.1. Binding Cache Structure and Binding Update List 411 The BID is required to be stored in the binding cache and binding 412 update list structure. 414 The sequence number value SHOULD be shared among all the binding 415 update list entries related to binding updates sent to a particular 416 home agent or correspondent node. Whenever a mobile node sends 417 either individual or bulk binding update, the sequence number is 418 incremented. On the other hand, if a mobile node manages an 419 individual sequence value per binding update list, a mobile node 420 SHOULD carefully select the sequence number value for the bulk 421 binding update. This is because all the bulk-registered bindings use 422 the same Sequence Number specified in the Binding Update. If each 423 binding uses different sequence number, a mobile node MUST use the 424 largest sequence number from the Binding Update list entries used for 425 the bulk registration. If the mobile node cannot select a sequence 426 number for all the bindings due to sequence number out of window, it 427 MUST NOT use the bulk registration for the binding whose sequence 428 number is out of window. A separate Binding Update should be sent 429 for the binding. 431 4.2. Binding Identifier Mobility Option 433 The Binding Identifier mobility option is included in the Binding 434 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 435 Test Init and Care-of Test message. The Binding Identifier Mobility 436 Option has an alignment requirement of 2n if the Care-of Address 437 field is not presented. Otherwise, it has the alignment requirement 438 of 8n + 2. 440 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type = TBD | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Binding ID (BID) | Status |O|H| Reserved | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 447 + + 448 : IPv4 or IPv6 care-of address (CoA) : 449 + + 450 +---------------------------------------------------------------+ 451 Figure 5: BID Mobility Option 453 Type 455 Type value for Binding Identifier is TBD 457 Length 459 8-bit unsigned integer. Length of the option, in octets, 460 excluding the Type and Length fields. It MUST be set to either 4, 461 12, or 20 depending on the care-of address field. When the 462 care-of address is not carried by this option, the length value 463 MUST be set to 4. If the IPv4 care-of address is stored in the 464 care-of address field, the length MUST be 12. Otherwise, the 465 Length value MUST be set to 20 for IPv6 care-of address. 467 Binding ID (BID) 469 The BID which is assigned to the binding indicated by the care-of 470 address in the Binding Update or the BID mobility option. The BID 471 is a 16-bit unsigned integer. The value of zero is reserved and 472 MUST NOT be used. 474 Status 476 The Status field is an 8-bit unsigned integer. When the Binding 477 Identifier mobility option is included in a Binding 478 Acknowledgement, this field overwrites the status field in the 479 Binding Acknowledgement. If this field is set to zero, the 480 receiver ignores this field and uses the registration status 481 stored in the Binding Acknowledgement message. The receiver MUST 482 ignore this field if the Binding Identifier mobility option is not 483 carried within either the Binding Acknowledgement or the Care-of 484 Test messages. The possible status codes are the same as the 485 status codes of Binding Acknowledgement. This Status field is 486 also used to carry error information related to the care-of 487 address test in the Care-of Test message. 489 Overwrite (O) flag 491 When this flag is set, a mobile node requests the recipient to 492 replace all the bindings to binding entries stored in a Binding 493 Update. 495 Simultaneous Home and Foreign Binding (H) flag 496 This flag indicates that the mobile node registers multiple 497 bindings to the home agent while is attached to the home link. 498 This flag is valid only for a Binding Update sent to the home 499 agent. 501 Reserved 503 5 bits Reserved field. The value MUST be initialized to zero by 504 the sender, and MUST be ignored by the receiver. 506 Care-of Address 508 If a Binding Identifier mobility option is included in a Binding 509 Update, either IPv4 or IPv6 care-of address for the corresponding 510 BID can be stored in this field. If no address is specified in 511 this field, the length of this field MUST be zero (i.e. not 512 appeared in the option). If the option is included in any other 513 messages than a Binding Update, the length of this field MUST be 514 also zero. 516 4.3. New Status Values for Binding Acknowledgement 518 New status values for the status field in a Binding Acknowledgement 519 are defined for handling the multiple Care-of Addresses registration: 521 MCOA NOTCOMPLETE (TBD less than 128) 523 In bulk registration, not all the binding identifier mobility 524 option are successfully registered. Some of them are rejected. 525 The error status value of the failed mobility option is 526 individually stored in the status field of the binding identifier 527 mobility option. 529 MCOA RETURNHOME WO/NDP (TBD less than 128) 531 When a mobile node returns home, it MUST NOT use NDP for the home 532 address on the home link. This is explained in more detail in 533 Section 5.6 535 MCOA MALFORMED (TBD more than 128) 537 Registration failed because Binding Identifier mobility option was 538 not formatted correctly. 540 MCOA BID CONFLICT (TBD more than 128) 541 The home agent cannot cache both a regular binding and a BID 542 extended binding simultaneously. It returns this status value 543 when the received binding conflicts with the existing binding 544 cache entry(ies). 546 MCOA PROHIBITED(TBD more than 128) 548 It implies the multiple care-of address registration is 549 administratively prohibited. 551 MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) 553 Bulk binding registration is not supported. 555 5. Mobile Node Operation 557 5.1. Management of Care-of Address(es) and Binding Identifier(s) 559 There are two cases when a mobile node might acquire several care-of 560 addresses. Note that a mixture of the two cases is also possible. 562 1. A mobile node may be using several physical network interfaces 563 and acquires a care-of address on each of its interfaces. 565 2. A mobile node uses a single physical network interface, but 566 receives advertisements for multiple prefixes on the link the 567 interface is attached to. This will result in the mobile node 568 configuring several global addresses on the interface from each 569 of the announced prefixes. 571 The difference between the above two cases is only in the number of 572 physical network interfaces and therefore irrelevant in this 573 document. What is of significance is the fact that the mobile node 574 has several addresses it can use as care-of addresses. 576 A mobile node assigns a BID to each care-of address when it wants to 577 register them simultaneously with its home address. The BID MUST be 578 unique for a given home address and care-of address pair. The value 579 should be an integer between 1 and 65535. Zero value MUST NOT be 580 used as BIDs. If a mobile node has only one care-of address, the 581 assignment of a BID is not needed until it has multiple care-of 582 addresses to register with, at which time all of the care-of 583 addresses MUST be mapped to BIDs. 585 5.2. Return Routability: Sending CoTI and Receiving CoT 587 When a mobile node wants to register multiple care-of address with a 588 correspondent node, it MUST have the valid Care-of Keygen token per 589 care-of address. The mobile node needs only one Home Keygen token 590 for its home address. 592 The mobile node MUST include a Binding Identifier mobility option in 593 the Care-of Test Init message. It MUST NOT set any flags in the 594 mobility option. The receiver (i.e. correspondent node) will 595 calculate a care-of Keygen token as specified in [RFC-3775] and reply 596 with a Care-of Test message, with the Binding Identifier mobility 597 option as described in Section 6.2. When the mobile node receives 598 the Care-of Test message, the message is verified as in [RFC-3775]. 599 If a Binding Identifier mobility option is not present in the CoT 600 message in reply to the CoTI message that included a Binding 601 Identifier mobility option, the mobile node must assume that the 602 correspondent node does not support Multiple Care-of Address 603 registration. Thus, the mobile node MUST NOT use a Binding 604 Identifier mobility option in any future Binding Updates to that 605 correspondent node. The mobile node MAY skip re-sending regular CoTI 606 message and keep the received care-of Keygen token for the regular 607 Binding Update. 609 5.3. Binding Registration 611 For the multiple Care-of Addresses registration, the mobile node MUST 612 include a Binding Identifier mobility option(s) in the Binding Update 613 as shown in Figure 6. The BID is copied from a corresponding Binding 614 Update List entry to the BID field of the Binding Identifier mobility 615 option. When IPsec ESP is used for protecting the Binding Update, 616 the care-of address can be carried in the Care-of Address field of 617 the Binding Identifier mobility option. If this is done, the 618 alternate care-of address option MUST NOT be included in the Binding 619 Update. For binding registration to a correspondent node, the mobile 620 node MUST have both active Home and Care-of Keygen tokens for Kbm 621 (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. 622 The care-of Keygen tokens MUST be maintained for each care-of address 623 that the mobile node wants to register to the correspondent node. 624 The Binding Update to the correspondent node is protected by the 625 Binding Authorization Data mobility option that is placed after the 626 Binding Identifier mobility option. 628 IPv6 header (src=CoA, dst=HA) 629 IPv6 Home Address Option 630 ESP Header* 631 Mobility header 632 Binding Update 633 Mobility Options 634 Binding Identifier mobility option 635 Binding Authorization mobility option+ 636 (*) if necessary, for home registration 637 (+) if necessary, for route optimization 639 Figure 6: Binding Update for Binding Registration 641 5.4. Bulk Registration 643 Bulk registration is an optimization for binding multiple care-of 644 addresses to a home address using a single Binding Update. This is 645 very useful if the mobile node, for instance, does not want to send a 646 lot of signaling messages through an interface where the bandwidth is 647 scarce. This document specifies bulk registration only for the 648 mobile node's home registration. A mobile node performing bulk 649 registration with a correspondent node is out of scope. 651 To use bulk registration, the mobile node includes a Binding 652 Identifier Mobility option for each BID and Care-of address pair it 653 wants to register in the same Binding Update message. This is shown 654 in Figure 7. The rest of the fields and options in the Binding 655 Update such as Lifetime, Sequence Number, and the flags in the 656 Binding Update are common across all care-of addresses. The 657 alternate care-of address option MUST NOT be used. 659 IPv6 header (src=CoA, dst=HA) 660 IPv6 Home Address Option 661 ESP Header 662 Mobility header 663 Binding Update 664 Mobility Options 665 Binding Identifier mobility options (CoA) 667 Figure 7: Binding Update for Bulk Registration 669 If the mobile node wants to replace existing registered bindings on 670 the home agent with the bindings in the sent Binding Update, it sets 671 the 'O' flag. Section 6.3 describes this registration procedure in 672 detail. 674 5.5. Binding De-Registration 676 When a mobile node decides to delete all the bindings for its home 677 address, it sends a regular de-registration Binding Update with 678 lifetime set to zero as defined in [RFC-3775]. The Binding 679 Identifier mobility option is not required. 681 If a mobile node wants to delete a particular binding(s) from its 682 home agent and correspondent nodes, the mobile node sends a Binding 683 Update with lifetime set to zero and includes a Binding Identifier 684 mobility option(s) with the BID(s) it wants to de-register. The 685 receiver will remove only the care-of address(es) that match(es) the 686 specified BID(s). The care-of addresses field in each mobility 687 option SHOULD be omitted by the sender (i.e. the field does not 688 appear in the option) and MUST be ignored by the receiver. This is 689 because the receiver will remove the binding that matches the 690 specified BID. 692 5.6. Returning Home 694 The mobile node may return to the home link, by attaching to the home 695 link through one of its interfaces. When the mobile node wants to 696 return home, it should be configured with information on what 697 interface it needs to use. The mobile node may use only the 698 interface with which it is attached to the home link, only the 699 interfaces still attached to the visited link(s) or use both 700 interfaces attached to the home link and visited link(s) 701 simultaneously. The following describes each option in more detail. 703 5.6.1. Using only Interface attached to the Home Link 705 The mobile node returns home and de-registers all the bindings as 706 shown in Figure 2 and as defined in [RFC-3775]. De-registering all 707 the bindings is the same as binding de-registration from foreign link 708 described in Section 5.5. After the de-registration step, all the 709 packets routed by the home agent are only forwarded to the interface 710 attached to the home link, even if there are other active interfaces 711 attached to the visited link(s). While the mobile node de-registers 712 all the bindings from the home agent, it may continue registering 713 bindings for interface(s) attached to visited link(s) to the 714 correspondent node as shown in Figure 2. 716 5.6.2. Using only Interface attached to the Visited Link 718 The mobile node returns home and shuts down the interface attached to 719 the home link as shown in Figure 3. Before shutting down the 720 interface, any binding for the care-of address previously associated 721 with the interface should be deleted. To delete the binding cache 722 entry, the mobile node SHOULD send a de-registration Binding Update 723 with the lifetime set to zero and include the corresponding BID 724 information. If the mobile node does not send a de-registration 725 Binding Update, the binding for the care-of address previously 726 assigned to the interface remains at the home agent until its 727 lifetime expires. 729 In this scenario, despite the fact that the mobile node is connected 730 to its home link, all of its traffic is sent and received via the 731 home agent and its foreign links. 733 5.6.3. Simultaneous Home and Visited Link Operation 735 [Problems of Simultaneous Home and Foreign Attachments] 737 The mobile node returns home and continues using all the interfaces 738 attached to both foreign and home links as shown in Figure 4. The 739 mobile node indicates this by setting the 'H' flag in the BID 740 mobility option as defined below. There are additional requirements 741 on the Returning Home procedures for possible Neighbor Discovery 742 states conflicts at the home link. 744 In [RFC-3775], the home agent intercepts packets meant for the mobile 745 node using the Proxy Neighbor Discovery [RFC-2461] while the mobile 746 node is away from the home link. When the mobile node returns home, 747 the home agent deletes the binding cache and stops proxying for the 748 home address so that a mobile node can configure its home address on 749 the interface attached to the home link. In this specification, a 750 mobile node may return home, configure the home address on the 751 interface attached to the home link, but still use the interfaces 752 attached to the foreign links. In this case, a possible conflict 753 arises when the both the home agent and the mobile node try to defend 754 the home address. If the home agent stops proxying for the home 755 address, the packets are always routed to the interface attached to 756 the home link and are never routed to the interfaces attached to the 757 visited links. It is required to avoid the conflict between the home 758 agent and the mobile node, while still allowing the simultaneous use 759 of home and foreign links. The following describes the mechanism for 760 achieving this. 762 [Overview and Approach] 764 In this specification, the home agent MUST intercept all the packets 765 meant for the mobile node and decide whether to send the traffic 766 directly to the home address on the link or tunnel to the care-of 767 address. The home agent intercepts all the packets even when the 768 mobile node is attached to the home link through one of its 769 interfaces. The home agent would make this decision based on the 770 type of flow. How to make this decision is out of scope in this 771 document. 773 Two scenarios are illustrated in Figure 4, depending on whether the 774 Home Agent is the only router at the home link or not. The 775 difference is on who defends the home address by (Proxy) Neighbor 776 Discovery on the home link. 778 1. Mobile node defends the home address by the regular Neighbor 779 Discovery Protocol (illustrated as topology-a in Figure 4). The 780 home agent is the only router on the home link. Therefore the 781 home agent is capable of intercepting packets without relying on 782 the proxy Neighbor Discovery protocol and the mobile node can 783 manage the Neighbor Cache entry of the home address on the home 784 link as a regular IPv6 node. 786 2. If there are other routers on the home link apart from the home 787 agent, then it cannot be guaranteed that all packets meant for 788 the mobile node are routed to the home agent. In this case, the 789 mobile node MUST NOT operate Neighbor Discovery protocol for the 790 home address on the home link. This allows the home agent to 791 keep using proxy neighbor discovery and thus it keeps receiving 792 all the packets sent to the mobile node's home address. If the 793 home agent, according to its local policy, needs to deliver 794 packets to the mobile node over the home link, an issue arises 795 with respect to how the home agent discovers the mobile node's 796 link local address. This specification uses Link-layer Address 797 (LLA) Option defined in [RFC-4068bis] in order to carry the 798 mobile node's link-layer address in the Binding Update. 799 Likewise, the mobile node would also know the link-layer address 800 of the default router address to send packets from the home link 801 without Neighbor Discovery. The link-layer address is used to 802 transmit packets from and to the mobile node on the home link. 803 The packets are transmitted without the Neighbor Discovery 804 protocol by constructing the link-layer header manually. This 805 operation is similar to Mobile IPv6 [RFC-3775] when a mobile node 806 sends a deregistration binding update to the home agent's link- 807 layer address in returning home operation. 809 [Sending Deregistration Binding Update] 811 o As soon as a mobile node returns home, it sends a de-registration 812 Binding Update to the home agent from the interface attached to 813 the home link. 815 o The mobile node MUST include the BID mobility option specifying 816 the BID the mobile node had previously associated with the 817 interface attached to the home link. The 'H' flag MUST be set in 818 the BID mobility option. Any address MUST NOT be set in the 819 Care-of Address field in the BID mobility option. When the 'H' 820 flag is set, the home agent recognizes that the mobile node wants 821 to continue using interfaces attached to both home and visited 822 links. Note that H flag MUST be set for all the binding updates 823 sent from the mobile node (ex. Binding Update for the 824 interface(s) attached to the foreign link(s)). 826 o The mobile node SHOULD include the Link-layer Address (LLA) Option 827 [RFC-4068bis] to notify the mobile node's link-layer address to 828 the home agent, too. The option code of the Link-layer Address 829 (LLA) option MUST be set to '2' (Link-layer Address of the mobile 830 node). This link-layer address is required for the home agent to 831 send the Binding Acknowledgement and to forward the mobile node's 832 packet. 834 o According to [RFC-3775], the mobile node MUST start responding to 835 Neighbor Solicitation for its home address right after it sends 836 the deregistration Binding Update to the home agent. However, in 837 this specification, the mobile node MUST NOT respond to Neighbor 838 Solicitation before receiving a Binding Acknowledgement, since the 839 home agent may continue proxying for the home address. If the 840 mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value 841 in the received Binding Acknowledgment, it MUST NOT respond to 842 Neighbor Solicitation even after the Binding Acknowledgement. 844 [Sending Binding Acknowledgement] 846 o When the home agent sends the Binding Acknowledgement after 847 successfully processing the binding de-registration, it MUST set 848 the status value to either 0 [Binding Update Accepted] or to [MCOA 849 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 850 Acknowledgment depending on home agent configuration at the home 851 link. The new values are: 853 * Binding Update Accepted (0): NDP is permitted for the home 854 address at the home link. This is regular returning home 855 operation of [RFC-3775] 857 * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home 858 address at the home link 860 If the binding update is rejected, the appropriate error value 861 MUST be set to the status field. In this case, the home agent 862 operation is same as [RFC-3775]. 864 o If the home agent is the only router at the home link, it stops 865 proxy Neighbor Discover for the requested home address and 866 responds with the [Binding Update Accepted] status value to the 867 mobile node. Since the mobile node will not reply to Neighbor 868 Solicitation for the home address before receiving the Binding 869 Acknowledgement, the home agent SHOULD use the link-layer address 870 carried by the Link Layer Address option [RFC-4068bis] in the 871 received Binding Update. After the completion of the binding 872 deregistration, the mobile node starts regular Neighbor Discovery 873 operations for the home address on the home link. The neighbor 874 cache entry for the home address is created by the regular 875 exchange of Neighbor Solicitation and Neighbor Advertisement. 877 o On the other hand, if the home agent is not the only router on the 878 home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status 879 field of the BID mobility option. The home agent learns the 880 mobile node's link-layer address by receiving the link-layer 881 address option carried by the Binding Update. It stores the link- 882 layer address as a neighbor cache entry for the mobile node so 883 that it can send the packets to the mobile node's link-layer 884 address. 886 o Note that the use of proxy Neighbor Discovery is easier way to 887 intercept the mobile nodes' packets instead of IP routing in some 888 deployment scenarios. Therefore, even if a home agent is the only 889 router, it is an implementation and operational choice whether the 890 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 891 WO/NDP]. 893 o If BID option is not included in the Binding Acknowledgement, the 894 home agent might not recognize the simultaneous home and foreign 895 attachment. The home agent might have processed the de- 896 registration Binding Update as a regular de-registration as 897 described in [RFC-3775] and deletes all the registered binding 898 cache entries for the mobile node. Thus, the mobile node SHOULD 899 stop using the interface attached to foreign link and use only the 900 interface attached to the home link. 902 [Sending Packets from the Home Link] 904 o When the mobile node receives the Binding Acknowledgement with the 905 status value 'Binding Update Accepted' and the BID option, it can 906 configure its home address to the interface attached to the home 907 link and start operating Neighbor Discovery for the home address 908 on the home link. Packets can be transmitted from and to the 909 mobile node as if the mobile node is a regular IPv6 node. 911 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 912 the Binding Acknowledgement, it MUST NOT operate Neighbor 913 Discovery for the home address. When the mobile node sends 914 packets from the interface attached to the home link, it MUST 915 learn the link-layer address of the next hop (i.e. default router 916 of the mobile node). A mobile node learns the default router's 917 link-layer address from a Source Link-Layer Address option in 918 Router Advertisements. The mobile node sends packets directly to 919 the default router's link-layer address. This is done by 920 constructing the packet including link-layer header with the 921 learned link-layer address of the default router. The home agent 922 also forwards the packet to the mobile node on the home link by 923 using the mobile node's link-layer address. The link-layer 924 address SHOULD be cached when the home agent received the 925 deregistration Binding Update message. 927 [Leaving from the Home Link] 929 o When the mobile node detaches from the home link, it SHOULD 930 immediately send a binding update for one of active care-of 931 address with H flag unset. When the 'H' flag of BID option is 932 unset in any Binding Update, the home agent stop forwarding the 933 mobile node's packet to the home link. 935 o On the other hand, if the mobile node does not have any active 936 care-of address to send a Binding Update and leaves the home link 937 (i.e. the mobile node is completely disconnected), the home agent 938 continues forwarding packets to the mobile node until the 939 expiration of all the binding cache entries for the home address. 940 Once all the bindings are expired, the mobile node is assumed to 941 be disconnected completely from networks. 943 [Changing Behavior during the attachment to the home link] 945 If a mobile node decides to return home completely without any active 946 foreign link attachment, it simply sends a deregistration binding 947 update as described in Section 5.6.1. Once the home agent receives 948 such de-registration binding update, the home agent clears all the 949 binding and states for the mobile node. 951 If a mobile node decides to stop using the interface attached to the 952 home link, it simply sends a binding update from the one of active 953 care-of address. In the Binding Update, the mobile node should 954 include the BID option for the care-of address and unset the H flag 955 of BID option. The home agent clears the states of the mobile node 956 for the interface attached to the home link and stop forwarding the 957 packets to the mobile node on the home link. 959 5.7. Receiving Binding Acknowledgement 961 The verification of a Binding Acknowledgement is the same as Mobile 962 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 963 Binding Acknowledgement is described in Section 6.3. 965 If a mobile node includes a Binding Identifier mobility option in a 966 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 967 carry a Binding Identifier mobility option. If no such mobility 968 option is included in the Binding Acknowledgement in response to a 969 Binding Update for multiple care-of address registration, this 970 indicates that the originating node of the Binding Acknowledgement 971 does not support processing the Binding Identifier mobility option. 972 The mobile node MUST then stop multiple care-of address registration 973 with that node. 975 If a Binding Identifier mobility option is present in the received 976 Binding Acknowledgement, the mobile node checks the status field in 977 the option. If the status value in the Binding Identifier mobility 978 option is zero, the mobile node uses the value in the Status field of 979 the Binding Acknowledgement. Otherwise, it uses the value in the 980 Status field of the Binding Identifier mobility option. 982 If the status code is greater than or equal to 128, the mobile node 983 starts relevant operations according to the error code. Otherwise, 984 the mobile node assumes that the originator (home agent or 985 correspondent node) successfully registered the binding information 986 and BID for the mobile node. 988 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 989 stop registering multiple bindings to the node that sent the 990 Binding Acknowledgement. 992 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 993 mobile node SHOULD stop using bulk registrations with the node 994 that sent the Binding Acknowledgement. 996 o If [MCOA MALFORMED] is specified, it indicates that the binding 997 identifier mobility option is formatted wrongly. 999 o If [MCOA BID CONFLICT] is specified, the binding entry specified 1000 by the Binding Identifier mobility option is already registered as 1001 a regular binding. In such case, the mobile node SHOULD stop 1002 sending Binding Updates with BID, or SHOULD use the 'O' flag to 1003 reset all the registered bindings. 1005 5.8. Receiving Binding Refresh Request 1007 The verification of a Binding Refresh Request is the same as in 1008 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 1009 a Binding Refresh Request is described in section Section 6.4. 1011 If a mobile node receives a Binding Refresh Request with a Binding 1012 Identifier mobility option, it indicates that the node sending the 1013 Binding Refresh Request message is requesting the mobile node to send 1014 a new Binding Update for the BID. The mobile node SHOULD then send a 1015 Binding Update only for the respective binding. The mobile node MUST 1016 include a Binding Identifier mobility option in the Binding Update. 1018 5.9. Bootstrapping 1020 When a mobile node bootstraps and registers multiple bindings for the 1021 first time, it MUST set the 'O' flag in the Binding Identifier 1022 mobility option. If old bindings still exists at the home agent, the 1023 mobile node has no knowledge of which bindings still exist at the 1024 home agent. This scenario happens when a mobile node reboots and 1025 looses state regarding the registrations. If the 'O' flag is set, 1026 all the bindings are replaced by the new binding(s). If the mobile 1027 node receives the Binding Acknowledgement with the status code set to 1028 135 [Sequence number out of window], it MUST retry sending a Binding 1029 Update with the last accepted sequence number indicated in the 1030 Binding Acknowledgement. 1032 The 'O' flag can also be used in individual Binding Updates sent to 1033 the correspondent nodes to override any existing binding cache 1034 entries at the correspondent node. 1036 6. Home Agent and Correspondent Node Operation 1038 6.1. Searching Binding Cache with Binding Identifier 1040 If either a correspondent node or a home agent has multiple bindings 1041 for a mobile node in their binding cache database, it can use any of 1042 the bindings to communicate with the mobile node. This section 1043 explains how to retrieve the desired binding for the binding 1044 management. This document does not provide any mechanism to select 1045 the suitable binding for forwarding data packets. 1047 A node which is either a correspondent node or a home agent SHOULD 1048 use both the home address and the BID as the search key of the 1049 binding cache if it knows the corresponding BID (ex. when processing 1050 signaling messages). In the example below, if a node searches the 1051 binding with the home address and BID2, it gets binding2 for this 1052 mobile node. 1054 binding1 [a:b:c:d::EUI, care-of address1, BID1] 1055 binding2 [a:b:c:d::EUI, care-of address2, BID2] 1056 binding3 [a:b:c:d::EUI, care-of address3, BID3] 1058 Figure 8: Searching the Binding Cache 1060 The node learns the BID when it receives a Binding Identifier 1061 mobility option. At that time, the node MUST look up its binding 1062 cache database with the home address and the BID retrieved from the 1063 Binding Update. If the node does not know the BID, it searches for a 1064 binding with only the home address. In such a case, the first 1065 matched binding is found. If the node does not desire to use 1066 multiple bindings for a mobile node, it can simply ignore the BID. 1068 6.2. Receiving CoTI and Sending CoT 1070 When a correspondent node receives a CoTI message which contains a 1071 Binding Identifier mobility option, it processes it as follows. 1073 First, the CoTI message is verified as specified in [RFC-3775]. The 1074 Binding Identifier mobility option is processed as follows: 1076 o If a correspondent node does not understand a Binding Identifier 1077 mobility option, it just ignores and skips processing the option. 1078 The calculation of a care-of Keygen token will thus be done 1079 without a BID value. The correspondent node returns a CoT message 1080 without a Binding Identifier mobility option. The mobile node 1081 knows whether the correspondent supports processing the Binding 1082 Identifier mobility option, by checking if the option is present 1083 in the CoT message. 1085 o If either the 'C' or the 'O' flag is set in the Binding Identifier 1086 mobility option, the correspondent Node SHOULD NOT calculate a 1087 care-of Keygen token, but MUST include a Binding Identifier 1088 mobility option with status value set to [MCOA MALFORMED] in the 1089 Care-of Test message. 1091 o Otherwise, the correspondent node MUST include a Binding 1092 Identifier mobility option with status value set to zero (success) 1093 in the Care-of Test message. 1095 o The Care-of address field of each Binding Identifier mobility 1096 option, can be omitted, because the mobile node can identify the 1097 corresponding Binding Update list entry using the BID. 1099 6.3. Processing Binding Update 1101 If a Binding Update does not contain a Binding Identifier mobility 1102 option, its processing is same as in [RFC-3775]. If the receiver 1103 already has multiple bindings for the home address, it MUST replace 1104 all the existing bindings by the received binding. As a result, the 1105 receiver node MUST have only one binding cache entry for the mobile 1106 node. If the Binding Update is for de-registration, the receiver 1107 MUST delete all existing bindings from its Binding Cache. 1109 If the Binding Update contains a Binding Identifier mobility 1110 option(s), it is first validated according to section 9.5.1 of [RFC- 1111 3775]. Then the receiver processes the Binding Identifier mobility 1112 option(s) as described in the following steps. 1114 o The length value is examined. The length value MUST be either 4, 1115 8, or 20 depending on the Care-of Address field. If the length is 1116 incorrect, the receiver MUST reject the Binding Update and returns 1117 the status value set to [MCOA MALFORMED]. 1119 o When the Length value is either 12 or 20, the care-of address MUST 1120 be present in the Binding Identifier mobility option. If the 1121 valid care-of address is not present, the receiver MUST reject the 1122 Binding Identifier mobility option and returns the status value 1123 set to [MCOA MALFORMED]. 1125 o When multiple Binding Identifier mobility options are present in 1126 the Binding Update, it is treated as bulk registration. If the 1127 receiving node is a correspondent node, it MUST reject the Binding 1128 Update and returns the status value in the binding acknowledgement 1129 set to [MCOA BULK REGISTRATION NOT SUPPORT] 1131 o If the Lifetime field in the Binding Update is set to zero, the 1132 receiving node deletes the binding entry that corresponds to the 1133 BID in the Binding Identifier mobility option. If the receiving 1134 node does not have an appropriate binding for the BID, it MUST 1135 reject the Binding Update and send a Binding Acknowledgement with 1136 status set to 133 [not home agent for this mobile node]. 1138 o If the 'O' flag is set in the de-registering Binding Update, it is 1139 ignored. If the 'H' flag is set, the home agent stores a home 1140 address in the Care-of Address field of the binding cache entry. 1141 The home agent MUST follow the descriptions described in 1142 Section 5.6. 1144 o If the Lifetime field is not set to zero, the receiving node 1145 registers a binding with the specified BID as a mobile node's 1146 binding. The Care-of address is obtained from the Binding Update 1147 packet as follows: 1149 * If the Length value of the Binding Identifier mobility option 1150 is 20, the care-of address is copied the IPv6 address from the 1151 care-of address field in the Binding Identifier mobility 1152 option. When the Length value is 12, the address MUST be the 1153 IPv4 valid address. Detail information can be found in 1154 Section 8. 1156 * If the Length value of the Binding Identifier mobility option 1157 is 4, the care-of address is copied from the source address 1158 field of the IPv6 header. 1160 * If the Length value of the Binding Identifier mobility option 1161 is 4 and an alternate care-of address is present, the care-of 1162 address is copied from the Alternate Care-of address mobility 1163 option. 1165 o Once the care-of address(es) have been retrieved from the Binding 1166 Update, the receiving nodes creates new binding(s). 1168 * If only the 'O' flag is set in the Binding Identifier mobility 1169 option, the home agent removes all the existing bindings and 1170 registers the received bindings. 1172 * If the receiver has a regular binding which does not have BID 1173 for the mobile node, it must not process the binding update. 1174 The receiver should sent a binding acknowledgement with status 1175 set to [MCOA BID CONFLICT]. 1177 * If the receiver already has a binding with the same BID but 1178 different care-of address, it MUST update the binding and 1179 respond with a Binding Acknowledgement with status set to 0 1180 [Binding Update accepted]. 1182 * If the receiver does not have a binding entry for the BID, it 1183 registers a new binding for the BID and responds with a Binding 1184 Acknowledgement with status set to 0 [Binding Update accepted]. 1186 If all the above operations are successfully completed, a Binding 1187 Acknowledgement containing the Binding Identifier mobility options 1188 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 1189 is sent, all the Binding Identifier mobility options stored in the 1190 Binding Update MUST be copied to the Binding Acknowledgement except 1191 the status field. The Care-of address field in each Binding 1192 Identifier mobility option, however, can be omitted, because the 1193 mobile node can match a corresponding binding update list entry using 1194 the BID. 1196 When a correspondent node sends a Binding Acknowledgement, the status 1197 value MUST be always stored in the Status field of the Binding 1198 Acknowledgement and the Status field of Binding Identifier mobility 1199 option MUST be always set to zero. 1201 When the home agent sends a Binding Acknowledgement, the status value 1202 can be stored in the Status field of either a Binding Acknowledgement 1203 or a Binding Identifier mobility option. If the status value is 1204 specific to one of bindings in the bulk registration, the status 1205 value MUST be stored in the Status field in the corresponding Binding 1206 Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be 1207 set to the Status field of the Binding Acknowledgement so that the 1208 receiver can examine the Status field of each Binding Identifier 1209 mobility option for further operations. Otherwise, the status field 1210 of the Binding Identifier mobility option MUST be set to zero and the 1211 home agent status field of the Binding Acknowledgement is used. 1213 6.4. Sending Binding Refresh Request 1215 When a node (home agent or correspondent node) sends a Binding 1216 Refresh Request for a particular binding created with the BID, the 1217 node SHOULD include the Binding Identifier mobility option in the 1218 Binding Refresh Request. The node MAY include multiple Binding 1219 Identifier mobility options if there are multiple bindings that need 1220 to be refreshed. 1222 6.5. Receiving Packets from Mobile Node 1224 When a node receives packets with a Home Address destination option 1225 from a mobile node, it MUST check that the care-of address that 1226 appears in the source address field of the IPv6 header MUST be equal 1227 to one of the care-of addresses in the binding cache entry. If no 1228 binding is found, the packets MUST be discarded. The node MUST also 1229 send a Binding Error message as specified in [RFC-3775]. This 1230 verification MUST NOT be done for a Binding Update. 1232 7. Network Mobility Applicability 1234 The binding management mechanisms are the same for a mobile host that 1235 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1236 Support protocol [RFC-3963]. Therefore the extensions described in 1237 this document can also be used to support a mobile router with 1238 multiple care-of addresses. 1240 8. DSMIPv6 Applicability 1242 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1243 register an IPv4 care-of address instead of the IPv6 care-of address 1244 when the mobile node is attached to an IPv4-only access network. It 1245 also allows the mobile node to acquire an IPv4 home address in 1246 addition to an IPv6 home address for use with IPv4-only correspondent 1247 nodes. This section describes how multiple care-of address 1248 registration works with IPv4 care-of and home addresses. 1250 8.1. IPv4 Care-of Address Registration 1252 The mobile node can use the extensions described in the document to 1253 register multiple care-of addresses, even if some of the care-of 1254 addresses are IPv4 address. 1256 Bulk registration MUST NOT be used for the initial binding from an 1257 IPv4 care-of address. This is because, the Binding Update and 1258 binding acknowledgement exchange is used to detect NAT on the path 1259 between the mobile node and the home agent. So the mobile node needs 1260 to check for a NAT between each IPv4 care-of address and the home 1261 agent. 1263 The Binding Update MUST be sent to the IPv4 home agent address by 1264 using UDP and IPv4 headers as shown in Figure 9. It is similar to 1265 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1266 used when the BID mobility option is used. 1268 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1269 UDP Header 1270 IPv6 header (src=V6HoA, dst=HAADDR) 1271 ESP Header 1272 Mobility header 1273 -Binding Update 1274 Mobility Options 1275 - Binding Identifier (IPv4 CoA) 1277 Figure 9: Initial Binding Update for IPv4 Care-of Address 1279 If a NAT is not detected, the mobile node can update the IPv4 care-of 1280 address by using bulk registration. The mobile node can register the 1281 IPv4 care-of address along with other IPv4 and IPv6 care-of 1282 addresses. Figure 10 shows the Binding Update format when the mobile 1283 node sends a Binding Update from one of its IPv6 care-of addresses. 1284 If the mobile node sends a Binding Update from IPv4 care-of address, 1285 it MUST follow the format described in Figure 9. Note that the IPv4 1286 Care-of Address must be registered by non bulk Binding registration, 1287 whenever it is changed. 1289 IPv6 header (src=V6CoA, dst=HAADDR) 1290 IPv6 Home Address Option 1291 ESP Header 1292 Mobility header 1293 -Binding Update 1294 Mobility Options 1295 - Binding Identifier (IPv6/v4 CoA) 1296 - Binding Identifier (IPv6/v4 CoA) 1297 - ... 1299 Figure 10: Binding Bulk Registration for IPv4 care-of address 1301 If the home agent rejects the IPv4 care-of address, it MUST store the 1302 error code value in the Status field of the BID mobility option. 1304 8.2. IPv4 HoA Management 1306 When the mobile node wants to configure an IPv4 home address in 1307 addition to the IPv6 home address, it can request for one using the 1308 IPv4 Home Address option in the Binding Update. If the home agent 1309 accepts the Binding Update, the mobile node can now register multiple 1310 care-of addresses for the IPv4 home address in addition to the IPv6 1311 home address. The same set of care-of addresses will be registered 1312 for both IPv6 and IPv4 home addresses. The mobile node cannot bind 1313 different set of care-of addresses to each home address. 1315 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1316 acknowledgement option in the Binding Acknowledgement only if the 1317 mobile node had requested for an IPv4 home address in the 1318 corresponding Binding Update. The IPv4 address acknowledgement 1319 option MUST be present before any BID option. The status field of 1320 the IPv4 address acknowledgement option contains only the error code 1321 corresponding to the IPv4 home address management. The error values 1322 related to the IPv4 care-of address registration MUST be stored in 1323 the BID mobility option. 1325 9. IPsec and IKEv2 interaction 1327 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1328 use of IPsec to protect signaling messages like Binding Updates, 1329 Binding Acknowledgements and return routability messages. IPsec may 1330 also be used protect all tunneled data traffic. The Mobile IPv6- 1331 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1332 setup the required IPsec security associations. The following 1333 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1334 respect to the use of IKEv2 and IPsec. 1336 o There is only one primary care-of address per mobile node. 1338 o The primary care-of address is stored in the IPsec database for 1339 tunnel encapsulation and decapsulation. 1341 o When the home agent receives a packet from the mobile node, the 1342 source address is verified against the care-of address in the 1343 corresponding binding cache entry. If the packet is a reverse 1344 tunneled packet from the mobile node, the care-of address check is 1345 done against the source address on the outer IPv6 header. The 1346 reverse tunnel packet could either be a tunneled HoTi message or 1347 tunneled data traffic to the correspondent node. 1349 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1350 the care-of address. The IKE SA is based on the care-of address 1351 of the mobile node. 1353 The above assumptions may not be valid when multiple care-of 1354 addresses are used by the mobile node. In the following sections, 1355 the main issues with the use of multiple care-of address with IPsec 1356 are addressed. 1358 9.1. Use of Care-of Address in the IKEv2 exchange 1360 For each home address the mobile node sets up security associations 1361 with the home agent, the mobile node must pick one care-of address 1362 and use that as the source address for all IKEv2 messages exchanged 1363 to create and maintain the IPsec security associations associated 1364 with the home address. The resultant IKEv2 security association is 1365 created based on this care-of address. 1367 If the mobile node needs to change the care-of address, it just sends 1368 a Binding Update with the care-of address it wants to use, with the 1369 corresponding Binding Identifier mobility option, and with the 'K' 1370 bit set. This will force the home agent to update the IKEv2 security 1371 association to use the new care-of address. If the 'K' bit is not 1372 supported on the mobile node or the home agent, the mobile node MUST 1373 re-establish the IKEv2 security association with the new care-of 1374 address. This will also result in new IPsec security associations 1375 being setup for the home address. 1377 9.2. Transport Mode IPsec protected messages 1379 For Mobile IPv6 signaling message protected using IPsec in transport 1380 mode, the use of a particular care-of address among multiple care-of 1381 addresses does not matter for IPsec processing. 1383 For Mobile Prefix Discovery messages, [RFC-3775] requires the home 1384 agent to verify that the mobile node is using the care-of address 1385 that is in the binding cache entry that corresponds to the mobile 1386 node's home address. If a different address is used as the source 1387 address, the message is silently dropped by the home agent. This 1388 document requires the home agent implementation to process the 1389 message as long as the source address is one of the care-of addresses 1390 in the binding cache entry for the mobile node. 1392 9.3. Tunnel Mode IPsec protected messages 1394 The use of IPsec in tunnel mode with multiple care-of address 1395 introduces a few issues that require changes to how the mobile node 1396 and the home agent send and receive tunneled traffic. The route 1397 optimization mechanism described in [RFC-3775] mandates the use of 1398 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1399 mobile node and the home agent may also choose to protect all reverse 1400 tunneled payload traffic with IPsec in tunnel mode. The following 1401 sections address multiple care-of address support for these two types 1402 of messages. 1404 9.3.1. Tunneled HoTi and HoT messages 1406 The mobile node MAY use the same care-of address for all HoTi 1407 messages sent reverse tunneled through the home agent. The mobile 1408 node may use the same care-of address irrespective of which 1409 correspondent node the HoTi message is being sent. RFC 3775 requires 1410 the home agent to verify that the mobile node is using the care-of 1411 address that is in the binding cache entry, when it receives a 1412 reverse tunneled HoTi message. If a different address is used as the 1413 source address, the message is silently dropped by the home agent. 1414 This document requires the home agent implementation to decapsulate 1415 and forward the HoTi message as long as the source address is one of 1416 the care-of addresses in the binding cache entry for the mobile node. 1418 When the home agent tunnels a HoT message to the mobile node, the 1419 care-of address used in the outer IPv6 header is not relevant to the 1420 HoT message. So regular IPsec tunnel encapsulation with the care-of 1421 address known to the IPsec implementation on the home agent is 1422 sufficient. 1424 9.3.2. Tunneled Payload Traffic 1426 When the mobile sends and receives multiple traffic flows protected 1427 by IPsec to different care-of addresses, the use of the correct 1428 care-of address for each flow becomes important. Support for this 1429 requires the following two considerations on the home agent. 1431 o When the home agent receives a reverse tunneled payload message 1432 protected by IPsec in tunnel mode, it must check that the care-of 1433 address is one of the care-of addresses in the binding cache 1434 entry. According to RFC 4306, the IPsec implementation on the 1435 home agent does not check the source address on the outer IPv6 1436 header. Therefore the care-of address used in the reverse 1437 tunneled traffic can be different from the care-of address used as 1438 the source address in the IKEv2 exchange. However, the Mobile 1439 IPv6 stack on the home agent MUST verify that the source address 1440 is one of the care-of addresses registered by the mobile node 1441 before decapsulating and forwarding the payload traffic towards 1442 the correspondent node. 1444 o For tunneled IPsec traffic from the home agent to the mobile node, 1445 The IPsec implementation on the home agent may not be aware of 1446 which care-of address to use when performing IPsec tunnel 1447 encapsulation. The Mobile IP stack on the home agent must specify 1448 the tunnel end point for the IPsec tunnel. This may require tight 1449 integration between the IPsec and Mobile IP implementations on the 1450 home agent. 1452 10. Security Considerations 1454 The security considerations for securing the Binding Update and 1455 binding acknowledgement messages with multiple care-of address are 1456 very similar to the security considerations for securing the Binding 1457 Update and binding acknowledgement. Please see [RFC-3775] for more 1458 information. The Binding Update and binding acknowledgement messages 1459 with multiple care-of addresses MUST be protected using IPsec as show 1460 in Section 9. Additional security considerations are described 1461 below. 1463 With simultaneous binding support, it is possible for a malicious 1464 mobile node to successfully bind a number of victims' addresses as 1465 valid care-of addresses for the mobile node with its home agent. 1466 Once these addresses have been bound, the malicious mobile node can 1467 perform a re-direction attack by instructing the home agent (e.g. 1468 setting filtering rules to direct a large file transfer) to tunnel 1469 packets to the victims' addresses. Such risk is highlighted in [ID- 1470 MIP6ANALYSIS]. These attacks are possible because the care-of 1471 addresses sent by the mobile node in the Binding Update messages are 1472 not verified by home agent, i.e., the home agent does not check if 1473 the mobile node is at the care-of address it is claiming to be. The 1474 security model for Mobile IPv6 assumes that there is a trust 1475 relationship between the mobile node and its home agent. Any 1476 malicious attack by the mobile node is traceable by the home agent. 1477 This acts as a deterrent for the mobile node to launch such attacks. 1479 Although such risk exists in Mobile IPv6, the risk level is escalated 1480 when simultaneous multiple care-of address bindings are performed. 1481 In Mobile IPv6, a mobile node can only have a single care-of address 1482 binding per home address at a given time. However, for simultaneous 1483 multiple care-of address bindings, a mobile node can have more than 1484 one care-of address binding per home address at a given time. This 1485 implies that a mobile node using simultaneous binding support can 1486 effectively bind more than a single victim's address. Another 1487 difference is the degree of risk involved. In the single care-of 1488 address binding case, once the re-direction attack is initiated, a 1489 malicious mobile node would be unable to use its home address for 1490 communications (such as to receive control packets pertaining to the 1491 file transfer). However, in the simultaneous binding support case, a 1492 malicious mobile node could bind a valid care-of address in addition 1493 to multiple victims addresses. This valid care-of address could then 1494 be used by the malicious mobile node to set up flow filtering rules 1495 at its home agent, thereby controlling and/or launching new re- 1496 direction attacks. 1498 Thus, in view of such risks, it is advisable for a home agent to 1499 employ some form of care-of address verification mechanism before 1500 using the care-of addresses as a valid routing path to a mobile node. 1501 Solutions related to this are described in [ID-COAVERIFY]. 1503 11. IANA Considerations 1505 The following Extension Types MUST be assigned by IANA: 1507 o Binding Identifier mobility option type: This must be assigned 1508 from the same space as mobility option in [RFC-3775]. 1510 o New Successful Status of Binding Acknowledgement: This status code 1511 must be assigned from the same space as binding acknowledgement 1512 status codes in [RFC-3775]. 1514 * MCOA NOTCOMPLETE (TBD) 1516 * MCOA RETURNHOME WO/NDP (TBD) 1518 o New Unsuccessful Status of Binding Acknowledgement: These status 1519 codes must also be assigned from the same space as binding 1520 acknowledgement status codes in [RFC-3775]. 1522 * MCOA MALFORMED (TBD) 1524 * MCOA BID CONFLICT (TBD) 1526 * MCOA PROHIBITED(TBD) 1528 * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 1530 12. Acknowledgements 1532 The authors would like to special thank George Tsirtsis for thorough 1533 review and suggestions. The authors would also like to thank 1534 Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin 1535 Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas 1536 Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to 1537 Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke 1538 Uehara, Masafumi Watari and Jun Murai for earlier work on this 1539 subject. 1541 13. References 1543 13.1. Normative References 1545 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1546 Requirement Levels", BCP 14, RFC 2119, March 1997. 1548 [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1549 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 1551 [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1552 Networks", RFC 2464, December 1998. 1554 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1555 in IPv6", RFC 3775, June 2004. 1557 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1558 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1559 January 2005. 1561 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1562 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1564 13.2. Informative References 1566 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1567 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1568 Interfaces and Global Addresses", 1569 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1570 progress), May 2008. 1572 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1573 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1575 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1576 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1577 draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. 1579 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1580 RFC 3753, June 2004. 1582 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1583 Terminology", RFC 4885, July 2007. 1585 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1586 and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-03 (work in 1587 progress), May 2008. 1589 [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of 1590 Addresses in Multiple Bindings Registration", 1591 draft-lim-mext-multiple-coa-verify-01 (work in progress), February 1592 2008. 1594 [RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers", 1595 draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April 1596 2008. 1598 Authors' Addresses 1600 Ryuji Wakikawa 1601 Toyota ITC / Keio University 1602 6-6-20 Akasaka, Minato-ku 1603 Tokyo 107-0052 1604 Japan 1606 Phone: +81-3-5561-8276 1607 Fax: +81-3-5561-8292 1608 Email: ryuji@jp.toyota-itc.com 1610 Vijay Devarapalli 1611 Wichorus 1612 3590 North First St 1613 San Jose, CA 95134 1614 USA 1616 Email: vijay@wichorus.com 1618 Thierry Ernst 1619 INRIA 1620 INRIA Rocquencourt 1621 Domaine de Voluceau B.P. 105 1622 Le Chesnay, 78153 1623 France 1625 Phone: +33-1-39-63-59-30 1626 Fax: +33-1-39-63-54-91 1627 Email: thierry.ernst@inria.fr 1628 URI: http://www.nautilus6.org/~thierry 1630 Kenichi Nagami 1631 INTEC NetCore Inc. 1632 1-3-3, Shin-suna 1633 Koto-ku, Tokyo 135-0075 1634 Japan 1636 Phone: +81-3-5565-5069 1637 Fax: +81-3-5565-5094 1638 Email: nagami@inetcore.com 1640 Full Copyright Statement 1642 Copyright (C) The IETF Trust (2008). 1644 This document is subject to the rights, licenses and restrictions 1645 contained in BCP 78, and except as set forth therein, the authors 1646 retain all their rights. 1648 This document and the information contained herein are provided on an 1649 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1650 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1651 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1652 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1653 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1654 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1656 Intellectual Property 1658 The IETF takes no position regarding the validity or scope of any 1659 Intellectual Property Rights or other rights that might be claimed to 1660 pertain to the implementation or use of the technology described in 1661 this document or the extent to which any license under such rights 1662 might or might not be available; nor does it represent that it has 1663 made any independent effort to identify any such rights. Information 1664 on the procedures with respect to rights in RFC documents can be 1665 found in BCP 78 and BCP 79. 1667 Copies of IPR disclosures made to the IETF Secretariat and any 1668 assurances of licenses to be made available, or the result of an 1669 attempt made to obtain a general license or permission for the use of 1670 such proprietary rights by implementers or users of this 1671 specification can be obtained from the IETF on-line IPR repository at 1672 http://www.ietf.org/ipr. 1674 The IETF invites any interested party to bring to its attention any 1675 copyrights, patents or patent applications, or other proprietary 1676 rights that may cover technology that may be required to implement 1677 this standard. Please address the information to the IETF at 1678 ietf-ipr@ietf.org. 1680 Acknowledgment 1682 Funding for the RFC Editor function is provided by the IETF 1683 Administrative Support Activity (IASA).