idnits 2.17.1 draft-ietf-mext-flow-binding-07.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 (August 16, 2010) is 5001 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-ietf-mext-binary-ts-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: February 17, 2011 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 August 16, 2010 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-07.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 February 17, 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 . . . . . . 11 66 4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 15 67 4.3. Flow Bindings entries list and its relationship to 68 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 16 69 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 19 70 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 19 72 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 19 73 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 20 74 5.2.2. Sending BU with Flow Identification Mobility 75 Options . . . . . . . . . . . . . . . . . . . . . . . 20 76 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22 77 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23 78 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23 79 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23 80 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24 81 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24 82 5.3.1. Handling Binding Identifier Mobility Options . . . . . 24 83 5.3.2. Handling Flow Identification Mobility Options . . . . 25 84 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28 85 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28 86 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 29 87 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 88 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 32 89 7. Security considerations . . . . . . . . . . . . . . . . . . . 33 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 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, however, does not define traffic 135 selectors and it is assumed that one or more ways of defining traffic 136 selectors are going to be defined in other specifications. This 137 specification, however, does define the traffic selector sub-option 138 format to be used for any defined traffic selectors. 140 Using the flow identifier option introduced in this specification a 141 mobile node / mobile router can bind one or more flows to a care-of 142 address while maintaining the reception of other flows on another 143 care-of address. The mobile node / mobile router assembles the flow 144 binding request based local policies, link characteristics and the 145 types of applications running at the time. Such policies are outside 146 the scope of this document. 148 It should be noted that the flow identification mobility option can 149 be associated with any binding update, whether it is sent to a 150 mobility agent or a correspondent node. 152 Note that per-packet load balancing may have negative impacts on TCP 153 congestion avoidance mechanisms as it is desirable to maintain order 154 between packets belonging to the same TCP connection. This behaviour 155 is specified in [RFC2702]. Other negative impacts are also foreseen 156 for other types of real time connections due to the potential 157 variations in round trip time between packets. Moreover, per-packet 158 load-balancing will negatively affect traffic with anti-reply 159 protection mechanisms. Hence, per-packet load balancing is not 160 envisioned in this specification. 162 In the rest of the document, the term "mobile node" is used to 163 designate either a mobile node as defined in [RFC3775] and [RFC5648], 164 or a mobile router as defined in [RFC3963] unless stated otherwise. 166 3. Terminology 168 Terms used in this document are defined in [RFC3753] and [RFC4885]. 169 The following terms are also used in this document: 171 Flow: A flow is a sequence of packets for which the MN desires 172 special handling either by the Home Agent (HA), the Corresponding 173 Node (CN) or the (Mobility Anchor Point) MAP. 175 Traffic Selector: One or more parameters that can be matched 176 against fields in the packet's headers for the purpose of 177 classifying a packet. Examples of such parameters include the 178 source and destination IP addresses, transport protocol number, 179 the source and destination port numbers and other fields in IP and 180 higher layer headers. 182 Flow binding: It consists of a traffic selector, and an action. 183 IP packets from one or more flows that match the traffic selector 184 associated with the flow binding, are processed according to the 185 action associated with the same flow binding. 187 Flow Identifier: A flow identifier uniquely identifies a flow 188 binding associated with a mobile node. It is generated by a 189 mobile node and is cached in the table of flow binding entries 190 maintained by the MN, HA, CN or MAP. 192 4. Mobile IPv6 Extensions 194 This section introduces extensions to Mobile IPv6 that are necessary 195 for supporting the flow binding mechanism described in this document. 197 4.1. Definition Update for Binding Identifier Mobility Option 199 This specification updates the definition of the Binding Identifier 200 Mobility option defined in [RFC5648], as follows: 202 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type = 35 | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Binding ID (BID) | Status |H| BID-PRI | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 209 + + 210 : IPv4 or IPv6 care-of address (CoA) : 211 + + 212 +---------------------------------------------------------------+ 214 Figure 1: The Binding Identifier Mobility option 216 BID-PRI 218 This is a 7-bit unsigned integer placing each BID to a relative 219 priority with other registered BIDs. Value '0' is reserved and 220 MUST NOT be used. A lower number in this field indicates a 221 higher priority, while BIDs with the same BID-PRI value have 222 equal priority meaning that, the BID used is an implementation 223 issue. This is consistent with current practice in packet 224 classifiers. 226 4.2. Flow Identification Mobility Option 228 The flow identification mobility option is a new mobility option 229 [RFC3775] and it is included in the binding update and 230 acknowledgement messages. This option contains information that 231 allows the receiver of a binding update to install policies on a 232 traffic flow and route it to a given care-of address. Multiple 233 options may exist within the same binding update message. The 234 alignment requirement for this option is 2n. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Option Type | Option Len | FID | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | FID-PRI | Action | Rsvd | Status | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Sub-options (optional) ... 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: The Flow Identification Mobility Option 248 Option Type 250 To be assigned by IANA 252 Option Len 254 Length of the option in octets as per [RFC3775]. 256 FID 258 The Flow Identifier field is a 16-bit unsigned integer that 259 includes the unique identifier for the flow binding. This 260 field is used to refer to an existing flow binding or to create 261 a new flow binding. The value of this field is set by the 262 mobile node. FID = 0 is reserved and MUST NOT be used. 264 FID-PRI 266 This is an 8-bit unsigned priority field to indicate the 267 priority of a particular option. This field is needed in cases 268 where two different flow descriptions in two different options 269 overlap. The priority field decides which policy should be in 270 those cases. A lower number in this field indicates a higher 271 priority. Value '0' is reserved and MUST NOT be used. FID-PRI 272 MUST be unique to each of the flows pertaining to a given MN. 274 Action 276 This 8-bit unsigned integer field specifies the action that 277 needs to be taken by the receiver of the binding update 278 containing the flow identification option. The details of 279 these requests are discussed below. The following values are 280 reserved for the Action field in this option: 282 0 Reserved and MUST NOT be used 284 1 'Discard'. This value indicates a request to discard all 285 packets in the flow described by the option. No BIDs are 286 associated with this Action. Care should be taken when 287 using this Action as it will lead to disrupting applications 288 communication. Implementations may consider notifying 289 impacted applications in mobile nodes. 291 2 'Forward'. This value indicates a request to send the 292 flow to one or more addresses indicated in the binding 293 reference sub-option (see Section 4.2.1.3). One or more 294 BIDs MUST be associated with this Action. If only one BID 295 is associated with this action then it is essentially a 296 request to forward packets to that CoA, otherwise matching 297 packets are replicated and forwarded to all of the indicated 298 CoAs. Care should be taken when multiple BIDs are used in 299 combination with the 'Forward' action as some transport 300 layers may not be able to handle packet duplication and this 301 can affect their performance. 303 3-255 Reserved for future use 305 Rsvd 307 This field is unused. It MUST be set to zero by the sender and 308 ignored by the receiver. 310 Status 312 This 8-bit unsigned integer field indicates the success or 313 failure of the flow binding operation for the particular flow 314 in the option. This field is not relevant to the binding 315 update message as a whole or to other flow identification 316 options. This field is only relevant when included in the 317 Binding Acknowledgement message and must be ignored in the 318 binding update message. The following values are reserved for 319 the status field within the flow identification mobility 320 option: 322 0 Flow binding successful 324 128 Administratively prohibited 326 129 Flow binding rejected, reason unspecified 327 130 Flow identification mobility option malformed 329 131 BID not found 331 132 FID not found 333 133 Traffic selector format not supported 335 134 Discard function not supported 337 135 Forward function not supported 339 Sub-options (optional) 341 zero or more sub-options, defined in Section 4.2.1 343 4.2.1. Flow Identification Sub-Options definition 345 Flow identification sub-options are encoded within the remaining 346 space of the flow identification mobility option, using a sub-option 347 type-length-value (TLV) format as follows: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Sub-Opt Type |Sub-Opt Length | Sub-Option Data... 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 3: Flow Identification Sub-Option format 357 Sub-opt Type 359 8-bit unsigned integer indicating the sub-option Type. When 360 processing a flow identification mobility option containing an 361 option for which the sub-option Type value is not recognized by 362 the receiver, the receiver MUST silently ignore and skip over 363 the option, correctly handling any remaining sub-options in the 364 same option. 366 Sub-opt Len 368 8-bit unsigned integer, representing the length in octets of 369 the flow identification sub-option. This field indicates the 370 length of the sub-option not including the Sub-opt Type and 371 Sub-opt Length fields. Note that Sub-opt Type '0' 372 (Section 4.2.1.1) is a special case that does not take a Sub- 373 opt Length field. 375 Sub-Option Data 377 A variable length field that contains data specific to the sub- 378 option 380 The following subsections specify the sub-option types which are 381 currently defined for use in the flow identification option. 382 Implementations MUST silently ignore any sub-options that they do not 383 understand. 385 These sub-options may have alignment requirements. Following the 386 convention in [RFC3775], regarding mobility options, these sub- 387 options are aligned in a packet so that multi-octet values within the 388 sub-option Data field of each sub-option fall on natural boundaries 389 (i.e., fields of width n octets are placed at an integer multiple of 390 n octets from the start of the header, for n = 1, 2, 4, or 8) . 392 4.2.1.1. Pad1 394 The Pad1 sub-option does not have any alignment requirements. Its 395 format is as follows: 397 0 398 0 1 2 3 4 5 6 7 399 +-+-+-+-+-+-+-+-+ 400 | Sub-Opt Type | 401 +-+-+-+-+-+-+-+-+ 403 Sub-opt Type 405 0 407 NOTE! the format of the Pad1 sub-option is a special case - it has 408 neither sub-option Length nor sub-option Data fields. 410 The Pad1 sub-option is used to insert one octet of padding in the 411 flow identification option. If more than one octet of padding is 412 required, the PadN sub-option, described next, should be used rather 413 than multiple Pad1 sub-options. 415 4.2.1.2. PadN 417 The PadN sub-option does not have any alignment requirements. Its 418 format is as follows: 420 0 1 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 423 | Sub-Opt Type | Sub-Opt Len | Option Data 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 426 Sub-opt Type 428 1 430 Sub-opt Len 432 set to the length of the sub-option 434 Sub-opt Data 436 0 or more bytes set to 0 by the sender and ignored by the 437 receiver. 439 The PadN sub-option is used to insert two or more octets of padding 440 in the flow identification mobility option. For N octets of padding, 441 the sub-option Length field contains the value N, and the sub-option 442 data consists of N-2 zero-valued octets. PadN sub-option data MUST 443 be ignored by the receiver. 445 4.2.1.3. Binding Reference Sub-option 447 This section introduces the binding reference sub-option, which may 448 be included in the flow identification mobility option. A node MUST 449 NOT include more than one binding reference sub-options in a given 450 flow binding identification option. The binding reference sub-option 451 includes one or more BIDs defined in MCoA [RFC5648]. When this sub- 452 option is included in the flow identification mobility option it 453 associates the flow described with one or more registered BIDs. 455 When binding a flow using this sub-option, the binding identifier 456 mobility option, defined in [RFC5648], MUST be included in either the 457 same or an earlier Binding Update (BU). The binding reference sub- 458 option is shown below. The alignment requirement for this sub-option 459 is 2n. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |Sub-opt Type | Sub-Opt Len | BID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | BID ........ 467 +-+-+-+-+-+-+-+-+-+- 469 Figure 4: The Binding Reference sub-option 471 Sub-opt Type 473 2 475 Sub-opt Len 477 Variable 479 BID 481 A 16-bit unsigned integer indicating the BID that the mobile 482 node wants to associate with the flow identification option. 483 One or more BID fields can be included in this sub-option. 484 Since each BID is 2 bytes long, the value of the Sub-opt Len 485 field indicates the number of BIDs present. Number of BIDs = 486 Sub-opt Len/2. 488 4.2.1.4. Traffic Selector sub-option 490 The traffic selector sub-option includes the parameters used to match 491 packets for a specific flow binding. A node MUST NOT include more 492 than one traffic selector sub-option in a given flow binding 493 identification option. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Traffic Selector ... 501 +-+-+-+-+-+-+-+-+-+-+-+ 503 Figure 5: The Traffic Selector sub-option 505 Sub-opt Type 507 3 509 Sub-opt Len 511 variable 513 TS Format 515 An 8-bit unsigned integer indicating the Traffic Selector Format. 516 Value "0" is reserved and MUST NOT be used. 518 Reserved 520 An 8-bit reserved field. It MUST be set to zero by the sender and 521 ignored by the receiver. 523 Traffic Selector 525 A variable length field, the format and content of which is out of 526 scope for this specification. The traffic selector defined in 527 [I-D.ietf-mext-binary-ts] is mandatory to implement. 529 4.2.2. Flow Summary Mobility Option 531 The flow summary mobility option is a new mobility option [RFC3775], 532 which includes one or more flow identifiers (FIDs) for the purpose of 533 refreshing their state. A node MUST NOT include more than one flow 534 summary mobility option in a given binding update message. The 535 alignment requirement for this option is 2n. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Option Type | Option Len | FID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | FID ........ 543 +-+-+-+-+-+-+-+-+-+- 545 Figure 6: The Flow Summary Mobility Option 547 Option Type 549 To be assigned by IANA 551 Option Length 553 Length of the option in octets as per [RFC3775] 555 FID 557 A 16-bit unsigned integer indicating a registered FID. One or 558 more FID fields can be included in this option. Number of FIDs 559 = Option Len/2 561 4.3. Flow Bindings entries list and its relationship to Binding Cache 563 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 564 identify the mobile IP state maintained by the mobile node, mobility 565 agent, and correspondent node. The binding cache includes, between 566 others, the mobile node's home address, the registered care-of 567 address, and the lifetime of the binding. The binding cache has been 568 extended by [RFC5648] to include more than one care-of addresses and 569 to associate each of them with a Binding Identifier (BID). 571 This specification does not modify the mobile IPv6 binding cache any 572 further. 574 Flow bindings can be thought of as a conceptual list of entries that 575 is separate from the binding cache. The flow bindings list contains 576 an entry for each of the registered flow bindings. Flow binding 577 entries can point to an entry in the binding cache by means of the 578 BID. Each flow binding entry includes the following parameters : 580 o FID (Flow Identifier): For a given mobile node, identified by its 581 primary home address, the FID MUST uniquely identify an entry, 582 i.e. a unique flow binding. Each mobile node can only have a 583 single entry identified by a given FID at any one time. A given 584 FID number space is used for all the addresses associated to a 585 given MN by the HA (e.g., via [RFC3963]). Different mobile nodes 586 use the same FID number space. 588 o A Traffic Selector: Included in a traffic selector sub-option. 590 o BID(s): The list of BIDs associated with the entry as defined by 591 the binding reference sub-option included in the FID option that 592 created it. 594 o Action: The action associated with a given entry as defined by the 595 Action field of the FID option that created it 597 o Active/Inactive flag: This flag indicates whether the entry is 598 active or inactive. 600 o FID-PRI: This field indicates the priority of the flow and is used 601 to break the tie between overlapping flows. 603 The flow bindings list is associated with a given mobile node, and 604 the correspondent binding cache. An entry in the flow bindings list, 605 however, is identified by the FID and the list is ordered according 606 to the FID-PRI field as defined in the FID option that created each 607 entry. 609 For entries that take BIDs (i.e., entries that do not indicate a 610 'Discard' action), a valid BID is required to make the entry 611 'Active'. If all of the BIDs pointed to by a given entry are 612 deregistered [RFC5648], the flow binding entry becomes 'Inactive', in 613 other words it does not affect data traffic. Note that if the action 614 parameter in an entry indicates 'Forward' then the entry becomes 615 'Inactive' only if all of the BIDs are deregistered. If only some of 616 the BIDs are still valid, the invalid BIDs are simply ignored. 618 Also note that the state described in this section is maintained by 619 the mobile node as well as in mobility agents and correspondent 620 nodes. As such the mobile node is fully aware of which are the valid 621 BIDs at any time and which flow binding entries are active/inactive. 622 Section 5 defines how these flow binding entries are manipulated by 623 the mobile node in detail. 625 As an example the following represents an ordered flow binding entry 626 table for a mobile node that has registered multiple care-of 627 addresses and flow bindings. 629 FID-PRI FID Traffic Selector BIDs Action A/I 630 ------- --- ---------------- ---- ------- ------ 631 10 4 TCP 2 Forward Active 632 20 3 srcAddr=IPx N/A Discard Active 633 30 2 srcAddr=IPy 4 Forward Inactive 634 40 5 UDP 1,3 Forward Active 636 Ordered Flow Binding Entries 638 According to the above list of flow binding entries, all TCP traffic 639 will match the first entry, and according to the Action indicated it 640 will be forwarded to BID2, corresponding to a given care-of address 641 (IP3), as shown below. Any traffic that is not TCP, but has as 642 source address IPx will match the second entry, and according to the 643 associated Action it will be discarded. Note that any TCP traffic 644 with source address IPx will match the first entry and thus it will 645 be forwarded as per that entry. 647 The third entry is marked as Inactive since the BID 4 does not exist 648 in the ordered list of BID entries below. Inactive entries do not 649 affect traffic, i.e., packets are not matched against them. 651 Any UDP traffic that does not match any of the earlier entries will 652 match the forth rule and according to the Action indicated, it will 653 be replicated and forwarded to BIDs 1 and 3, corresponding to care-of 654 addresses IP1 and IP2 shown below. 656 Finally any remaining packets that do not match any of the entries 657 above will be simply forwarded to the care-of address indicated by 658 the highest order BID in the table below. In the example, such 659 packets will be forwarded to BID1 corresponding to care-of address 660 IP1. 662 BID-PRI BID CoA 663 --------- --- --- 664 20 1 IP1 665 30 3 IP2 666 30 2 IP3 668 Ordered BID Entries 670 Mobility agent and corresponding node implementations should take 671 care to avoid flow binding rules affecting the fundamental operation 672 of Mobile IPv6 and its extensions. In particular, flow binding rules 673 MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 674 and corresponding nodes communicating with a given mobile node, since 675 that could adversely affect the operation of the protocol. Other, 676 non Mobile IPv6 traffic generated by these entities SHOULD be matched 677 against the mobile node's flow binding rules as normal. 679 5. Protocol operations 681 5.1. General 683 This specification introduces a flow bindings list of entries and an 684 ordered list of flow binding identifiers, allowing mobile nodes to 685 associate flow binding policies with the registered care-of 686 addresses. 688 The flow identification mobility option defines how the mobile node 689 can control a set of flow binding entries maintained in a mobility 690 agent, or correspondent node. The fields of the flow identification 691 mobility option are necessary for ordering flow identification 692 mobility options, indicating the sort of action that should be 693 undertaken to the recipient's flow binding list of entries or for 694 carrying the results of such a petition. 696 This specification allows mobile nodes to direct flows to a 697 particular care-of address. The granularity of what constitutes a 698 flow depends on the traffic selector used. 700 The remainder of this section discusses how mobile nodes can use the 701 options and sub-options defined in this document when sending binding 702 updates to the correspondent node, home agent, or mobility anchor 703 point. In addition, refresh, deletion, and modification of flow 704 binding entries are all discussed below. 706 5.1.1. Preferred Care-of address 708 Any node that supports this specification MUST maintain an ordered 709 list of care-of addresses for each mobile node it maintains a list of 710 flow bindings for. The ordered list of care-of addresses is built 711 based on the BID-PRI field of the binding identifier mobility option 712 (see Section 4.1). 714 The ordered list of BIDs is used to determine how to forward a packet 715 to a given mobile node when the packet does not match any of the flow 716 binding entries defined in Section 4.3. A packet that does not match 717 any of the flow binding entries SHOULD be forwarded to the care-of 718 address identified by the BID with the highest priority i.e., lowest 719 BID-PRI value. 721 5.2. Mobile Node Considerations 723 This specification allows the mobile node to maintain several 724 bindings with its mobility agent, and correspondent nodes and to 725 direct packets to different care-of addresses according to flow 726 bindings. This section details the mobile node operations necessary 727 to implement this specification. 729 The mobility agent and correspondent node list of flow bindings is 730 manipulated by the mobile node, via flow identification and flow 731 summary mobility options included in binding update messages. Each 732 flow binding update can add, modify, refresh, or delete a given 733 binding. More than one flow identification mobility options MAY be 734 included in the same binding update but each of them MUST include a 735 different FID. In other words, two flow identification options in 736 the same message can not be about the same flow binding. 738 All flow binding state MUST be refreshed in every binding update the 739 mobile node sends. Any previously registered flow binding that is 740 not included in a given binding update will be deleted. So, any flow 741 bindings that are not added or modified by a flow identification 742 mobility option, but have previously registered and need to be 743 maintained MUST be included in a flow summary mobility option. Only 744 one flow summary mobility option can be included in a given binding 745 update. 747 5.2.1. Sending BU with BID Options 749 This specification (see Section 4.1) updates the definition of the 750 binding identifier mobility option, originally defined in [RFC5648]. 751 According to this specification the BID option includes a BID-PRI 752 field assigning each registered care-of address a priority, and thus 753 placing them in an ordered list as also described in Section 4.3. 755 To ensure backwards compatibility with [RFC5648] for the purpose of 756 this specification the field BID-PRI MUST NOT be set to zero. 757 Receiver implementation of this specification will take a BID-PRI 758 field of value zero as an indication that this is a BID option of the 759 format defined in [RFC5648]. 761 Mobile nodes supporting this specification MUST use the BID option 762 format defined in Section 4.1. Mobile nodes MUST also register all 763 care-of addresses using the updated BID option format, either in the 764 same BU as any flow identification mobility options using them, or in 765 earlier BUs. 767 5.2.2. Sending BU with Flow Identification Mobility Options 769 5.2.2.1. New Flow Bindings 771 When adding a new flow binding, a mobile node sends the flow 772 identification mobility option in the binding update, with the FID 773 field set to a value that is not already present in the list of flow 774 binding entries maintained by the receiver. The care-of address(es) 775 associated with each flow identification mobility options in the 776 binding update, must be logically registered by this binding update, 777 or must have already been registered by the receiver of the binding 778 update in an earlier binding update, as defined in Section 5.2.1. 780 The flow identification mobility option MUST include a unique flow 781 identifier in the FID field. The FID needs only be unique for the 782 receiver of the binding update and for the same sender, i.e. the same 783 FID can be used across different receivers of the binding update, for 784 the same sender. 786 The FID-PRI field is set to the desired unique priority of the 787 FID, defining the order of the flow binding to be added in the 788 list of flow binding entries as defined in Section 4.3. 790 The Action field is set to one of the defined action codes (see 791 Section 4.2). 793 The Status field is set to zero in all binding update messages. 795 Since this flow identification mobility option is requesting the 796 addition of a new flow binding in the list of flow bindings 797 maintained by the receiver, the mobile node MUST include exactly one 798 Traffic Selector sub-option (see Section 4.2.1.4) describing the flow 799 associated with the new flow binding. The TS Format field of the 800 Traffic Selector sub-option MUST be set to the non-zero value of the 801 format used by the mobile node. 803 The mobile node MAY also include up to one BID Reference sub-option 804 (see Section 4.2.1.3) to associate the flow binding with a given set 805 of BIDs and corresponding CoAs. Depending on the Action field of the 806 flow identification mobility option, the following rules MUST be 807 followed with respect to the binding reference sub-option: 809 - if the Action indicates 'Discard', the binding reference sub- 810 option SHOULD NOT be included. If it is included it will be 811 ignored by the receiver. 813 - if the Action indicates 'Forward', a single binding reference 814 sub-option with one or more BIDs MUST be included. 816 5.2.2.2. Updating Flow Bindings 818 Flow binding modification is essentially a process where parameters 819 associated with an existing flow binding in the list of flow binding 820 entries is replaced by parameters included in the flow identification 821 mobility option, and the same FID is maintained. With this procedure 822 the mobile node can change the action, the priority, the BID, and/or 823 the traffic selector associated with a flow binding. 825 To modify an existing flow binding the mobile node MUST send a 826 binding update with a flow identification option, with the FID field 827 set to one of the FID values already in the list of flow binding 828 entries. 830 The FID-PRI and Action fields MUST be set to the priority value 831 for the flow binding entry. 833 The Status field is set to zero since this option is in a binding 834 update. 836 The mobile node MAY include exactly one traffic selector sub-option 837 (see Section 4.2.1.4) describing the updated flow to be associated 838 with the flow binding. The mobile node MAY, however, omit the 839 traffic selector sub-option if it wants the traffic selector 840 currently associated with the flow binding entry identified by the 841 FID field to be maintained. 843 The mobile node MAY include exactly one binding reference sub-option 844 (see Section 4.2.1.3) to associate the existing flow binding with a 845 new set of CoAs. If the mobile node includes a binding reference 846 sub-option then it should follow the rules described in 847 Section 5.2.2.1. The mobile node MAY omit the binding reference sub- 848 option if it wants the BIDs currently associated with the flow 849 binding entry identified by the FID field to be maintained. 851 Note that it is also possible for the mobile node to effectively 852 modify the effect of a flow binding entry without actually changing 853 the entry itself. This can be done by changing the CoA associated 854 with a given BID, which is a process defined in detail in [RFC5648]. 856 5.2.3. Sending BU with a Flow Summary Option 858 When the mobile node sends a binding update it MUST refresh all flow 859 bindings it wants to maintain even if it does not want to change any 860 of their parameters. 862 To refresh an existing flow binding the mobile node MUST send a 863 binding update with a flow summary option. The flow summary option 864 MUST include one or more FID fields as indicated in Section 4.2.2. 865 Each FID field included MUST be set to one of the FID values already 866 in the list of flow binding entries. 868 Any flow bindings (active or inactive) that are not included in a 869 binding update will be removed from the list of flow binding entries. 871 Note that any inactive flow bindings, i.e., flow bindings without 872 associated BIDs that are marked as Inactive in the list of flow 873 binding entries (see Section 4.3), MUST also be refreshed, or 874 modified, to be maintained. If they are not included in a BU they 875 will be removed. 877 5.2.4. Removing flow bindings 879 Removal of flow binding entries is performed implicitly by omission 880 of a given FID from a binding update. 882 To remove a flow binding the MN simply sends a binding update that 883 includes flow identification and flow summary mobility options for 884 all the FIDs that need to be refreshed, modified, or added, and 885 simply omits any FIDs that need to be removed. 887 Note that a mobile node can also render a flow binding inactive by 888 removing the BIDs associated with it, without removing the flow 889 binding itself. The procedure for removing a BID is defined in 890 detail in [RFC5648]. 892 When all the BIDs associated with a flow binding are removed, the 893 flow binding MUST be marked as inactive in the list of flow binding 894 entries as shown in Section 4.3. In other words the state associated 895 with the flow binding MUST be maintained but it does no longer affect 896 the mobile node's traffic. The MN can return an inactive flow 897 binding to the active state by using the flow binding modification 898 process described in Section 5.2.2.2, to associate it again with one 899 or more valid BIDs. Remember that flow bindings indicating a 900 'Discard' action do not take BIDs and thus cannot be rendered 901 inactive. Instead these entries can only be removed by omitting 902 their FID from a subsequent BU. 904 5.2.5. Returning Home 906 This specification is compatible to the home registration procedures 907 defined in [RFC3775] and [RFC5648]. More specifically, if the mobile 908 node performs an [RFC3775] style deregistration, all of its bindings, 909 including flow bindings are deleted. If the mobile node, however, 910 performs an [RFC5648] style home registration, then the home link is 911 associated with a specific BID and so, as far as this specification 912 is concerned, it is treated as any other link associated with a given 913 BID. 915 5.2.6. Receiving Binding Acknowledgements 917 According to [RFC3775] all nodes are required to silently ignore 918 mobility options not understood while processing binding updates. As 919 such a mobile node receiving a Binding Acknowledgement in response to 920 the transmission of a binding update MUST determine if the Binding 921 Acknowledgement contains a copy of every flow identification mobility 922 options included in the binding update. A Binding Acknowledgement 923 without flow identification option(s), in response to a Binding 924 Update with flow identification mobility option, would indicate 925 inability (or unwillingness) on behalf of the source node to support 926 the extensions presented in this document. 928 If a received Binding Acknowledgement contains a copy of each flow 929 identification mobility option that was sent within the binding 930 update, the status field of each flow identification option indicates 931 the status of the flow binding on the distant node. 933 5.2.7. Return Routability Procedure 935 A mobile node may perform route optimization with correspondent nodes 936 as defined in [RFC3775]. Route optimization allows a mobile node to 937 bind a care-of address to a home address in order to allow the 938 correspondent node to direct the traffic to the current location of 939 the mobile node. Before sending a Binding Update to correspondent 940 node, the Return Routability Procedure needs to be performed between 941 the mobile node and the correspondent node.This procedure is not 942 affected by the extensions defined in this document. 944 5.3. HA, MAP, and CN Considerations 946 This specification allows the mobility agents (Home Agents and 947 Mobility Anchor Points), and correspondent nodes to maintain several 948 flow bindings for a given home address and to direct packets to 949 different care-of addresses according to flow bindings. This section 950 details the home agent operations necessary to implement this 951 specification. These operations are identical for MAPs and CNs 952 unless otherwise stated. 954 Note that route optimization is only defined for mobile nodes (MIPv6 955 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 956 sections only apply to correspondent nodes with respect to mobile 957 nodes and not for mobile routers. 959 5.3.1. Handling Binding Identifier Mobility Options 961 This specification (see Section 4.1) updates the definition of the 962 binding identifier mobility option, originally defined in [RFC5648]. 963 According to this specification the BID option includes a BID-PRI 964 field assigning each registered care-of address a priority, and thus 965 placing them in an ordered list (see Section 4.3). 967 Home agents receiving BUs including BID options and flow 968 identification options MUST logically process BID options first. 969 This is because BID Reference sub-options included in the flow 970 identification mobility options might refer to BIDs defined in BID 971 options included in the same message. 973 The BID option is processed as defined in [RFC5648] but then the BID 974 to care-of address mapping is placed in an ordered list according to 975 the BID-PRI field of the BID option. 977 Binding Identifier registrations and deregistrations indirectly 978 affect the MN's flow binding entries. The home agent MUST update the 979 flow binding entries table accordingly as BIDs are added or removed ( 980 [RFC5648]). For example, as discussed in Section 4.3, if all of the 981 BIDs associated with a given flow binding entry are removed (i.e., 982 become invalid) the entry MUST be marked as inactive. While if any 983 of the invalid BIDs associated with an inactive flow binding entry 984 are registered (i.e., become valid), the entry MUST be marked as 985 active. 987 5.3.2. Handling Flow Identification Mobility Options 989 When the home agent receives a binding update which includes at least 990 one flow identification mobility option, it first performs the 991 operation described in section 10.3.1 of RFC3775, followed by the 992 operations defined in Section 5.3.1 of this document. 994 Home agents that do not support this specification will ignore the 995 flow identification mobility options and all their sub-options, 996 having no effect on the operation of the rest of the protocol. 998 If the binding update is accepted, and the home agent is willing to 999 support flow bindings for this MN, the home agent checks the flow 1000 identification mobility options. 1002 If more than one flow identification mobility option in the same BU, 1003 has the same value in the FID field, all the flow identification 1004 mobility options MUST be rejected. 1006 If all FID fields have different values the flow identification 1007 mobility options can be processed further and in any order, as 1008 defined by the following subsections. 1010 5.3.2.1. Handling new FIDs 1012 If the FID field of the flow identification mobility option is not 1013 already present in the list of flow binding entries for this mobile 1014 node, then this is a request for a new entry. 1016 If the flow identification mobility option does not include a traffic 1017 selector sub-option, the home agent MUST reject this request by 1018 copying the flow identification mobility option in the BA, and 1019 setting the Status field to the value defined in Figure 2 for "Flow 1020 identification option malformed". 1022 If the flow identification option does include a traffic selector 1023 sub-option, but the format indicated in the TS Format field is not 1024 supported, the home agent MUST reject this request by copying the 1025 flow identification mobility option in the BA, and setting the Status 1026 field to the value defined in Figure 2 for "Traffic Selector format 1027 not supported". 1029 Then the home agent MUST check the Action field in combination with 1030 the Binding Reference sub-option if present. 1032 - if the Action indicates 'Discard', 1034 Any binding reference sub-options that might be present SHOULD be 1035 ignored. 1037 The home agent SHOULD add a new entry in the mobile node's list of 1038 flow binding entries, as defined below. 1040 - if the Action indicates 'Forward", 1042 If the Binding reference sub-option is not included, the home 1043 agent MUST reject this request by copying the flow identification 1044 mobility option in the BA, and setting the Status field to the 1045 value defined for "Flow identification mobility option malformed" 1046 in Section 4.2. 1048 If the binding reference sub-option is present and includes one or 1049 more BIDs that are not present in the binding cache of the mobile 1050 node the home agent MUST reject this request by copying the flow 1051 identification option in the BA, and setting the Status field to 1052 the value defined for "BID not found" in Section 4.2. 1054 If the binding reference sub-option is present and includes one or 1055 more BIDs, and the BIDs exist in the mobile node's binding cache, 1056 the home agent SHOULD add a new entry in the mobile node's list of 1057 flow binding entries, as defined below. 1059 When the home agent decides to add an entry in the mobile node's list 1060 of flow binding entries, as discussed above, it MUST do it according 1061 to the following rules: The entry MUST be placed according to the 1062 order indicated by the FID-PRI field of the flow identification 1063 mobility option and it MUST include: 1065 the FID as a key to the entry 1067 The traffic selector included in the corresponding sub-option 1069 the action indicated in the Action field 1071 the BIDs, depending on action field, indicated in the binding 1072 reference sub-option 1074 the entry MUST be marked as Active, as shown in Section 4.3 1076 5.3.2.2. Handling known FIDs 1078 If the FID field of the flow identification mobility option is 1079 already present in the list of flow binding entries for this mobile 1080 node, then this is a request to update the existing entry. 1082 The flow binding modification is essentially a process where 1083 parameters associated with an existing flow binding entry are 1084 replaced by the parameters included in a flow identification mobility 1085 option with the same FID as the existing entry. 1087 The home agent MUST: 1089 Change the priority of the entry according to the FID-PRI field of 1090 the flow identification mobility option. 1092 Change the action associated with the entry according to the 1093 Action field of the flow identification mobility option. 1095 Since this flow identification mobility option is designed to update 1096 an existing entry it may or may not include a traffic selector sub- 1097 option. 1099 If a traffic selector sub-option is not included in the flow 1100 identification mobility option, then the traffic selector already 1101 associated with entry MUST be maintained, 1103 otherwise the traffic selector in the entry MUST be replaced by 1104 the traffic selector in the sub-option. 1106 Like Section 5.3.2.1, if the Action field in the flow identification 1107 mobility option is set to 'Discard' if a binding reference sub-option 1108 is included in the option, it SHOULD be ignored; and any BIDs 1109 associated with the existing flow binding entry SHOULD be removed. 1111 Unlike Section 5.3.2.1, however, if the Action field in the flow 1112 identification mobility option is set to 'Forward', and since this 1113 flow identification mobility option is designed to update an existing 1114 entry, it may or may not include a binding reference sub-option. 1116 If a binding reference sub-option is not included in the flow 1117 identification mobility option, then the BIDs already associated 1118 with entry MUST be maintained, 1120 otherwise the BIDs in the entry MUST be replaced by the BIDs in 1121 the sub-option. 1123 5.3.3. Handling Flow Summary Mobility Option 1125 When the home agent receives a binding update which includes a flow 1126 summary mobility option, it first performs the operation described in 1127 section 10.3.1 of RFC3775. Binding update messages including more 1128 than one flow summary mobility option MUST be rejected. 1130 An [RFC3775] de-registration binding update (with a zero lifetime) 1131 would result in deleting all bindings, including all flow bindings 1132 regardless of the presence of the flow summary mobility option. A 1133 binding update (with a zero lifetime) would result in deleting all 1134 bindings, including all flow bindings regardless of the presence of 1135 the flow summary mobility option. A specific binding de- 1136 registration, however, as defined in [RFC5648] (with lifetime of zero 1137 and one or mobe Binding Identifier mobility options identifying 1138 specific BIDs)does not remove all the bindings for the MN and thus it 1139 SHOULD include a Flow Summary Mobility Option to maintain the flow 1140 bindings that need to be preserved. 1142 If the value of any of the FID fields included in the flow summary 1143 mobility option is not present in the list of flow binding entries 1144 for this mobile node, the home agent MUST reject this flow binding 1145 refresh by including a flow identification mobility option in the BA 1146 for each FID that is not found, and by setting the FID field to the 1147 value of the FID that is not found and the Status field to the value 1148 defined for "FID not found" in Section 4.2. 1150 If the value of the FID field is present in the mobile nodes list of 1151 flow binding entries the, home agent SHOULD refresh the flow binding 1152 entry identified by the FID without changing any of the other 1153 parameters associated with it. 1155 5.3.4. Flow Binding Removals 1157 Removal of flow bindings is performed implicitly by omission of a 1158 given FID from a binding update. 1160 When a valid binding update is received, any registered FIDs that are 1161 not explicitly referred to in a flow identification mobility option 1162 or in a flow summary mobility option, in the same binding update, 1163 MUST be removed from the list of flow binding entries for the mobile 1164 node. 1166 5.3.5. Sending Binding Acknowledgements 1168 Upon the reception of a binding update, the home agent is required to 1169 send back a Binding Acknowledgment. The status code in the Binding 1170 Acknowledgement must be set as recommended in [RFC3775]. This status 1171 code does not give information on the success or failure of flow 1172 bindings. 1174 In order to inform the mobile node about the status of the flow 1175 binding(s) requested by a mobile node, flow identification options 1176 SHOULD be included in the Binding Acknowledgement message. 1177 Specifically, the home agent SHOULD copy each flow identification 1178 mobility option received in the binding update and set its status 1179 code to an appropriate value. Note that the home agent does not need 1180 to respond specifically regarding FIDs included in a flow summary 1181 mobility option but only to those in flow identification mobility 1182 options. If an operation requested in a flow identification option 1183 by a mobile node is performed successfully by the home agent, the 1184 status field on the copied flow identification mobility option in the 1185 BA, SHOULD be set to the value defined for "Flow binding successful" 1186 in Section 4.2, otherwise it SHOULD be set to one of the rejection 1187 codes also defined in Section 4.2. Section 5.3.2 identifies a number 1188 of cases where specific error codes should be used. 1190 Home agents that support this specification MAY refuse to maintain 1191 flow bindings by setting the status field of any flow identification 1192 mobility options to the value defined for "Administratively 1193 prohibited" in Section 4.2, or by just ignoring all the flow binding 1194 options. 1196 Note that BID options and their Status field are handled as defined 1197 in [RFC5648]. 1199 5.3.6. Packet Processing 1201 This section defines packet processing rules according to this 1202 specification. This specification does not change any of the packet 1203 interception rules defined in [RFC3775], and [RFC5555]. These rules 1204 apply to HAs, MAPs, and CNs, as part of the routing process for any 1205 packet with destination address set to a valid home address of the 1206 mobile node. For nodes other than CNs this also applies to packets 1207 with destination address set to an address under any of the 1208 registered prefixes. These rules apply equally to IPv6 packets as 1209 well as to IPv4 packets as per [RFC5555]. 1211 Before a packet is forwarded to the mobile node it MUST be matched 1212 against the ordered list of flow bindings stored in the list of flow 1213 binding entries for this mobile node (see Section 4.3). A match is 1214 attempted with the traffic selector included in the first line 1215 (highest order) of the table. If the packet matches the traffic 1216 selector, the action defined by the action parameter of the table 1217 SHOULD be performed. 1219 - if the Action indicates 'Discard', the packet is silently 1220 discarded 1222 - if the Action indicates 'Forward", a copy of the packet is 1223 forwarded to each of the care-of addresses associated with the 1224 BIDs indicated in the same line of the table. 1226 If the action indicated in one of the entries in the list of flow 1227 bindings is 'Discard' then, no BIDs need to be indicated in the same 1228 entry since the packet is not forwarded. If, however, the action 1229 indicated in an entry of the list of flow bindings is 'Forward", the 1230 entry should indicate one or more valid BIDs. For 'Forward' if any 1231 of the BIDs indicated does not correspond to a valid care-of address, 1232 e.g., the BID was deregistered then that BID has no effect on the 1233 traffic. In other words, packets matching the flow binding are 1234 forwarded to the remaining BIDs, pointing to registered care-of 1235 addresses. If none of the BIDs pointed to in a flow binding entry is 1236 valid then the entry is considered to be inactive (as defined in 1237 Section 4.3) and is skipped. In other words packets should not be 1238 matched against that entry. 1240 If a packet does not match any of the active flow binding entries for 1241 the given MN, the packet SHOULD be forwarded to the care-of address 1242 associated with the BID with the highest BID-PRI. 1244 If a packet is fragmented, only the first fragment contains all IP 1245 and transport layer headers, while subsequent fragments only contain 1246 an IP header without transport layer headers. For this reason it is 1247 possible that subsequent fragments do not match the same traffic 1248 selector as the initial fragment of such a packet. Unless specific 1249 measures are taken the likely outcome is that the initial fragment is 1250 routed as the MN intended while subsequent fragments are routed 1251 differently, and probably based on the default flow binding. HAs, 1252 MAPs, and CNs SHOULD take care to forward all fragments of a given 1253 packet the same way, and in accordance to the flow binding matching 1254 the first fragment of said packet. This should be possible given the 1255 fact that fragment headers include enough information to identify a 1256 fragment as part of a specific packet, but the details of how this is 1257 ensured are implementation specific and are not defined in this 1258 specification. 1260 6. MTU Considerations 1262 The options and sub-options defined in this specification add to 1263 those defined in [RFC3775] and other related specifications, all of 1264 which potentially adds to the size of binding update messages. 1265 Implementations SHOULD take care to minimize fragmentation by forming 1266 binding updates that are shorter than what the path MTU allows 1267 whenever possible. 1269 This specification offers a number of mechanisms for reducing the 1270 size of binding updates. The operations defined in this 1271 specification that require the most verbose options are those 1272 registering new BIDs Section 4.1 and identifying new flows 1273 Section 4.2.1.4. Implementations are encouradged to keep binding 1274 updates to sizes below than that of the path's MTU by making full use 1275 of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub- 1276 options, which allows them to refer to already registered care-off 1277 addresses and flows, while registering new ones in subsequent binding 1278 update messages. 1280 7. Security considerations 1282 This draft introduces a new option that adds more granularity to the 1283 binding update and acknowledgement messages defined in [RFC3775], , 1284 and [RFC5555] [RFC3963], and as such inherits the security 1285 considerations discussed in these documents. The new option allows 1286 the mobile node to associate some flows to one interface and other 1287 flows to another interface. Since the flow identification mobility 1288 option is part of the mobility header, it uses the same security as 1289 the Binding Update, whether it is sent to a mobility agent, or to a 1290 correspondent node. 1292 This specification does not open up new fundamental lines of attack 1293 on communications between the MN and its correspondent nodes. 1294 However, it allows attacks of a finer granularity than those on the 1295 binding update. For instance, the attacker can divert or replicate 1296 flows of special interest to the attacker to an address of the 1297 attacker's choosing, if the attacker is able to impersonate the MN or 1298 modify a binding update sent by the MN. Hence it becomes doubly 1299 critical that authentication and integrity services are applied to 1300 binding updates. 1302 8. IANA Considerations 1304 This specification requires the following IANA assignments on 1305 existing namespaces as well as the creation of some new namespaces. 1307 1) New Mobility Options [RFC3775]: This registry is available from 1308 http://www.iana.org under "Mobile IPv6 parameters". The following 1309 type numbers need to be assigned for: 1311 Flow Identification Mobility Option, define in Section 4.2 1313 Flow Summary Mobility Option, defined in Section 4.2.2 1315 2) New "Flow Identification Mobility Option Action codes" 1316 namespace needs to be created. The following 'Action' codes are 1317 defined in this specification, in Section 4.2: 1319 0 Reserved 1321 1 Discard 1323 2 Forward 1325 3-254 unassigned and available for allocation based on 1326 Standards Action or IESG Approval as per [RFC5226] 1328 255 reserved for experimental use. A single value should be 1329 sufficient for experimenting with a different flow 1330 identifiction format. 1332 3) New "Flow Identification Mobility Option Status codes" 1333 namespace needs to be created. The following 'Status' codes are 1334 defined in this specification, in Section 4.2: 1336 0 Flow binding successful 1338 1-127 unassigned and available for success codes to be 1339 allocated via STD action 1341 128 Administratively prohibited 1343 129 Flow binding rejected, reason unspecified 1345 130 Flow identification mobility option malformed 1347 131 BID not found 1348 132 FID not found 1350 133 Traffic selector format not supported 1352 134 Discard function not supported 1354 135 Forward function not supported 1356 126-250 unassigned and available for reject codes to be 1357 allocated via Standards Action or IESG Approval as per 1358 [RFC5226] 1360 251-255 reserved for experimental use. This small number of 1361 status codes should be sufficient for experiments with 1362 currently unforeseen error conditions. 1364 4) New "Flow Identification Sub-Options" namespace for the Flow 1365 Identification Mobility Option. The sub-option space is defined 1366 in Figure 3. The following Sub-option Type values are defined in 1367 this specification: 1369 0 Pad 1371 1 PadN 1373 2 BID Reference 1375 3 Traffic Selector 1377 4-250 unassigned and available for allocation based on 1378 Standards Action or IESG Approval as per [RFC5226] 1380 251-255 reserved for experimental use. This small number of 1381 sub-option types should be sufficient for experiments with 1382 additional parameters associated with a flow. 1384 5) New "Traffic Selector Format" namespace for the Traffic 1385 Selector sub-option. The traffic selector format space is defined 1386 by the TS Format field in Figure 5. The following values are 1387 defined in this specification: 1389 0 Reserved 1391 1-250 unassigned and available for allocation based on 1392 Standards Action or IESG Approval as per [RFC5226] 1394 251-255 reserved for experimental use. This small number of 1395 traffic selector format types should be sufficient for 1396 experiments with different ways of representing a traffic 1397 selector. 1399 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1400 spaces, future allocations from the new number spaces requires 1401 Standards Action or IESG Approval as per [RFC5226] 1403 9. Contributors 1405 We would like to explicitly acknowledge the following person who co- 1406 authored one of the documents used as source material for this 1407 document. 1409 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1411 10. Acknowledgements 1413 We would also like to acknowledge the following people in 1414 alphabetical order for their contributions to this specification: C. 1415 Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- 1416 Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. 1417 Also, Gabor Fekete for the analysis that led to the inclusion of the 1418 BIDRef sub-option, and Henrik Levkowetz for suggesting support for 1419 other ways of describing flows. 1421 11. References 1423 11.1. Normative References 1425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1426 Requirement Levels", BCP 14, RFC 2119, March 1997. 1428 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1429 in IPv6", RFC 3775, June 2004. 1431 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1432 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1433 RFC 3963, January 2005. 1435 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1436 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1437 May 2008. 1439 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1440 Routers", RFC 5555, June 2009. 1442 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1443 and K. Nagami, "Multiple Care-of Addresses Registration", 1444 RFC 5648, October 2009. 1446 11.2. Informative References 1448 [I-D.ietf-mext-binary-ts] 1449 Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, 1450 "Traffic Selectors for Flow Bindings", 1451 draft-ietf-mext-binary-ts-04 (work in progress), 1452 February 2010. 1454 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1455 McManus, "Requirements for Traffic Engineering Over MPLS", 1456 RFC 2702, September 1999. 1458 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1459 RFC 3753, June 2004. 1461 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1462 Terminology", RFC 4885, July 2007. 1464 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1465 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1466 Management", RFC 5380, October 2008. 1468 Authors' Addresses 1470 George Tsirtsis 1471 Qualcomm 1473 Email: tsirtsis@qualcomm.com 1475 Hesham Soliman 1476 Elevate Technologies 1478 Email: hesham@elevatemobile.com 1480 Nicolas Montavont 1481 Institut Telecom / Telecom Bretagne 1482 2, rue de la chataigneraie 1483 Cesson Sevigne 35576 1484 France 1486 Phone: (+33) 2 99 12 70 23 1487 Email: nicolas.montavont@telecom-bretagne.eu 1488 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1490 Gerardo Giaretta 1491 Qualcomm 1493 Email: gerardog@qualcomm.com 1495 Koojana Kuladinithi 1496 University of Bremen 1497 ComNets-ikom,University of Bremen. 1498 Otto-Hahn-Allee NW 1 1499 Bremen, Bremen 28359 1500 Germany 1502 Phone: +49-421-218-8264 1503 Fax: +49-421-218-3601 1504 Email: koo@comnets.uni-bremen.de 1505 URI: http://www.comnets.uni-bremen.de/~koo/