idnits 2.17.1 draft-ietf-mext-flow-binding-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1140. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 267: '...d is unused. It MUST be initialized t...' RFC 2119 keyword, line 268: '... sender and MUST be ignored by th...' RFC 2119 keyword, line 291: '...ence sub-options MUST exist. The Bind...' RFC 2119 keyword, line 341: '...the same BU, but MUST be already known...' RFC 2119 keyword, line 358: '... option, this field MUST be set to 1....' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o 15: Remove a flow binding. This action enables a mobile node to remove the Flow Binding indicated by the FID on the targeted node. A mobile node MUST not issue a Flow Identifier with the PRO field set to 15 for a non existent FID. -- 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 16, 2008) is 5795 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) == Unused Reference: '12' is defined on line 1053, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (ref. '3') (Obsoleted by RFC 5380) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-00 ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-01 ** Downref: Normative reference to an Informational draft: draft-ietf-monami6-mipv6-analysis (ref. '6') == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '9') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '11') -- No information found for draft-ietf-monami6-multihoming-motivations-scenarios - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Expires: November 17, 2008 N. Montavont 5 IT/Telecom Bretagne 6 N. Fikouras 7 K. Kuladinithi 8 University of Bremen 9 May 16, 2008 11 Flow Bindings in Mobile IPv6 and Nemo Basic Support 12 draft-ietf-mext-flow-binding-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 17, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document introduces extensions to Mobile IPv6 [1] and Nemo Basic 46 Support [2] that allow nodes to bind one or more flows to a care-of 47 address. These extensions allow multihomed nodes to take full 48 advantage of the different properties associated with each of their 49 interfaces. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7 58 3.1. Flow Identification option . . . . . . . . . . . . . . . . 7 59 3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 10 60 3.3. Binding Cache and Binding Update list extensions . . . . . 10 62 4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 12 63 4.1. Interaction with the Multiple CoA bindings mechanism . . . 12 64 4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 12 65 4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 13 66 4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 13 67 4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 14 68 4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 14 69 4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15 70 4.8. Acknowledging flow identification options . . . . . . . . 15 72 5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18 75 6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 18 76 6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 18 77 6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 19 78 6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 19 79 6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 20 80 6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 6.3. Return Routability Procedure . . . . . . . . . . . . . . . 20 82 6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21 84 7. Applicability to Route Optimization . . . . . . . . . . . . . 22 85 7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22 87 8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24 88 8.1. Receiving Binding Update with the Flow Identification 89 option . . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25 92 8.3. Deleting an entry in the binding cache . . . . . . . . . . 25 93 8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 25 95 9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 27 97 10. Security considerations . . . . . . . . . . . . . . . . . . . 28 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 104 Intellectual Property and Copyright Statements . . . . . . . . . . 32 106 1. Introduction 108 Mobile IPv6 (RFC3775) [1] and Nemo Basic Support (RFC3963) [2] allow 109 a mobile node / mobile router to manage its mobility using the 110 binding update message, which binds one care-of address to one home 111 address. The binding update message can be sent to the home agent. 112 In Mobile IPv6, the Binding Update can also be sent to correspondent 113 node or to a mobility anchor point (see RFC4140 [3]). The semantics 114 of the binding update are limited to address changes. That is, 115 RFC3775 [1] and RFC3963 [2] do not allow a mobile node / mobile 116 router to bind more than one address to the home address. 117 Furthermore, the binding granularity is limited to the address. 118 Therefore, a mobile host cannot associate one of the connections 119 using the home address with a different care-of address. In 120 draft-ietf-monami6-multiplecoa [4] Mobile IPv6 and Nemo Basic Support 121 are extended to allow the binding of more than one care-of address to 122 a home address. This specification extends Mobile IPv6 and Nemo 123 Basic Support to allow it to specify policies associated with each 124 binding. A policy can contain a request for a special treatment of a 125 particular flow. Hence, this specification allows a mobile node / 126 mobile router to bind a particular flow to a care-of address without 127 affecting other flows using the same home address. In addition, we 128 will see that this specification allows to bind a particular flow to 129 a particular care-of address directly with correspondent node and 130 mobility anchor point in the case of a single mobile node. 132 In this document, a flow is defined as one or more connections that 133 are identified by a flow identifier. A single connection is 134 typically identified by the source and destination IP addresses, 135 transport protocol number and the source and destination port 136 numbers. Alternatively a flow can be identified in a simpler manner 137 using the flow label field in the IPv6 header [5] or the Security 138 Parameter Index (SPI) when IPsec is used. 140 Flow bindings are useful in cases where the mobile node / mobile 141 router has more than one address, probably due to being multihomed, 142 and wants to direct certain flows to certain addresses [6], [7]. 143 This may be done because some flows are better suited to certain link 144 layers or simply to load balance flows between different interfaces. 145 This specification introduces the flow identifier option, which is 146 included in the binding update message and used to distribute 147 policies to the recipient of the binding update. However, this 148 document does not define the flow itself but only the action to take 149 on this flow. The flow description will be defined in another 150 document. This will allow to use the same flow description in 151 several protocols. Using the flow identifier option introduced in 152 this specification a mobile node / mobile router can bind one or more 153 flows to a care-of address while maintaining the reception of other 154 flows on another care-of address. Requesting the flow binding can be 155 decided based on local policies within the mobile node / mobile 156 router and based on the link characteristics and the types of 157 applications running at the time. Such policies are outside the 158 scope of this document. 160 It should be noted that the flow identification option can be 161 associated with any binding update, whether it is sent to a 162 correspondent node (in the case of Mobile IPv6), home agent or 163 mobility anchor point (in the case of Hierarchical Mobile IPv6). A 164 Similar mechanism for Mobile IPv4 is described in [8]. 166 In the rest of the document, the term "mobile node" is used to 167 designate either a mobile node as defined in RFC3775 [1] or a mobile 168 router as defined in RFC3963 [2] unless stated otherwise. 170 2. Terminology 172 Terms used in this document are defined in [9] and [10]. The 173 following terms are also used in this document: 175 Flow 177 A flow is identified as a set of data packets that are exchanged 178 between two distant hosts. 180 Flow Description 182 A set of instructions that describes a flow. 184 Flow Identifier 186 Identifier of a flow binding. 188 Flow binding 190 A mobility binding extended with a flow identifier and flow 191 description. 193 3. Mobile IPv6 Extensions 195 This section introduces extensions to Mobile IPv6 that are necessary 196 for supporting the flow binding mechanism described in this document. 198 3.1. Flow Identification option 200 The Flow identification option is included in the binding update and 201 acknowledgement messages. This option contains information that 202 allows the receiver of a binding update to install policies on a 203 traffic flow and route it to a given address. Multiple options may 204 exist within a binding update message. The Flow identification 205 option must come with another option (that will be defined in another 206 document) that will describe the flow. This additional option is 207 called Flow Description in the remaining of this document. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Option Type | Option Len | PRI | FID | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | FID | Action | Status | PRO | Res. | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Flow Description ... 218 Figure 1: The flow identification option 220 Option Type 222 TBD 224 Option Len 226 Length of option in 8-octet units 228 PRI 230 This is a 8-bit priority field to indicate the priority of a 231 particular option. This field is needed in cases where two 232 different flow descriptions in two different options overlap. The 233 priority field decides which policy should be in those cases. A 234 lower number in this field indicates a higher priority. 236 FID 238 The Flow Identifier field is an 8-bit unsigned integer that 239 includes the identifier for the flow binding. This field is used 240 to refer to an existing binding or to create a new binding. 242 Action 244 This field specifies the action that needs to be taken by the 245 receiver of the binding update containing the flow identification 246 option. 248 Status 250 This field indicates the success or failure of the flow binding 251 operation for the particular flow in the option. This field is 252 not relevant to the binding update message as a whole or to other 253 flow identification options. Values from 0 to 127 indicate 254 success. Values of 128 and higher indicate failure. This field 255 is only relevant when included in the Binding Acknowledgement 256 message and must be ignored in the binding update message. 258 PRO 260 This is a 4-bit field that describes the required processing for 261 the option. This field may indicate a request for adding, 262 deleting, modifying or refreshing the option. The details of 263 these requests are discussed below. 265 Res. 267 This field is unused. It MUST be initialized to zero by the 268 sender and MUST be ignored by the receiver. 270 The following values are reserved for the PRO field in this option: 272 0 Add a flow binding 274 1 Replace a flow binding 276 2 Refresh the current binding 278 15 Remove a flow binding 280 The following values are reserved for the Action field in this 281 option: 283 1 Forward. This value indicates a request to forward a flow to the 284 address included or referred to by the option. 286 2 Discard. This value indicates a request to discard all packets in 287 the flow described by this option. 289 3 n-cast. This value indicates a request to replicate the flow to 290 several addresses. If this value is used, one or more Binding 291 Reference sub-options MUST exist. The Binding Reference sub-option 292 is described later in this specification. 294 The following values are reserved for the status field within the 295 flow identification option: 297 0 Flow binding successful. 299 128 Flow binding rejected, reason unspecified. 301 129 Flow binding option poorly formed. 303 130 Administratively prohibited. 305 131 Flow identification by IPv6 prefix is not supported. 307 132 Flow identification by port numbers is not supported. 309 133 Flow identification with Flow label is not supported. 311 134 Flow identification with SPI is not supported. 313 135 FID already in use 315 136 FID not found 317 137 Classifier language not supported. 319 138 Discard function not supported. 321 139 N-cast function not supported. 323 It should be noted that per-packet load balancing has negative 324 impacts on TCP congestion avoidance mechanisms as it is desirable to 325 maintain order between packets belonging to the same TCP connection. 326 This behaviour is specified in RFC2702 [11]. Other negative impacts 327 are also foreseen for other types of real time connections due to the 328 potential variations in RTT between packets. Hence per-packet load 329 balancing is not allowed in this extension. However, the MN can 330 still request per-flow load balancing provided that the entire flow 331 is moved to the new interface. 333 3.2. The Binding Reference Sub-option 335 This section introduces the Binding Reference sub-option, which may 336 be included in the Flow identification option. The Binding Reference 337 sub-option includes one or more BIDs as defined in [4]. When this 338 sub-option is included in the Flow identification option it 339 associates the flow described with one or more BIDs that where 340 already registered with the recipient of the BU. A BID sub-option is 341 not necessarily included in the same BU, but MUST be already known to 342 the receiver of the BU. The Binding Reference sub-option is shown 343 below. 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |Sub-opt Type | Sub-Opt Len | BID | ...... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ........ 351 +-+-+-+- 353 Figure 2: The Binding Reference sub-option 355 Sub-opt Type 357 Indicates the Sub-option type. For the Binding Reference sub- 358 option, this field MUST be set to 1. 360 Sub-opt Len 362 Indicates the sub-option length in octets. This field includes 363 the entire length of the sub-option including the type and length 364 fields. 366 BID 368 The BID that the mobile node wants to associate with the flow 369 identification option. One or more BID fields can be included in 370 this sub-option. 372 3.3. Binding Cache and Binding Update list extensions 374 Flow bindings are conceptually stored in Binding Cache of home agent, 375 mobility anchor point and correspondent node, and in Binding Update 376 List of mobile node. These logical structures need to be extended to 377 include the following parameters (in addition to those described in 378 RFC3775 [1]): 380 o FID (Flow Identifier). For a given home address, the FID MUST 381 uniquely identify an entry, i.e. a unique flow binding. An FID is 382 only unique for a given home address. Different mobile nodes can 383 use the same FID value. 385 o Each attribute that constitutes the flow dsecription (and that are 386 defined in a separate document). 388 An entry in these structures is identified by the couple (home 389 address, FID). 391 4. Protocol operations 393 The flow identification option defines the controls on flow bindings. 394 The fields of the flow identification option are necessary for 395 indexing flow identification options, indicating the sort of action 396 that should be undertaken to the recipient's Binding Cache or for 397 carrying the results of such a petition. The flow description is 398 transported in another option that will be defined in another 399 document. This separation is made to use the same flow description 400 in various protocols. 402 This specification allows mobile nodes to direct flows to a 403 particular care-of address. This can be done by aggregating many 404 flows in the flow identification option (e.g. all TCP traffic), or by 405 uniquely identifying a flow in the flow identification option. 407 The remaining of this section discusses how mobile nodes can use the 408 flow identification option when sending binding updates to the 409 correspondent node, home agent or mobility anchor point. In 410 addition, deletion and modification of bindings are all discussed 411 below. 413 4.1. Interaction with the Multiple CoA bindings mechanism 415 Flow binding presented in this specification MUST be used with the 416 solution in [4]. The main reason why is to avoid the duplication of 417 the default binding to be used when none of the registered rules can 418 apply to a flow. As the multiple CoA bindings document already 419 defines a prority field which indicates which care-of address is 420 preferred, flow binding uses this priority field in order to maintain 421 a primary Care-of address (see below section Section 4.3). 423 Moreover, combining the mechanism in this specification with the 424 multiple CoA bindings allows for further aggregation of bindings. 425 For example, if a mobile node has several flow identifiers bound to a 426 single Care-of address identified by a unique BID, the mobile node 427 can change the Care-of address for all these flows bindings just by 428 changing the Care-of address associated with the given BID. 430 Additionally, the combination of the two mechanisms allows for 431 additional features (e.g., n-casting) to take place with minimal 432 effort. Hence, this specification makes use of the BID option 433 described in [4]. 435 4.2. Flow binding storage 437 Home agent, correspondent node and mobility anchor point maintain 438 Binding Cache in order to record associations between home addresses 439 and care-of addresses of mobile nodes that are away from the home 440 link. Mobile nodes maintain binding update list to record binding 441 between home address and care-of address. RFC 3775 [1] allows mobile 442 nodes to register only one care-of address per home address. Thus a 443 binding cache entry is uniquely identified by the home address. 445 This specification extends the binding cache and the binding update 446 list structures, and allows mobile node to (1) register multiple 447 care-of addresses for a given home address and (2) associate flow 448 binding policies with the registered care-of addresses. 450 New parameters are added to these conceptual structures in order to 451 list the particular rule associated with a standard binding. On one 452 hand, an entry is now identified by the pair (home address, FID) 453 because several Care-of addresses may be bound to a single home 454 address. On the other hand, the Care-of address is selected 455 according to the best match between the packets that need to be sent, 456 and the existing flow bindings. If no matching is found between the 457 flow bindings and the data packet, a preferred entry is used (see 458 next subsection). If a flow matches two different flow bindings, the 459 PRI field indicates which action is preferred by the mobile node. 461 4.3. Preferred Care-of address 463 Any distant node which supports the flow identification option MUST 464 maintain a default binding per home address. A default binding 465 indicates an association between a home address and a Care-of 466 address. In addition to the default binding, several bindings may 467 co-exist within a binding cache for the same home address, each of 468 them indicating different bindings between flows and Care-of 469 addresses. When a data flow is intercepted by a home agent or 470 initiated by a correspondent node, if the said data flow does not 471 match an existing flow identification option, the care-of address 472 indicated in the default binding is used as destination address for 473 the mobile node. The default binding is indicated by the Priority 474 field in the BID option described in [4]. A mobile node is 475 responsible for having a preferred care-of address with the receiver 476 of the flow identification option. 478 4.4. Adding flow bindings 480 When adding a new flow binding, a mobile node sends the flow 481 identification option in the binding update. The care-of address 482 concerned with this binding update must already be registered by the 483 receiver of the binding update (i.e., must already be associated with 484 a BID), or a BID sub-option MUST be present in the binding update (as 485 defined in [4]). The flow identification option MUST include a 486 unique FID. The FID needs only be unique for the receiver of the 487 binding update, i.e. the same FID can be used across different 488 receivers of the binding update. The PRO field MUST indicate an Add 489 operation. Adding the flow binding implies associating a flow with a 490 particular care-of address for the mobile node. The care-of address 491 concerned with the flow binding is present in the source address of 492 the packet or the alternate care-of address option. Alternatively, 493 the care-of address may be indicated by the BID (which is pointing to 494 an existing care-of address) when the Binding Reference sub-option of 495 the Flow Identification option is present. 497 The mobile node may need to define the flow partially or entirely 498 based on the source and destination addresses in packets. For 499 instance, a mobile node may choose to forward all flows from address 500 A to address B to a particular care-of address. Alternatively, more 501 granularity can be added by including port numbers and protocol. 502 These descriptions will be given in another document. 504 An Add operation implies that the FID is new and is not already used 505 by the mobile node for any other flow binding. If the Flow 506 identification option is sent without any flow description and with 507 the PRO field indicating an Add operation, this MUST be seen as a 508 wild card request by the sender. A wild card request implies that 509 all flows should be directed to the particular care-of address in the 510 packet. 512 4.5. Modifying flow bindings 514 When modifying a flow binding (either the care-of address or other 515 attributes of the flow), the mobile node sends the binding update 516 with a flow identification option. The option includes the FID for 517 the binding being modified, as well as the PRO field set to 1, 518 indicating a request to modify the binding. A flow description 519 option may come with the flow identification option and contain the 520 new attributes needed to classify the flow. Hence, flow modification 521 is essentially a process where an existing flow definition is removed 522 and a new flow (included in the option) is added and given the same 523 FID as the flow that was removed. 525 If one of the care-of addresses needs to be updated with a new one 526 (e.g., after a change of the IP point of attachment), the mobile node 527 may just need to register the new care-of address for the given BID. 529 4.6. Removing flow bindings 531 When removing a flow binding, the mobile node sends a binding update 532 message with the flow identification option. The PRO field MUST be 533 set to a value of 15, which indicates a request for removing a flow 534 binding. This will provide enough information for the receiver to 535 locate the flow binding using the FID and remove it. 537 4.7. Refreshing Flow Bindings 539 A flow binding is refreshed by simply including the Flow 540 identification option in the BU message. In this case the PRO field 541 is set to indicate a refresh operation. 543 The refresh operation is included in this specification due to the 544 nature of the BU message. The BU message updates existing bindings 545 with new information. Hence, all information previously sent in the 546 last BU message need to be resent in all new messages, otherwise such 547 information will be lost. 549 4.8. Acknowledging flow identification options 551 The home agent and mobility anchor point are required to ackowledge 552 the reception of Binding Update by sending Binding Acknowledgment. A 553 correspondent node SHOULD also acknowledge Binding Update. The 554 Binding Acknowledgement is extended by this specification to indicate 555 to the mobile node the success of the flow binding. If a Binding 556 Acknowledgement needs to be sent in response to a Binding Update that 557 contained flow identification option(s), a copy of each flow 558 identification MUST be included. Only the Status field needs to be 559 changed to the appropriate value. The absence of flow identification 560 option in Binding Acknwoledgement indicates that the sender does not 561 support the extension descibed in this document and therefore MUST be 562 interpreted as a negative acknowledgement. 564 5. Usage scenario 566 In this section, we highlight a use case of the flow identification 567 option. 569 Assume a mobile node equipped with two interfaces namely If1 and If2, 570 each connected to a different foreign network. The mobile node 571 configures one global IPv6 address on each interface, namely CoA1 and 572 CoA2 respectively. The mobile node runs Mobile IPv6 with a home 573 agent located in its home network. We assume that an existing IPsec 574 security association is set up betweeen the mobile node and its home 575 agent. We assume that the mobile node wants to exchange secure data 576 flows over CoA1 and insecure data flows over CoA2. To do so, the 577 mobile node may request its home agent to redirect packets intended 578 to the mobile node's home address to a different care-of address, 579 depending on the type of the communication. For example, port 580 numbers 22 (ssh) and 443 (https) may be tunneled to CoA1 while other 581 communications may be tunneled to CoA2. In order to set up these 582 flow bindings, the following messages are exchanged: 584 o The mobile node sends a Binding Update through If2, with the 585 source address set to CoA2. The Binding Update includes a BID 586 sub-option as described in [4]. This sub-option intends to set 587 the highest preference on the given Care-of address. 589 o When the home agent receives the Binding Update, it first 590 validates the Binding Update as recommanded in section 10.3 of 591 [1]. If the Binding Update is accepted, the home agent processes 592 the BID sub-option as described in section 6.2 of [4]. It then 593 registers the source address of the Binding Update as the 594 preferred care-of address for the given home address and sends 595 back a Binding Acknowledgement. 597 o Later, the mobile node sends additional Binding Update with both 598 Flow Identification options and BID sub-option of [4]. The BID 599 sub-option is used to indicate the priority of the new Care-of 600 address. In this example, the priority must be lower than the 601 priority of CoA2. The flow identification options are used to 602 indicate the Care-of address usage preferences. In order to 603 redirect source port numbers 22 and 443 to CoA1, two flow 604 identification options need to be transported as well in the 605 Binding Update. These flow identification options are set as 606 follows: PRI is set to 1, Action is set to 0 (forward), PRO is set 607 to 0 (add), FID is set to 1 (and 2 for the second option), and the 608 following flow description option should indicate port number 22 609 and 443. 611 o When the home agent receives this second Binding Update, it first 612 checks the validity of the Binding Update as recommanded in 613 section 10.3 of [1] and section 6.2 of [4]. If the Binding Update 614 is accepted, the Flow Identification options are treated. If 615 these options are accepted by the home agent, it will return a 616 Binding Acknowledgement with Flow Identification options, each of 617 them having the same first 8 bytes, and the Status field set to 0 618 (success). 620 Thereafter, if a data flow is destinated to the home address of 621 the mobile node, the home agent will determine if the source port 622 number is equal to 22 or 443. If yes, the home agent will tunnel 623 the data flow to CoA1. If not, the data flow will be forwarded to 624 CoA2. 626 6. Mobile Node operations 628 6.1. Default Bindings 630 A default binding is always maintained between a MN and its peers 631 (home agent, correspondent node if RO is used and mobility anchor 632 point if applicable). The default entry indicates which care-of 633 address to use for a data flow that does not match any of the flow 634 bindings. The preferred care-of address is determined through the 635 BID option described in [4]. 637 6.1.1. Managing Flow Bindings with the Home Agent and MAP 639 A mobile node may establish a Flow Binding by issuing a Binding 640 Update containing a Flow Identifier (possibly associated with a Flow 641 Description) in its mobility options. The Flow Identification option 642 MUST indicate valid FID, PRO, PRI (rule priority) and Action fields. 644 The PRO field of the Flow Identification option indicates the 645 processing that the targeted node has to perform to its Bindings 646 Cache List. A mobile node may request for any of the following 647 requests: 649 o 0: Add flow binding. Create a new Flow Binding with the indicated 650 FID and include the attached Flow. A mobile node MUST NOT issue a 651 Flow Identifier with the PRO field set to zero for an existing 652 FID. 654 o 1: Replace a flow binding. This request enables the mobile node 655 to replace attributes of the flow or the care-of address 656 associated with the FID. A mobile node MUST NOT issue a Flow 657 Identifier with the PRO field set to one for a non existent FID. 659 o 2: Refresh a flow binding. This request allows the mobile node to 660 inform the receiver of the BU message that the flow binding is 661 still valid. This request does not modify the flow option. A 662 flow identification option MUST NOT contain this value in the PRO 663 field for a non-existent FID. 665 o 15: Remove a flow binding. This action enables a mobile node to 666 remove the Flow Binding indicated by the FID on the targeted node. 667 A mobile node MUST not issue a Flow Identifier with the PRO field 668 set to 15 for a non existent FID. 670 When adding a flow binding on the home agent or MAP, the mobile node 671 MUST ensure the following: 673 o The PRO field MUST be set to indicate an Add operation. 675 o The FID field includes a value that does not already exist in the 676 mobile node's binding update list. 678 o The PRI field is set to indicate the priority of the rule in case 679 of an overlap between rules. An overlap can occur when one flow 680 matches multiple flow description options. 682 o If the Action field is set to indicate N-cast, the Binding 683 Reference sub-option must be present and it must contain one or 684 more BIDs. If the Binding Update sub-option includes only one 685 BID, it must be pointing to a care-of address other than the one 686 included in the binding update. 688 6.1.2. Managing Flow Bindings in Correspondent nodes 690 When route optimisation is used (see RFC3775 [1]), a mobile node 691 sends the BU message to the correspondent node after the return 692 routability test procedure. When adding flow bindings in the BU sent 693 to the correspondent node, the mobile node MUST ensure the following: 695 o The FID field includes a value that is not already stored in the 696 binding update list with the correspondent node's address. 698 o The PRO field is set to indicate an Add operation. 700 A mobile node can also modify or delete flow bindings in a similar 701 manner to that described earlier with the home agent and MAP. When 702 Modifying a flow binding, the mobile node MUST ensure that the FID 703 used already exists. The rest of the rules for modifying flow 704 bindings are the same as those listed above for adding a flow 705 binding. 707 Refreshing and deleting flow bindings are done in the same manner as 708 that described for the home agent and MAP with one exception: the 709 mobile node MUST NOT refresh or delete bindings associated with any 710 care-of address other than the one included in the BU message. 712 6.1.3. Using Alternate Care-Of Address 714 If the Alternate Care-of Address option is used in the Binding 715 Update, it shall indicate the care-of address to be associated with 716 the Flow Identification options. The Flow Identification options 717 shall contain the FID to be allocated to the Flow Binding. 719 6.1.4. Receiving Binding Acknowledgements 721 According to [1] all nodes are required to silently ignore mobility 722 options not understood while processing Binding Updates. As such a 723 mobile node receiving a Binding Acknowledgement in response to the 724 transmission of a Binding Update MUST determine if the Binding 725 Acknowledgement contains a copy of the 8 bytes of every Flow 726 Identification options included in the Binding Update. A Binding 727 Acknowledgement without Flow Identification option(s) would indicate 728 inabillity on behalf of the source node to support the extensions 729 presented in this document. 731 If a received Binding Acknowledgement contains a copy of the 8 bytes 732 of each flow identification option that was sent within the Binding 733 Update, the status field of each flow identification option indicates 734 the status of the flow binding on the distant node. 736 6.2. Movement 738 When a MN changes its point of attachment to the Internet, its 739 Care-of address(es) may become invalid and need to be updated. All 740 the flow bindings that are attached to such an old Care-of address 741 need to be udpated with a new Care-of address. This can be achieved 742 by adding flow identification options in Binding Update. One flow 743 identification is needed per flow binding. The flow description may 744 not be needed if only the Care-of address is changed, and not the 745 filter itself. The FID must be set to the flow binding that needs to 746 be udpated and the PRO field MUST be set to 1 (i.e., MODIFY). 748 Another solution is to take advantage of the multiple care-of 749 addresses bindings [4] to aggregate updates; the mobile node may only 750 need to update the care-of address associated with the given BID. 751 This would avoid to send a flow identification option per flow 752 binding. 754 6.3. Return Routability Procedure 756 A mobile node may perform route optimization with correpondent nodes. 757 Route optimization allows a mobile node to bind a care-of address to 758 a home address in order to allow the correspondent node to direct the 759 traffic to the current location of the mobile node. Before sending a 760 Binding Update to correspondent node, the Return Routability 761 Procedure needs to be performed between the mobile node and the 762 correspondent node. 764 This procedure is not affected by the extensions defined in this 765 document. However, since a Binding Update message is secured with 766 the key generated based on the home address and care-of address test, 767 a mobile node MUST NOT bind a flow to a care-of address whose keygen 768 token (see RFC3775 [1]) was not used to generate the key for securing 769 the Binding Update. This limitation prohibits the sender from 770 requesting the n-cast action before having registered each care-of 771 address one by one. 773 6.4. Returning Home 775 Whenever a mobile node acquires a point of attachment to the home 776 network and wishes to abolish all Flow Bindings associated with the 777 respective home address, it is required to act as described in 778 Section 11.5.4 of RFC3775 [1]. This will cause the home agent to 779 remove all bindings that are linked to the home address, including 780 the flow bindings. 782 7. Applicability to Route Optimization 784 The route optimization is only defined for mobile nodes (RFC3775 785 [1]), and not mobile router (RFC3963 [2]). Thus, this section does 786 not apply to mobile routers. This section describes the 787 correspondent node operations. 789 Every correspondent node is required to maintain a Binding Cache 790 containing records of associations between mobile node home addresses 791 and care-of addresses (bindings) as they roam away from the home 792 network. RFC3775 [1] allows mobile nodes to register only a single 793 binding per home address with each correspondent node. 795 This specification extends the binding cache structure, and enables 796 correspondent nodes to (i) maintain multiple bindings for a given 797 home address and (ii) to associate multiple Flow Identification / 798 description options with every binding, termed as Flow Binding. A 799 flow matching a Flow Description should be directed to the Care-of 800 address indicated by the Flow Binding. 802 7.1. Receiving Binding Udpate 804 When a correspondant node receives a Binding Update, it first 805 performs the same operation as defined in RFC3775 [1]. If the 806 Binding Update is valid and contains a Flow identification option, 807 the correspondent node needs to check the content of the PRO field. 808 If the PRO field contains a value indicating a request to add a new 809 flow binding, the following checks are done: 811 o The FID field needs to contain a value that does not already 812 exist. If the FID contains a value that already exists, the 813 correspondent node MUST reject the option by sending that option 814 back in its Binding Acknowledgement with a Status field that 815 contains an error value. 817 o If the Action field indicates a request to n-cast the flow, the 818 correspondent node MUST reject the option by sending the option in 819 its binding acknowledgement with an appropriate error code. 821 o If both the FID and Action fields are valid, the correspondent 822 node checks the flow description that must follow the flow 823 identification option. If all of the checks above indicated a 824 valid option, the correspondent node should add the flow binding 825 to its binding cache. 827 If the PRO field in the option indicates a request to modify the 828 option, the following checks must be done by the correspondent node: 830 o The FID MUST include a value that already exists. If the FID 831 cannot be found in the correspondent node's binding cache, the 832 flow identification option MUST be rejected with an appropriate 833 error code. 835 o If the Action field indicates a request to n-cast the flow, the 836 correspondent node MUST reject the option by sending the option in 837 its binding acknowledgement with an appropriate error code. 839 o If the Binding Reference sub-option is present, the correspondent 840 node MUST ensure that the BID points to the care-of address in the 841 packet, or to an already authrozied care-of address. Otherwise 842 the option MUST be rejected with an appropriate error code. 844 o If all of the above checks returned a valid result, the 845 correspondent node should modify the binding as requested. 847 If the PRO field in the option contains a request to refresh a 848 binding, the correspondent node MUST ensure that the FID already 849 exists. If the FID does not exist, the correspondent node MUST 850 reject the option by sending it back in its binding acknowledgement 851 with an appropriate error code in the status field. Otherwise, if 852 the FID exists, the correspondent node must keep it in its binding 853 cache. No further checks need to be done in the option. 855 The correspondent node should reply with a Binding Acknowledgement 856 message. This Binding Acknowlegement message must contain a copy of 857 the 8 bytes of each flow identification option that was included in 858 the Binding Udpate. The Status field of each Flow Identification 859 option MUST be set to an appropriate value. 861 8. Home Agent operations 863 This specification allows the home agent to maintain several bindings 864 for a given home address and to direct packets to different care-of 865 addresses according to flow bindings. This section details the home 866 agent operations necessary to implement this specification. 868 8.1. Receiving Binding Update with the Flow Identification option 870 When the home agent receives a Binding Update which includes at least 871 one Flow Identification option, it first performs the operation 872 described in section 10.3.1 of RFC3775. If the Binding Update is 873 accepted, the home agent then checks the flow identification option. 874 If the PRO field in the option indicates an Add operation, the 875 following checks must be done: 877 o The FID field needs to contain a value that does not already 878 exist. If the FID contains a value that already exists, the home 879 agent MUST reject the option by sending that option back in its 880 Binding acknowledgement with a Status field that contains an 881 appropriate error value. 883 o If the FID field is valid, the home agent then checks the Action 884 field. If the Action field contains a request for n-cast and the 885 Binding Reference sub-option is not included in the option, the 886 flow binding MUST be rejected in the binding acknowledgement 887 containing an error code in the Status field. 889 o If both of the checks above indicate valid FID and Action fields, 890 the home agent checks the flow description following the flow 891 identification option, and identifies the filter that needs to be 892 set up. 894 o If the flow option includes an action field that requests 895 n-casting, the home agent MUST check for the presence of the BID 896 sub-option(s). If the sub-options are not present, the flow 897 identification option MUST be rejected as a poorly formatted 898 option. If one or more BIDs are present in the BID Reference sub- 899 option, the home agent needs to create multiple logical entries in 900 its binding cache. All flows matching the one in the option would 901 be n-cast to the care-of addresses pointed to by the BIDs or the 902 set of registered care-of addresses. If only one BID were 903 included in the Binding Reference sub-option and it pointed to a 904 different care-of address from the one included in the packet, 905 then packets matching the flow would be bicast to those two 906 addresses. However, if only one BID is present and points to the 907 same address in the BU, the n-cast is essentially pointing to one 908 address and therefore cannot be performed. Such option MAY be 909 rejected as a poorly formatted option. 911 o If all of the checks above indicated a valid option, the home 912 agent should add the flow binding to its binding cache. 914 If the PRO field in the option contains a value indicating a request 915 to modify an existing binding, the following actions must be taken: 917 o The FID MUST include a value that already exists. If the FID 918 cannot be found in the home agent's binding cache, the flow 919 identification option MUST be rejected as a poorly formed option. 921 o If the FID is valid, the home agent MUST perform the same steps 922 described above for the Add operation. 924 If the PRO field indicates a refresh operation, the home agent MUST 925 ensure that the FID in the option already exists. If the FID field 926 did not exist, the option MUST be rejected as a poorly formed option. 927 If the FID existed, the home agent MUST keep the current flow binding 928 in its binding cache. 930 8.2. Sending Binding Ackowledgement 932 Upon the reception of a Binding Update, the home agent is required to 933 send back a Binding Acknowledgment. The status code in the Binding 934 Acknowledgement must be set as recommanded in [1] and is not modified 935 by the extension defined in this specification. This status code 936 does not give information on the success or failure of the flow 937 binding. 939 In order to inform about the status of the flow binding that was 940 requested by a mobile node, a flow identification option MUST be set 941 in the Binding Acknowledgement message. The home agent must copy the 942 8 octets of each Flow Identification option received in the Binding 943 Update and set the status code to an approriate value. Each option 944 must be included in the Binding Acknowledgement message. 946 8.3. Deleting an entry in the binding cache 948 A home agent might delete an entry in its binding cache for two 949 reasons: either an entry expires, or the MN explicitly requests the 950 home agent to remove a specific entry. If an entry is going to 951 expire, the home agent SHOULD send a Binding Refresh Advice. 953 8.3.1. Removing Flow Bindings 955 If the home agent receives a valid Binding Update with a flow 956 Identification option where the PRO field is set to 15 (Remove), the 957 home agent MUST remove the corresponding entry. The home agent looks 958 up the entry corresponding to the FID of the Binding Update. If an 959 entry is found, the entry is removed from the Binding cache and a 960 Binding Acknowledgement is sent back to the mobile node with a 961 success value for the status of the flow Identification option (see 962 section Section 8.2. This operation does not modify any other 963 binding that may appear with the same home address. If the FID is 964 not present in the binding cache entry for the corresponding home 965 address, the home agent MUST send back to the mobile node a Binding 966 Acknowledgement with error code 137 (FID not found) in the flow 967 identification option. 969 9. Applicability to Hierarchical Mobile IPv6 971 This section describes the Mobility Anchor Point (MAP) operations. 972 The MAP operation is the same as the home agent operation. Flow 973 bindings sent to the MAP are associated with the regional care-of 974 address. 976 When a MAP receives a Binding Update that includes the flow 977 Identification option, it checks if such option is valid according to 978 the requirements in Section 8.1. If the option is valid, the MAP 979 installs the flow binding associated with the flow identified by the 980 flow description. The lifetime of the binding is the lifetime of the 981 Binding Update. Once the binding is successfully installed, the MAP 982 sends the binding acknowledgement and includes the flow 983 Identification option. The MAP sets the status field to a value 984 indicating success. 986 In all cases, a flow identification option SHOULD be included in the 987 Binding Acknowledgement to indicate success or failure of the flow 988 binding installation. 990 10. Security considerations 992 This draft introduces a new option that adds more granularity to the 993 Binding Update message. The new option allows the mobile node to 994 associate some flows to an interface and other flows to another 995 interface. Since the flow Identification option is part of the 996 mobility header, it uses the same security as the Binding Update, 997 whether it is sent to the home agent, correspondent node, or MAP. 999 11. Acknowledgements 1001 We would like to thank all authors of initial I-Ds that were merged 1002 together to create this document; in alphabetical order: C. 1003 Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. 1004 Pavlidou. Thanks to George Tsirtsis and Vince Park for their 1005 thorough review and input to the draft. Gabor Fekete for the 1006 analysis that led to the inclusion of the BID support. Henrik 1007 Levkowetz for suggesting the equivalent of the CLS field to allow 1008 other ways of describing flows. 1010 12. References 1012 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1013 IPv6", RFC 3775, June 2004. 1015 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1016 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1017 January 2005. 1019 [3] Soliman, H., Castellucia, C., ElMalki, K., and L. Bellier, 1020 "Hierarchical MIPv6 mobility management", RFC 4140, 1021 August 2005. 1023 [4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of 1024 Addresses Registration", draft-ietf-monami6-multiplecoa-00 1025 (work in progress), June 2006. 1027 [5] Deering, S. and R. Hinden, "Internet Protocol Version 6 1028 (IPv6)", IETF RFC 2460, December 1998. 1030 [6] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1031 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1032 draft-ietf-monami6-mipv6-analysis-01 (work in progress), 1033 June 2006. 1035 [7] Ng, C., Paik, E., Ernst, T., and M. Bagnulo, "Analysis of 1036 Multihoming in Network Mobility Support", 1037 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1038 June 2006. 1040 [8] Zhao, X., Castelluccia, C., and M. Baker, "Flexible Network 1041 Support for Mobile Hosts", Journal ACM MONET, April 2001. 1043 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 1044 RFC 3753, June 2004. 1046 [10] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1047 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 1049 [11] Awduche, D., Malcolm, J., Agogbua, J., O Dell, M., and J. 1050 McManus, "Requirements for Traffic Engineering Over MPLS", 1051 RFC 2702, September 1999. 1053 [12] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1054 Kuladinithi, "Motivations and Scenarios for Using Multiple 1055 Interfaces and Global Addresses", 1056 draft-ietf-monami6-multihoming-motivations-scenarios (work in 1057 progress), February 2006. 1059 Authors' Addresses 1061 Hesham Soliman 1062 Elevate Technologies 1064 Phone: 1065 Email: Hesham@elevatemobile.com 1066 URI: 1068 Nicolas Montavont 1069 IT / Telecom Bretagne 1070 2, rue de la chataigneraie 1071 Cesson Sevigne 35576 1072 France 1074 Phone: (+33) 2 99 12 70 23 1075 Email: nicolas.montavont@telecom-bretagne.eu 1076 URI: http://www.rennes.telecom-bretagne.eu/~montavont/ 1078 Nikolaus A. Fikouras 1079 University of Bremen 1080 ComNets-ikom,University of Bremen. 1081 Otto-Hahn-Allee NW 1 1082 Bremen, Bremen 28359 1083 Germany 1085 Phone: +49-421-218-8264 1086 Fax: +49-421-218-3601 1087 Email: niko@comnets.uni-bremen.de 1088 URI: http://www.comnets.uni-bremen.de 1090 Koojana Kuladinithi 1091 University of Bremen 1092 ComNets-ikom,University of Bremen. 1093 Otto-Hahn-Allee NW 1 1094 Bremen, Bremen 28359 1095 Germany 1097 Phone: +49-421-218-8251 1098 Fax: +49-421-218-3601 1099 Email: koo@comnets.uni-bremen.de 1100 URI: http://www.comnets.uni-bremen.de/~koo/ 1102 Full Copyright Statement 1104 Copyright (C) The IETF Trust (2008). 1106 This document is subject to the rights, licenses and restrictions 1107 contained in BCP 78, and except as set forth therein, the authors 1108 retain all their rights. 1110 This document and the information contained herein are provided on an 1111 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1112 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1113 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1114 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1115 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1116 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1118 Intellectual Property 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1132 such proprietary rights by implementers or users of this 1133 specification can be obtained from the IETF on-line IPR repository at 1134 http://www.ietf.org/ipr. 1136 The IETF invites any interested party to bring to its attention any 1137 copyrights, patents or patent applications, or other proprietary 1138 rights that may cover technology that may be required to implement 1139 this standard. Please address the information to the IETF at 1140 ietf-ipr@ietf.org. 1142 Acknowledgment 1144 Funding for the RFC Editor function is provided by the IETF 1145 Administrative Support Activity (IASA).