idnits 2.17.1 draft-ietf-mext-flow-binding-09.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 17, 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 -- 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: February 18, 2011 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 August 17, 2010 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-09.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 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . 41 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 on 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-replay 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 270 executed in those cases. A lower number in this field 271 indicates a higher priority. Value '0' is reserved and MUST 272 NOT be used. FID-PRI MUST be unique to each of the flows 273 pertaining to a given MN. In other words, two FIDs MUST NOT be 274 associated with the same FID-PRI value 276 Action 278 This 8-bit unsigned integer field specifies the action that 279 needs to be taken by the receiver of the binding update 280 containing the flow identification option. The details of 281 these requests are discussed below. The following values are 282 reserved for the Action field in this option: 284 0 Reserved and MUST NOT be used 286 1 'Discard'. This value indicates a request to discard all 287 packets in the flow described by the option. No BIDs are 288 associated with this Action. Care should be taken when 289 using this Action as it will lead to disrupting applications 290 communication. Implementations may consider notifying 291 impacted applications in mobile nodes. 293 2 'Forward'. This value indicates a request to send the 294 flow to one or more addresses indicated in the binding 295 reference sub-option (see Section 4.2.1.3). One or more 296 BIDs MUST be associated with this Action. If only one BID 297 is associated with this action then it is essentially a 298 request to forward packets to that CoA, otherwise matching 299 packets are replicated and forwarded to all of the indicated 300 CoAs. Care should be taken when multiple BIDs are used in 301 combination with the 'Forward' action as some transport 302 layers may not be able to handle packet duplication and this 303 can affect their performance. 305 3-255 Reserved for future use 307 Rsvd 309 This field is unused. It MUST be set to zero by the sender and 310 ignored by the receiver. 312 Status 314 This 8-bit unsigned integer field indicates the success or 315 failure of the flow binding operation for the particular flow 316 in the option. This field is not relevant to the binding 317 update message as a whole or to other flow identification 318 options. This field is only relevant when included in the 319 Binding Acknowledgement message and must be ignored in the 320 binding update message. The following values are reserved for 321 the status field within the flow identification mobility 322 option: 324 0 Flow binding successful 326 128 Administratively prohibited 327 129 Flow binding rejected, reason unspecified 329 130 Flow identification mobility option malformed 331 131 BID not found 333 132 FID not found 335 133 Traffic selector format not supported 337 134 Discard function not supported 339 135 Forward function not supported 341 Sub-options (optional) 343 zero or more sub-options, defined in Section 4.2.1 345 4.2.1. Flow Identification Sub-Options definition 347 Flow identification sub-options are encoded within the remaining 348 space of the flow identification mobility option, using a sub-option 349 type-length-value (TLV) format as follows: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Sub-Opt Type |Sub-Opt Length | Sub-Option Data... 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 3: Flow Identification Sub-Option format 359 Sub-opt Type 361 8-bit unsigned integer indicating the sub-option Type. When 362 processing a flow identification mobility option containing an 363 option for which the sub-option Type value is not recognized by 364 the receiver, the receiver MUST silently ignore and skip over 365 the sub-option, correctly handling any remaining sub-options in 366 the same option. 368 Sub-opt Len 370 8-bit unsigned integer, representing the length in octets of 371 the flow identification sub-option. This field indicates the 372 length of the sub-option not including the Sub-opt Type and 373 Sub-opt Length fields. Note that Sub-opt Type '0' 374 (Section 4.2.1.1) is a special case that does not take a Sub- 375 opt Length field. 377 Sub-Option Data 379 A variable length field that contains data specific to the sub- 380 option 382 The following subsections specify the sub-option types which are 383 currently defined for use in the flow identification option. 384 Implementations MUST silently ignore any sub-options that they do not 385 understand. 387 These sub-options may have alignment requirements. Following the 388 convention in [RFC3775], regarding mobility options, these sub- 389 options are aligned in a packet so that multi-octet values within the 390 sub-option Data field of each sub-option fall on natural boundaries 391 (i.e., fields of width n octets are placed at an integer multiple of 392 n octets from the start of the header, for n = 1, 2, 4, or 8) . 394 4.2.1.1. Pad1 396 The Pad1 sub-option does not have any alignment requirements. Its 397 format is as follows: 399 0 400 0 1 2 3 4 5 6 7 401 +-+-+-+-+-+-+-+-+ 402 | Sub-Opt Type | 403 +-+-+-+-+-+-+-+-+ 405 Sub-opt Type 407 0 409 NOTE! the format of the Pad1 sub-option is a special case - it has 410 neither sub-option Length nor sub-option Data fields. 412 The Pad1 sub-option is used to insert one octet of padding in the 413 flow identification option. If more than one octet of padding is 414 required, the PadN sub-option, described next, should be used rather 415 than multiple Pad1 sub-options. 417 4.2.1.2. PadN 419 The PadN sub-option does not have any alignment requirements. Its 420 format is as follows: 422 0 1 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 425 | Sub-Opt Type | Sub-Opt Len | Option Data 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 428 Sub-opt Type 430 1 432 Sub-opt Len 434 set to the length of the sub-option 436 Sub-opt Data 438 0 or more bytes set to 0 by the sender and ignored by the 439 receiver. 441 The PadN sub-option is used to insert two or more octets of padding 442 in the flow identification mobility option. For N octets of padding, 443 the sub-option Length field contains the value N, and the sub-option 444 data consists of N-2 zero-valued octets. PadN sub-option data MUST 445 be ignored by the receiver. 447 4.2.1.3. Binding Reference Sub-option 449 This section introduces the binding reference sub-option, which may 450 be included in the flow identification mobility option. A node MUST 451 NOT include more than one binding reference sub-options in a given 452 flow binding identification option. The binding reference sub-option 453 includes one or more BIDs defined in MCoA [RFC5648]. When this sub- 454 option is included in the flow identification mobility option it 455 associates the flow described with one or more registered BIDs. 457 When binding a flow using this sub-option, the binding identifier 458 mobility option, defined in [RFC5648], MUST be included in either the 459 same or an earlier Binding Update (BU). The binding reference sub- 460 option is shown below. The alignment requirement for this sub-option 461 is 2n. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |Sub-opt Type | Sub-Opt Len | BID | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | BID ........ 469 +-+-+-+-+-+-+-+-+-+- 471 Figure 4: The Binding Reference sub-option 473 Sub-opt Type 475 2 477 Sub-opt Len 479 Variable 481 BID 483 A 16-bit unsigned integer indicating the BID that the mobile 484 node wants to associate with the flow identification option. 485 One or more BID fields can be included in this sub-option. 486 Since each BID is 2 bytes long, the value of the Sub-opt Len 487 field indicates the number of BIDs present. Number of BIDs = 488 Sub-opt Len/2. 490 4.2.1.4. Traffic Selector sub-option 492 The traffic selector sub-option includes the parameters used to match 493 packets for a specific flow binding. A node MUST NOT include more 494 than one traffic selector sub-option in a given flow binding 495 identification option. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Traffic Selector ... 503 +-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 5: The Traffic Selector sub-option 507 Sub-opt Type 509 3 511 Sub-opt Len 513 variable 515 TS Format 517 An 8-bit unsigned integer indicating the Traffic Selector Format. 518 Value "0" is reserved and MUST NOT be used. 520 Reserved 522 An 8-bit reserved field. It MUST be set to zero by the sender and 523 ignored by the receiver. 525 Traffic Selector 527 A variable length field, the format and content of which is out of 528 scope for this specification. The traffic selector defined in 529 [I-D.ietf-mext-binary-ts] is mandatory to implement. 531 4.2.2. Flow Summary Mobility Option 533 The flow summary mobility option is a new mobility option [RFC3775], 534 which includes one or more flow identifiers (FIDs) for the purpose of 535 refreshing their state. A node MUST NOT include more than one flow 536 summary mobility option in a given binding update message. The 537 alignment requirement for this option is 2n. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Option Type | Option Len | FID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | FID ........ 545 +-+-+-+-+-+-+-+-+-+- 547 Figure 6: The Flow Summary Mobility Option 549 Option Type 551 To be assigned by IANA 553 Option Length 555 Length of the option in octets as per [RFC3775] 557 FID 559 A 16-bit unsigned integer indicating a registered FID. One or 560 more FID fields can be included in this option. Number of FIDs 561 = Option Len/2 563 4.3. Flow Bindings entries list and its relationship to Binding Cache 565 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 566 identify the mobile IP state maintained by the mobile node, mobility 567 agent, and correspondent node. The binding cache includes, between 568 others, the mobile node's home address, the registered care-of 569 address, and the lifetime of the binding. The binding cache has been 570 extended by [RFC5648] to include more than one care-of addresses and 571 to associate each of them with a Binding Identifier (BID). 573 This specification does not modify the mobile IPv6 binding cache any 574 further. 576 Flow bindings can be thought of as a conceptual list of entries that 577 is separate from the binding cache. The flow bindings list contains 578 an entry for each of the registered flow bindings. Flow binding 579 entries can point to an entry in the binding cache by means of the 580 BID. Each flow binding entry includes the following parameters: 582 o FID (Flow Identifier): For a given mobile node, identified by its 583 primary home address, the FID MUST uniquely identify an entry, 584 i.e. a unique flow binding. Each mobile node can only have a 585 single entry identified by a given FID at any one time. A given 586 FID number space is used for all the addresses associated to a 587 given MN by the HA (e.g., via [RFC3963]). Different mobile nodes 588 use the same FID number space. 590 o A Traffic Selector: Included in a traffic selector sub-option. 592 o BID(s): The list of BIDs associated with the entry as defined by 593 the binding reference sub-option included in the FID option that 594 created it. 596 o Action: The action associated with a given entry as defined by the 597 Action field of the FID option that created it 599 o Active/Inactive flag: This flag indicates whether the entry is 600 active or inactive. 602 o FID-PRI: This field indicates the priority of the flow and is used 603 to break the tie between overlapping flows. 605 The flow bindings list is associated with a given mobile node, and 606 the correspondent binding cache. An entry in the flow bindings list, 607 however, is identified by the FID and the list is ordered according 608 to the FID-PRI field as defined in the FID option that created each 609 entry. 611 For entries that take BIDs (i.e., entries that do not indicate a 612 'Discard' action), a valid BID is required to make the entry 613 'Active'. If all of the BIDs pointed to by a given entry are 614 deregistered [RFC5648], the flow binding entry becomes 'Inactive', in 615 other words it does not affect data traffic. Note that if the action 616 parameter in an entry indicates 'Forward' then the entry becomes 617 'Inactive' only if all of the BIDs are deregistered. If only some of 618 the BIDs are still valid, the invalid BIDs are simply ignored. 620 Also note that the state described in this section is maintained by 621 the mobile node as well as in mobility agents and correspondent 622 nodes. As such the mobile node is fully aware of which are the valid 623 BIDs at any time and which flow binding entries are active/inactive. 624 Section 5 defines how these flow binding entries are manipulated by 625 the mobile node in detail. 627 As an example the following represents an ordered flow binding entry 628 table for a mobile node that has registered multiple care-of 629 addresses and flow bindings. 631 FID-PRI FID Traffic Selector BIDs Action A/I 632 ------- --- ---------------- ---- ------- ------ 633 10 4 TCP 2 Forward Active 634 20 3 srcAddr=IPx N/A Discard Active 635 30 2 srcAddr=IPy 4 Forward Inactive 636 40 5 UDP 1,3 Forward Active 638 Ordered Flow Binding Entries 640 According to the above list of flow binding entries, all TCP traffic 641 will match the first entry, and according to the Action indicated it 642 will be forwarded to BID2, corresponding to a given care-of address 643 (IP3), as shown below. Any traffic that is not TCP, but has as 644 source address IPx will match the second entry, and according to the 645 associated Action it will be discarded. Note that any TCP traffic 646 with source address IPx will match the first entry and thus it will 647 be forwarded as per that entry. 649 The third entry is marked as Inactive since the BID 4 does not exist 650 in the ordered list of BID entries below. Inactive entries do not 651 affect traffic, i.e., packets are not matched against them. 653 Any UDP traffic that does not match any of the earlier entries will 654 match the fourth rule and according to the Action indicated, it will 655 be replicated and forwarded to BIDs 1 and 3, corresponding to care-of 656 addresses IP1 and IP2 shown below. 658 Finally any remaining packets that do not match any of the entries 659 above will be simply forwarded to the care-of address indicated by 660 the highest order BID in the table below. In the example, such 661 packets will be forwarded to BID1 corresponding to care-of address 662 IP1. 664 BID-PRI BID CoA 665 --------- --- --- 666 20 1 IP1 667 30 3 IP2 668 30 2 IP3 670 Ordered BID Entries 672 Mobility agent and corresponding node implementations should take 673 care to avoid flow binding rules affecting the fundamental operation 674 of Mobile IPv6 and its extensions. In particular, flow binding rules 675 MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 676 and corresponding nodes communicating with a given mobile node, since 677 that could adversely affect the operation of the protocol. Other, 678 non Mobile IPv6 traffic generated by these entities SHOULD be matched 679 against the mobile node's flow binding rules as normal. 681 5. Protocol operations 683 5.1. General 685 This specification introduces a flow bindings list of entries and an 686 ordered list of flow binding identifiers, allowing mobile nodes to 687 associate flow binding policies with the registered care-of 688 addresses. 690 The flow identification mobility option defines how the mobile node 691 can control a set of flow binding entries maintained in a mobility 692 agent, or correspondent node. The fields of the flow identification 693 mobility option are necessary for ordering flow identification 694 mobility options, indicating the sort of action that should be 695 undertaken to the recipient's flow binding list of entries or for 696 carrying the results of such a petition. 698 This specification allows mobile nodes to direct flows to a 699 particular care-of address. The granularity of what constitutes a 700 flow depends on the traffic selector used. 702 The remainder of this section discusses how mobile nodes can use the 703 options and sub-options defined in this document when sending binding 704 updates to the correspondent node, home agent, or mobility anchor 705 point. In addition, refresh, deletion, and modification of flow 706 binding entries are all discussed below. 708 5.1.1. Preferred Care-of address 710 Any node that supports this specification MUST maintain an ordered 711 list of care-of addresses for each mobile node it maintains a list of 712 flow bindings for. The ordered list of care-of addresses is built 713 based on the BID-PRI field of the binding identifier mobility option 714 (see Section 4.1). 716 The ordered list of BIDs is used to determine how to forward a packet 717 to a given mobile node when the packet does not match any of the flow 718 binding entries defined in Section 4.3. A packet that does not match 719 any of the flow binding entries SHOULD be forwarded to the care-of 720 address identified by the BID with the highest priority i.e., lowest 721 BID-PRI value. 723 5.2. Mobile Node Considerations 725 This specification allows the mobile node to maintain several 726 bindings with its mobility agent, and correspondent nodes and to 727 direct packets to different care-of addresses according to flow 728 bindings. This section details the mobile node operations necessary 729 to implement this specification. 731 The mobility agent and correspondent node list of flow bindings is 732 manipulated by the mobile node, via flow identification and flow 733 summary mobility options included in binding update messages. Each 734 flow binding update can add, modify, refresh, or delete a given 735 binding. More than one flow identification mobility options MAY be 736 included in the same binding update but each of them MUST include a 737 different FID. In other words, two flow identification options in 738 the same message can not be about the same flow binding. 740 All flow binding state MUST be refreshed in every binding update the 741 mobile node sends. Any previously registered flow binding that is 742 not included in a given binding update will be deleted. So, any flow 743 bindings that are not added or modified by a flow identification 744 mobility option, but have previously registered and need to be 745 maintained MUST be included in a flow summary mobility option. Only 746 one flow summary mobility option can be included in a given binding 747 update. 749 5.2.1. Sending BU with BID Options 751 This specification (see Section 4.1) updates the definition of the 752 binding identifier mobility option, originally defined in [RFC5648]. 753 According to this specification the BID option includes a BID-PRI 754 field assigning each registered care-of address a priority, and thus 755 placing them in an ordered list as also described in Section 4.3. 757 To ensure backwards compatibility with [RFC5648] for the purpose of 758 this specification the field BID-PRI MUST NOT be set to zero. 759 Receiver implementation of this specification will take a BID-PRI 760 field of value zero as an indication that this is a BID option of the 761 format defined in [RFC5648]. 763 Mobile nodes supporting this specification MUST use the BID option 764 format defined in Section 4.1. Mobile nodes MUST also register all 765 care-of addresses using the updated BID option format, either in the 766 same BU as any flow identification mobility options using them, or in 767 earlier BUs. 769 5.2.2. Sending BU with Flow Identification Mobility Options 771 5.2.2.1. New Flow Bindings 773 When adding a new flow binding, a mobile node sends the flow 774 identification mobility option in the binding update, with the FID 775 field set to a value that is not already present in the list of flow 776 binding entries maintained by the receiver. The care-of address(es) 777 associated with each flow identification mobility options in the 778 binding update, must be logically registered by this binding update, 779 or must have already been registered by the receiver of the binding 780 update in an earlier binding update, as defined in Section 5.2.1. 782 The flow identification mobility option MUST include a unique flow 783 identifier in the FID field. The FID needs only be unique for the 784 receiver of the binding update and for the same sender, i.e. the same 785 FID can be used across different receivers of the binding update, for 786 the same sender. 788 The FID-PRI field is set to the desired unique priority of the 789 FID, defining the order of the flow binding to be added in the 790 list of flow binding entries as defined in Section 4.3. 792 The Action field is set to one of the defined action codes (see 793 Section 4.2). 795 The Status field is set to zero in all binding update messages. 797 Since this flow identification mobility option is requesting the 798 addition of a new flow binding in the list of flow bindings 799 maintained by the receiver, the mobile node MUST include exactly one 800 Traffic Selector sub-option (see Section 4.2.1.4) describing the flow 801 associated with the new flow binding. The TS Format field of the 802 Traffic Selector sub-option MUST be set to the non-zero value of the 803 format used by the mobile node. 805 The mobile node MAY also include up to one BID Reference sub-option 806 (see Section 4.2.1.3) to associate the flow binding with a given set 807 of BIDs and corresponding CoAs. Depending on the Action field of the 808 flow identification mobility option, the following rules MUST be 809 followed with respect to the binding reference sub-option: 811 - if the Action indicates 'Discard', the binding reference sub- 812 option SHOULD NOT be included. If it is included it will be 813 ignored by the receiver. 815 - if the Action indicates 'Forward', a single binding reference 816 sub-option with one or more BIDs MUST be included. 818 5.2.2.2. Updating Flow Bindings 820 Flow binding modification is essentially a process where parameters 821 associated with an existing flow binding in the list of flow binding 822 entries is replaced by parameters included in the flow identification 823 mobility option, and the same FID is maintained. With this procedure 824 the mobile node can change the action, the priority, the BID, and/or 825 the traffic selector associated with a flow binding. 827 To modify an existing flow binding the mobile node MUST send a 828 binding update with a flow identification option, with the FID field 829 set to one of the FID values already in the list of flow binding 830 entries. 832 The FID-PRI and Action fields MUST be set to the priority value 833 for the flow binding entry. 835 The Status field is set to zero since this option is in a binding 836 update. 838 The mobile node MAY include exactly one traffic selector sub-option 839 (see Section 4.2.1.4) describing the updated flow to be associated 840 with the flow binding. The mobile node MAY, however, omit the 841 traffic selector sub-option if it wants the traffic selector 842 currently associated with the flow binding entry identified by the 843 FID field to be maintained. 845 The mobile node MAY include exactly one binding reference sub-option 846 (see Section 4.2.1.3) to associate the existing flow binding with a 847 new set of CoAs. If the mobile node includes a binding reference 848 sub-option then it should follow the rules described in 849 Section 5.2.2.1. The mobile node MAY omit the binding reference sub- 850 option if it wants the BIDs currently associated with the flow 851 binding entry identified by the FID field to be maintained. 853 Note that it is also possible for the mobile node to effectively 854 modify the effect of a flow binding entry without actually changing 855 the entry itself. This can be done by changing the CoA associated 856 with a given BID, which is a process defined in detail in [RFC5648]. 858 5.2.3. Sending BU with a Flow Summary Option 860 When the mobile node sends a binding update it MUST refresh all flow 861 bindings it wants to maintain even if it does not want to change any 862 of their parameters. 864 To refresh an existing flow binding the mobile node MUST send a 865 binding update with a flow summary option. The flow summary option 866 MUST include one or more FID fields as indicated in Section 4.2.2. 867 Each FID field included MUST be set to one of the FID values already 868 in the list of flow binding entries. 870 Any flow bindings (active or inactive) that are not included in a 871 binding update will be removed from the list of flow binding entries. 873 Note that any inactive flow bindings, i.e., flow bindings without 874 associated BIDs that are marked as Inactive in the list of flow 875 binding entries (see Section 4.3), MUST also be refreshed, or 876 modified, to be maintained. If they are not included in a BU they 877 will be removed. 879 5.2.4. Removing flow bindings 881 Removal of flow binding entries is performed implicitly by omission 882 of a given FID from a binding update. 884 To remove a flow binding the MN simply sends a binding update that 885 includes flow identification and flow summary mobility options for 886 all the FIDs that need to be refreshed, modified, or added, and 887 simply omits any FIDs that need to be removed. 889 Note that a mobile node can also render a flow binding inactive by 890 removing the BIDs associated with it, without removing the flow 891 binding itself. The procedure for removing a BID is defined in 892 detail in [RFC5648]. 894 When all the BIDs associated with a flow binding are removed, the 895 flow binding MUST be marked as inactive in the list of flow binding 896 entries as shown in Section 4.3. In other words the state associated 897 with the flow binding MUST be maintained but it does no longer affect 898 the mobile node's traffic. The MN can return an inactive flow 899 binding to the active state by using the flow binding modification 900 process described in Section 5.2.2.2, to associate it again with one 901 or more valid BIDs. Remember that flow bindings indicating a 902 'Discard' action do not take BIDs and thus cannot be rendered 903 inactive. Instead these entries can only be removed by omitting 904 their FID from a subsequent BU. 906 5.2.5. Returning Home 908 This specification is compatible to the home registration procedures 909 defined in [RFC3775] and [RFC5648]. More specifically, if the mobile 910 node performs an [RFC3775] style deregistration, all of its bindings, 911 including flow bindings are deleted. If the mobile node, however, 912 performs an [RFC5648] style home registration, then the home link is 913 associated with a specific BID and so, as far as this specification 914 is concerned, it is treated as any other link associated with a given 915 BID. 917 5.2.6. Receiving Binding Acknowledgements 919 According to [RFC3775] all nodes are required to silently ignore 920 mobility options not understood while processing binding updates. As 921 such a mobile node receiving a Binding Acknowledgement in response to 922 the transmission of a binding update MUST determine if the Binding 923 Acknowledgement contains a copy of every flow identification mobility 924 options included in the binding update. A Binding Acknowledgement 925 without flow identification option(s), in response to a Binding 926 Update with flow identification mobility option, would indicate 927 inability (or unwillingness) on behalf of the source node to support 928 the extensions presented in this document. 930 If a received Binding Acknowledgement contains a copy of each flow 931 identification mobility option that was sent within the binding 932 update, the status field of each flow identification option indicates 933 the status of the flow binding on the distant node. 935 5.2.7. Return Routability Procedure 937 A mobile node may perform route optimization with correspondent nodes 938 as defined in [RFC3775]. Route optimization allows a mobile node to 939 bind a care-of address to a home address in order to allow the 940 correspondent node to direct the traffic to the current location of 941 the mobile node. Before sending a Binding Update to correspondent 942 node, the Return Routability Procedure needs to be performed between 943 the mobile node and the correspondent node.This procedure is not 944 affected by the extensions defined in this document. 946 5.3. HA, MAP, and CN Considerations 948 This specification allows the mobility agents (Home Agents and 949 Mobility Anchor Points), and correspondent nodes to maintain several 950 flow bindings for a given home address and to direct packets to 951 different care-of addresses according to flow bindings. This section 952 details the home agent operations necessary to implement this 953 specification. These operations are identical for MAPs and CNs 954 unless otherwise stated. 956 Note that route optimization is only defined for mobile nodes (MIPv6 957 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 958 sections only apply to correspondent nodes with respect to mobile 959 nodes and not for mobile routers. 961 5.3.1. Handling Binding Identifier Mobility Options 963 This specification (see Section 4.1) updates the definition of the 964 binding identifier mobility option, originally defined in [RFC5648]. 965 According to this specification the BID option includes a BID-PRI 966 field assigning each registered care-of address a priority, and thus 967 placing them in an ordered list (see Section 4.3). 969 Home agents receiving BUs including BID options and flow 970 identification options MUST logically process BID options first. 971 This is because BID Reference sub-options included in the flow 972 identification mobility options might refer to BIDs defined in BID 973 options included in the same message. 975 The BID option is processed as defined in [RFC5648] but then the BID 976 to care-of address mapping is placed in an ordered list according to 977 the BID-PRI field of the BID option. 979 Binding Identifier registrations and deregistrations indirectly 980 affect the MN's flow binding entries. The home agent MUST update the 981 flow binding entries table accordingly as BIDs are added or removed ( 982 [RFC5648]). For example, as discussed in Section 4.3, if all of the 983 BIDs associated with a given flow binding entry are removed (i.e., 984 become invalid) the entry MUST be marked as inactive. While if any 985 of the invalid BIDs associated with an inactive flow binding entry 986 are registered (i.e., become valid), the entry MUST be marked as 987 active. 989 5.3.2. Handling Flow Identification Mobility Options 991 When the home agent receives a binding update which includes at least 992 one flow identification mobility option, it first performs the 993 operation described in section 10.3.1 of RFC3775, followed by the 994 operations defined in Section 5.3.1 of this document. 996 Home agents that do not support this specification will ignore the 997 flow identification mobility options and all their sub-options, 998 having no effect on the operation of the rest of the protocol. 1000 If the binding update is accepted, and the home agent is willing to 1001 support flow bindings for this MN, the home agent checks the flow 1002 identification mobility options. 1004 If more than one flow identification mobility option in the same BU, 1005 has the same value in the FID field, all the flow identification 1006 mobility options MUST be rejected. 1008 If all FID fields have different values the flow identification 1009 mobility options can be processed further and in any order, as 1010 defined by the following subsections. 1012 5.3.2.1. Handling new FIDs 1014 If the FID field of the flow identification mobility option is not 1015 already present in the list of flow binding entries for this mobile 1016 node, then this is a request for a new entry. 1018 If the flow identification mobility option does not include a traffic 1019 selector sub-option, the home agent MUST reject this request by 1020 copying the flow identification mobility option in the BA, and 1021 setting the Status field to the value defined in Figure 2 for "Flow 1022 identification option malformed". 1024 If the flow identification option does include a traffic selector 1025 sub-option, but the format indicated in the TS Format field is not 1026 supported, the home agent MUST reject this request by copying the 1027 flow identification mobility option in the BA, and setting the Status 1028 field to the value defined in Figure 2 for "Traffic Selector format 1029 not supported". 1031 Then the home agent MUST check the Action field in combination with 1032 the Binding Reference sub-option if present. 1034 - if the Action indicates 'Discard', 1036 Any binding reference sub-options that might be present SHOULD be 1037 ignored. 1039 The home agent SHOULD add a new entry in the mobile node's list of 1040 flow binding entries, as defined below. 1042 - if the Action indicates 'Forward", 1044 If the Binding reference sub-option is not included, the home 1045 agent MUST reject this request by copying the flow identification 1046 mobility option in the BA, and setting the Status field to the 1047 value defined for "Flow identification mobility option malformed" 1048 in Section 4.2. 1050 If the binding reference sub-option is present and includes one or 1051 more BIDs that are not present in the binding cache of the mobile 1052 node the home agent MUST reject this request by copying the flow 1053 identification option in the BA, and setting the Status field to 1054 the value defined for "BID not found" in Section 4.2. 1056 If the binding reference sub-option is present and includes one or 1057 more BIDs, and the BIDs exist in the mobile node's binding cache, 1058 the home agent SHOULD add a new entry in the mobile node's list of 1059 flow binding entries, as defined below. 1061 When the home agent decides to add an entry in the mobile node's list 1062 of flow binding entries, as discussed above, it MUST do it according 1063 to the following rules: The entry MUST be placed according to the 1064 order indicated by the FID-PRI field of the flow identification 1065 mobility option and it MUST include: 1067 the FID as a key to the entry 1069 The traffic selector included in the corresponding sub-option 1071 the action indicated in the Action field 1073 the BIDs, depending on action field, indicated in the binding 1074 reference sub-option 1076 the entry MUST be marked as Active, as shown in Section 4.3 1078 5.3.2.2. Handling known FIDs 1080 If the FID field of the flow identification mobility option is 1081 already present in the list of flow binding entries for this mobile 1082 node, then this is a request to update the existing entry. 1084 The flow binding modification is essentially a process where 1085 parameters associated with an existing flow binding entry are 1086 replaced by the parameters included in a flow identification mobility 1087 option with the same FID as the existing entry. 1089 The home agent MUST: 1091 Change the priority of the entry according to the FID-PRI field of 1092 the flow identification mobility option. 1094 Change the action associated with the entry according to the 1095 Action field of the flow identification mobility option. 1097 Since this flow identification mobility option is designed to update 1098 an existing entry it may or may not include a traffic selector sub- 1099 option. 1101 If a traffic selector sub-option is not included in the flow 1102 identification mobility option, then the traffic selector already 1103 associated with entry MUST be maintained, 1105 otherwise the traffic selector in the entry MUST be replaced by 1106 the traffic selector in the sub-option. 1108 Like Section 5.3.2.1, if the Action field in the flow identification 1109 mobility option is set to 'Discard' if a binding reference sub-option 1110 is included in the option, it SHOULD be ignored; and any BIDs 1111 associated with the existing flow binding entry SHOULD be removed. 1113 Unlike Section 5.3.2.1, however, if the Action field in the flow 1114 identification mobility option is set to 'Forward', and since this 1115 flow identification mobility option is designed to update an existing 1116 entry, it may or may not include a binding reference sub-option. 1118 If a binding reference sub-option is not included in the flow 1119 identification mobility option, then the BIDs already associated 1120 with entry MUST be maintained, 1122 otherwise the BIDs in the entry MUST be replaced by the BIDs in 1123 the sub-option. 1125 5.3.3. Handling Flow Summary Mobility Option 1127 When the home agent receives a binding update which includes a flow 1128 summary mobility option, it first performs the operation described in 1129 section 10.3.1 of RFC3775. Binding update messages including more 1130 than one flow summary mobility option MUST be rejected. 1132 An [RFC3775] de-registration binding update (with a zero lifetime) 1133 would result in deleting all bindings, including all flow bindings 1134 regardless of the presence of the flow summary mobility option. A 1135 binding update (with a zero lifetime) would result in deleting all 1136 bindings, including all flow bindings regardless of the presence of 1137 the flow summary mobility option. A specific binding de- 1138 registration, however, as defined in [RFC5648] (with lifetime of zero 1139 and one or mobe Binding Identifier mobility options identifying 1140 specific BIDs)does not remove all the bindings for the MN and thus it 1141 SHOULD include a Flow Summary Mobility Option to maintain the flow 1142 bindings that need to be preserved. 1144 If the value of any of the FID fields included in the flow summary 1145 mobility option is not present in the list of flow binding entries 1146 for this mobile node, the home agent MUST reject this flow binding 1147 refresh by including a flow identification mobility option in the BA 1148 for each FID that is not found, and by setting the FID field to the 1149 value of the FID that is not found and the Status field to the value 1150 defined for "FID not found" in Section 4.2. 1152 If the value of the FID field is present in the mobile nodes list of 1153 flow binding entries the, home agent SHOULD refresh the flow binding 1154 entry identified by the FID without changing any of the other 1155 parameters associated with it. 1157 5.3.4. Flow Binding Removals 1159 Removal of flow bindings is performed implicitly by omission of a 1160 given FID from a binding update. 1162 When a valid binding update is received, any registered FIDs that are 1163 not explicitly referred to in a flow identification mobility option 1164 or in a flow summary mobility option, in the same binding update, 1165 MUST be removed from the list of flow binding entries for the mobile 1166 node. 1168 5.3.5. Sending Binding Acknowledgements 1170 Upon the reception of a binding update, the home agent is required to 1171 send back a Binding Acknowledgment. The status code in the Binding 1172 Acknowledgement must be set as recommended in [RFC3775]. This status 1173 code does not give information on the success or failure of flow 1174 bindings. 1176 In order to inform the mobile node about the status of the flow 1177 binding(s) requested by a mobile node, flow identification options 1178 SHOULD be included in the Binding Acknowledgement message. 1179 Specifically, the home agent SHOULD copy each flow identification 1180 mobility option received in the binding update and set its status 1181 code to an appropriate value. Note that the home agent does not need 1182 to respond specifically regarding FIDs included in a flow summary 1183 mobility option but only to those in flow identification mobility 1184 options. If an operation requested in a flow identification option 1185 by a mobile node is performed successfully by the home agent, the 1186 status field on the copied flow identification mobility option in the 1187 BA, SHOULD be set to the value defined for "Flow binding successful" 1188 in Section 4.2, otherwise it SHOULD be set to one of the rejection 1189 codes also defined in Section 4.2. Section 5.3.2 identifies a number 1190 of cases where specific error codes should be used. 1192 Home agents that support this specification MAY refuse to maintain 1193 flow bindings by setting the status field of any flow identification 1194 mobility options to the value defined for "Administratively 1195 prohibited" in Section 4.2, or by just ignoring all the flow binding 1196 options. 1198 Note that BID options and their Status field are handled as defined 1199 in [RFC5648]. 1201 5.3.6. Packet Processing 1203 This section defines packet processing rules according to this 1204 specification. This specification does not change any of the packet 1205 interception rules defined in [RFC3775], and [RFC5555]. These rules 1206 apply to HAs, MAPs, and CNs, as part of the routing process for any 1207 packet with destination address set to a valid home address of the 1208 mobile node. For nodes other than CNs this also applies to packets 1209 with destination address set to an address under any of the 1210 registered prefixes. These rules apply equally to IPv6 packets as 1211 well as to IPv4 packets as per [RFC5555]. 1213 Before a packet is forwarded to the mobile node it MUST be matched 1214 against the ordered list of flow bindings stored in the list of flow 1215 binding entries for this mobile node (see Section 4.3). A match is 1216 attempted with the traffic selector included in the first line 1217 (highest order) of the table. If the packet matches the traffic 1218 selector, the action defined by the action parameter of the table 1219 SHOULD be performed. 1221 - if the Action indicates 'Discard', the packet is silently 1222 discarded 1224 - if the Action indicates 'Forward", a copy of the packet is 1225 forwarded to each of the care-of addresses associated with the 1226 BIDs indicated in the same line of the table. 1228 If the action indicated in one of the entries in the list of flow 1229 bindings is 'Discard' then, no BIDs need to be indicated in the same 1230 entry since the packet is not forwarded. If, however, the action 1231 indicated in an entry of the list of flow bindings is 'Forward", the 1232 entry should indicate one or more valid BIDs. For 'Forward' if any 1233 of the BIDs indicated does not correspond to a valid care-of address, 1234 e.g., the BID was deregistered then that BID has no effect on the 1235 traffic. In other words, packets matching the flow binding are 1236 forwarded to the remaining BIDs, pointing to registered care-of 1237 addresses. If none of the BIDs pointed to in a flow binding entry is 1238 valid then the entry is considered to be inactive (as defined in 1239 Section 4.3) and is skipped. In other words packets should not be 1240 matched against that entry. 1242 If a packet does not match any of the active flow binding entries for 1243 the given MN, the packet SHOULD be forwarded to the care-of address 1244 associated with the BID with the highest BID-PRI. 1246 If a packet is fragmented, only the first fragment contains all IP 1247 and transport layer headers, while subsequent fragments only contain 1248 an IP header without transport layer headers. For this reason it is 1249 possible that subsequent fragments do not match the same traffic 1250 selector as the initial fragment of such a packet. Unless specific 1251 measures are taken the likely outcome is that the initial fragment is 1252 routed as the MN intended while subsequent fragments are routed 1253 differently, and probably based on the default flow binding. HAs, 1254 MAPs, and CNs SHOULD take care to forward all fragments of a given 1255 packet the same way, and in accordance to the flow binding matching 1256 the first fragment of said packet. This should be possible given the 1257 fact that fragment headers include enough information to identify a 1258 fragment as part of a specific packet, but the details of how this is 1259 ensured are implementation specific and are not defined in this 1260 specification. 1262 6. MTU Considerations 1264 The options and sub-options defined in this specification add to 1265 those defined in [RFC3775] and other related specifications, all of 1266 which potentially adds to the size of binding update messages. 1267 Implementations SHOULD take care to minimize fragmentation by forming 1268 binding updates that are shorter than what the path MTU allows 1269 whenever possible. 1271 This specification offers a number of mechanisms for reducing the 1272 size of binding updates. The operations defined in this 1273 specification that require the most verbose options are those 1274 registering new BIDs Section 4.1 and identifying new flows 1275 Section 4.2.1.4. Implementations are encouradged to keep binding 1276 updates to sizes below than that of the path's MTU by making full use 1277 of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub- 1278 options, which allows them to refer to already registered care-of 1279 addresses and flows, while registering new ones in subsequent binding 1280 update messages. 1282 7. Security considerations 1284 This draft introduces a new option that adds more granularity to the 1285 binding update and acknowledgement messages defined in [RFC3775], 1286 [RFC5555], and [RFC3963], so it inherits the security considerations 1287 discussed in these documents. The new option allows the mobile node 1288 to associate some flows to one interface and other flows to another 1289 interface. Since the flow identification mobility option is part of 1290 the mobility header, it uses the same security as the Binding Update, 1291 whether it is sent to a mobility agent, or to a correspondent node. 1293 This specification does not open up new fundamental lines of attack 1294 on communications between the MN and its correspondent nodes. 1295 However, it allows attacks of a finer granularity than those on the 1296 binding update. For instance, the attacker can divert or replicate 1297 flows of special interest to the attacker to an address of the 1298 attacker's choosing, if the attacker is able to impersonate the MN or 1299 modify a binding update sent by the MN. Hence it becomes doubly 1300 critical that authentication and integrity services are applied to 1301 binding updates. 1303 Finally, when the optional anti-replay feature of Encapsulating 1304 Security Payload (ESP) [RFC4303] is employed and packets from/to 1305 different CoAs are sent on the same security association (SA), some 1306 packets could be discarded at the receiver due to the windowing 1307 mechanism used by this feature. Therefore, a sender SHOULD put 1308 traffic from/to different CoAs, but with the same HoA in the selector 1309 values, on different SAs to support Multiple Care-of Addresses 1310 appropriately. To permit this, the IPsec implementation SHOULD 1311 establish and maintain multiple SAs between a given sender and 1312 receiver, with the same selectors. Distribution of traffic among 1313 these parallel SAs to support Multiple Care-of Addresses is locally 1314 determined by the sender and is not negotiated by the Internet Key 1315 Exchange (IKEv2) protocol [RFC4306]. The receiver will process the 1316 packets from the different SAs without prejudice. 1318 8. IANA Considerations 1320 This specification requires the following IANA assignments on 1321 existing namespaces as well as the creation of some new namespaces. 1323 1) New Mobility Options [RFC3775]: This registry is available from 1324 http://www.iana.org under "Mobile IPv6 parameters". The following 1325 type numbers need to be assigned for: 1327 Flow Identification Mobility Option, define in Section 4.2 1329 Flow Summary Mobility Option, defined in Section 4.2.2 1331 2) New "Flow Identification Mobility Option Action codes" 1332 namespace needs to be created. The following 'Action' codes are 1333 defined in this specification, in Section 4.2: 1335 0 Reserved 1337 1 Discard 1339 2 Forward 1341 3-254 unassigned and available for allocation based on 1342 Standards Action or IESG Approval as per [RFC5226] 1344 255 reserved for experimental use. A single value should be 1345 sufficient for experimenting with a different flow 1346 identifiction format. 1348 3) New "Flow Identification Mobility Option Status codes" 1349 namespace needs to be created. The following 'Status' codes are 1350 defined in this specification, in Section 4.2: 1352 0 Flow binding successful 1354 1-127 unassigned and available for success codes to be 1355 allocated via STD action 1357 128 Administratively prohibited 1359 129 Flow binding rejected, reason unspecified 1361 130 Flow identification mobility option malformed 1363 131 BID not found 1364 132 FID not found 1366 133 Traffic selector format not supported 1368 134 Discard function not supported 1370 135 Forward function not supported 1372 136-250 unassigned and available for reject codes to be 1373 allocated via Standards Action or IESG Approval as per 1374 [RFC5226] 1376 251-255 reserved for experimental use. This small number of 1377 status codes should be sufficient for experiments with 1378 currently unforeseen error conditions. 1380 4) New "Flow Identification Sub-Options" namespace for the Flow 1381 Identification Mobility Option. The sub-option space is defined 1382 in Figure 3. The following Sub-option Type values are defined in 1383 this specification: 1385 0 Pad 1387 1 PadN 1389 2 BID Reference 1391 3 Traffic Selector 1393 4-250 unassigned and available for allocation based on 1394 Standards Action or IESG Approval as per [RFC5226] 1396 251-255 reserved for experimental use. This small number of 1397 sub-option types should be sufficient for experiments with 1398 additional parameters associated with a flow. 1400 5) New "Traffic Selector Format" namespace for the Traffic 1401 Selector sub-option. The traffic selector format space is defined 1402 by the TS Format field in Figure 5. The following values are 1403 defined in this specification: 1405 0 Reserved 1407 1-250 unassigned and available for allocation based on 1408 Standards Action or IESG Approval as per [RFC5226] 1410 251-255 reserved for experimental use. This small number of 1411 traffic selector format types should be sufficient for 1412 experiments with different ways of representing a traffic 1413 selector. 1415 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1416 spaces, future allocations from the new number spaces requires 1417 Standards Action or IESG Approval as per [RFC5226] 1419 9. Contributors 1421 We would like to explicitly acknowledge the following person who co- 1422 authored one of the documents used as source material for this 1423 document. 1425 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1427 10. Acknowledgements 1429 We would also like to acknowledge the following people in 1430 alphabetical order for their contributions to this specification: C. 1431 Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- 1432 Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. 1433 Also, Gabor Fekete for the analysis that led to the inclusion of the 1434 BIDRef sub-option, and Henrik Levkowetz for suggesting support for 1435 other ways of describing flows. 1437 11. References 1439 11.1. Normative References 1441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", BCP 14, RFC 2119, March 1997. 1444 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1445 in IPv6", RFC 3775, June 2004. 1447 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1448 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1449 RFC 3963, January 2005. 1451 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1452 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1453 May 2008. 1455 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1456 Routers", RFC 5555, June 2009. 1458 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1459 and K. Nagami, "Multiple Care-of Addresses Registration", 1460 RFC 5648, October 2009. 1462 11.2. Informative References 1464 [I-D.ietf-mext-binary-ts] 1465 Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, 1466 "Traffic Selectors for Flow Bindings", 1467 draft-ietf-mext-binary-ts-04 (work in progress), 1468 February 2010. 1470 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1471 McManus, "Requirements for Traffic Engineering Over MPLS", 1472 RFC 2702, September 1999. 1474 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1475 RFC 3753, June 2004. 1477 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1478 RFC 4303, December 2005. 1480 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1481 RFC 4306, December 2005. 1483 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1484 Terminology", RFC 4885, July 2007. 1486 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1487 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1488 Management", RFC 5380, October 2008. 1490 Authors' Addresses 1492 George Tsirtsis 1493 Qualcomm 1495 Email: tsirtsis@qualcomm.com 1497 Hesham Soliman 1498 Elevate Technologies 1500 Email: hesham@elevatemobile.com 1502 Nicolas Montavont 1503 Institut Telecom / Telecom Bretagne 1504 2, rue de la chataigneraie 1505 Cesson Sevigne 35576 1506 France 1508 Phone: (+33) 2 99 12 70 23 1509 Email: nicolas.montavont@telecom-bretagne.eu 1510 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1512 Gerardo Giaretta 1513 Qualcomm 1515 Email: gerardog@qualcomm.com 1517 Koojana Kuladinithi 1518 University of Bremen 1519 ComNets-ikom,University of Bremen. 1520 Otto-Hahn-Allee NW 1 1521 Bremen, Bremen 28359 1522 Germany 1524 Phone: +49-421-218-8264 1525 Fax: +49-421-218-3601 1526 Email: koo@comnets.uni-bremen.de 1527 URI: http://www.comnets.uni-bremen.de/~koo/