idnits 2.17.1 draft-ietf-monami6-multiplecoa-09.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 1637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1661. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 28, 2008) is 5717 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 974, but not defined == Missing Reference: 'MCOA MALFORMED' is mentioned on line 1109, but not defined == Missing Reference: 'MCOA NOTCOMPLETE' is mentioned on line 1192, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-05 -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) Summary: 2 errors (**), 0 flaws (~~), 5 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 V. Devarapalli (Ed.) 5 Expires: March 1, 2009 Wichorus 6 T. Ernst 7 INRIA 8 K. Nagami 9 INTEC NetCore 10 August 28, 2008 12 Multiple Care-of Addresses Registration 13 draft-ietf-monami6-multiplecoa-09.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 March 1, 2009. 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 2001:db8::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 [2001:db8::EUI care-of address1 BID1] 249 binding [2001:db8::EUI care-of address2 BID2] 250 binding [2001:db8::EUI care-of address3 BID3] 251 correspondent node's binding 252 binding [2001:db8::EUI care-of address1 BID1] 253 binding [2001:db8::EUI care-of address2 BID2] 254 binding [2001:db8::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 if a BID is available. This is different from RFC 3775, 268 where only the home address is used for binding cache lookup. 269 Binding cache lookup is operated for either protocol signaling and 270 data packets. For the protocol signaling such as a binding update, 271 BID should be always carried by a BID sub-option in a protocol 272 signaling. Therefore, a correspondent binding cache that matches the 273 specified BID MUST be found from the binding cache database. On the 274 other hand, for the data packets, no BID information is carried in a 275 packet. The binding cache lookup may involve policy or flow filters 276 to retrieve a correspondent BID per packet in cases where some policy 277 or flow filters are used to direct a certain packet or flow to a 278 particular care-of address. However, the binding cache lookup using 279 policy or flow filters is out of scope for this document. If no such 280 mechanism is available and no BID is found for a packet, a node can 281 lookup based on only the home address. It uses the first matched 282 binding or a binding in a round robin fashion. This is 283 implementation dependent and configurable on a node. In case the 284 binding cache lookup for data packets, using the combination of home 285 address and BID, does not return a valid binding cache entry, the 286 home agent MAY perform another lookup based on only the home address. 288 The mobile node may return to the home link through one of its 289 interfaces. There are two options possible for the mobile node when 290 its returns home. Section 5.6 describes the returning home 291 procedures in more detail. 293 1. The mobile node uses only the interface with which it attaches to 294 the home link. This is illustrated in Figure 2. It de-registers 295 all bindings with the home agent related to all care-of 296 addresses. The interfaces still attached to the visited link(s) 297 are no longer going to be receiving any encapsulated traffic from 298 the home agent. On the other hand, the mobile node can continue 299 communicating with the correspondent node from the other 300 interfaces attached to foreign links by using route optimization. 301 Even if the mobile node is attached to the home link, it can 302 still send Binding Updates for other active care-of addresses 303 (CoA1 and CoA2) to correspondent nodes. Since the correspondent 304 node has bindings, packets are routed to each Care-of Addresses 305 directly. 307 +----+ 308 | CN | 309 +--+-+ 310 | 311 +---+------+ +----+ 312 +------+ Internet |----------+ HA | 313 | +----+-----+ +--+-+ 314 CoA2| | | Home Link 315 +--+--+ | --+---+------ 316 | MN +========+ | 317 +--+--+ CoA1 | 318 | | 319 +---------------------------+ 321 Binding Cache Database: 322 home agent's binding 323 none 324 correspondent node's binding 325 binding [2001:db8::EUI care-of address1 BID1] 326 binding [2001:db8::EUI care-of address2 BID2] 328 Figure 2: Using only Interface Attached to Home Link 330 2. The mobile node may simultaneously use both the interface 331 attached to the home link and the interfaces still attached to 332 the visited link(s) as shown in Figure 3. There are two possible 333 topologies depending on whether the home agent is only router on 334 the home link or not. The operation of Neighbor Discovery [RFC- 335 4861] is different in the two topologies. More details can be 336 found in Section 5.6.3. The home agent and the correspondent 337 node have the binding entries listed in Figure 3 in their binding 338 cache database in both topologies. The home agent also knows 339 that the mobile node is attached to the home link. All the 340 traffic from the Internet is intercepted by the home agent first 341 and routed to either the interface attached to the home link or 342 the one of the foreign links. How the home agent decides to 343 route a particular flow to the interface attached to the home 344 link or foreign link is out of scope in this document. 346 Topology-a) 347 +----+ 348 | CN | 349 +--+-+ 350 | 351 +---+------+ +----+ 352 +------+ Internet |----------+ HA | 353 | +----+-----+ +--+-+ 354 CoA2| | | Home Link 355 +--+--+ | --+---+------ 356 | MN +========+ | 357 +--+--+ CoA1 | 358 | | 359 +---------------------------+ 361 Topology-b) 362 +----+ 363 | CN | 364 +--+-+ 365 | 366 +---+------+ Router +----+ 367 +------+ Internet |-------R | HA | 368 | +----+-----+ | +--+-+ 369 CoA2| | | | Home Link 370 +--+--+ | --+-+-------+------ 371 | MN +========+ | 372 +--+--+ CoA1 | 373 | | 374 +---------------------------+ 376 Binding Cache Database: 377 home agent's binding 378 binding [2001:db8::EUI care-of address1 BID1] 379 binding [2001:db8::EUI care-of address2 BID2] 380 correspondent node's binding 381 binding [2001:db8::EUI care-of address1 BID1] 382 binding [2001:db8::EUI care-of address2 BID2] 384 Figure 3: Simultaneous Home and Visited Link Operation 386 4. Mobile IPv6 Extensions 388 This section summarizes the extensions to Mobile IPv6 necessary for 389 manage multiple bindings. 391 4.1. Binding Cache Structure and Binding Update List 393 The BID is required to be stored in the binding cache and binding 394 update list structure. 396 The sequence number value SHOULD be shared among all the binding 397 update list entries related to binding updates sent to a particular 398 home agent or correspondent node. Whenever a mobile node sends 399 either individual or bulk binding update, the sequence number is 400 incremented. On the other hand, if a mobile node manages an 401 individual sequence value per binding update list, a mobile node 402 SHOULD carefully select the sequence number value for the bulk 403 binding update. This is because all the bulk-registered bindings use 404 the same Sequence Number specified in the Binding Update. If each 405 binding uses different sequence number, a mobile node MUST use the 406 largest sequence number from the Binding Update list entries used for 407 the bulk registration. If the mobile node cannot select a sequence 408 number for all the bindings due to sequence number out of window, it 409 MUST NOT use the bulk registration for the binding whose sequence 410 number is out of window. A separate Binding Update should be sent 411 for the binding. 413 4.2. Binding Identifier Mobility Option 415 The Binding Identifier mobility option is included in the Binding 416 Update, Binding Acknowledgement, Binding Refresh Request, and Care-of 417 Test Init and Care-of Test message. The Binding Identifier Mobility 418 Option has an alignment requirement of 2n if the Care-of Address 419 field is not present. Otherwise, it has the alignment requirement of 420 8n + 2. 422 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Type = TBD | Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Binding ID (BID) | Status |O|H| Reserved | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 429 + + 430 : IPv4 or IPv6 care-of address (CoA) : 431 + + 432 +---------------------------------------------------------------+ 433 Figure 4: BID Mobility Option 435 Type 437 Type value for Binding Identifier is TBD 439 Length 441 8-bit unsigned integer. Length of the option, in octets, 442 excluding the Type and Length fields. It MUST be set to either 4, 443 12, or 20 depending on the care-of address field. When the 444 care-of address is not carried by this option, the length value 445 MUST be set to 4. If the IPv4 care-of address is stored in the 446 care-of address field, the length MUST be 12. Otherwise, the 447 Length value MUST be set to 20 for IPv6 care-of address. 449 Binding ID (BID) 451 The BID which is assigned to the binding indicated by the care-of 452 address in the Binding Update or the BID mobility option. The BID 453 is a 16-bit unsigned integer. The value of zero is reserved and 454 MUST NOT be used. 456 Status 458 The Status field is an 8-bit unsigned integer. When the Binding 459 Identifier mobility option is included in a Binding 460 Acknowledgement, this field overwrites the status field in the 461 Binding Acknowledgement. If this field is set to zero, the 462 receiver ignores this field and uses the registration status 463 stored in the Binding Acknowledgement message. The receiver MUST 464 ignore this field if the Binding Identifier mobility option is not 465 carried within either the Binding Acknowledgement or the Care-of 466 Test messages. The possible status codes are the same as the 467 status codes of Binding Acknowledgement. This Status field is 468 also used to carry error information related to the care-of 469 address test in the Care-of Test message. 471 Overwrite (O) flag 473 When this flag is set, all the binding cache entries for a mobile 474 node are replaced by new entries registering with this binding 475 update message. 477 Simultaneous Home and Foreign Binding (H) flag 478 This flag indicates that the mobile node registers multiple 479 bindings to the home agent while is attached to the home link. 480 This flag is valid only for a Binding Update sent to the home 481 agent. 483 Reserved 485 5 bits Reserved field. The value MUST be initialized to zero by 486 the sender, and MUST be ignored by the receiver. 488 Care-of Address 490 If a Binding Identifier mobility option is included in a Binding 491 Update, either IPv4 or IPv6 care-of address for the corresponding 492 BID can be stored in this field. If no address is specified in 493 this field, the length of this field MUST be zero (i.e. not 494 appeared in the option). If the option is included in any other 495 messages than a Binding Update, the length of this field MUST be 496 also zero. 498 4.3. New Status Values for Binding Acknowledgement 500 New status values for the status field in a Binding Acknowledgement 501 are defined for handling the multiple Care-of Addresses registration: 503 MCOA NOTCOMPLETE (TBD less than 128) 505 In bulk registration, not all the binding identifier mobility 506 option are successfully registered. Some of them are rejected. 507 The error status value of the failed mobility option is 508 individually stored in the status field of the binding identifier 509 mobility option. 511 MCOA RETURNHOME WO/NDP (TBD less than 128) 513 When a mobile node returns home, it MUST NOT use NDP for the home 514 address on the home link. This is explained in more detail in 515 Section 5.6 517 MCOA MALFORMED (TBD more than 128) 519 Registration failed because Binding Identifier mobility option was 520 not formatted correctly. 522 MCOA BID CONFLICT (TBD more than 128) 523 The home agent cannot cache both a regular binding and a BID 524 extended binding simultaneously. It returns this status value 525 when the received binding conflicts with the existing binding 526 cache entry(ies). 528 MCOA PROHIBITED(TBD more than 128) 530 It implies the multiple care-of address registration is 531 administratively prohibited. 533 MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) 535 Bulk binding registration is not supported. Note that the bulk 536 registration is optional procedure and might not be available on a 537 home agent. 539 5. Mobile Node Operation 541 5.1. Management of Care-of Address(es) and Binding Identifier(s) 543 There are two cases when a mobile node might acquire several care-of 544 addresses. Note that a mixture of the two cases is also possible. 546 1. A mobile node may be using several physical network interfaces 547 and acquires a care-of address on each of its interfaces. 549 2. A mobile node uses a single physical network interface, but 550 receives advertisements for multiple prefixes on the link the 551 interface is attached to. This will result in the mobile node 552 configuring several global addresses on the interface from each 553 of the announced prefixes. 555 The difference between the above two cases is only in the number of 556 physical network interfaces and therefore irrelevant in this 557 document. What is of significance is the fact that the mobile node 558 has several addresses it can use as care-of addresses. 560 A mobile node assigns a BID to each care-of address when it wants to 561 register them simultaneously with its home address. The BID MUST be 562 unique for a given home address and care-of address pair. The value 563 should be an integer between 1 and 65535. Zero value MUST NOT be 564 used as BIDs. If a mobile node has only one care-of address, the 565 assignment of a BID is not needed until it has multiple care-of 566 addresses to register with, at which time all of the care-of 567 addresses MUST be mapped to BIDs. 569 5.2. Return Routability: Sending CoTI and Receiving CoT 571 When a mobile node wants to register multiple care-of address with a 572 correspondent node, it MUST have the valid Care-of Keygen token per 573 care-of address. The mobile node needs only one Home Keygen token 574 for its home address. 576 The mobile node MUST include a Binding Identifier mobility option in 577 the Care-of Test Init message. It MUST NOT set any flags in the 578 mobility option. The receiver (i.e. correspondent node) will 579 calculate a care-of Keygen token as specified in [RFC-3775] and reply 580 with a Care-of Test message, with the Binding Identifier mobility 581 option as described in Section 6.2. When the mobile node receives 582 the Care-of Test message, the message is verified as in [RFC-3775]. 583 If a Binding Identifier mobility option is not present in the CoT 584 message in reply to the CoTI message that included a Binding 585 Identifier mobility option, the mobile node must assume that the 586 correspondent node does not support Multiple Care-of Address 587 registration. Thus, the mobile node MUST NOT use a Binding 588 Identifier mobility option in any future Binding Updates to that 589 correspondent node. The mobile node MAY skip re-sending regular CoTI 590 message and keep the received care-of Keygen token for the regular 591 Binding Update. 593 5.3. Binding Registration 595 For the multiple Care-of Addresses registration, the mobile node MUST 596 include a Binding Identifier mobility option(s) in the Binding Update 597 as shown in Figure 5. The BID is copied from a corresponding Binding 598 Update List entry to the BID field of the Binding Identifier mobility 599 option. When IPsec ESP is used for protecting the Binding Update, 600 the care-of address can be carried in the Care-of Address field of 601 the Binding Identifier mobility option. If this is done, the 602 alternate care-of address option MUST NOT be included in the Binding 603 Update. For binding registration to a correspondent node, the mobile 604 node MUST have both active Home and Care-of Keygen tokens for Kbm 605 (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. 606 The care-of Keygen tokens MUST be maintained for each care-of address 607 that the mobile node wants to register to the correspondent node. 608 The Binding Update to the correspondent node is protected by the 609 Binding Authorization Data mobility option that is placed after the 610 Binding Identifier mobility option. 612 IPv6 header (src=CoA, dst=HA) 613 IPv6 Home Address Option 614 ESP Header* 615 Mobility header 616 Binding Update 617 Mobility Options 618 Binding Identifier mobility option 619 Binding Authorization mobility option+ 620 (*) if necessary, for home registration 621 (+) if necessary, for route optimization 623 Figure 5: Binding Update for Binding Registration 625 5.4. Bulk Registration 627 Bulk registration is an optimization for binding multiple care-of 628 addresses to a home address using a single Binding Update. This is 629 very useful if the mobile node, for instance, does not want to send a 630 lot of signaling messages through an interface where the bandwidth is 631 scarce. This document specifies bulk registration only for the 632 mobile node's home registration. A mobile node performing bulk 633 registration with a correspondent node is out of scope. 635 To use bulk registration, the mobile node includes a Binding 636 Identifier Mobility option for each BID and Care-of address pair it 637 wants to register in the same Binding Update message. This is shown 638 in Figure 6. The rest of the fields and options in the Binding 639 Update such as Lifetime, Sequence Number, and the flags in the 640 Binding Update are common across all care-of addresses. The 641 alternate care-of address option MUST NOT be used. 643 IPv6 header (src=CoA, dst=HA) 644 IPv6 Home Address Option 645 ESP Header 646 Mobility header 647 Binding Update 648 Mobility Options 649 Binding Identifier mobility options (CoA) 651 Figure 6: Binding Update for Bulk Registration 653 If the mobile node wants to replace existing registered bindings on 654 the home agent with the bindings in the sent Binding Update, it sets 655 the 'O' flag. Section 6.3 describes this registration procedure in 656 detail. 658 5.5. Binding De-Registration 660 When a mobile node decides to delete all the bindings for its home 661 address, it sends a regular de-registration Binding Update with 662 lifetime set to zero as defined in [RFC-3775]. The Binding 663 Identifier mobility option is not required. 665 If a mobile node wants to delete a particular binding(s) from its 666 home agent and correspondent nodes, the mobile node sends a Binding 667 Update with lifetime set to zero and includes a Binding Identifier 668 mobility option(s) with the BID(s) it wants to de-register. The 669 receiver will remove only the care-of address(es) that match(es) the 670 specified BID(s). The care-of addresses field in each mobility 671 option SHOULD be omitted by the sender (i.e. the field does not 672 appear in the option) and MUST be ignored by the receiver. This is 673 because the receiver will remove the binding that matches the 674 specified BID. 676 5.6. Returning Home 678 The mobile node may return to the home link, by attaching to the home 679 link through one of its interfaces. When the mobile node wants to 680 return home, it should be configured with information on what 681 interface it needs to use. The mobile node may use only the 682 interface with which it is attached to the home link, only the 683 interfaces still attached to the visited link(s) or use both 684 interfaces attached to the home link and visited link(s) 685 simultaneously. The following describes each option in more detail. 687 5.6.1. Using only Interface attached to the Home Link 689 The mobile node returns home and de-registers all the bindings as 690 shown in Figure 2 and as defined in [RFC-3775]. De-registering all 691 the bindings is the same as binding de-registration from foreign link 692 described in Section 5.5. After the de-registration step, all the 693 packets routed by the home agent are only forwarded to the interface 694 attached to the home link, even if there are other active interfaces 695 attached to the visited link(s). While the mobile node de-registers 696 all the bindings from the home agent, it may continue registering 697 bindings for interface(s) attached to visited link(s) to the 698 correspondent node as shown in Figure 2. 700 5.6.2. Using only Interface attached to the Visited Link 702 The mobile node returns home in physically and shuts down the 703 interface attached to the home link. As a result, a mobile node does 704 not return home even though it attaches to the home link by one of 705 interfaces. Following procedures should be taken by the mobile node. 706 Before shutting down the interface, any binding for the care-of 707 address previously associated with the interface should be deleted. 708 To delete the binding cache entry, the mobile node SHOULD send a de- 709 registration Binding Update with the lifetime set to zero and include 710 the corresponding BID information. If the mobile node does not send 711 a de-registration Binding Update, the binding for the care-of address 712 previously assigned to the interface remains at the home agent until 713 its lifetime expires. 715 In this scenario, despite the fact that the mobile node is connected 716 to its home link, all of its traffic is sent and received via the 717 home agent and its foreign links. 719 5.6.3. Simultaneous Home and Visited Link Operation 721 [Problems of Simultaneous Home and Foreign Attachments] 723 The mobile node returns home and continues using all the interfaces 724 attached to both foreign and home links as shown in Figure 3. The 725 mobile node indicates this by setting the 'H' flag in the BID 726 mobility option as defined below. There are additional requirements 727 on the Returning Home procedures for possible Neighbor Discovery 728 states conflicts at the home link. 730 In [RFC-3775], the home agent intercepts packets meant for the mobile 731 node using the Proxy Neighbor Discovery [RFC-4861] while the mobile 732 node is away from the home link. When the mobile node returns home, 733 the home agent deletes the binding cache and stops proxying for the 734 home address so that a mobile node can configure its home address on 735 the interface attached to the home link. In this specification, a 736 mobile node may return home, configure the home address on the 737 interface attached to the home link, but still use the interfaces 738 attached to the foreign links. In this case, a possible conflict 739 arises when the both the home agent and the mobile node try to defend 740 the home address. If the home agent stops proxying for the home 741 address, the packets are always routed to the interface attached to 742 the home link and are never routed to the interfaces attached to the 743 visited links. It is required to avoid the conflict between the home 744 agent and the mobile node, while still allowing the simultaneous use 745 of home and foreign links. The following describes the mechanism for 746 achieving this. 748 [Overview and Approach] 750 In this specification, the home agent MUST intercept all the packets 751 meant for the mobile node and decide whether to send the traffic 752 directly to the home address on the link or tunnel to the care-of 753 address. The home agent intercepts all the packets even when the 754 mobile node is attached to the home link through one of its 755 interfaces. The home agent would make this decision based on the 756 type of flow. How to make this decision is out of scope in this 757 document. 759 Two scenarios are illustrated in Figure 3, depending on whether the 760 Home Agent is the only router at the home link or not. The 761 difference is on who defends the home address by (Proxy) Neighbor 762 Discovery on the home link. 764 1. Mobile node defends the home address by the regular Neighbor 765 Discovery Protocol (illustrated as topology-a in Figure 3). The 766 home agent is the only router on the home link. Therefore the 767 home agent is capable of intercepting packets without relying on 768 the proxy Neighbor Discovery protocol and the mobile node can 769 manage the Neighbor Cache entry of the home address on the home 770 link as a regular IPv6 node. 772 2. If there are other routers on the home link apart from the home 773 agent, then it cannot be guaranteed that all packets meant for 774 the mobile node are routed to the home agent. In this case, the 775 mobile node MUST NOT operate Neighbor Discovery protocol for the 776 home address on the home link. This allows the home agent to 777 keep using proxy neighbor discovery and thus it keeps receiving 778 all the packets sent to the mobile node's home address. If the 779 home agent, according to its local policy, needs to deliver 780 packets to the mobile node over the home link, an issue arises 781 with respect to how the home agent discovers the mobile node's 782 link local address. This specification uses Link-layer Address 783 (LLA) Option defined in [RFC-5268] in order to carry the mobile 784 node's link-layer address in the Binding Update. Likewise, the 785 mobile node would also know the link-layer address of the default 786 router address to send packets from the home link without 787 Neighbor Discovery. The link-layer address is used to transmit 788 packets from and to the mobile node on the home link. The 789 packets are transmitted without the Neighbor Discovery protocol 790 by constructing the link-layer header manually. This operation 791 is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a 792 deregistration binding update to the home agent's link-layer 793 address in returning home operation. 795 [Sending Deregistration Binding Update] 797 o As soon as a mobile node returns home, it sends a de-registration 798 Binding Update to the home agent from the interface attached to 799 the home link. 801 o The mobile node MUST include the BID mobility option specifying 802 the BID the mobile node had previously associated with the 803 interface attached to the home link. The 'H' flag MUST be set in 804 the BID mobility option. None of the care-of address MUST be sent 805 in the Care-of Address field of the BID mobility option. When the 806 'H' flag is set, the home agent recognizes that the mobile node 807 wants to continue using interfaces attached to both home and 808 visited links. Note that H flag MUST be set for all the binding 809 updates sent from the mobile node (ex. Binding Update for the 810 interface(s) attached to the foreign link(s)). 812 o The mobile node SHOULD include the Link-layer Address (LLA) Option 813 [RFC-5268] to notify the mobile node's link-layer address to the 814 home agent, too. The option code of the Link-layer Address (LLA) 815 option MUST be set to '2' (Link-layer Address of the mobile node). 816 This link-layer address is required for the home agent to send the 817 Binding Acknowledgement and to forward the mobile node's packet. 819 o According to [RFC-3775], the mobile node MUST start responding to 820 Neighbor Solicitation for its home address right after it sends 821 the deregistration Binding Update to the home agent. However, in 822 this specification, the mobile node MUST NOT respond to Neighbor 823 Solicitation before receiving a Binding Acknowledgement, since the 824 home agent may continue proxying for the home address. If the 825 mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value 826 in the received Binding Acknowledgment, it MUST NOT respond to 827 Neighbor Solicitation even after the Binding Acknowledgement. 829 [Sending Binding Acknowledgement] 831 o When the home agent sends the Binding Acknowledgement after 832 successfully processing the binding de-registration, it MUST set 833 the status value to either 0 [Binding Update Accepted] or to [MCOA 834 RETURNHOME WO/NDP (TBD)] in the Status field of the Binding 835 Acknowledgment depending on home agent configuration at the home 836 link. The new values are: 838 * Binding Update Accepted (0): NDP is permitted for the home 839 address at the home link. This is regular returning home 840 operation of [RFC-3775] 842 * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home 843 address at the home link 845 If the binding update is rejected, the appropriate error value 846 MUST be set to the status field. In this case, the home agent 847 operation is same as [RFC-3775]. 849 o Only if the home agent is certainly the only router in the home 850 link, it MAY turn off Neighbor Discovery for the requested home 851 address and responds with the [Binding Update Accepted] status 852 value to the mobile node. Since the mobile node will not reply to 853 Neighbor Solicitation for the home address before receiving the 854 Binding Acknowledgement, the home agent SHOULD use the link-layer 855 address carried by the Link Layer Address option [RFC-5268] in the 856 received Binding Update. After the completion of the binding 857 deregistration, the mobile node starts regular Neighbor Discovery 858 operations for the home address on the home link. The neighbor 859 cache entry for the home address is created by the regular 860 exchange of Neighbor Solicitation and Neighbor Advertisement. 862 o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] 863 value in the Status field of the BID mobility option. The home 864 agent learns the mobile node's link-layer address by receiving the 865 link-layer address option carried by the Binding Update. It 866 stores the link-layer address as a neighbor cache entry for the 867 mobile node so that it can send the packets to the mobile node's 868 link-layer address. 870 o Note that the use of proxy Neighbor Discovery is easier way to 871 intercept the mobile nodes' packets instead of IP routing in some 872 deployment scenarios. Therefore, even if a home agent is the only 873 router, it is an implementation and operational choice whether the 874 home agent returns [Binding Update Accepted] or [MCOA RETURNHOME 875 WO/NDP]. 877 o If BID option is not included in the Binding Acknowledgement, the 878 home agent might not recognize the simultaneous home and foreign 879 attachment. The home agent might have processed the de- 880 registration Binding Update as a regular de-registration as 881 described in [RFC-3775] and deletes all the registered binding 882 cache entries for the mobile node. Thus, the mobile node SHOULD 883 stop using the interface attached to foreign link and use only the 884 interface attached to the home link. 886 [Sending Packets from the Home Link] 888 o When the mobile node receives the Binding Acknowledgement with the 889 status value 'Binding Update Accepted' and the BID option, it can 890 configure its home address to the interface attached to the home 891 link and start operating Neighbor Discovery for the home address 892 on the home link. Packets can be transmitted from and to the 893 mobile node as if the mobile node is a regular IPv6 node. 895 o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in 896 the Binding Acknowledgement, it MUST NOT operate Neighbor 897 Discovery for the home address. When the mobile node sends 898 packets from the interface attached to the home link, it MUST 899 learn the link-layer address of the next hop (i.e. default router 900 of the mobile node). A mobile node learns the default router's 901 link-layer address from a Source Link-Layer Address option in 902 Router Advertisements. The mobile node sends packets directly to 903 the default router's link-layer address. This is done by 904 constructing the packet including link-layer header with the 905 learned link-layer address of the default router. The home agent 906 also forwards the packet to the mobile node on the home link by 907 using the mobile node's link-layer address. The link-layer 908 address SHOULD be cached when the home agent received the 909 deregistration Binding Update message. Note that the default 910 router MUST NOT cache the mobile node's link-layer address as a 911 neighbor cache when it forwards the packet from the mobile node to 912 the home agent. 914 [Leaving from the Home Link] 915 o When the mobile node detaches from the home link, it SHOULD 916 immediately send a binding update for one of active care-of 917 address with H flag unset. When the 'H' flag of BID option is 918 unset in any Binding Update, the home agent stop forwarding the 919 mobile node's packet to the home link. 921 o On the other hand, if the mobile node does not have any active 922 care-of address to send a Binding Update and leaves the home link 923 (i.e. the mobile node is completely disconnected), the home agent 924 continues forwarding packets to the mobile node until the 925 expiration of all the binding cache entries for the home address. 926 Once all the bindings are expired, the mobile node is assumed to 927 be disconnected completely from networks. 929 [Changing Behavior during the attachment to the home link] 931 If a mobile node decides to return home completely without any active 932 foreign link attachment, it simply sends a deregistration binding 933 update as described in Section 5.6.1. Once the home agent receives 934 such de-registration binding update, the home agent clears all the 935 binding and states for the mobile node. 937 If a mobile node decides to stop using the interface attached to the 938 home link, it simply sends a binding update from the one of active 939 care-of address. In the Binding Update, the mobile node should 940 include the BID option for the care-of address and unset the H flag 941 of BID option. The home agent clears the states of the mobile node 942 for the interface attached to the home link and stop forwarding the 943 packets to the mobile node on the home link. 945 5.7. Receiving Binding Acknowledgement 947 The verification of a Binding Acknowledgement is the same as Mobile 948 IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a 949 Binding Acknowledgement is described in Section 6.3. 951 If a mobile node includes a Binding Identifier mobility option in a 952 Binding Update with the 'A' flag set, a Binding Acknowledgement MUST 953 carry a Binding Identifier mobility option. If no such mobility 954 option is included in the Binding Acknowledgement in response to a 955 Binding Update for multiple care-of address registration, this 956 indicates that the originating node of the Binding Acknowledgement 957 does not support processing the Binding Identifier mobility option. 958 The mobile node MUST then stop multiple care-of address registration 959 with that node. 961 If a Binding Identifier mobility option is present in the received 962 Binding Acknowledgement, the mobile node checks the status field in 963 the option. If the status value in the Binding Identifier mobility 964 option is zero, the mobile node uses the value in the Status field of 965 the Binding Acknowledgement. Otherwise, it uses the value in the 966 Status field of the Binding Identifier mobility option. 968 If the status code is greater than or equal to 128, the mobile node 969 starts relevant operations according to the error code. Otherwise, 970 the mobile node assumes that the originator (home agent or 971 correspondent node) successfully registered the binding information 972 and BID for the mobile node. 974 o If the Status value is [MCOA PROHIBITED], the mobile node MUST 975 stop registering multiple bindings to the node that sent the 976 Binding Acknowledgement. 978 o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the 979 mobile node SHOULD stop using bulk registrations with the node 980 that sent the Binding Acknowledgement. 982 o If [MCOA MALFORMED] is specified, it indicates that the binding 983 identifier mobility option is formatted wrongly. 985 o If [MCOA BID CONFLICT] is specified, the binding entry specified 986 by the Binding Identifier mobility option is already registered as 987 a regular binding. In such case, the mobile node SHOULD stop 988 sending Binding Updates with BID, or SHOULD use the 'O' flag to 989 reset all the registered bindings. 991 5.8. Receiving Binding Refresh Request 993 The verification of a Binding Refresh Request is the same as in 994 Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending 995 a Binding Refresh Request is described in section Section 6.4. 997 If a mobile node receives a Binding Refresh Request with a Binding 998 Identifier mobility option, it indicates that the node sending the 999 Binding Refresh Request message is requesting the mobile node to send 1000 a new Binding Update for the BID. The mobile node SHOULD then send a 1001 Binding Update only for the respective binding. The mobile node MUST 1002 include a Binding Identifier mobility option in the Binding Update. 1004 5.9. Bootstrapping 1006 When a mobile node bootstraps and registers multiple bindings for the 1007 first time, it MUST set the 'O' flag in the Binding Identifier 1008 mobility option. If old bindings still exists at the home agent, the 1009 mobile node has no knowledge of which bindings still exist at the 1010 home agent. This scenario happens when a mobile node reboots and 1011 looses state regarding the registrations. If the 'O' flag is set, 1012 all the bindings are replaced by the new binding(s). If the mobile 1013 node receives the Binding Acknowledgement with the status code set to 1014 135 [Sequence number out of window], it MUST retry sending a Binding 1015 Update with the last accepted sequence number indicated in the 1016 Binding Acknowledgement. 1018 The 'O' flag can also be used in individual Binding Updates sent to 1019 the correspondent nodes to override any existing binding cache 1020 entries at the correspondent node. 1022 6. Home Agent and Correspondent Node Operation 1024 6.1. Searching Binding Cache with Binding Identifier 1026 If either a correspondent node or a home agent has multiple bindings 1027 for a mobile node in their binding cache database, it can use any of 1028 the bindings to communicate with the mobile node. This section 1029 explains how to retrieve the desired binding for the binding 1030 management. This document does not provide any mechanism to select 1031 the suitable binding for forwarding data packets. 1033 A node which is either a correspondent node or a home agent SHOULD 1034 use both the home address and the BID as the search key of the 1035 binding cache if it knows the corresponding BID (ex. when processing 1036 signaling messages). In the example below, if a node searches the 1037 binding with the home address and BID2, it gets binding2 for this 1038 mobile node. 1040 binding1 [2001:db8::EUI, care-of address1, BID1] 1041 binding2 [2001:db8::EUI, care-of address2, BID2] 1042 binding3 [2001:db8::EUI, care-of address3, BID3] 1044 Figure 7: Searching the Binding Cache 1046 The node learns the BID when it receives a Binding Identifier 1047 mobility option. At that time, the node MUST look up its binding 1048 cache database with the home address and the BID retrieved from the 1049 Binding Update. If the node does not know the BID, it searches for a 1050 binding with only the home address. In such a case, the first 1051 matched binding is found. If the node does not desire to use 1052 multiple bindings for a mobile node, it can simply ignore the BID. 1054 6.2. Receiving CoTI and Sending CoT 1056 When a correspondent node receives a CoTI message which contains a 1057 Binding Identifier mobility option, it processes it as follows. 1059 First, the CoTI message is verified as specified in [RFC-3775]. The 1060 Binding Identifier mobility option is processed as follows: 1062 o If a correspondent node does not understand a Binding Identifier 1063 mobility option, it just ignores and skips processing the option. 1064 The calculation of a care-of Keygen token will thus be done 1065 without a BID value. The correspondent node returns a CoT message 1066 without a Binding Identifier mobility option. The mobile node 1067 knows whether the correspondent supports processing the Binding 1068 Identifier mobility option, by checking if the option is present 1069 in the CoT message. 1071 o If either the 'C' or the 'O' flag is set in the Binding Identifier 1072 mobility option, the correspondent Node SHOULD NOT calculate a 1073 care-of Keygen token, but MUST include a Binding Identifier 1074 mobility option with status value set to [MCOA MALFORMED] in the 1075 Care-of Test message. 1077 o Otherwise, the correspondent node MUST include a Binding 1078 Identifier mobility option with status value set to zero (success) 1079 in the Care-of Test message. 1081 o The Care-of address field of each Binding Identifier mobility 1082 option, can be omitted, because the mobile node can identify the 1083 corresponding Binding Update list entry using the BID. 1085 6.3. Processing Binding Update 1087 If a Binding Update does not contain a Binding Identifier mobility 1088 option, its processing is same as in [RFC-3775]. If the receiver 1089 already has multiple bindings for the home address, it MUST replace 1090 all the existing bindings by the received binding. As a result, the 1091 receiver node MUST have only one binding cache entry for the mobile 1092 node. If the Binding Update is for de-registration, the receiver 1093 MUST delete all existing bindings from its Binding Cache. 1095 If the Binding Update contains a Binding Identifier mobility 1096 option(s), it is first validated according to section 9.5.1 of [RFC- 1097 3775]. Then the receiver processes the Binding Identifier mobility 1098 option(s) as described in the following steps. 1100 o The length value is examined. The length value MUST be either 4, 1101 8, or 20 depending on the Care-of Address field. If the length is 1102 incorrect, the receiver MUST reject the Binding Update and returns 1103 the status value set to [MCOA MALFORMED]. 1105 o When the Length value is either 12 or 20, the care-of address MUST 1106 be present in the Binding Identifier mobility option. If the 1107 valid care-of address is not present, the receiver MUST reject the 1108 Binding Identifier mobility option and returns the status value 1109 set to [MCOA MALFORMED]. 1111 o When multiple Binding Identifier mobility options are present in 1112 the Binding Update, it is treated as bulk registration. If the 1113 receiving node is a correspondent node, it MUST reject the Binding 1114 Update and returns the status value in the binding acknowledgement 1115 set to [MCOA BULK REGISTRATION NOT SUPPORT] 1117 o If the Lifetime field in the Binding Update is set to zero, the 1118 receiving node deletes the binding entry that corresponds to the 1119 BID in the Binding Identifier mobility option. If the receiving 1120 node does not have an appropriate binding for the BID, it MUST 1121 reject the Binding Update and send a Binding Acknowledgement with 1122 status set to 133 [not home agent for this mobile node]. 1124 o If the 'O' flag is set in the de-registering Binding Update, it is 1125 ignored. If the 'H' flag is set, the home agent stores a home 1126 address in the Care-of Address field of the binding cache entry. 1127 The home agent MUST follow the descriptions described in 1128 Section 5.6. 1130 o If the Lifetime field is not set to zero, the receiving node 1131 registers a binding with the specified BID as a mobile node's 1132 binding. The Care-of address is obtained from the Binding Update 1133 packet as follows: 1135 * If the Length value of the Binding Identifier mobility option 1136 is 20, the care-of address is copied the IPv6 address from the 1137 care-of address field in the Binding Identifier mobility 1138 option. When the Length value is 12, the address MUST be the 1139 IPv4 valid address. Detail information can be found in 1140 Section 8. 1142 * If the Length value of the Binding Identifier mobility option 1143 is 4, the care-of address is copied from the source address 1144 field of the IPv6 header. 1146 * If the Length value of the Binding Identifier mobility option 1147 is 4 and an alternate care-of address is present, the care-of 1148 address is copied from the Alternate Care-of address mobility 1149 option. 1151 o Once the care-of address(es) have been retrieved from the Binding 1152 Update, the receiving nodes creates new binding(s). 1154 * If only the 'O' flag is set in the Binding Identifier mobility 1155 option, the home agent removes all the existing bindings and 1156 registers the received bindings. 1158 * If the receiver has a regular binding which does not have BID 1159 for the mobile node, it must not process the binding update. 1160 The receiver should sent a binding acknowledgement with status 1161 set to [MCOA BID CONFLICT]. 1163 * If the receiver already has a binding with the same BID but 1164 different care-of address, it MUST update the binding and 1165 respond with a Binding Acknowledgement with status set to 0 1166 [Binding Update accepted]. 1168 * If the receiver does not have a binding entry for the BID, it 1169 registers a new binding for the BID and responds with a Binding 1170 Acknowledgement with status set to 0 [Binding Update accepted]. 1172 If all the above operations are successfully completed, a Binding 1173 Acknowledgement containing the Binding Identifier mobility options 1174 MUST be sent to the mobile node. Whenever a Binding Acknowledgement 1175 is sent, all the Binding Identifier mobility options stored in the 1176 Binding Update MUST be copied to the Binding Acknowledgement except 1177 the status field. The Care-of address field in each Binding 1178 Identifier mobility option, however, can be omitted, because the 1179 mobile node can match a corresponding binding update list entry using 1180 the BID. 1182 When a correspondent node sends a Binding Acknowledgement, the status 1183 value MUST be always stored in the Status field of the Binding 1184 Acknowledgement and the Status field of Binding Identifier mobility 1185 option MUST be always set to zero. 1187 When the home agent sends a Binding Acknowledgement, the status value 1188 can be stored in the Status field of either a Binding Acknowledgement 1189 or a Binding Identifier mobility option. If the status value is 1190 specific to one of bindings in the bulk registration, the status 1191 value MUST be stored in the Status field in the corresponding Binding 1192 Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be 1193 set to the Status field of the Binding Acknowledgement so that the 1194 receiver can examine the Status field of each Binding Identifier 1195 mobility option for further operations. Otherwise, the status field 1196 of the Binding Identifier mobility option MUST be set to zero and the 1197 home agent status field of the Binding Acknowledgement is used. 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. The node MAY include multiple Binding 1205 Identifier mobility options if there are multiple bindings that need 1206 to be refreshed. 1208 6.5. Receiving Packets from Mobile Node 1210 When a node receives packets with a Home Address destination option 1211 from a mobile node, it MUST check that the care-of address that 1212 appears in the source address field of the IPv6 header MUST be equal 1213 to one of the care-of addresses in the binding cache entry. If no 1214 binding is found, the packets MUST be discarded. The node MUST also 1215 send a Binding Error message as specified in [RFC-3775]. This 1216 verification MUST NOT be done for a Binding Update. 1218 7. Network Mobility Applicability 1220 The binding management mechanisms are the same for a mobile host that 1221 uses Mobile IPv6 and for a mobile router that is using the NEMO Basic 1222 Support protocol [RFC-3963]. Therefore the extensions described in 1223 this document can also be used to support a mobile router with 1224 multiple care-of addresses. [RFC-4980] is a document for an analysis 1225 of NEMO multihoming. 1227 8. DSMIPv6 Applicability 1229 Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to 1230 register an IPv4 care-of address instead of the IPv6 care-of address 1231 when the mobile node is attached to an IPv4-only access network. It 1232 also allows the mobile node to acquire an IPv4 home address in 1233 addition to an IPv6 home address for use with IPv4-only correspondent 1234 nodes. This section describes how multiple care-of address 1235 registration works with IPv4 care-of and home addresses. 1237 8.1. IPv4 Care-of Address Registration 1239 The mobile node can use the extensions described in the document to 1240 register multiple care-of addresses, even if some of the care-of 1241 addresses are IPv4 address. 1243 Bulk registration MUST NOT be used for the initial binding from an 1244 IPv4 care-of address. This is because, the Binding Update and 1245 binding acknowledgement exchange is used to detect NAT on the path 1246 between the mobile node and the home agent. So the mobile node needs 1247 to check for a NAT between each IPv4 care-of address and the home 1248 agent. 1250 The Binding Update MUST be sent to the IPv4 home agent address by 1251 using UDP and IPv4 headers as shown in Figure 8. It is similar to 1252 [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be 1253 used when the BID mobility option is used. 1255 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1256 UDP Header 1257 IPv6 header (src=V6HoA, dst=HAADDR) 1258 ESP Header 1259 Mobility header 1260 -Binding Update 1261 Mobility Options 1262 - Binding Identifier (IPv4 CoA) 1264 Figure 8: Initial Binding Update for IPv4 Care-of Address 1266 If a NAT is not detected, the mobile node can update the IPv4 care-of 1267 address by using bulk registration. The mobile node can register the 1268 IPv4 care-of address along with other IPv4 and IPv6 care-of 1269 addresses. Figure 9 shows the Binding Update format when the mobile 1270 node sends a Binding Update from one of its IPv6 care-of addresses. 1271 If the mobile node sends a Binding Update from IPv4 care-of address, 1272 it MUST follow the format described in Figure 8. Note that the IPv4 1273 Care-of Address must be registered by non bulk Binding registration, 1274 whenever it is changed. 1276 IPv6 header (src=V6CoA, dst=HAADDR) 1277 IPv6 Home Address Option 1278 ESP Header 1279 Mobility header 1280 -Binding Update 1281 Mobility Options 1282 - Binding Identifier (IPv6/v4 CoA) 1283 - Binding Identifier (IPv6/v4 CoA) 1284 - ... 1286 Figure 9: Binding Bulk Registration for IPv4 care-of address 1288 If the home agent rejects the IPv4 care-of address, it MUST store the 1289 error code value in the Status field of the BID mobility option. 1291 8.2. IPv4 HoA Management 1293 When the mobile node wants to configure an IPv4 home address in 1294 addition to the IPv6 home address, it can request for one using the 1295 IPv4 Home Address option in the Binding Update. If the home agent 1296 accepts the Binding Update, the mobile node can now register multiple 1297 care-of addresses for the IPv4 home address in addition to the IPv6 1298 home address. The same set of care-of addresses will be registered 1299 for both IPv6 and IPv4 home addresses. The mobile node cannot bind 1300 different set of care-of addresses to each home address. 1302 According to [ID-DSMIPv6], the home agent includes the IPv4 address 1303 acknowledgement option in the Binding Acknowledgement only if the 1304 mobile node had requested for an IPv4 home address in the 1305 corresponding Binding Update. The IPv4 address acknowledgement 1306 option MUST be present before any BID option. The status field of 1307 the IPv4 address acknowledgement option contains only the error code 1308 corresponding to the IPv4 home address management. The error values 1309 related to the IPv4 care-of address registration MUST be stored in 1310 the BID mobility option. 1312 9. IPsec and IKEv2 interaction 1314 Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 1315 use of IPsec to protect signaling messages like Binding Updates, 1316 Binding Acknowledgements and return routability messages. IPsec may 1317 also be used protect all tunneled data traffic. The Mobile IPv6- 1318 IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to 1319 setup the required IPsec security associations. The following 1320 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with 1321 respect to the use of IKEv2 and IPsec. 1323 o There is only one primary care-of address per mobile node. 1325 o The primary care-of address is stored in the IPsec database for 1326 tunnel encapsulation and decapsulation. 1328 o When the home agent receives a packet from the mobile node, the 1329 source address is verified against the care-of address in the 1330 corresponding binding cache entry. If the packet is a reverse 1331 tunneled packet from the mobile node, the care-of address check is 1332 done against the source address on the outer IPv6 header. The 1333 reverse tunnel packet could either be a tunneled HoTi message or 1334 tunneled data traffic to the correspondent node. 1336 o The mobile node runs IKEv2 (or IKEv1) with the home agent using 1337 the care-of address. The IKE SA is based on the care-of address 1338 of the mobile node. 1340 The above assumptions may not be valid when multiple care-of 1341 addresses are used by the mobile node. In the following sections, 1342 the main issues with the use of multiple care-of address with IPsec 1343 are addressed. 1345 9.1. Use of Care-of Address in the IKEv2 exchange 1347 For each home address the mobile node sets up security associations 1348 with the home agent, the mobile node must pick one care-of address 1349 and use that as the source address for all IKEv2 messages exchanged 1350 to create and maintain the IPsec security associations associated 1351 with the home address. The resultant IKEv2 security association is 1352 created based on this care-of address. 1354 If the mobile node needs to change the care-of address, it just sends 1355 a Binding Update with the care-of address it wants to use, with the 1356 corresponding Binding Identifier mobility option, and with the 'K' 1357 bit set. This will force the home agent to update the IKEv2 security 1358 association to use the new care-of address. If the 'K' bit is not 1359 supported on the mobile node or the home agent, the mobile node MUST 1360 re-establish the IKEv2 security association with the new care-of 1361 address. This will also result in new IPsec security associations 1362 being setup for the home address. 1364 9.2. Transport Mode IPsec protected messages 1366 For Mobile IPv6 signaling message protected using IPsec in transport 1367 mode, the use of a particular care-of address among multiple care-of 1368 addresses does not matter for IPsec processing. 1370 For Mobile Prefix Discovery messages, [RFC-3775] requires the home 1371 agent to verify that the mobile node is using the care-of address 1372 that is in the binding cache entry that corresponds to the mobile 1373 node's home address. If a different address is used as the source 1374 address, the message is silently dropped by the home agent. This 1375 document requires the home agent implementation to process the 1376 message as long as the source address is one of the care-of addresses 1377 in the binding cache entry for the mobile node. 1379 9.3. Tunnel Mode IPsec protected messages 1381 The use of IPsec in tunnel mode with multiple care-of address 1382 introduces a few issues that require changes to how the mobile node 1383 and the home agent send and receive tunneled traffic. The route 1384 optimization mechanism described in [RFC-3775] mandates the use of 1385 IPsec protection in tunnel mode for the HoTi and HoT messages. The 1386 mobile node and the home agent may also choose to protect all reverse 1387 tunneled payload traffic with IPsec in tunnel mode. The following 1388 sections address multiple care-of address support for these two types 1389 of messages. 1391 9.3.1. Tunneled HoTi and HoT messages 1393 The mobile node MAY use the same care-of address for all HoTi 1394 messages sent reverse tunneled through the home agent. The mobile 1395 node may use the same care-of address irrespective of which 1396 correspondent node the HoTi message is being sent. RFC 3775 requires 1397 the home agent to verify that the mobile node is using the care-of 1398 address that is in the binding cache entry, when it receives a 1399 reverse tunneled HoTi message. If a different address is used as the 1400 source address, the message is silently dropped by the home agent. 1401 This document requires the home agent implementation to decapsulate 1402 and forward the HoTi message as long as the source address is one of 1403 the care-of addresses in the binding cache entry for the mobile node. 1405 When the home agent tunnels a HoT message to the mobile node, the 1406 care-of address used in the outer IPv6 header is not relevant to the 1407 HoT message. So regular IPsec tunnel encapsulation with the care-of 1408 address known to the IPsec implementation on the home agent is 1409 sufficient. 1411 9.3.2. Tunneled Payload Traffic 1413 When the mobile sends and receives multiple traffic flows protected 1414 by IPsec to different care-of addresses, the use of the correct 1415 care-of address for each flow becomes important. Support for this 1416 requires the following two considerations on the home agent. 1418 o When the home agent receives a reverse tunneled payload message 1419 protected by IPsec in tunnel mode, it must check that the care-of 1420 address is one of the care-of addresses in the binding cache 1421 entry. According to RFC 4306, the IPsec implementation on the 1422 home agent does not check the source address on the outer IPv6 1423 header. Therefore the care-of address used in the reverse 1424 tunneled traffic can be different from the care-of address used as 1425 the source address in the IKEv2 exchange. However, the Mobile 1426 IPv6 stack on the home agent MUST verify that the source address 1427 is one of the care-of addresses registered by the mobile node 1428 before decapsulating and forwarding the payload traffic towards 1429 the correspondent node. 1431 o For tunneled IPsec traffic from the home agent to the mobile node, 1432 The IPsec implementation on the home agent may not be aware of 1433 which care-of address to use when performing IPsec tunnel 1434 encapsulation. The Mobile IP stack on the home agent must specify 1435 the tunnel end point for the IPsec tunnel. This may require tight 1436 integration between the IPsec and Mobile IP implementations on the 1437 home agent. 1439 10. Security Considerations 1441 The security considerations for securing the Binding Update and 1442 binding acknowledgement messages with multiple care-of address are 1443 very similar to the security considerations for securing the Binding 1444 Update and binding acknowledgement. Please see [RFC-3775] for more 1445 information. The Binding Update and binding acknowledgement messages 1446 with multiple care-of addresses MUST be protected using IPsec as show 1447 in Section 9. Additional security considerations are described 1448 below. 1450 With simultaneous binding support, it is possible for a malicious 1451 mobile node to successfully bind a number of victims' addresses as 1452 valid care-of addresses for the mobile node with its home agent. 1453 Once these addresses have been bound, the malicious mobile node can 1454 perform a re-direction attack by instructing the home agent (e.g. 1455 setting filtering rules to direct a large file transfer) to tunnel 1456 packets to the victims' addresses. Such risk is highlighted in [ID- 1457 MIP6ANALYSIS]. These attacks are possible because the care-of 1458 addresses sent by the mobile node in the Binding Update messages are 1459 not verified by home agent, i.e., the home agent does not check if 1460 the mobile node is at the care-of address it is claiming to be. The 1461 security model for Mobile IPv6 assumes that there is a trust 1462 relationship between the mobile node and its home agent. Any 1463 malicious attack by the mobile node is traceable by the home agent. 1464 This acts as a deterrent for the mobile node to launch such attacks. 1466 Although such risk exists in Mobile IPv6, the risk level is escalated 1467 when simultaneous multiple care-of address bindings are performed. 1468 In Mobile IPv6, a mobile node can only have a single care-of address 1469 binding per home address at a given time. However, for simultaneous 1470 multiple care-of address bindings, a mobile node can have more than 1471 one care-of address binding per home address at a given time. This 1472 implies that a mobile node using simultaneous binding support can 1473 effectively bind more than a single victim's address. Another 1474 difference is the degree of risk involved. In the single care-of 1475 address binding case, once the re-direction attack is initiated, a 1476 malicious mobile node would be unable to use its home address for 1477 communications (such as to receive control packets pertaining to the 1478 file transfer). However, in the simultaneous binding support case, a 1479 malicious mobile node could bind a valid care-of address in addition 1480 to multiple victims addresses. This valid care-of address could then 1481 be used by the malicious mobile node to set up flow filtering rules 1482 at its home agent, thereby controlling and/or launching new re- 1483 direction attacks. 1485 Thus, in view of such risks, it is advisable for a home agent to 1486 employ some form of care-of address verification mechanism before 1487 using the care-of addresses as a valid routing path to a mobile node. 1488 Solutions related to this are described in [ID-COAVERIFY]. 1490 11. IANA Considerations 1492 The following Extension Types MUST be assigned by IANA: 1494 o Binding Identifier mobility option type: This must be assigned 1495 from the same space as mobility option in [RFC-3775]. 1497 o New Successful Status of Binding Acknowledgement: This status code 1498 must be assigned from the same space as binding acknowledgement 1499 status codes in [RFC-3775]. 1501 * MCOA NOTCOMPLETE (TBD) 1503 * MCOA RETURNHOME WO/NDP (TBD) 1505 o New Unsuccessful Status of Binding Acknowledgement: These status 1506 codes must also be assigned from the same space as binding 1507 acknowledgement status codes in [RFC-3775]. 1509 * MCOA MALFORMED (TBD) 1511 * MCOA BID CONFLICT (TBD) 1513 * MCOA PROHIBITED(TBD) 1515 * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) 1517 12. Acknowledgements 1519 The authors would like to special thank George Tsirtsis for thorough 1520 review and suggestions. The authors would also like to thank 1521 Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin 1522 Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas 1523 Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to 1524 Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke 1525 Uehara, Masafumi Watari and Jun Murai for earlier work on this 1526 subject. 1528 13. References 1530 13.1. Normative References 1532 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1533 Requirement Levels", BCP 14, RFC 2119, March 1997. 1535 [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, 1536 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 1537 2007.. 1539 [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1540 in IPv6", RFC 3775, June 2004. 1542 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1543 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1544 January 2005. 1546 [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1547 IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. 1549 13.2. Informative References 1551 [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and 1552 K. Kuladinithi, "Motivations and Scenarios for Using Multiple 1553 Interfaces and Global Addresses", 1554 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1555 progress), May 2008. 1557 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of 1558 Multihoming in Network Mobility Support", RFC 4980, October 2007. 1560 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and 1561 K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1562 draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. 1564 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1565 RFC 3753, June 2004. 1567 [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support 1568 Terminology", RFC 4885, July 2007. 1570 [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts 1571 and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in 1572 progress), July 2008. 1574 [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of 1575 Addresses in Multiple Bindings Registration", 1576 draft-lim-mext-multiple-coa-verify-02 (work in progress), July 2008. 1578 [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June 1579 2008. 1581 Authors' Addresses 1583 Ryuji Wakikawa 1584 Toyota ITC / Keio University 1585 6-6-20 Akasaka, Minato-ku 1586 Tokyo 107-0052 1587 Japan 1589 Phone: +81-3-5561-8276 1590 Fax: +81-3-5561-8292 1591 Email: ryuji@jp.toyota-itc.com 1593 Vijay Devarapalli 1594 Wichorus 1595 3590 North First St 1596 San Jose, CA 95134 1597 USA 1599 Email: vijay@wichorus.com 1601 Thierry Ernst 1602 INRIA 1603 INRIA Rocquencourt 1604 Domaine de Voluceau B.P. 105 1605 Le Chesnay, 78153 1606 France 1608 Phone: +33-1-39-63-59-30 1609 Fax: +33-1-39-63-54-91 1610 Email: thierry.ernst@inria.fr 1611 URI: http://www.nautilus6.org/~thierry 1613 Kenichi Nagami 1614 INTEC NetCore Inc. 1615 1-3-3, Shin-suna 1616 Koto-ku, Tokyo 135-0075 1617 Japan 1619 Phone: +81-3-5565-5069 1620 Fax: +81-3-5565-5094 1621 Email: nagami@inetcore.com 1623 Full Copyright Statement 1625 Copyright (C) The IETF Trust (2008). 1627 This document is subject to the rights, licenses and restrictions 1628 contained in BCP 78, and except as set forth therein, the authors 1629 retain all their rights. 1631 This document and the information contained herein are provided on an 1632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1639 Intellectual Property 1641 The IETF takes no position regarding the validity or scope of any 1642 Intellectual Property Rights or other rights that might be claimed to 1643 pertain to the implementation or use of the technology described in 1644 this document or the extent to which any license under such rights 1645 might or might not be available; nor does it represent that it has 1646 made any independent effort to identify any such rights. Information 1647 on the procedures with respect to rights in RFC documents can be 1648 found in BCP 78 and BCP 79. 1650 Copies of IPR disclosures made to the IETF Secretariat and any 1651 assurances of licenses to be made available, or the result of an 1652 attempt made to obtain a general license or permission for the use of 1653 such proprietary rights by implementers or users of this 1654 specification can be obtained from the IETF on-line IPR repository at 1655 http://www.ietf.org/ipr. 1657 The IETF invites any interested party to bring to its attention any 1658 copyrights, patents or patent applications, or other proprietary 1659 rights that may cover technology that may be required to implement 1660 this standard. Please address the information to the IETF at 1661 ietf-ipr@ietf.org. 1663 Acknowledgment 1665 Funding for the RFC Editor function is provided by the IETF 1666 Administrative Support Activity (IASA).