idnits 2.17.1 draft-ietf-mext-flow-binding-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5648, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5648, updated by this document, for RFC5378 checks: 2006-06-13) -- 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 (October 5, 2010) is 4924 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) == Outdated reference: A later version (-05) exists of draft-ietf-mext-binary-ts-04 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group G. Tsirtsis 3 Internet-Draft Qualcomm 4 Updates: 5648 (if approved) H. Soliman 5 Intended status: Standards Track Elevate Technologies 6 Expires: April 8, 2011 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 October 5, 2010 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-11.txt 17 Abstract 19 This document introduces extensions to Mobile IPv6 that allow nodes 20 to bind one or more flows to a care-of address. These extensions 21 allow multihomed nodes to instruct home agents and other Mobile IPv6 22 entities to direct inbound flows to specific addresses. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 8, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 62 4.1. Definition Update for Binding Identifier Mobility 63 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 65 4.2.1. Flow Identification Sub-Options definition . . . . . . 10 66 4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 14 67 4.3. Flow Bindings entries list and its relationship to 68 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 15 69 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 18 70 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 18 72 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 18 73 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 19 74 5.2.2. Sending BU with Flow Identification Mobility 75 Options . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 21 77 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 21 78 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 22 79 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 22 80 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 22 81 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 23 82 5.3.1. Handling Binding Identifier Mobility Options . . . . . 23 83 5.3.2. Handling Flow Identification Mobility Options . . . . 23 84 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 26 85 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 27 86 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 27 87 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 28 88 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 30 89 7. Security considerations . . . . . . . . . . . . . . . . . . . 31 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 99 1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support 108 [RFC3963] allow a mobile node / mobile router to manage its mobility 109 using the binding update message, which binds one care-of address to 110 one home address and associated mobile networks. The binding update 111 message can be sent to the home agent. In Mobile IPv6, the binding 112 update can also be sent to correspondent node or to a mobility anchor 113 point (see [RFC5380]). The semantics of the binding update are 114 limited to care-of address changes. That is, [RFC3775], [RFC5555], 115 and [RFC3963] do not allow a mobile node / mobile router to bind more 116 than one address to the home address. In [RFC5648] Mobile IPv6 and 117 NEMO Basic Support are extended to allow the binding of more than one 118 care-of address to a home address. This specification further 119 extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to 120 specify policies associated with each binding. A policy can contain 121 a request for special treatment of a particular IPv4 or IPv6 flow, 122 which is viewed as a group of packets matching a traffic selector. 123 Hence, this specification allows a mobile node / mobile router to 124 bind a particular flow to a care-of address without affecting other 125 flows using the same home address. In addition, this specification 126 allows to bind a particular flow to a particular care-of address 127 directly with correspondent node and mobility agents (i.e., home 128 agents [RFC3775] and mobility anchor points [RFC5380]). 130 In this document, a flow is defined as a set of IP packets matching a 131 traffic selector. A traffic selector can identify the source and 132 destination IP addresses, transport protocol number, the source and 133 destination port numbers and other fields in IP and higher layer 134 headers. This specification, does not define traffic selectors, 135 which are going to be defined in other specifications. This 136 specification, however, does define the traffic selector sub-option 137 format to be used for any specific traffic selector. 139 Using the flow identifier option introduced in this specification a 140 mobile node / mobile router can bind one or more flows to a care-of 141 address while maintaining the reception of other flows on another 142 care-of address. The mobile node / mobile router assembles the flow 143 binding requests based on local policies, link characteristics and 144 the types of applications running at the time. Such policies are 145 outside the scope of this document. 147 It should be noted that the flow identification mobility option can 148 be associated with any binding update, whether it is sent to a 149 mobility agent or a correspondent node. 151 Note that per-packet load balancing may have negative impacts on TCP 152 congestion avoidance mechanisms as it is desirable to maintain order 153 between packets belonging to the same TCP connection. This behaviour 154 is specified in [RFC2702]. Other negative impacts are also foreseen 155 for other types of real time connections due to the potential 156 variations in round trip time between packets. Moreover, per-packet 157 load-balancing will negatively affect traffic with anti-replay 158 protection mechanisms. Hence, per-packet load balancing is not 159 envisioned in this specification. 161 In the rest of the document, the term "mobile node" is used to 162 designate either a mobile node as defined in [RFC3775] and [RFC5648], 163 or a mobile router as defined in [RFC3963] unless stated otherwise. 165 3. Terminology 167 Terms used in this document are defined in [RFC3753] and [RFC4885]. 168 The following terms are also used in this document: 170 Flow: A flow is a sequence of packets for which the MN desires 171 special handling either by the Home Agent (HA), the Corresponding 172 Node (CN) or the (Mobility Anchor Point) MAP. 174 Traffic Selector: One or more parameters that can be matched 175 against fields in the packet's headers for the purpose of 176 classifying a packet. Examples of such parameters include the 177 source and destination IP addresses, transport protocol number, 178 the source and destination port numbers and other fields in IP and 179 higher layer headers. 181 Flow binding: It consists of a traffic selector, and one or more 182 BIDs. IP packets from one or more flows that match the traffic 183 selector associated with the flow binding, are forwarded to the 184 BIDs associated with the same flow binding. 186 Flow Identifier: A flow identifier uniquely identifies a flow 187 binding associated with a mobile node. It is generated by a 188 mobile node and is cached in the table of flow binding entries 189 maintained by the MN, HA, CN or MAP. 191 4. Mobile IPv6 Extensions 193 This section introduces extensions to Mobile IPv6 that are necessary 194 for supporting the flow binding mechanism described in this document. 196 4.1. Definition Update for Binding Identifier Mobility Option 198 This specification updates the definition of the Binding Identifier 199 Mobility option defined in [RFC5648], as follows: 201 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type = 35 | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Binding ID (BID) | Status |H| BID-PRI | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 208 + + 209 : IPv4 or IPv6 care-of address (CoA) : 210 + + 211 +---------------------------------------------------------------+ 213 Figure 1: The Binding Identifier Mobility option 215 BID-PRI 217 This is a 7-bit unsigned integer placing each BID to a relative 218 priority with other registered BIDs. Value '0' is reserved and 219 MUST NOT be used. A lower number in this field indicates a 220 higher priority, while BIDs with the same BID-PRI value have 221 equal priority meaning that, the BID used is an implementation 222 issue. This is consistent with current practice in packet 223 classifiers. 225 4.2. Flow Identification Mobility Option 227 The flow identification mobility option is a new mobility option 228 [RFC3775] and it is included in the binding update and 229 acknowledgement messages. This option contains information that 230 allows the receiver of a binding update to install policies on a 231 traffic flow and route it to a given care-of address. Multiple 232 options may exist within the same binding update message. The 233 alignment requirement for this option is 2n. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Option Type | Option Len | FID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | FID-PRI | Reserved | Status | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Sub-options (optional) ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: The Flow Identification Mobility Option 247 Option Type 249 To be assigned by IANA 251 Option Len 253 Length of the option in octets as per [RFC3775]. 255 FID 257 The Flow Identifier field is a 16-bit unsigned integer that 258 includes the unique identifier for the flow binding. This 259 field is used to refer to an existing flow binding or to create 260 a new flow binding. The value of this field is set by the 261 mobile node. FID = 0 is reserved and MUST NOT be used. 263 FID-PRI 265 This is a 16-bit unsigned integer priority field to indicate 266 the priority of a particular option. This field is needed in 267 cases where two different flow descriptions in two different 268 options overlap. The priority field decides which policy 269 should be executed in those cases. A lower number in this 270 field indicates a higher priority. Value '0' is reserved and 271 MUST NOT be used. FID-PRI MUST be unique to each of the flows 272 pertaining to a given MN. In other words, two FIDs MUST NOT be 273 associated with the same FID-PRI value. 275 Status 277 This 8-bit unsigned integer field indicates the success or 278 failure of the flow binding operation for the particular flow 279 in the option. This field is not relevant to the binding 280 update message as a whole or to other flow identification 281 options. This field is only relevant when included in the 282 Binding Acknowledgement message and must be ignored in the 283 binding update message. The following values are reserved for 284 the status field within the flow identification mobility 285 option: 287 0 Flow binding successful 289 128 Administratively prohibited 291 129 Flow binding rejected, reason unspecified 293 130 Flow identification mobility option malformed 295 131 BID not found 297 132 FID not found 299 133 Traffic selector format not supported 301 Sub-options (optional) 303 zero or more sub-options, defined in Section 4.2.1 305 4.2.1. Flow Identification Sub-Options definition 307 Flow identification sub-options are encoded within the remaining 308 space of the flow identification mobility option, using a sub-option 309 type-length-value (TLV) format as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Sub-Opt Type |Sub-Opt Length | Sub-Option Data... 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 3: Flow Identification Sub-Option format 319 Sub-opt Type 321 8-bit unsigned integer indicating the sub-option Type. When 322 processing a flow identification mobility option containing an 323 option for which the sub-option Type value is not recognized by 324 the receiver, the receiver MUST silently ignore and skip over 325 the sub-option, correctly handling any remaining sub-options in 326 the same option. 328 Sub-opt Len 330 8-bit unsigned integer, representing the length in octets of 331 the flow identification sub-option. This field indicates the 332 length of the sub-option not including the Sub-opt Type and 333 Sub-opt Length fields. Note that Sub-opt Type '0' 334 (Section 4.2.1.1) is a special case that does not take a Sub- 335 opt Length field. 337 Sub-Option Data 339 A variable length field that contains data specific to the sub- 340 option 342 The following subsections specify the sub-option types which are 343 currently defined for use in the flow identification option. 344 Implementations MUST silently ignore any sub-options that they do not 345 understand. 347 These sub-options may have alignment requirements. Following the 348 convention in [RFC3775], regarding mobility options, these sub- 349 options are aligned in a packet so that multi-octet values within the 350 sub-option Data field of each sub-option fall on natural boundaries 351 (i.e., fields of width n octets are placed at an integer multiple of 352 n octets from the start of the header, for n = 1, 2, 4, or 8) . 354 4.2.1.1. Pad1 356 The Pad1 sub-option does not have any alignment requirements. Its 357 format is as follows: 359 0 360 0 1 2 3 4 5 6 7 361 +-+-+-+-+-+-+-+-+ 362 | Sub-Opt Type | 363 +-+-+-+-+-+-+-+-+ 365 Sub-opt Type 367 0 369 NOTE! the format of the Pad1 sub-option is a special case - it has 370 neither sub-option Length nor sub-option Data fields. 372 The Pad1 sub-option is used to insert one octet of padding in the 373 flow identification option. If more than one octet of padding is 374 required, the PadN sub-option, described next, should be used rather 375 than multiple Pad1 sub-options. 377 4.2.1.2. PadN 379 The PadN sub-option does not have any alignment requirements. Its 380 format is as follows: 382 0 1 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 385 | Sub-Opt Type | Sub-Opt Len | Option Data 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 388 Sub-opt Type 390 1 392 Sub-opt Len 394 set to the length of the sub-option 396 Sub-opt Data 398 0 or more bytes set to 0 by the sender and ignored by the 399 receiver. 401 The PadN sub-option is used to insert two or more octets of padding 402 in the flow identification mobility option. For N octets of padding, 403 the sub-option Length field contains the value N, and the sub-option 404 data consists of N-2 zero-valued octets. PadN sub-option data MUST 405 be ignored by the receiver. 407 4.2.1.3. Binding Reference Sub-option 409 This section introduces the binding reference sub-option, included in 410 the flow identification mobility option. A node MUST NOT include 411 more than one binding reference sub-options in a given flow binding 412 identification option. The binding reference sub-option includes one 413 or more BIDs defined in MCoA [RFC5648]. This sub-option associates 414 the flow described in a a flow identification mobility option with 415 one or more registered BIDs. 417 When binding a flow using this sub-option, the binding identifier 418 mobility option, defined in [RFC5648], MUST be included in either the 419 same or an earlier Binding Update (BU). The binding reference sub- 420 option is shown below. The alignment requirement for this sub-option 421 is 2n. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |Sub-opt Type | Sub-Opt Len | BID | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | BID ........ 429 +-+-+-+-+-+-+-+-+-+- 431 Figure 4: The Binding Reference sub-option 433 Sub-opt Type 435 2 437 Sub-opt Len 439 Variable 441 BID 443 A 16-bit unsigned integer indicating the BID that the mobile 444 node wants to associate with the flow identification option. 445 One or more BID fields can be included in this sub-option. 446 Since each BID is 2 bytes long, the value of the Sub-opt Len 447 field indicates the number of BIDs present. Number of BIDs = 448 Sub-opt Len/2. 450 4.2.1.4. Traffic Selector sub-option 452 The traffic selector sub-option includes the parameters used to match 453 packets for a specific flow binding. A node MUST NOT include more 454 than one traffic selector sub-option in a given flow binding 455 identification option. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Traffic Selector ... 463 +-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 5: The Traffic Selector sub-option 467 Sub-opt Type 469 3 471 Sub-opt Len 473 variable 475 TS Format 477 An 8-bit unsigned integer indicating the Traffic Selector Format. 478 Value "0" is reserved and MUST NOT be used. 480 Reserved 482 An 8-bit reserved field. It MUST be set to zero by the sender and 483 ignored by the receiver. 485 Traffic Selector 487 A variable length field, the format and content of which is out of 488 scope for this specification. The traffic selector defined in 489 [I-D.ietf-mext-binary-ts] is mandatory to implement. 491 4.2.2. Flow Summary Mobility Option 493 The flow summary mobility option is a new mobility option [RFC3775], 494 which includes one or more flow identifiers (FIDs) for the purpose of 495 refreshing their state. The alignment requirement for this option is 496 2n. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Option Type | Option Len | FID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | FID ........ 504 +-+-+-+-+-+-+-+-+-+- 506 Figure 6: The Flow Summary Mobility Option 508 Option Type 510 To be assigned by IANA 512 Option Length 514 Length of the option in octets as per [RFC3775] 516 FID 518 A 16-bit unsigned integer indicating a registered FID. One or 519 more FID fields can be included in this option. Number of FIDs 520 = Option Len/2 522 4.3. Flow Bindings entries list and its relationship to Binding Cache 524 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 525 identify the mobile IP state maintained by the mobile node, mobility 526 agent, and correspondent node. The binding cache includes, between 527 others, the mobile node's home address, the registered care-of 528 address, and the lifetime of the binding. The binding cache has been 529 extended by [RFC5648] to include more than one care-of addresses and 530 to associate each of them with a Binding Identifier (BID). 532 This specification does not modify the mobile IPv6 binding cache any 533 further. 535 Flow bindings can be thought of as a conceptual list of entries that 536 is separate from the binding cache. The flow bindings list contains 537 an entry for each of the registered flow bindings. Flow binding 538 entries point to an entry in the binding cache by means of the BID. 539 Each flow binding entry includes the following parameters: 541 o FID (Flow Identifier): For a given mobile node, identified by its 542 primary home address, the FID MUST uniquely identify an entry, 543 i.e. a unique flow binding. Each mobile node can only have a 544 single entry identified by a given FID at any one time. A given 545 FID number space is used for all the addresses associated to a 546 given MN by the HA (e.g., via [RFC3963]). Different mobile nodes 547 use the same FID number space. 549 o A Traffic Selector: Included in a traffic selector sub-option. 551 o BID(s): The list of BIDs associated with the entry as defined by 552 the binding reference sub-option included in the FID option that 553 created it. 555 o Active/Inactive flag: This flag indicates whether the entry is 556 active or inactive. 558 o FID-PRI: This field indicates the priority of the flow binding and 559 is used to break the tie between overlapping flow bindings. 561 The flow bindings list is associated with a given mobile node, and 562 the correspondent binding cache. An entry in the flow bindings list, 563 however, is identified by the FID and the list is ordered according 564 to the FID-PRI field as defined in the FID option that created each 565 entry. 567 A valid BID is required to make the entry 'Active'. If all of the 568 BIDs pointed to by a given entry are deregistered [RFC5648], the flow 569 binding entry becomes 'Inactive', in other words it does not affect 570 data traffic. Note that an entry becomes 'Inactive' only if all of 571 the BIDs are deregistered. If only some of the BIDs are still valid, 572 the invalid BIDs are simply ignored. 574 Also note that the state described in this section is maintained by 575 the mobile node as well as in mobility agents and correspondent 576 nodes. As such the mobile node is fully aware of which are the valid 577 BIDs at any time and which flow binding entries are active/inactive. 578 Section 5 defines how these flow binding entries are manipulated by 579 the mobile node in detail. 581 As an example the following represents an ordered flow binding entry 582 table for a mobile node that has registered multiple care-of 583 addresses and flow bindings. 585 FID-PRI FID Traffic Selector BIDs A/I 586 ------- --- ---------------- ---- ------- 587 10 4 TCP 2 Active 588 30 2 srcAddr=IPy 4 Inactive 589 40 5 UDP 1,3 Active 591 Ordered Flow Binding Entries 593 According to the above list of flow binding entries, all TCP traffic 594 will match the first entry, and will be forwarded to BID2, 595 corresponding to a given care-of address (IP3), as shown below. 597 The second entry is marked as Inactive since the BID 4 does not exist 598 in the ordered list of BID entries below. Inactive entries do not 599 affect traffic, i.e., packets are not matched against them. 601 Any UDP traffic that does not match any of the earlier entries will 602 match the third rule, at which point it will be replicated and 603 forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and 604 IP2 shown below. 606 Finally any remaining packets that do not match any of the entries 607 above will be simply forwarded to the care-of address indicated by 608 the highest order BID in the table below. In the example, such 609 packets will be forwarded to BID1 corresponding to care-of address 610 IP1. 612 BID-PRI BID CoA 613 --------- --- --- 614 20 1 IP1 615 30 3 IP2 616 30 2 IP3 618 Ordered BID Entries 620 Mobility agent and corresponding node implementations should take 621 care to avoid flow binding rules affecting the fundamental operation 622 of Mobile IPv6 and its extensions. In particular, flow binding rules 623 MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 624 and corresponding nodes communicating with a given mobile node, since 625 that could adversely affect the operation of the protocol. Other, 626 non Mobile IPv6 traffic generated by these entities SHOULD be matched 627 against the mobile node's flow binding rules as normal. 629 5. Protocol operations 631 5.1. General 633 This specification introduces a flow bindings list of entries and an 634 ordered list of flow binding identifiers, allowing mobile nodes to 635 associate flow binding policies with the registered care-of 636 addresses. 638 The flow identification mobility option defines how the mobile node 639 can control a set of flow binding entries maintained in a mobility 640 agent, or correspondent node. 642 This specification allows mobile nodes to direct flows to a 643 particular care-of address. The granularity of what constitutes a 644 flow depends on the traffic selector used. 646 The remainder of this section discusses how mobile nodes can use the 647 options and sub-options defined in this document when sending binding 648 updates to the correspondent node, home agent, or mobility anchor 649 point. In addition, refresh, deletion, and modification of flow 650 binding entries are all discussed below. 652 5.1.1. Preferred Care-of address 654 Any node that supports this specification MUST maintain an ordered 655 list of care-of addresses for each mobile node it maintains a list of 656 flow bindings for. The ordered list of care-of addresses is built 657 based on the BID-PRI field of the binding identifier mobility option 658 (see Section 4.1). 660 The ordered list of BIDs is used to determine how to forward a packet 661 to a given mobile node when the packet does not match any of the flow 662 binding entries defined in Section 4.3. A packet that does not match 663 any of the flow binding entries SHOULD be forwarded to the care-of 664 address identified by the BID with the highest priority i.e., lowest 665 BID-PRI value. 667 5.2. Mobile Node Considerations 669 This specification allows the mobile node to maintain several 670 bindings with its mobility agent, and correspondent nodes and to 671 direct packets to different care-of addresses according to flow 672 bindings. This section details the mobile node operations necessary 673 to implement this specification. 675 The mobility agent and correspondent node list of flow bindings is 676 manipulated by the mobile node, via flow identification and flow 677 summary mobility options included in binding update messages. Each 678 flow binding update can add, modify, refresh, or delete a given 679 binding. More than one flow identification mobility options MAY be 680 included in the same binding update but each of them MUST include a 681 different FID. In other words, two flow identification options in 682 the same message can not be about the same flow binding. 684 All flow binding state MUST be refreshed in every binding update the 685 mobile node sends. Any previously registered flow binding that is 686 not included in a given binding update will be deleted. So, any flow 687 bindings that are not added or modified by a flow identification 688 mobility option, but have previously registered and need to be 689 maintained MUST be included in a flow summary mobility option. 691 5.2.1. Sending BU with BID Options 693 This specification (see Section 4.1) updates the definition of the 694 binding identifier mobility option, originally defined in [RFC5648]. 695 According to this specification the BID option includes a BID-PRI 696 field assigning each registered care-of address a priority, and thus 697 placing them in an ordered list as also described in Section 4.3. 699 To ensure backwards compatibility with [RFC5648] for the purpose of 700 this specification the field BID-PRI MUST NOT be set to zero. 701 Receiver implementation of this specification will take a BID-PRI 702 field of value zero as an indication that this is a BID option of the 703 format defined in [RFC5648]. 705 Mobile nodes supporting this specification MUST use the BID option 706 format defined in Section 4.1. Mobile nodes MUST also register all 707 care-of addresses using the updated BID option format, either in the 708 same BU as any flow identification mobility options using them, or in 709 earlier BUs. 711 5.2.2. Sending BU with Flow Identification Mobility Options 713 5.2.2.1. New Flow Bindings 715 When adding a new flow binding, a mobile node sends the flow 716 identification mobility option in the binding update, with the FID 717 field set to a value that is not already present in the list of flow 718 binding entries maintained by the receiver. The care-of address(es) 719 associated with each flow identification mobility options in the 720 binding update, must be logically registered by this binding update, 721 or must have already been registered by the receiver of the binding 722 update in an earlier binding update, as defined in Section 5.2.1. 724 The flow identification mobility option MUST include a unique flow 725 identifier in the FID field. The FID needs only be unique for the 726 receiver of the binding update and for the same sender, i.e. the same 727 FID can be used across different receivers of the binding update, for 728 the same sender. The FID-PRI field is set to the desired unique 729 priority of the FID, defining the order of the flow binding to be 730 added in the list of flow binding entries as defined in Section 4.3. 731 The Status field is set to zero in all binding update messages. 733 Since this flow identification mobility option is requesting the 734 addition of a new flow binding in the list of flow bindings 735 maintained by the receiver, the mobile node MUST include exactly one 736 Traffic Selector sub-option (see Section 4.2.1.4) describing the flow 737 associated with the new flow binding. The TS Format field of the 738 Traffic Selector sub-option MUST be set to the non-zero value of the 739 format used by the mobile node. 741 The mobile node MUST also include exactly one BID Reference sub- 742 option (see Section 4.2.1.3) to associate the flow binding with a 743 given set of BIDs and corresponding CoAs. 745 5.2.2.2. Updating Flow Bindings 747 Flow binding modification is essentially a process where parameters 748 associated with an existing flow binding in the list of flow binding 749 entries is replaced by parameters included in the flow identification 750 mobility option, and the same FID is maintained. With this procedure 751 the mobile node can change the priority, the BID(s), and/or the 752 traffic selector associated with a flow binding. 754 To modify an existing flow binding the mobile node MUST send a 755 binding update with a flow identification option, with the FID field 756 set to one of the FID values already in the list of flow binding 757 entries. The FID-PRI field MUST be set to the priority value for the 758 flow binding entry. The Status field is set to zero since this 759 option is in a binding update. 761 The mobile node MAY include exactly one traffic selector sub-option 762 (see Section 4.2.1.4) describing the updated flow to be associated 763 with the flow binding. The mobile node MAY, however, omit the 764 traffic selector sub-option if it wants the traffic selector 765 currently associated with the flow binding entry identified by the 766 FID field to be maintained. 768 The mobile node MAY include exactly one binding reference sub-option 769 (see Section 4.2.1.3) to associate the existing flow binding with a 770 new set of CoAs. The mobile node MAY omit the binding reference sub- 771 option if it wants the BIDs currently associated with the flow 772 binding entry identified by the FID field to be maintained. 774 Note that it is also possible for the mobile node to effectively 775 modify the effect of a flow binding entry without actually changing 776 the entry itself. This can be done by changing the CoA associated 777 with a given BID, which is a process defined in detail in [RFC5648]. 779 5.2.3. Sending BU with a Flow Summary Option 781 When the mobile node sends a binding update it MUST refresh all flow 782 bindings it wants to maintain even if it does not want to change any 783 of their parameters. 785 To refresh an existing flow binding the mobile node MUST send a 786 binding update with a flow summary option. The flow summary option 787 MUST include one or more FID fields as indicated in Section 4.2.2. 788 Each FID field included MUST be set to one of the FID values already 789 in the list of flow binding entries. Each flow summary mobility 790 options can identify up to 127 FIDs, so more than one such options 791 can be included in a binding update message as required. A given FID 792 SHOULD NOT be included more than once in all of the flow summary 793 mobility options included a given binding update message. 795 Any flow bindings (active or inactive) that are not identified in a 796 binding update will be removed from the list of flow binding entries. 798 Note that any inactive flow bindings, i.e., flow bindings without 799 associated BIDs that are marked as Inactive in the list of flow 800 binding entries (see Section 4.3), MUST also be refreshed, or 801 modified, to be maintained. If they are not included in a BU they 802 will be removed. 804 5.2.4. Removing flow bindings 806 Removal of flow binding entries is performed implicitly by omission 807 of a given FID from a binding update. 809 To remove a flow binding the MN simply sends a binding update that 810 includes flow identification and flow summary mobility options for 811 all the FIDs that need to be refreshed, modified, or added, and 812 simply omits any FIDs that need to be removed. 814 Note that a mobile node can also render a flow binding inactive by 815 removing the BIDs associated with it, without removing the flow 816 binding itself. The procedure for removing a BID is defined in 817 detail in [RFC5648]. 819 When all the BIDs associated with a flow binding are removed, the 820 flow binding MUST be marked as inactive in the list of flow binding 821 entries as shown in Section 4.3. In other words the state associated 822 with the flow binding MUST be maintained but it does no longer affect 823 the mobile node's traffic. The MN can return an inactive flow 824 binding to the active state by using the flow binding modification 825 process described in Section 5.2.2.2, to associate it again with one 826 or more valid BIDs. 828 5.2.5. Returning Home 830 This specification is compatible to the home registration procedures 831 defined in [RFC3775] and [RFC5648]. More specifically, if the mobile 832 node performs an [RFC3775] style deregistration, all of its bindings, 833 including flow bindings are deleted. If the mobile node, however, 834 performs an [RFC5648] style home registration, then the home link is 835 associated with a specific BID and so, as far as this specification 836 is concerned, it is treated as any other link associated with a given 837 BID. 839 5.2.6. Receiving Binding Acknowledgements 841 According to [RFC3775] all nodes are required to silently ignore 842 mobility options not understood while processing binding updates. As 843 such, a mobile node receiving a Binding Acknowledgement in response 844 to the transmission of a binding update MUST determine if the Binding 845 Acknowledgement contains a copy of every flow identification mobility 846 options included in the binding update. A Binding Acknowledgement 847 without flow identification option(s), in response to a Binding 848 Update with flow identification mobility option, would indicate 849 inability (or unwillingness) on behalf of the source node to support 850 the extensions presented in this document. 852 If a received Binding Acknowledgement contains a copy of each flow 853 identification mobility option that was sent within the binding 854 update, the status field of each flow identification option indicates 855 the status of the flow binding on the distant node. 857 5.2.7. Return Routability Procedure 859 A mobile node may perform route optimization with correspondent nodes 860 as defined in [RFC3775]. Route optimization allows a mobile node to 861 bind a care-of address to a home address in order to allow the 862 correspondent node to direct the traffic to the current location of 863 the mobile node. Before sending a Binding Update to correspondent 864 node, the Return Routability Procedure needs to be performed between 865 the mobile node and the correspondent node. This procedure is not 866 affected by the extensions defined in this document. 868 5.3. HA, MAP, and CN Considerations 870 This specification allows the mobility agents (Home Agents and 871 Mobility Anchor Points), and correspondent nodes to maintain several 872 flow bindings for a given home address and to direct packets to 873 different care-of addresses according to flow bindings. This section 874 details the home agent operations necessary to implement this 875 specification. These operations are identical for MAPs and CNs 876 unless otherwise stated. 878 Note that route optimization is only defined for mobile nodes (MIPv6 879 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 880 sections only apply to correspondent nodes with respect to mobile 881 nodes and not for mobile routers. 883 5.3.1. Handling Binding Identifier Mobility Options 885 This specification (see Section 4.1) updates the definition of the 886 binding identifier mobility option, originally defined in [RFC5648]. 887 According to this specification the BID option includes a BID-PRI 888 field assigning each registered care-of address a priority, and thus 889 placing them in an ordered list (see Section 4.3). 891 Home agents receiving BUs including BID options and flow 892 identification options MUST logically process BID options first. 893 This is because BID Reference sub-options included in the flow 894 identification mobility options might refer to BIDs defined in BID 895 options included in the same message. 897 The BID option is processed as defined in [RFC5648] but then the BID 898 to care-of address mapping is placed in an ordered list according to 899 the BID-PRI field of the BID option. 901 Binding Identifier registrations and deregistrations indirectly 902 affect the MN's flow binding entries. The home agent MUST update the 903 flow binding entries table accordingly as BIDs are added or removed ( 904 as per [RFC5648]). For example, as discussed in Section 4.3, if all 905 of the BIDs associated with a given flow binding entry are removed 906 (i.e., become invalid) the entry MUST be marked as inactive. While 907 if any of the invalid BIDs associated with an inactive flow binding 908 entry are registered (i.e., become valid), the entry MUST be marked 909 as active. 911 5.3.2. Handling Flow Identification Mobility Options 913 When the home agent receives a binding update which includes at least 914 one flow identification mobility option, it first performs the 915 operation described in section 10.3.1 of RFC3775, followed by the 916 operations defined in Section 5.3.1 of this document. 918 Home agents that do not support this specification will ignore the 919 flow identification mobility options and all their sub-options, 920 having no effect on the operation of the rest of the protocol. 922 If the binding update is accepted, and the home agent is willing to 923 support flow bindings for this MN, the home agent checks the flow 924 identification mobility options. 926 If more than one flow identification mobility option in the same BU, 927 has the same value in the FID field, all the flow identification 928 mobility options MUST be rejected. 930 If all FID fields have different values the flow identification 931 mobility options can be processed further and in any order, as 932 defined by the following subsections. 934 5.3.2.1. Handling new FIDs 936 If the FID field of the flow identification mobility option is not 937 already present in the list of flow binding entries for this mobile 938 node, then this is a request for a new entry. 940 If the flow identification mobility option does not include a 941 traffic selector sub-option, the home agent MUST reject this 942 request by copying the flow identification mobility option in the 943 BA, and setting the Status field to the value defined in Figure 2 944 for "Flow identification option malformed". 946 If the flow identification option does include a traffic selector 947 sub-option, but the format indicated in the TS Format field is not 948 supported, the home agent MUST reject this request by copying the 949 flow identification mobility option in the BA, and setting the 950 Status field to the value defined in Figure 2 for "Traffic 951 Selector format not supported". 953 Then the home agent MUST check the Binding Reference sub-option. 955 If the Binding reference sub-option is not included, the home 956 agent MUST reject this request by copying the flow identification 957 mobility option in the BA, and setting the Status field to the 958 value defined for "Flow identification mobility option malformed" 959 in Section 4.2. 961 If the binding reference sub-option is present and includes one or 962 more BIDs that are not present in the binding cache of the mobile 963 node the home agent MUST reject this request by copying the flow 964 identification option in the BA, and setting the Status field to 965 the value defined for "BID not found" in Section 4.2. 967 If the binding reference sub-option is present and includes one or 968 more BIDs, and the BIDs exist in the mobile node's binding cache, 969 the home agent SHOULD add a new entry in the mobile node's list of 970 flow binding entries, as defined below. 972 When the home agent decides to add an entry in the mobile node's list 973 of flow binding entries, as discussed above, it MUST do it according 974 to the following rules: The entry MUST be placed according to the 975 order indicated by the FID-PRI field of the flow identification 976 mobility option and it MUST include: 978 the FID as a key to the entry 980 The traffic selector included in the corresponding sub-option 982 the BIDs indicated in the binding reference sub-option 984 the entry MUST be marked as Active, as shown in Section 4.3 986 5.3.2.2. Handling known FIDs 988 If the FID field of the flow identification mobility option is 989 already present in the list of flow binding entries for this mobile 990 node, then this is a request to update the existing entry. 992 The flow binding modification is essentially a process where 993 parameters associated with an existing flow binding entry are 994 replaced by the parameters included in a flow identification mobility 995 option with the same FID as the existing entry. 997 The home agent MUST change the priority of the entry according to the 998 FID-PRI field of the flow identification mobility option. 1000 Since this flow identification mobility option is designed to update 1001 an existing entry it may or may not include a traffic selector sub- 1002 option. Specifically: 1004 if a traffic selector sub-option is not included in the flow 1005 identification mobility option, then the traffic selector already 1006 associated with entry MUST be maintained, 1008 otherwise the traffic selector in the entry MUST be replaced by 1009 the traffic selector in the sub-option. 1011 Since this flow identification mobility option is designed to update 1012 an existing entry, it may or may not include a binding reference sub- 1013 option. Specifically: 1015 if a binding reference sub-option is not included in the flow 1016 identification mobility option, then the BIDs already associated 1017 with entry MUST be maintained, 1019 otherwise the BIDs in the entry MUST be replaced by the BIDs in 1020 the sub-option. 1022 5.3.3. Handling Flow Summary Mobility Option 1024 When the home agent receives a binding update which includes flow 1025 summary mobility options, it first performs the operation described 1026 so far in Section 5.3. 1028 If the value of any of the FID fields included in a flow summary 1029 mobility option is not present in the list of flow binding entries 1030 for this mobile node, the home agent MUST reject this flow binding 1031 refresh by including a flow identification mobility option in the BA 1032 for each FID that is not found, and by setting the FID field to the 1033 value of the FID that is not found and the Status field to the value 1034 defined for "FID not found" in Section 4.2. 1036 If the value of the FID field is present in the mobile nodes list of 1037 flow binding entries the, home agent SHOULD refresh the flow binding 1038 entry identified by the FID without changing any of the other 1039 parameters associated with it. 1041 If a given FID is included more than once in the same or different 1042 flow summary mobility options in the same binding update message, the 1043 duplicates can be simply ignored. 1045 Note that, an [RFC3775] de-registration binding update (with a zero 1046 lifetime) would result in deleting all bindings, including all flow 1047 bindings regardless of the presence of flow summary mobility options. 1048 A binding update (with a zero lifetime) would result in deleting all 1049 bindings, including all flow bindings regardless of the presence of 1050 flow summary mobility options. A specific binding de-registration, 1051 however, as defined in [RFC5648] (with lifetime of zero and one or 1052 more Binding Identifier mobility options identifying specific BIDs) 1053 does not remove all the bindings for the MN and thus it SHOULD 1054 include flow summary mobility options to maintain the flow bindings 1055 that need to be preserved. 1057 5.3.4. Flow Binding Removals 1059 Removal of flow bindings is performed implicitly by omission of a 1060 given FID from a binding update. 1062 When a valid binding update is received, any registered FIDs that are 1063 not explicitly referred to in a flow identification mobility option 1064 or in a flow summary mobility option, in the same binding update, 1065 MUST be removed from the list of flow binding entries for the mobile 1066 node. 1068 5.3.5. Sending Binding Acknowledgements 1070 Upon the reception of a binding update, the home agent is required to 1071 send back a Binding Acknowledgment. The status code in the Binding 1072 Acknowledgement must be set as recommended in [RFC3775]. This status 1073 code does not give information on the success or failure of flow 1074 bindings. 1076 In order to inform the mobile node about the status of the flow 1077 binding(s) requested by a mobile node, flow identification options 1078 SHOULD be included in the Binding Acknowledgement message. 1079 Specifically, the home agent SHOULD copy each flow identification 1080 mobility option received in the binding update and set its status 1081 code to an appropriate value. Note that the home agent does not need 1082 to respond specifically regarding FIDs included in a flow summary 1083 mobility option but only to those in flow identification mobility 1084 options. If an operation requested in a flow identification option 1085 by a mobile node is performed successfully by the home agent, the 1086 status field on the copied flow identification mobility option in the 1087 BA, SHOULD be set to the value defined for "Flow binding successful" 1088 in Section 4.2, otherwise it SHOULD be set to one of the rejection 1089 codes also defined in Section 4.2. Section 5.3.2 identifies a number 1090 of cases where specific error codes should be used. 1092 Home agents that support this specification MAY refuse to maintain 1093 flow bindings by setting the status field of any flow identification 1094 mobility options to the value defined for "Administratively 1095 prohibited" in Section 4.2, or by just ignoring all the flow binding 1096 options. 1098 Note that BID options and their Status field are handled as defined 1099 in [RFC5648]. The BID-PRI field in a BID option included in the 1100 binding acknowledgement is copied from the the BID-PRI field of the 1101 corresponding BID option in the binding request. 1103 5.3.6. Packet Processing 1105 This section defines packet processing rules according to this 1106 specification. This specification does not change any of the packet 1107 interception rules defined in [RFC3775], and [RFC5555]. These rules 1108 apply to HAs, MAPs, and CNs, as part of the routing process for any 1109 packet with destination address set to a valid home address of the 1110 mobile node. For nodes other than CNs this also applies to packets 1111 with destination address set to an address under any of the 1112 registered prefixes. These rules apply equally to IPv6 packets as 1113 well as to IPv4 packets as per [RFC5555]. 1115 Before a packet is forwarded to the mobile node it MUST be matched 1116 against the ordered list of flow bindings stored in the list of flow 1117 binding entries for this mobile node (see Section 4.3). A match is 1118 attempted with the traffic selector included in the first line 1119 (highest order) of the table. The first entry that creates a match 1120 defines how the packet is routed. When a packet matches the traffic 1121 selector of a given entry, a copy of the packet is forwarded to each 1122 of the care-of addresses associated with the BIDs indicated in the 1123 same line of the table. 1125 If any of the BIDs indicated does not correspond to a valid care-of 1126 address, e.g., the BID was deregistered then, that BID has no effect 1127 on the traffic. In other words, packets matching the flow binding 1128 are forwarded to the remaining BIDs, pointing to registered care-of 1129 addresses. If none of the BIDs pointed to in a flow binding entry is 1130 valid then the entry is considered to be inactive (as defined in 1131 Section 4.3) and is skipped. In other words packets should not be 1132 matched against that entry. 1134 If a packet does not match any of the active flow binding entries for 1135 the given MN, the packet SHOULD be forwarded to the highest order 1136 care-of address i.e., the one associated with the BID with the lowest 1137 BID-PRI. 1139 If a packet is fragmented, only the first fragment contains all IP 1140 and transport layer headers, while subsequent fragments only contain 1141 an IP header without transport layer headers. For this reason it is 1142 possible that subsequent fragments do not match the same traffic 1143 selector as the initial fragment of such a packet. Unless specific 1144 measures are taken the likely outcome is that the initial fragment is 1145 routed as the MN intended while subsequent fragments are routed 1146 differently, and probably based on the default flow binding. HAs, 1147 MAPs, and CNs SHOULD take care to forward all fragments of a given 1148 packet the same way, and in accordance to the flow binding matching 1149 the first fragment of said packet. This should be possible given the 1150 fact that fragment headers include enough information to identify a 1151 fragment as part of a specific packet, but the details of how this is 1152 ensured are implementation specific and are not defined in this 1153 specification. 1155 6. MTU Considerations 1157 The options and sub-options defined in this specification add to 1158 those defined in [RFC3775] and other related specifications, all of 1159 which potentially adds to the size of binding update messages. 1160 Implementations SHOULD take care to minimize fragmentation by forming 1161 binding updates that are shorter than what the path MTU allows 1162 whenever possible. 1164 This specification offers a number of mechanisms for reducing the 1165 size of binding updates. The operations defined in this 1166 specification that require the most verbose options are those 1167 registering new BIDs Section 4.1 and identifying new flows 1168 Section 4.2.1.4. Implementations are encouradged to keep binding 1169 updates to sizes below than that of the path's MTU by making full use 1170 of BID reference Section 4.2.1.3 sub-option and flow summary 1171 Section 4.2.2 option, which allows them to refer to already 1172 registered care-of addresses and flow bindings, while registering new 1173 ones in subsequent binding update messages. 1175 7. Security considerations 1177 This draft introduces a new option that adds more granularity to the 1178 binding update and acknowledgement messages defined in [RFC3775], 1179 [RFC5555], and [RFC3963], so it inherits the security considerations 1180 discussed in these documents. The new option allows the mobile node 1181 to associate some flows to one interface and other flows to another 1182 interface. Since the flow identification mobility option is part of 1183 the mobility header, it uses the same security as the Binding Update, 1184 whether it is sent to a mobility agent, or to a correspondent node. 1186 This specification does not open up new fundamental lines of attack 1187 on communications between the MN and its correspondent nodes. 1188 However, it allows attacks of a finer granularity than those on the 1189 binding update. For instance, the attacker can divert or replicate 1190 flows of special interest to the attacker to an address of the 1191 attacker's choosing, if the attacker is able to impersonate the MN or 1192 modify a binding update sent by the MN. Hence it becomes doubly 1193 critical that authentication and integrity services are applied to 1194 binding updates. 1196 Finally, when the optional anti-replay feature of Encapsulating 1197 Security Payload (ESP) [RFC4303] is employed and packets from/to 1198 different CoAs are sent on the same security association (SA), some 1199 packets could be discarded at the receiver due to the windowing 1200 mechanism used by this feature. Therefore, a sender SHOULD put 1201 traffic from/to different CoAs, but with the same HoA in the selector 1202 values, on different SAs to support Multiple Care-of Addresses 1203 appropriately. To permit this, the IPsec implementation SHOULD 1204 establish and maintain multiple SAs between a given sender and 1205 receiver, with the same selectors. Distribution of traffic among 1206 these parallel SAs to support Multiple Care-of Addresses is locally 1207 determined by the sender and is not negotiated by the Internet Key 1208 Exchange (IKEv2) protocol [RFC4306]. The receiver will process the 1209 packets from the different SAs without prejudice. 1211 8. IANA Considerations 1213 This specification requires the following IANA assignments on 1214 existing namespaces as well as the creation of some new namespaces. 1216 1) New Mobility Options [RFC3775]: This registry is available from 1217 http://www.iana.org under "Mobile IPv6 parameters". The following 1218 type numbers need to be assigned for: 1220 Flow Identification Mobility Option, define in Section 4.2 1222 Flow Summary Mobility Option, defined in Section 4.2.2 1224 2) New "Flow Identification Mobility Option Status codes" 1225 namespace needs to be created. The following 'Status' codes are 1226 defined in this specification, in Section 4.2: 1228 0 Flow binding successful 1230 1-127 unassigned and available for success codes to be 1231 allocated via Standards Action or IESG Approval as per 1232 [RFC5226] 1234 128 Administratively prohibited 1236 129 Flow binding rejected, reason unspecified 1238 130 Flow identification mobility option malformed 1240 131 BID not found 1242 132 FID not found 1244 133 Traffic selector format not supported 1246 134-250 unassigned and available for reject codes to be 1247 allocated via Standards Action or IESG Approval as per 1248 [RFC5226] 1250 251-255 reserved for experimental use. This small number of 1251 status codes should be sufficient for experiments with 1252 currently unforeseen error conditions. 1254 4) New "Flow Identification Sub-Options" namespace for the Flow 1255 Identification Mobility Option. The sub-option space is defined 1256 in Figure 3. The following Sub-option Type values are defined in 1257 this specification: 1259 0 Pad 1261 1 PadN 1263 2 BID Reference 1265 3 Traffic Selector 1267 4-250 unassigned and available for allocation based on 1268 Standards Action or IESG Approval as per [RFC5226] 1270 251-255 reserved for experimental use. This small number of 1271 sub-option types should be sufficient for experiments with 1272 additional parameters associated with a flow. 1274 5) New "Traffic Selector Format" namespace for the Traffic 1275 Selector sub-option. The traffic selector format space is defined 1276 by the TS Format field in Figure 5. The following values are 1277 defined in this specification: 1279 0 Reserved 1281 1-250 unassigned and available for allocation based on 1282 Standards Action or IESG Approval as per [RFC5226] 1284 251-255 reserved for experimental use. This small number of 1285 traffic selector format types should be sufficient for 1286 experiments with different ways of representing a traffic 1287 selector. 1289 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1290 spaces, future allocations from the new number spaces requires 1291 Standards Action or IESG Approval as per [RFC5226] 1293 9. Contributors 1295 We would like to explicitly acknowledge the following person who co- 1296 authored one of the documents used as source material for this 1297 document. 1299 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1301 10. Acknowledgements 1303 We would also like to acknowledge the following people in 1304 alphabetical order for their contributions to this specification: C. 1305 Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- 1306 Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. 1307 Also, Gabor Fekete for the analysis that led to the inclusion of the 1308 BIDRef sub-option, and Henrik Levkowetz for suggesting support for 1309 other ways of describing flows. 1311 11. References 1313 11.1. Normative References 1315 [I-D.ietf-mext-binary-ts] 1316 Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, 1317 "Traffic Selectors for Flow Bindings", 1318 draft-ietf-mext-binary-ts-04 (work in progress), 1319 February 2010. 1321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1322 Requirement Levels", BCP 14, RFC 2119, March 1997. 1324 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1325 in IPv6", RFC 3775, June 2004. 1327 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1328 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1329 RFC 3963, January 2005. 1331 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1332 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1333 May 2008. 1335 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1336 Routers", RFC 5555, June 2009. 1338 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1339 and K. Nagami, "Multiple Care-of Addresses Registration", 1340 RFC 5648, October 2009. 1342 11.2. Informative References 1344 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1345 McManus, "Requirements for Traffic Engineering Over MPLS", 1346 RFC 2702, September 1999. 1348 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1349 RFC 3753, June 2004. 1351 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1352 RFC 4303, December 2005. 1354 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1355 RFC 4306, December 2005. 1357 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1358 Terminology", RFC 4885, July 2007. 1360 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1361 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1362 Management", RFC 5380, October 2008. 1364 Authors' Addresses 1366 George Tsirtsis 1367 Qualcomm 1369 Email: tsirtsis@qualcomm.com 1371 Hesham Soliman 1372 Elevate Technologies 1374 Email: hesham@elevatemobile.com 1376 Nicolas Montavont 1377 Institut Telecom / Telecom Bretagne 1378 2, rue de la chataigneraie 1379 Cesson Sevigne 35576 1380 France 1382 Phone: (+33) 2 99 12 70 23 1383 Email: nicolas.montavont@telecom-bretagne.eu 1384 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1386 Gerardo Giaretta 1387 Qualcomm 1389 Email: gerardog@qualcomm.com 1391 Koojana Kuladinithi 1392 University of Bremen 1393 ComNets-ikom,University of Bremen. 1394 Otto-Hahn-Allee NW 1 1395 Bremen, Bremen 28359 1396 Germany 1398 Phone: +49-421-218-8264 1399 Fax: +49-421-218-3601 1400 Email: koo@comnets.uni-bremen.de 1401 URI: http://www.comnets.uni-bremen.de/~koo/