idnits 2.17.1 draft-ietf-mext-flow-binding-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2010) is 5164 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track G. Tsirtsis 5 Expires: September 2, 2010 Qualcomm 6 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 March 1, 2010 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-06.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 to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 2, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Definition Update for Binding Identifier Mobility 68 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 70 4.2.1. Flow Identification Sub-Options definition . . . . . . 11 71 4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 15 72 4.3. Flow Bindings entries list and its relationship to 73 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 16 74 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 19 75 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 19 77 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 19 78 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 20 79 5.2.2. Sending BU with Flow Identification Mobility 80 Options . . . . . . . . . . . . . . . . . . . . . . . 20 81 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22 82 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23 83 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23 84 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23 85 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24 86 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24 87 5.3.1. Handling Binding Identifier Mobility Options . . . . . 24 88 5.3.2. Handling Flow Identification Mobility Options . . . . 25 89 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28 90 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28 91 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 28 92 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 93 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 31 94 7. Security considerations . . . . . . . . . . . . . . . . . . . 32 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 96 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 103 1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Introduction 111 Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support 112 [RFC3963] allow a mobile node / mobile router to manage its mobility 113 using the binding update message, which binds one care-of address to 114 one home address and associated mobile networks. The binding update 115 message can be sent to the home agent. In Mobile IPv6, the binding 116 update can also be sent to correspondent node or to a mobility anchor 117 point (see [RFC5380]). The semantics of the binding update are 118 limited to care-of address changes. That is, [RFC3775], [RFC5555], 119 and [RFC3963] do not allow a mobile node / mobile router to bind more 120 than one address to the home address. In [RFC5648] Mobile IPv6 and 121 NEMO Basic Support are extended to allow the binding of more than one 122 care-of address to a home address. This specification further 123 extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to 124 specify policies associated with each binding. A policy can contain 125 a request for special treatment of a particular IPv4 or IPv6 flow, 126 which is viewed as a group of packets matching a traffic selector. 127 Hence, this specification allows a mobile node / mobile router to 128 bind a particular flow to a care-of address without affecting other 129 flows using the same home address. In addition, this specification 130 allows to bind a particular flow to a particular care-of address 131 directly with correspondent node and mobility agents (i.e., home 132 agents [RFC3775] and mobility anchor points [RFC5380]). 134 In this document, a flow is defined as a set of IP packets matching a 135 traffic selector. A traffic selector can identify the source and 136 destination IP addresses, transport protocol number, the source and 137 destination port numbers and other fields in IP and higher layer 138 headers. This specification, however, does not define traffic 139 selectors and it is assumed that one or more ways of defining traffic 140 selectors are going to be defined in other specifications. This 141 specification, however, does define the traffic selector sub-option 142 format to be used for any defined traffic selectors. 144 Using the flow identifier option introduced in this specification a 145 mobile node / mobile router can bind one or more flows to a care-of 146 address while maintaining the reception of other flows on another 147 care-of address. The mobile node / mobile router assembles the flow 148 binding request based local policies, link characteristics and the 149 types of applications running at the time. Such policies are outside 150 the scope of this document. 152 It should be noted that the flow identification mobility option can 153 be associated with any binding update, whether it is sent to a 154 mobility agent or a correspondent node. 156 Note that per-packet load balancing may have negative impacts on TCP 157 congestion avoidance mechanisms as it is desirable to maintain order 158 between packets belonging to the same TCP connection. This behaviour 159 is specified in [RFC2702]. Other negative impacts are also foreseen 160 for other types of real time connections due to the potential 161 variations in round trip time between packets. Moreover, per-packet 162 load-balancing will negatively affect traffic with anti-reply 163 protection mechanisms. Hence, per-packet load balancing is not 164 envisioned in this specification. 166 In the rest of the document, the term "mobile node" is used to 167 designate either a mobile node as defined in [RFC3775] and [RFC5648], 168 or a mobile router as defined in [RFC3963] unless stated otherwise. 170 3. Terminology 172 Terms used in this document are defined in [RFC3753] and [RFC4885]. 173 The following terms are also used in this document: 175 Flow: A flow is a sequence of packets for which the MN desires 176 special handling either by the HA, the CN or the MAP. 178 Traffic Selector: One or more parameters that can be matched 179 against fields in the packet's headers for the purpose of 180 classifying a packet. Examples of such parameters include the 181 source and destination IP addresses, transport protocol number, 182 the source and destination port numbers and other fields in IP and 183 higher layer headers. 185 Flow binding: It consists of a traffic selector, and an action. 186 IP packets from one or more flows that match the traffic selector 187 associated with the flow binding, are processed according to the 188 action associated with the same flow binding. 190 Flow Identifier: A flow identifier uniquely identifies a flow 191 binding associated with a mobile node. It is generated by a 192 mobile node and is cached in the table of flow binding entries 193 maintained by the MN, HA, CN or MAP. 195 4. Mobile IPv6 Extensions 197 This section introduces extensions to Mobile IPv6 that are necessary 198 for supporting the flow binding mechanism described in this document. 200 4.1. Definition Update for Binding Identifier Mobility Option 202 This specification updates the definition of the Binding Identifier 203 Mobility option defined in [RFC5648], as follows: 205 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type = 35 | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Binding ID (BID) | Status |H| BID-PRI | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 212 + + 213 : IPv4 or IPv6 care-of address (CoA) : 214 + + 215 +---------------------------------------------------------------+ 217 Figure 1: The Binding Identifier Mobility option 219 BID-PRI 221 This is a 7-bit unsigned integer placing each BID to a relative 222 priority with other registered BIDs. Value '0' is reserved and 223 SHOULD NOT be used. A lower number in this field indicates a 224 higher priority, while BIDs with the same BID-PRI value have 225 equal priority meaning that, the BID used is an implementation 226 issue. This is consistent with current practice in packet 227 classifiers. 229 4.2. Flow Identification Mobility Option 231 The flow identification mobility option is a new mobility option 232 [RFC3775] and it is included in the binding update and 233 acknowledgement messages. This option contains information that 234 allows the receiver of a binding update to install policies on a 235 traffic flow and route it to a given care-of address. Multiple 236 options may exist within the same binding update message. The 237 alignment requirement for this option is 2n. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Option Type | Option Len | FID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | FID-PRI | Action | Rsvd | Status | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Sub-options (optional) ... 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: The Flow Identification Mobility Option 251 Option Type 253 To be assigned by IANA 255 Option Len 257 Length of the option in octets as per [RFC3775]. 259 FID 261 The Flow Identifier field is a 16-bit unsigned integer that 262 includes the unique identifier for the flow binding. This 263 field is used to refer to an existing flow binding or to create 264 a new flow binding. The value of this field is set by the 265 mobile node. FID = 0 is reserved and SHOULD NOT be used. 267 FID-PRI 269 This is an 8-bit unsigned priority field to indicate the 270 priority of a particular option. This field is needed in cases 271 where two different flow descriptions in two different options 272 overlap. The priority field decides which policy should be in 273 those cases. A lower number in this field indicates a higher 274 priority. Value '0' is reserved and SHOULD NOT be used. FID- 275 PRI MUST be unique to each of the flows pertaining to a given 276 MN. 278 Action 280 This 8-bit unsigned integer field specifies the action that 281 needs to be taken by the receiver of the binding update 282 containing the flow identification option. The details of 283 these requests are discussed below. The following values are 284 reserved for the Action field in this option: 286 0 Reserved and SHOULD NOT be used 288 1 'Discard'. This value indicates a request to discard all 289 packets in the flow described by the option. No BIDs are 290 associated with this Action. Care should be taken when 291 using this Action as it will lead to disrupting applications 292 communication. Implementations may consider notifying 293 impacted applications in mobile nodes. 295 2 'Forward'. This value indicates a request to send the 296 flow to one or more addresses indicated in the binding 297 reference sub-option (see Section 4.2.1.3). One or more 298 BIDs MUST be associated with this Action. If only one BID 299 is associated with this action then it is essentially a 300 request to forward packets to that CoA, otherwise matching 301 packets are replicated and forwarded to all of the indicated 302 CoAs. Care should be taken when multiple BIDs are used in 303 combination with the 'Forward' action as some transport 304 layers may not be able to handle packet duplication and this 305 can affect their performance. 307 3-255 Reserved for future use 309 Rsvd 311 This field is unused. It SHOULD be set to zero by the sender 312 and ignored by the receiver. 314 Status 316 This 8-bit unsigned integer field indicates the success or 317 failure of the flow binding operation for the particular flow 318 in the option. This field is not relevant to the binding 319 update message as a whole or to other flow identification 320 options. This field is only relevant when included in the 321 Binding Acknowledgement message and must be ignored in the 322 binding update message. The following values are reserved for 323 the status field within the flow identification mobility 324 option: 326 0 Flow binding successful 328 128 Administratively prohibited 330 129 Flow binding rejected, reason unspecified 331 130 Flow identification mobility option malformed 333 131 BID not found 335 132 FID not found 337 133 Traffic selector format not supported 339 134 Discard function not supported 341 135 Forward function not supported 343 Sub-options (optional) 345 zero or more sub-options, defined in Section 4.2.1 347 4.2.1. Flow Identification Sub-Options definition 349 Flow identification sub-options are encoded within the remaining 350 space of the flow identification mobility option, using a sub-option 351 type-length-value (TLV) format as follows: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sub-Opt Type |Sub-Opt Length | Sub-Option Data... 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 3: Flow Identification Sub-Option format 361 Sub-opt Type 363 8-bit unsigned integer indicating the sub-option Type. When 364 processing a flow identification mobility option containing an 365 option for which the sub-option Type value is not recognized by 366 the receiver, the receiver MUST quietly ignore and skip over 367 the option, correctly handling any remaining sub-options in the 368 same option. 370 Sub-opt Len 372 8-bit unsigned integer, representing the length in octets of 373 the flow identification sub-option. This field indicates the 374 length of the sub-option not including the Sub-opt Type and 375 Sub-opt Length fields. Note that Sub-opt Type '0' 376 (Section 4.2.1.1) is a special case that does not take a Sub- 377 opt Length field. 379 Sub-Option Data 381 A variable length field that contains data specific to the sub- 382 option 384 The following subsections specify the sub-option types which are 385 currently defined for use in the flow identification option. 386 Implementations MUST silently ignore any sub-options that they do not 387 understand. 389 These sub-options may have alignment requirements. Following the 390 convention in [RFC3775], regarding mobility options, these sub- 391 options are aligned in a packet so that multi-octet values within the 392 sub-option Data field of each sub-option fall on natural boundaries 393 (i.e., fields of width n octets are placed at an integer multiple of 394 n octets from the start of the header, for n = 1, 2, 4, or 8) . 396 4.2.1.1. Pad1 398 The Pad1 sub-option does not have any alignment requirements. Its 399 format is as follows: 401 0 402 0 1 2 3 4 5 6 7 403 +-+-+-+-+-+-+-+-+ 404 | Sub-Opt Type | 405 +-+-+-+-+-+-+-+-+ 407 Sub-opt Type 409 0 411 NOTE! the format of the Pad1 sub-option is a special case - it has 412 neither sub-option Length nor sub-option Data fields. 414 The Pad1 sub-option is used to insert one octet of padding in the 415 flow identification option. If more than one octet of padding is 416 required, the PadN sub-option, described next, should be used rather 417 than multiple Pad1 sub-options. 419 4.2.1.2. PadN 421 The PadN sub-option does not have any alignment requirements. Its 422 format is as follows: 424 0 1 425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 427 | Sub-Opt Type | Sub-Opt Len | Option Data 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 430 Sub-opt Type 432 1 434 Sub-opt Len 436 set to the length of the sub-option 438 Sub-opt Data 440 0 or more bytes set to 0 by the sender and ignored by the 441 receiver. 443 The PadN sub-option is used to insert two or more octets of padding 444 in the flow identification mobility option. For N octets of padding, 445 the sub-option Length field contains the value N, and the sub-option 446 data consists of N-2 zero-valued octets. PadN sub-option data MUST 447 be ignored by the receiver. 449 4.2.1.3. Binding Reference Sub-option 451 This section introduces the binding reference sub-option, which may 452 be included in the flow identification mobility option. A node MUST 453 NOT include more than one binding reference sub-options in a given 454 flow binding identification option. The binding reference sub-option 455 includes one or more BIDs defined in MCoA [RFC5648]. When this sub- 456 option is included in the flow identification mobility option it 457 associates the flow described with one or more registered BIDs. 459 When binding a flow using this sub-option, the binding identifier 460 mobility option, defined in [RFC5648], MUST be included in either the 461 same or an earlier BU. The binding reference sub-option is shown 462 below. The alignment requirement for this sub-option is 2n. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |Sub-opt Type | Sub-Opt Len | BID | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | BID ........ 470 +-+-+-+-+-+-+-+-+-+- 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 SHOULD NOT be used. 520 Reserved 522 An 8-bit reserved field. It SHOULD be set to zero by the sender 523 and 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. 530 4.2.2. Flow Summary Mobility Option 532 The flow summary mobility option is a new mobility option [RFC3775], 533 which includes one or more flow identifiers (FIDs) for the purpose of 534 refreshing their state. A node MUST NOT include more than one flow 535 summary mobility option in a given binding update message. The 536 alignment requirement for this option is 2n. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Option Type | Option Len | FID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | FID ........ 544 +-+-+-+-+-+-+-+-+-+- 546 Figure 6: The Flow Summary Mobility Option 548 Option Type 550 To be assigned by IANA 552 Option Length 554 Length of the option in octets as per [RFC3775] 556 FID 558 A 16-bit unsigned integer indicating a registered FID. One or 559 more FID fields can be included in this option. Number of FIDs 560 = Option Len/2 562 4.3. Flow Bindings entries list and its relationship to Binding Cache 564 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 565 identify the mobile IP state maintained by the mobile node, mobility 566 agent, and correspondent node. The binding cache includes, between 567 others, the mobile node's home address, the registered care-of 568 address, and the lifetime of the binding. The binding cache has been 569 extended by [RFC5648] to include more than one care-of addresses and 570 to associate each of them with a Binding Identifier (BID). 572 This specification does not modify the mobile IPv6 binding cache any 573 further. 575 Flow bindings can be thought of as a conceptual list of entries that 576 is separate from the binding cache. The flow bindings list contains 577 an entry for each of the registered flow bindings. Flow binding 578 entries can point to an entry in the binding cache by means of the 579 BID. Each flow binding entry includes the following parameters : 581 o FID (Flow Identifier): For a given mobile node, identified by its 582 primary home address, the FID MUST uniquely identify an entry, 583 i.e. a unique flow binding. Each mobile node can only have a 584 single entry identified by a given FID at any one time. A given 585 FID number space is used for all the addresses associated to a 586 given MN by the HA (e.g., via [RFC3963]). Different mobile nodes 587 use the same FID number space. 589 o A Traffic Selector: Included in a traffic selector sub-option. 591 o BID(s): The list of BIDs associated with the entry as defined by 592 the binding reference sub-option included in the FID option that 593 created it. 595 o Action: The action associated with a given entry as defined by the 596 Action field of the FID option that created it 598 o Active/Inactive flag: This flag indicates whether the entry is 599 active or inactive. 601 o FID-PRI: This field indicates the priority of the flow and is used 602 to break the tie between overlapping flows. 604 The flow bindings list is associated with a given mobile node, and 605 the correspondent binding cache. An entry in the flow bindings list, 606 however, is identified by the FID and the list is ordered according 607 to the FID-PRI field as defined in the FID option that created each 608 entry. 610 For entries that take BIDs (i.e., entries that do not indicate a 611 'Discard' action), a valid BID is required to make the entry 612 'Active'. If all of the BIDs pointed to by a given entry are 613 deregistered [RFC5648], the flow binding entry becomes 'Inactive', in 614 other words it does not affect data traffic. Note that if the action 615 parameter in an entry indicates 'Forward' then the entry becomes 616 'Inactive' only if all of the BIDs are deregistered. If only some of 617 the BIDs are still valid, the invalid BIDs are simply ignored. 619 Also note that the state described in this section is maintained by 620 the mobile node as well as in mobility agents and correspondent 621 nodes. As such the mobile node is fully aware of which are the valid 622 BIDs at any time and which flow binding entries are active/inactive. 623 Section 5 defines how these flow binding entries are manipulated by 624 the mobile node in detail. 626 As an example the following represents an ordered flow binding entry 627 table for a mobile node that has registered multiple care-of 628 addresses and flow bindings. 630 FID-PRI FID Traffic Selector BIDs Action A/I 631 ------- --- ---------------- ---- ------- ------ 632 10 4 TCP 2 Forward Active 633 20 3 srcAddr=IPx N/A Discard Active 634 30 2 srcAddr=IPy 4 Forward Inactive 635 40 5 UDP 1,3 Forward Active 637 Ordered Flow Binding Entries 639 According to the above list of flow binding entries, all TCP traffic 640 will match the first entry, and according to the Action indicated it 641 will be forwarded to BID2, corresponding to a given care-of address 642 (IP3), as shown below. Any traffic that is not TCP, but has as 643 source address IPx will match the second entry, and according to the 644 associated Action it will be discarded. Note that any TCP traffic 645 with source address IPx will match the first entry and thus it will 646 be forwarded as per that entry. 648 The third entry is marked as Inactive since the BID 4 does not exist 649 in the ordered list of BID entries below. Inactive entries do not 650 affect traffic, i.e., packets are not matched against them. 652 Any UDP traffic that does not match any of the earlier entries will 653 match the forth rule and according to the Action indicated, it will 654 be replicated and forwarded to BIDs 1 and 3, corresponding to care-of 655 addresses IP1 and IP2 shown below. 657 Finally any remaining packets that do not match any of the entries 658 above will be simply forwarded to the care-of address indicated by 659 the highest order BID in the table below. In the example, such 660 packets will be forwarded to BID1 corresponding to care-of address 661 IP1. 663 BID-PRI BID CoA 664 --------- --- --- 665 20 1 IP1 666 30 3 IP2 667 30 2 IP3 669 Ordered BID Entries 671 Mobility agent and corresponding node implementations should take 672 care to avoid flow binding rules affecting the fundamental operation 673 of Mobile IPv6 and its extensions. In particular, flow binding rules 674 MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 675 and corresponding nodes communicating with a given mobile node, since 676 that could adversely affect the operation of the protocol. Other, 677 non Mobile IPv6 traffic generated by these entities SHOULD be matched 678 against the mobile node's flow binding rules as normal. 680 5. Protocol operations 682 5.1. General 684 This specification introduces a flow bindings list of entries and an 685 ordered list of flow binding identifiers, allowing mobile nodes to 686 associate flow binding policies with the registered care-of 687 addresses. 689 The flow identification mobility option defines how the mobile node 690 can control a set of flow binding entries maintained in a mobility 691 agent, or correspondent node. The fields of the flow identification 692 mobility option are necessary for ordering flow identification 693 mobility options, indicating the sort of action that should be 694 undertaken to the recipient's flow binding list of entries or for 695 carrying the results of such a petition. 697 This specification allows mobile nodes to direct flows to a 698 particular care-of address. The granularity of what constitutes a 699 flow depends on the traffic selector used. 701 The remainder of this section discusses how mobile nodes can use the 702 options and sub-options defined in this document when sending binding 703 updates to the correspondent node, home agent, or mobility anchor 704 point. In addition, refresh, deletion, and modification of flow 705 binding entries are all discussed below. 707 5.1.1. Preferred Care-of address 709 Any node that supports this specification MUST maintain an ordered 710 list of care-of addresses for each mobile node it maintains a list of 711 flow bindings for. The ordered list of care-of addresses is built 712 based on the BID-PRI field of the binding identifier mobility option 713 (see Section 4.1). 715 The ordered list of BIDs is used to determine how to forward a packet 716 to a given mobile node when the packet does not match any of the flow 717 binding entries defined in Section 4.3. A packet that does not match 718 any of the flow binding entries SHOULD be forwarded to the care-of 719 address identified by the BID with the highest priority i.e., lowest 720 BID-PRI value. 722 5.2. Mobile Node Considerations 724 This specification allows the mobile node to maintain several 725 bindings with its mobility agent, and correspondent nodes and to 726 direct packets to different care-of addresses according to flow 727 bindings. This section details the mobile node operations necessary 728 to implement this specification. 730 The mobility agent and correspondent node list of flow bindings is 731 manipulated by the mobile node, via flow identification and flow 732 summary mobility options included in binding update messages. Each 733 flow binding update can add, modify, refresh, or delete a given 734 binding. More than one flow identification mobility options MAY be 735 included in the same binding update but each of them MUST include a 736 different FID. In other words, two flow identification options in 737 the same message can not be about the same flow binding. 739 All flow binding state MUST be refreshed in every binding update the 740 mobile node sends. Any previously registered flow binding that is 741 not included in a given binding update will be deleted. So, any flow 742 bindings that are not added or modified by a flow identification 743 mobility option, but have previously registered and need to be 744 maintained MUST be included in a flow summary mobility option. Only 745 one flow summary mobility option can be included in a given binding 746 update. 748 5.2.1. Sending BU with BID Options 750 This specification (see Section 4.1) updates the definition of the 751 binding identifier mobility option, originally defined in [RFC5648]. 752 According to this specification the BID option includes a BID-PRI 753 field assigning each registered care-of address a priority, and thus 754 placing them in an ordered list as also described in Section 4.3. 756 To ensure backwards compatibility with [RFC5648] for the purpose of 757 this specification the field BID-PRI SHOULD NOT be set to zero. 758 Receiver implementation of this specification will take a BID-PRI 759 field of value zero as an indication that this is a BID option of the 760 format defined in [RFC5648]. 762 Mobile nodes supporting this specification MUST use the BID option 763 format defined in Section 4.1. Mobile nodes MUST also register all 764 care-of addresses using the updated BID option format, either in the 765 same BU as any flow identification mobility options using them, or in 766 earlier BUs. 768 5.2.2. Sending BU with Flow Identification Mobility Options 770 5.2.2.1. New Flow Bindings 772 When adding a new flow binding, a mobile node sends the flow 773 identification mobility option in the binding update, with the FID 774 field set to a value that is not already present in the list of flow 775 binding entries maintained by the receiver. The care-of address(es) 776 associated with each flow identification mobility options in the 777 binding update, must be logically registered by this binding update, 778 or must have already been registered by the receiver of the binding 779 update in an earlier binding update, as defined in Section 5.2.1. 781 The flow identification mobility option MUST include a unique flow 782 identifier in the FID field. The FID needs only be unique for the 783 receiver of the binding update and for the same sender, i.e. the same 784 FID can be used across different receivers of the binding update, for 785 the same sender. 787 The FID-PRI field is set to the desired unique priority of the 788 FID, defining the order of the flow binding to be added in the 789 list of flow binding entries as defined in Section 4.3. 791 The Action field is set to one of the defined action codes (see 792 Section 4.2). 794 The Status field is set to zero in all binding update messages. 796 Since this flow identification mobility option is requesting the 797 addition of a new flow binding in the list of flow bindings 798 maintained by the receiver, the mobile node MUST include exactly one 799 Traffic Selector sub-option (see Section 4.2.1.4) describing the flow 800 associated with the new flow binding. The TS Format field of the 801 Traffic Selector sub-option MUST be set to the non-zero value of the 802 format used by the mobile node. 804 The mobile node MAY also include up to one BID Reference sub-option 805 (see Section 4.2.1.3) to associate the flow binding with a given set 806 of BIDs and corresponding CoAs. Depending on the Action field of the 807 flow identification mobility option, the following rules MUST be 808 followed with respect to the binding reference sub-option: 810 - if the Action indicates 'Discard', the binding reference sub- 811 option SHOULD NOT be included. If it is included it will be 812 ignored by the receiver. 814 - if the Action indicates 'Forward', a single binding reference 815 sub-option with one or more BIDs MUST be included. 817 5.2.2.2. Updating Flow Bindings 819 Flow binding modification is essentially a process where parameters 820 associated with an existing flow binding in the list of flow binding 821 entries is replaced by parameters included in the flow identification 822 mobility option, and the same FID is maintained. With this procedure 823 the mobile node can change the action, the priority, the BID, and/or 824 the traffic selector associated with a flow binding. 826 To modify an existing flow binding the mobile node MUST send a 827 binding update with a flow identification option, with the FID field 828 set to one of the FID values already in the list of flow binding 829 entries. 831 The FID-PRI and Action fields MUST be set to the priority value 832 for the flow binding entry. 834 The Status field is set to zero since this option is in a binding 835 update. 837 The mobile node MAY include exactly one traffic selector sub-option 838 (see Section 4.2.1.4) describing the updated flow to be associated 839 with the flow binding. The mobile node MAY, however, omit the 840 traffic selector sub-option if it wants the traffic selector 841 currently associated with the flow binding entry identified by the 842 FID field to be maintained. 844 The mobile node MAY include exactly one binding reference sub-option 845 (see Section 4.2.1.3) to associate the existing flow binding with a 846 new set of CoAs. If the mobile node includes a binding reference 847 sub-option then it should follow the rules described in 848 Section 5.2.2.1. The mobile node MAY omit the binding reference sub- 849 option if it wants the BIDs currently associated with the flow 850 binding entry identified by the FID field to be maintained. 852 Note that it is also possible for the mobile node to effectively 853 modify the effect of a flow binding entry without actually changing 854 the entry itself. This can be done by changing the CoA associated 855 with a given BID, which is a process defined in detail in [RFC5648]. 857 5.2.3. Sending BU with a Flow Summary Option 859 When the mobile node sends a binding update it MUST refresh all flow 860 bindings it wants to maintain even if it does not want to change any 861 of their parameters. 863 To refresh an existing flow binding the mobile node MUST send a 864 binding update with a flow summary option. The flow summary option 865 MUST include one or more FID fields as indicated in Section 4.2.2. 866 Each FID field included MUST be set to one of the FID values already 867 in the list of flow binding entries. 869 Any flow bindings (active or inactive) that are not included in a 870 binding update will be removed from the list of flow binding entries. 872 Note that any inactive flow bindings, i.e., flow bindings without 873 associated BIDs that are marked as Inactive in the list of flow 874 binding entries (see Section 4.3), MUST also be refreshed, or 875 modified, to be maintained. If they are not included in a BU they 876 will be removed. 878 5.2.4. Removing flow bindings 880 Removal of flow binding entries is performed implicitly by omission 881 of a given FID from a binding update. 883 To remove a flow binding the MN simply sends a binding update that 884 includes flow identification and flow summary mobility options for 885 all the FIDs that need to be refreshed, modified, or added, and 886 simply omits any FIDs that need to be removed. 888 Note that a mobile node can also render a flow binding inactive by 889 removing the BIDs associated with it, without removing the flow 890 binding itself. The procedure for removing a BID is defined in 891 detail in [RFC5648]. 893 When all the BIDs associated with a flow binding are removed, the 894 flow binding MUST be marked as inactive in the list of flow binding 895 entries as shown in Section 4.3. In other words the state associated 896 with the flow binding MUST be maintained but it does no longer affect 897 the mobile node's traffic. The MN can return an inactive flow 898 binding to the active state by using the flow binding modification 899 process described in Section 5.2.2.2, to associate it again with one 900 or more valid BIDs. Remember that flow bindings indicating a 901 'Discard' action do not take BIDs and thus cannot be rendered 902 inactive. Instead these entries can only be removed by omitting 903 their FID from a subsequent BU. 905 5.2.5. Returning Home 907 This specification is compatible to the home registration procedures 908 defined in [RFC3775] and [RFC5648]. More specifically, if the mobile 909 node performs an [RFC3775] style deregistration, all of its bindings, 910 including flow bindings are deleted. If the mobile node, however, 911 performs an [RFC5648] style home registration, then the home link is 912 associated with a specific BID and so, as far as this specification 913 is concerned, it is treated as any other link associated with a given 914 BID. 916 5.2.6. Receiving Binding Acknowledgements 918 According to [RFC3775] all nodes are required to silently ignore 919 mobility options not understood while processing binding updates. As 920 such a mobile node receiving a Binding Acknowledgement in response to 921 the transmission of a binding update MUST determine if the Binding 922 Acknowledgement contains a copy of every flow identification mobility 923 options included in the binding update. A Binding Acknowledgement 924 without flow identification option(s), in response to a Binding 925 Update with flow identification mobility option, would indicate 926 inability (or unwillingness) on behalf of the source node to support 927 the extensions presented in this document. 929 If a received Binding Acknowledgement contains a copy of each flow 930 identification mobility option that was sent within the binding 931 update, the status field of each flow identification option indicates 932 the status of the flow binding on the distant node. 934 5.2.7. Return Routability Procedure 936 A mobile node may perform route optimization with correspondent nodes 937 as defined in [RFC3775]. Route optimization allows a mobile node to 938 bind a care-of address to a home address in order to allow the 939 correspondent node to direct the traffic to the current location of 940 the mobile node. Before sending a Binding Update to correspondent 941 node, the Return Routability Procedure needs to be performed between 942 the mobile node and the correspondent node.This procedure is not 943 affected by the extensions defined in this document. 945 5.3. HA, MAP, and CN Considerations 947 This specification allows the mobility agents (Home Agents and 948 Mobility Anchor Points), and correspondent nodes to maintain several 949 flow bindings for a given home address and to direct packets to 950 different care-of addresses according to flow bindings. This section 951 details the home agent operations necessary to implement this 952 specification. These operations are identical for MAPs and CNs 953 unless otherwise stated. 955 Note that route optimization is only defined for mobile nodes (MIPv6 956 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 957 sections only apply to correspondent nodes with respect to mobile 958 nodes and not for mobile routers. 960 5.3.1. Handling Binding Identifier Mobility Options 962 This specification (see Section 4.1) updates the definition of the 963 binding identifier mobility option, originally defined in [RFC5648]. 964 According to this specification the BID option includes a BID-PRI 965 field assigning each registered care-of address a priority, and thus 966 placing them in an ordered list (see Section 4.3). 968 Home agents receiving BUs including BID options and flow 969 identification options MUST logically process BID options first. 970 This is because BID Reference sub-options included in the flow 971 identification mobility options might refer to BIDs defined in BID 972 options included in the same message. 974 The BID option is processed as defined in [RFC5648] but then the BID 975 to care-of address mapping is placed in an ordered list according to 976 the BID-PRI field of the BID option. 978 Binding Identifier registrations and deregistrations indirectly 979 affect the MN's flow binding entries. The home agent MUST update the 980 flow binding entries table accordingly as BIDs are added or removed ( 981 [RFC5648]). For example, as discussed in Section 4.3, if all of the 982 BIDs associated with a given flow binding entry are removed (i.e., 983 become invalid) the entry MUST be marked as inactive. While if any 984 of the invalid BIDs associated with an inactive flow binding entry 985 are registered (i.e., become valid), the entry MUST be marked as 986 active. 988 5.3.2. Handling Flow Identification Mobility Options 990 When the home agent receives a binding update which includes at least 991 one flow identification mobility option, it first performs the 992 operation described in section 10.3.1 of RFC3775, followed by the 993 operations defined in Section 5.3.1 of this document. 995 Home agents that do not support this specification will ignore the 996 flow identification mobility options and all their sub-options, 997 having no effect on the operation of the rest of the protocol. 999 If the binding update is accepted, and the home agent is willing to 1000 support flow bindings for this MN, the home agent checks the flow 1001 identification mobility options. 1003 If more than one flow identification mobility option in the same BU, 1004 has the same value in the FID field, all the flow identification 1005 mobility options MUST be rejected. 1007 If all FID fields have different values the flow identification 1008 mobility options can be processed further and in any order, as 1009 defined by the following subsections. 1011 5.3.2.1. Handling new FIDs 1013 If the FID field of the flow identification mobility option is not 1014 already present in the list of flow binding entries for this mobile 1015 node, then this is a request for a new entry. 1017 If the flow identification mobility option does not include a traffic 1018 selector sub-option, the home agent MUST reject this request by 1019 copying the flow identification mobility option in the BA, and 1020 setting the Status field to the value defined in Figure 2 for "Flow 1021 identification option malformed". 1023 If the flow identification option does include a traffic selector 1024 sub-option, but the format indicated in the TS Format field is not 1025 supported, the home agent MUST reject this request by copying the 1026 flow identification mobility option in the BA, and setting the Status 1027 field to the value defined in Figure 2 for "Traffic Selector format 1028 not supported". 1030 Then the home agent MUST check the Action field in combination with 1031 the Binding Reference sub-option if present. 1033 - if the Action indicates 'Discard', 1035 Any binding reference sub-options that might be present SHOULD be 1036 ignored. 1038 The home agent SHOULD add a new entry in the mobile node's list of 1039 flow binding entries, as defined below. 1041 - if the Action indicates 'Forward", 1043 If the Binding reference sub-option is not included, the home 1044 agent MUST reject this request by copying the flow identification 1045 mobility option in the BA, and setting the Status field to the 1046 value defined for "Flow identification mobility option malformed" 1047 in Section 4.2. 1049 If the binding reference sub-option is present and includes one or 1050 more BIDs that are not present in the binding cache of the mobile 1051 node the home agent MUST reject this request by copying the flow 1052 identification option in the BA, and setting the Status field to 1053 the value defined for "BID not found" in Section 4.2. 1055 If the binding reference sub-option is present and includes one or 1056 more BIDs, and the BIDs exist in the mobile node's binding cache, 1057 the home agent SHOULD add a new entry in the mobile node's list of 1058 flow binding entries, as defined below. 1060 When the home agent decides to add an entry in the mobile node's list 1061 of flow binding entries, as discussed above, it MUST do it according 1062 to the following rules: The entry MUST be placed according to the 1063 order indicated by the FID-PRI field of the flow identification 1064 mobility option and it MUST include: 1066 the FID as a key to the entry 1068 The traffic selector included in the corresponding sub-option 1070 the action indicated in the Action field 1072 the BIDs, depending on action field, indicated in the binding 1073 reference sub-option 1075 the entry MUST be marked as Active, as shown in Section 4.3 1077 5.3.2.2. Handling known FIDs 1079 If the FID field of the flow identification mobility option is 1080 already present in the list of flow binding entries for this mobile 1081 node, then this is a request to update the existing entry. 1083 The flow binding modification is essentially a process where 1084 parameters associated with an existing flow binding entry are 1085 replaced by the parameters included in a flow identification mobility 1086 option with the same FID as the existing entry. 1088 The home agent MUST: 1090 Change the priority of the entry according to the FID-PRI field of 1091 the flow identification mobility option. 1093 Change the action associated with the entry according to the 1094 Action field of the flow identification mobility option. 1096 Since this flow identification mobility option is designed to update 1097 an existing entry it may not include a traffic selector sub-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 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. A de- 1129 registration binding update (with a zero lifetime) would result in 1130 deleting all bindings, including all flow bindings regardless of the 1131 presence of the flow summary mobility option. 1133 If the value of any of the FID fields included in the flow summary 1134 mobility option is not present in the list of flow binding entries 1135 for this mobile node, the home agent MUST reject this flow binding 1136 refresh by including a flow identification mobility option in the BA 1137 for each FID that is not found, and by setting the FID field to the 1138 value of the FID that is not found and the Status field to the value 1139 defined for "FID not found" in Section 4.2. 1141 If the value of the FID field is present in the mobile nodes list of 1142 flow binding entries the, home agent SHOULD refresh the flow binding 1143 entry identified by the FID without changing any of the other 1144 parameters associated with it. 1146 5.3.4. Flow Binding Removals 1148 Removal of flow bindings is performed implicitly by omission of a 1149 given FID from a binding update. 1151 When a valid binding update is received, any registered FIDs that are 1152 not explicitly referred to in a flow identification mobility option 1153 or in a flow summary mobility option, in the same binding update, 1154 MUST be removed from the list of flow binding entries for the mobile 1155 node. 1157 5.3.5. Sending Binding Acknowledgements 1159 Upon the reception of a binding update, the home agent is required to 1160 send back a Binding Acknowledgment. The status code in the Binding 1161 Acknowledgement must be set as recommended in [RFC3775]. This status 1162 code does not give information on the success or failure of flow 1163 bindings. 1165 In order to inform the mobile node about the status of the flow 1166 binding(s) requested by a mobile node, flow identification options 1167 SHOULD be included in the Binding Acknowledgement message. 1168 Specifically, the home agent SHOULD copy each flow identification 1169 mobility option received in the binding update and set its status 1170 code to an appropriate value. If an operation requested in a flow 1171 identification option by a mobile node is performed successfully by 1172 the home agent, the status field on the copied flow identification 1173 mobility option in the BA, SHOULD be set to the value defined for 1174 "Flow binding successful" in Section 4.2, otherwise it SHOULD be set 1175 to one of the rejection codes also defined in Section 4.2. 1176 Section 5.3.2 identifies a number of cases where specific error codes 1177 should be used. 1179 Home agents that support this specification MAY refuse to maintain 1180 flow bindings by setting the status field of any flow identification 1181 mobility options to the value defined for "Administratively 1182 prohibited" in Section 4.2, or by just ignoring all the flow binding 1183 options. 1185 Note that BID options and their Status field are handled as defined 1186 in [RFC5648]. 1188 5.3.6. Packet Processing 1190 This section defines packet processing rules according to this 1191 specification. This specification does not change any of the packet 1192 interception rules defined in [RFC3775], and [RFC5555]. These rules 1193 apply to HAs, MAPs, and CNs, as part of the routing process for any 1194 packet with destination address set to a valid home address of the 1195 mobile node. For nodes other than CNs this also applies to packets 1196 with destination address set to an address under any of the 1197 registered prefixes. These rules apply equally to IPv6 packets as 1198 well as to IPv4 packets as per [RFC5555]. 1200 Before a packet is forwarded to the mobile node it MUST be matched 1201 against the ordered list of flow bindings stored in the list of flow 1202 binding entries for this mobile node (see Section 4.3). A match is 1203 attempted with the traffic selector included in the first line 1204 (highest order) of the table. If the packet matches the traffic 1205 selector, the action defined by the action parameter of the table 1206 SHOULD be performed. 1208 - if the Action indicates 'Discard', the packet is silently 1209 discarded 1210 - if the Action indicates 'Forward", a copy of the packet is 1211 forwarded to each of the care-of addresses associated with the 1212 BIDs indicated in the same line of the table. 1214 If the action indicated in one of the entries in the list of flow 1215 bindings is 'Discard' then, no BIDs need to be indicated in the same 1216 entry since the packet is not forwarded. If, however, the action 1217 indicated in an entry of the list of flow bindings is 'Forward", the 1218 entry should indicate one or more valid BIDs. For 'Forward' if any 1219 of the BIDs indicated does not correspond to a valid care-of address, 1220 e.g., the BID was deregistered then that BID has no effect on the 1221 traffic. In other words, packets matching the flow binding are 1222 forwarded to the remaining BIDs, pointing to registered care-of 1223 addresses. If none of the BIDs pointed to in a flow binding entry is 1224 valid then the entry is considered to be inactive (as defined in 1225 Section 4.3) and is skipped. In other words packets should not be 1226 matched against that entry. 1228 If a packet does not match any of the active flow binding entries for 1229 the given MN, the packet SHOULD be forwarded to the care-of address 1230 associated with the BID with the highest BID-PRI. 1232 If a packet is fragmented, only the first fragment contains all IP 1233 and transport layer headers, while subsequent fragments only contain 1234 an IP header without transport layer headers. For this reason it is 1235 possible that subsequent fragments do not match the same traffic 1236 selector as the initial fragment of such a packet. Unless specific 1237 measures are taken the likely outcome is that the initial fragment is 1238 routed as the MN intended while subsequent fragments are routed 1239 differently, and probably based on the default flow binding. HAs, 1240 MAPs, and CNs SHOULD take care to forward all fragments of a given 1241 packet the same way, and in accordance to the flow binding matching 1242 the first fragment of said packet. This should be possible given the 1243 fact that fragment headers include enough information to identify a 1244 fragment as part of a specific packet, but the details of how this is 1245 ensured are implementation specific and are not defined in this 1246 specification. 1248 6. MTU Considerations 1250 The options and sub-options defined in this specification add to 1251 those defined in [RFC3775] and other related specifications, all of 1252 which potentially adds to the size of binding update messages. 1253 Implementations SHOULD take care to minimize fragmentation by forming 1254 binding updates that are shorter than what the path MTU allows 1255 whenever possible. 1257 This specification offers a number of mechanisms for reducing the 1258 size of binding updates. The operations defined in this 1259 specification that require the most verbose options are those 1260 registering new BIDs Section 4.1 and identifying new flows 1261 Section 4.2.1.4. Implementations are encouradged to keep binding 1262 updates to sizes below than that of the path's MTU by making full use 1263 of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub- 1264 options, which allows them to refer to already registered care-off 1265 addresses and flows, while registering new ones in subsequent binding 1266 update messages. 1268 7. Security considerations 1270 This draft introduces a new option that adds more granularity to the 1271 binding update message. The new option allows the mobile node to 1272 associate some flows to one interface and other flows to another 1273 interface. Since the flow identification mobility option is part of 1274 the mobility header, it uses the same security as the Binding Update, 1275 whether it is sent to a mobility agent, or to a correspondent node. 1277 8. IANA Considerations 1279 This specification requires the following IANA assignments on 1280 existing namespaces as well as the creation of some new namespaces. 1282 1) New Mobility Options [RFC3775]: This registry is available from 1283 http://www.iana.org under "Mobile IPv6 parameters". The following 1284 type numbers need to be assigned for: 1286 Flow Identification Mobility Option, define in Section 4.2 1288 Flow Summary Mobility Option, defined in Section 4.2.2 1290 2) New "Flow Identification Mobility Option Action codes" 1291 namespace needs to be created. The following 'Action' codes are 1292 defined in this specification, in Section 4.2: 1294 0 Reserved 1296 1 Discard 1298 2 Forward 1300 3-254 unassigned and available for allocation based on 1301 Standards Action or IESG Approval as per [RFC5226] 1303 255 reserved for experimental use. A single value should be 1304 sufficient for experimenting with a different flow 1305 identifiction format. 1307 3) New "Flow Identification Mobility Option Status codes" 1308 namespace needs to be created. The following 'Status' codes are 1309 defined in this specification, in Section 4.2: 1311 0 Flow binding successful 1313 1-127 unassigned and available for success codes to be 1314 allocated via STD action 1316 128 Administratively prohibited 1318 129 Flow binding rejected, reason unspecified 1320 130 Flow identification mobility option malformed 1322 131 BID not found 1323 132 FID not found 1325 133 Traffic selector format not supported 1327 134 Discard function not supported 1329 135 Forward function not supported 1331 126-250 unassigned and available for reject codes to be 1332 allocated via Standards Action or IESG Approval as per 1333 [RFC5226] 1335 251-255 reserved for experimental use. This small number of 1336 status codes should be sufficient for experiments with 1337 currently unforeseen error conditions. 1339 4) New "Flow Identification Sub-Options" namespace for the Flow 1340 Identification Mobility Option. The sub-option space is defined 1341 in Figure 3. The following Sub-option Type values are defined in 1342 this specification: 1344 0 Pad 1346 1 PadN 1348 2 BID Reference 1350 3 Traffic Selector 1352 4-250 unassigned and available for allocation based on 1353 Standards Action or IESG Approval as per [RFC5226] 1355 251-255 reserved for experimental use. This small number of 1356 sub-option types should be sufficient for experiments with 1357 additional parameters associated with a flow. 1359 5) New "Traffic Selector Format" namespace for the Traffic 1360 Selector sub-option. The traffic selector format space is defined 1361 by the TS Format field in Figure 5. The following values are 1362 defined in this specification: 1364 0 Reserved 1366 1-250 unassigned and available for allocation based on 1367 Standards Action or IESG Approval as per [RFC5226] 1369 251-255 reserved for experimental use. This small number of 1370 traffic selector format types should be sufficient for 1371 experiments with different ways of representing a traffic 1372 selector. 1374 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1375 spaces, future allocations from the new number spaces requires 1376 Standards Action or IESG Approval as per [RFC5226] 1378 9. Contributors 1380 We would like to explicitly acknowledge the following person who co- 1381 authored one of the documents used as source material for this 1382 document. 1384 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1386 10. Acknowledgements 1388 We would also like to acknowledge the following people in 1389 alphabetical order for their contributions to this specification: C. 1390 Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- 1391 Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. 1392 Also, Gabor Fekete for the analysis that led to the inclusion of the 1393 BIDRef sub-option, and Henrik Levkowetz for suggesting support for 1394 other ways of describing flows. 1396 11. References 1398 11.1. Normative References 1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1401 Requirement Levels", BCP 14, RFC 2119, March 1997. 1403 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1404 in IPv6", RFC 3775, June 2004. 1406 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1407 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1408 RFC 3963, January 2005. 1410 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1411 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1412 May 2008. 1414 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1415 Routers", RFC 5555, June 2009. 1417 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1418 and K. Nagami, "Multiple Care-of Addresses Registration", 1419 RFC 5648, October 2009. 1421 11.2. Informative References 1423 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1424 McManus, "Requirements for Traffic Engineering Over MPLS", 1425 RFC 2702, September 1999. 1427 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1428 RFC 3753, June 2004. 1430 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1431 Terminology", RFC 4885, July 2007. 1433 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1434 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1435 Management", RFC 5380, October 2008. 1437 Authors' Addresses 1439 Hesham Soliman 1440 Elevate Technologies 1442 Email: hesham@elevatemobile.com 1444 George Tsirtsis 1445 Qualcomm 1447 Email: tsirtsis@qualcomm.com 1449 Nicolas Montavont 1450 Institut Telecom / Telecom Bretagne 1451 2, rue de la chataigneraie 1452 Cesson Sevigne 35576 1453 France 1455 Phone: (+33) 2 99 12 70 23 1456 Email: nicolas.montavont@telecom-bretagne.eu 1457 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1459 Gerardo Giaretta 1460 Qualcomm 1462 Email: gerardog@qualcomm.com 1464 Koojana Kuladinithi 1465 University of Bremen 1466 ComNets-ikom,University of Bremen. 1467 Otto-Hahn-Allee NW 1 1468 Bremen, Bremen 28359 1469 Germany 1471 Phone: +49-421-218-8264 1472 Fax: +49-421-218-3601 1473 Email: koo@comnets.uni-bremen.de 1474 URI: http://www.comnets.uni-bremen.de/~koo/