idnits 2.17.1 draft-ietf-mext-flow-binding-04.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 (November 9, 2009) is 5272 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: May 13, 2010 Qualcomm 6 N. Montavont 7 IT/TB 8 G. Giaretta 9 Qualcomm 10 K. Kuladinithi 11 University of Bremen 12 November 9, 2009 14 Flow Bindings in Mobile IPv6 and NEMO Basic Support 15 draft-ietf-mext-flow-binding-04.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 May 13, 2010. 47 Copyright Notice 48 Copyright (c) 2009 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 . . . . . . . . . . . 29 92 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 93 6. Security considerations . . . . . . . . . . . . . . . . . . . 31 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 95 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 102 1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Introduction 110 Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support 111 [RFC3963] allow a mobile node / mobile router to manage its mobility 112 using the binding update message, which binds one care-of address to 113 one home address and associated mobile networks. The binding update 114 message can be sent to the home agent. In Mobile IPv6, the binding 115 update can also be sent to correspondent node or to a mobility anchor 116 point (see [RFC5380]). The semantics of the binding update are 117 limited to care-of address changes. That is, [RFC3775], [RFC5555], 118 and [RFC3963] do not allow a mobile node / mobile router to bind more 119 than one address to the home address. In [RFC5648] Mobile IPv6 and 120 NEMO Basic Support are extended to allow the binding of more than one 121 care-of address to a home address. This specification further 122 extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to 123 specify policies associated with each binding. A policy can contain 124 a request for special treatment of a particular IPv4 or IPv6 flow, 125 which is viewed as a group of packets matching a traffic selector. 126 Hence, this specification allows a mobile node / mobile router to 127 bind a particular flow to a care-of address without affecting other 128 flows using the same home address. In addition, this specification 129 allows to bind a particular flow to a particular care-of address 130 directly with correspondent node and mobility agents (i.e., home 131 agents [RFC3775] and mobility anchor points [RFC5380]). 133 In this document, a flow is defined as a set of IP packets matching a 134 traffic selector. A traffic selector can identify the source and 135 destination IP addresses, transport protocol number, the source and 136 destination port numbers and other fields in IP and higher layer 137 headers. This specification, however, does not define traffic 138 selectors and it is assumed that one or more ways of defining traffic 139 selectors are going to be defined in other specifications. This 140 specification, however, does define the traffic selector sub-option 141 format to be used for any defined traffic selectors. 143 Using the flow identifier option introduced in this specification a 144 mobile node / mobile router can bind one or more flows to a care-of 145 address while maintaining the reception of other flows on another 146 care-of address. The mobile node / mobile router assembles the flow 147 binding request based local policies, link characteristics and the 148 types of applications running at the time. Such policies are outside 149 the scope of this document. 151 It should be noted that the flow identification mobility option can 152 be associated with any binding update, whether it is sent to a 153 mobility agent or a correspondent node. 155 Note that per-packet load balancing may have negative impacts on TCP 156 congestion avoidance mechanisms as it is desirable to maintain order 157 between packets belonging to the same TCP connection. This behaviour 158 is specified in [RFC2702]. Other negative impacts are also foreseen 159 for other types of real time connections due to the potential 160 variations in round trip time between packets. Moreover, per-packet 161 load-balancing will negatively affect traffic with anti-reply 162 protection mechanisms. Hence, per-packet load balancing is not 163 envisioned in this specification. 165 In the rest of the document, the term "mobile node" is used to 166 designate either a mobile node as defined in [RFC3775] and [RFC5648], 167 or a mobile router as defined in [RFC3963] unless stated otherwise. 169 3. Terminology 171 Terms used in this document are defined in [RFC3753] and [RFC4885]. 172 The following terms are also used in this document: 174 Flow: A flow is as a set of data packets that are exchanged 175 between two nodes. In the context of this specification the term 176 "flow" is some times used to refer to a plurality of flows as well 177 as a single flow. 179 Traffic Selector: Information that identifies one or more flows. 181 Flow binding: It consists of a traffic selector, and an action. 182 IP packets from one or more flows that match the traffic selector 183 associated with the flow binding, are processed according to the 184 action associated with the same flow binding. 186 Flow Identifier: A flow identifier uniquely identifies a flow 187 binding associated with a mobile node. It is generated by a 188 mobile node and is cached in the table of flow binding entries 189 maintained by the MN, HA, CN or MAP. 191 4. Mobile IPv6 Extensions 193 This section introduces extensions to Mobile IPv6 that are necessary 194 for supporting the flow binding mechanism described in this document. 196 4.1. Definition Update for Binding Identifier Mobility Option 198 This specification updates the definition of the Binding Identifier 199 Mobility option defined in [RFC5648], as follows: 201 1 2 3 202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type = 35 | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Binding ID (BID) | Status |H| BID-PRI | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 208 + + 209 : IPv4 or IPv6 care-of address (CoA) : 210 + + 211 +---------------------------------------------------------------+ 213 Figure 1: The Binding Identifier Mobility option 215 BID-PRI 217 This is a 7-bit unsigned integer placing each BID to a relative 218 priority with other registered BIDs. Value '0' is reserved and 219 SHOULD NOT be used. A lower number in this field indicates a 220 higher priority, while BIDs with the same BID-PRI value have 221 equal priority meaning that, the BID used is an implementation 222 issue. This is consistent with current practice in packet 223 classifiers. 225 4.2. Flow Identification Mobility Option 227 The flow identification mobility option is a new mobility option 228 [RFC3775] and it is included in the binding update and 229 acknowledgement messages. This option contains information that 230 allows the receiver of a binding update to install policies on a 231 traffic flow and route it to a given care-of address. Multiple 232 options may exist within the same binding update message. The 233 alignment requirement for this option is 2n. 235 0 1 2 3 236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Option Type | Option Len | FID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | FID-PRI | Action | Rsvd | Status | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Sub-options (optional) ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: The Flow Identification Mobility Option 247 Option Type 249 To be assigned by IANA 251 Option Len 253 Length of the option in octets as per [RFC3775]. 255 FID 257 The Flow Identifier field is a 16-bit unsigned integer that 258 includes the unique identifier for the flow binding. This 259 field is used to refer to an existing flow binding or to create 260 a new flow binding. The value of this field is set by the 261 mobile node. FID = 0 is reserved and SHOULD NOT be used. 263 FID-PRI 265 This is an 8-bit unsigned priority field to indicate the 266 priority of a particular option. This field is needed in cases 267 where two different flow descriptions in two different options 268 overlap. The priority field decides which policy should be in 269 those cases. A lower number in this field indicates a higher 270 priority. Value '0' is reserved and SHOULD NOT be used. FID- 271 PRI MUST be unique to each of the flows pertaining to a given 272 MN. 274 Action 276 This 8-bit unsigned integer field specifies the action that 277 needs to be taken by the receiver of the binding update 278 containing the flow identification option. The details of 279 these requests are discussed below. The following values are 280 reserved for the Action field in this option: 282 0 Reserved and SHOULD NOT be used 284 1 'Discard'. This value indicates a request to discard all 285 packets in the flow described by the option. No BIDs are 286 associated with this Action. Care should be taken when 287 using this Action as it will lead to disrupting applications 288 communication. Implementations may consider notifying 289 impacted applications in mobile nodes. 291 2 'Forward'. This value indicates a request to send the 292 flow to one or more addresses indicated in the binding 293 reference sub-option (see Section 4.2.1.3). One or more 294 BIDs MUST be associated with this Action. If only one BID 295 is associated with this action then it is essentially a 296 request to forward packets to that CoA, otherwise matching 297 packets are replicated and forwarded to all of the indicated 298 CoAs. Care should be taken when multiple BIDs are used in 299 combination with the 'Forward' action as some transport 300 layers may not be able to handle packet duplication and this 301 can affect their performance. 303 3-255 Reserved for future use 305 Rsvd 307 This field is unused. It SHOULD be set to zero by the sender 308 and ignored by the receiver. 310 Status 312 This 8-bit unsigned integer field indicates the success or 313 failure of the flow binding operation for the particular flow 314 in the option. This field is not relevant to the binding 315 update message as a whole or to other flow identification 316 options. This field is only relevant when included in the 317 Binding Acknowledgement message and must be ignored in the 318 binding update message. The following values are reserved for 319 the status field within the flow identification mobility 320 option: 322 0 Flow binding successful 324 128 Administratively prohibited 326 129 Flow binding rejected, reason unspecified 327 130 Flow identification mobility option malformed 329 131 BID not found 331 132 FID not found 333 133 Traffic selector format not supported 335 134 Discard function not supported 337 135 Forward function not supported 339 Sub-options (optional) 341 zero or more sub-options, defined in Section 4.2.1 343 4.2.1. Flow Identification Sub-Options definition 345 Flow identification sub-options are encoded within the remaining 346 space of the flow identification mobility option, using a sub-option 347 type-length-value (TLV) format as follows: 349 0 1 2 3 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Sub-Opt Type |Sub-Opt Length | Sub-Option Data... 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 3: Flow Identification Sub-Option format 357 Sub-opt Type 359 8-bit unsigned integer indicating the sub-option Type. When 360 processing a flow identification mobility option containing an 361 option for which the sub-option Type value is not recognized by 362 the receiver, the receiver MUST quietly ignore and skip over 363 the option, correctly handling any remaining sub-options in the 364 same option. 366 Sub-opt Len 368 8-bit unsigned integer, representing the length in octets of 369 the flow identification sub-option. This field indicates the 370 length of the sub-option not including the Sub-opt Type and 371 Sub-opt Length fields. Note that Sub-opt Type '0' 372 (Section 4.2.1.1) is a special case that does not take a Sub- 373 opt Length field. 375 Sub-Option Data 377 A variable length field that contains data specific to the sub- 378 option 380 The following subsections specify the sub-option types which are 381 currently defined for use in the flow identification option. 382 Implementations MUST silently ignore any sub-options that they do not 383 understand. 385 These sub-options may have alignment requirements. Following the 386 convention in [RFC3775], regarding mobility options, these sub- 387 options are aligned in a packet so that multi-octet values within the 388 sub-option Data field of each sub-option fall on natural boundaries 389 (i.e., fields of width n octets are placed at an integer multiple of 390 n octets from the start of the header, for n = 1, 2, 4, or 8) . 392 4.2.1.1. Pad1 394 The Pad1 sub-option does not have any alignment requirements. Its 395 format is as follows: 397 0 398 0 1 2 3 4 5 6 7 399 +-+-+-+-+-+-+-+-+ 400 | Sub-Opt Type | 401 +-+-+-+-+-+-+-+-+ 403 Sub-opt Type 405 0 407 NOTE! the format of the Pad1 sub-option is a special case - it has 408 neither sub-option Length nor sub-option Data fields. 410 The Pad1 sub-option is used to insert one octet of padding in the 411 flow identification option. If more than one octet of padding is 412 required, the PadN sub-option, described next, should be used rather 413 than multiple Pad1 sub-options. 415 4.2.1.2. PadN 417 The PadN sub-option does not have any alignment requirements. Its 418 format is as follows: 420 0 1 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 423 | Sub-Opt Type | Sub-Opt Len | Option Data 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 426 Sub-opt Type 428 1 430 Sub-opt Len 432 set to the length of the sub-option 434 Sub-opt Data 436 0 or more bytes set to 0 by the sender and ignored by the 437 receiver. 439 The PadN sub-option is used to insert two or more octets of padding 440 in the flow identification mobility option. For N octets of padding, 441 the sub-option Length field contains the value N, and the sub-option 442 data consists of N-2 zero-valued octets. PadN sub-option data MUST 443 be ignored by the receiver. 445 4.2.1.3. Binding Reference Sub-option 447 This section introduces the binding reference sub-option, which may 448 be included in the flow identification mobility option. A node MUST 449 NOT include more than one binding reference sub-options in a given 450 flow binding identification option. The binding reference sub-option 451 includes one or more BIDs defined in MCoA [RFC5648]. When this sub- 452 option is included in the flow identification mobility option it 453 associates the flow described with one or more registered BIDs. 455 When binding a flow using this sub-option, the binding identifier 456 mobility option, defined in [RFC5648], MUST be included in either the 457 same or an earlier BU. The binding reference sub-option is shown 458 below. The alignment requirement for this sub-option is 2n. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |Sub-opt Type | Sub-Opt Len | BID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | BID ........ 466 +-+-+-+-+-+-+-+-+-+- 467 Figure 4: The Binding Reference sub-option 469 Sub-opt Type 471 2 473 Sub-opt Len 475 Variable 477 BID 479 A 16-bit unsigned integer indicating the BID that the mobile 480 node wants to associate with the flow identification option. 481 One or more BID fields can be included in this sub-option. 482 Since each BID is 2 bytes long, the value of the Sub-opt Len 483 field indicates the number of BIDs present. Number of BIDs = 484 Sub-opt Len/2. 486 4.2.1.4. Traffic Selector sub-option 488 The traffic selector sub-option includes the parameters used to match 489 packets for a specific flow binding. A node MUST NOT include more 490 than one traffic selector sub-option in a given flow binding 491 identification option. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Traffic Selector ... 499 +-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 5: The Traffic Selector sub-option 503 Sub-opt Type 505 3 507 Sub-opt Len 509 variable 511 TS Format 513 An 8-bit unsigned integer indicating the Traffic Selector Format. 514 Value "0" is reserved and SHOULD NOT be used. 516 Reserved 518 An 8-bit reserved field. It SHOULD be set to zero by the sender 519 and ignored by the receiver. 521 Traffic Selector 523 A variable length field, the format and content of which is out of 524 scope for this specification. 526 4.2.2. Flow Summary Mobility Option 528 The flow summary mobility option is a new mobility option [RFC3775], 529 which includes one or more flow identifiers (FIDs) for the purpose of 530 refreshing their state. A node MUST NOT include more than one flow 531 summary mobility option in a given binding update message. The 532 alignment requirement for this option is 2n. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Option Type | Option Len | FID | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | FID ........ 540 +-+-+-+-+-+-+-+-+-+- 542 Figure 6: The Flow Summary Mobility Option 544 Option Type 546 To be assigned by IANA 548 Option Length 550 Length of the option in octets as per [RFC3775] 552 FID 554 A 16-bit unsigned integer indicating a registered FID. One or 555 more FID fields can be included in this option. Number of FIDs 556 = Option Len/2 558 4.3. Flow Bindings entries list and its relationship to Binding Cache 560 The conceptual mobile IPv6 binding cache was defined in [RFC3775] to 561 identify the mobile IP state maintained by the mobile node, mobility 562 agent, and correspondent node. The binding cache includes, between 563 others, the mobile node's home address, the registered care-of 564 address, and the lifetime of the binding. The binding cache has been 565 extended by [RFC5648] to include more than one care-of addresses and 566 to associate each of them with a Binding Identifier (BID). 568 This specification does not modify the mobile IPv6 binding cache any 569 further. 571 Flow bindings can be thought of as a conceptual list of entries that 572 is separate from the binding cache. The flow bindings list contains 573 an entry for each of the registered flow bindings. Flow binding 574 entries can point to an entry in the binding cache by means of the 575 BID. Each flow binding entry includes the following parameters : 577 o FID (Flow Identifier): For a given mobile node, identified by its 578 home address, the FID MUST uniquely identify an entry, i.e. a 579 unique flow binding. Each mobile node can only have a single 580 entry identified by a given FID at any one time. Different mobile 581 nodes can use the same FID number space. 583 o A Traffic Selector: Included in a traffic selector sub-option. 585 o BID(s): The list of BIDs associated with the entry as defined by 586 the binding reference sub-option included in the FID option that 587 created it. 589 o Action: The action associated with a given entry as defined by the 590 Action field of the FID option that created it 592 o Active/Inactive flag: This flag indicates whether the entry is 593 active or inactive. 595 o FID-PRI: This field indicates the priority of the flow and is used 596 to break the tie between overlapping flows. 598 The flow bindings list is associated with a given mobile node, and 599 the correspondent binding cache. An entry in the flow bindings list, 600 however, is identified by the FID and the list is ordered according 601 to the FID-PRI field as defined in the FID option that created each 602 entry. 604 For entries that take BIDs (i.e., entries that do not indicate a 605 'Discard' action), a valid BID is required to make the entry 606 'Active'. If all of the BIDs pointed to by a given entry are 607 deregistered [RFC5648], the flow binding entry becomes 'Inactive', in 608 other words it does not affect data traffic. Note that if the action 609 parameter in an entry indicates 'Forward' then the entry becomes 610 'Inactive' only if all of the BIDs are deregistered. If only some of 611 the BIDs are still valid, the invalid BIDs are simply ignored. 613 Also note that the state described in this section is maintained by 614 the mobile node as well as in mobility agents and correspondent 615 nodes. As such the mobile node is fully aware of which are the valid 616 BIDs at any time and which flow binding entries are active/inactive. 617 Section 5 defines how these flow binding entries are manipulated by 618 the mobile node in detail. 620 As an example the following represents an ordered flow binding entry 621 table for a mobile node that has registered multiple care-of 622 addresses and flow bindings. 624 FID-PRI FID Traffic Selector BIDs Action A/I 625 ------- --- ---------------- ---- ------- ------ 626 10 4 TCP 2 Forward Active 627 20 3 srcAddr=IPx N/A Discard Active 628 30 2 srcAddr=IPy 4 Forward Inactive 629 40 5 UDP 1,3 Forward Active 631 Ordered Flow Binding Entries 633 According to the above list of flow binding entries, all TCP traffic 634 will match the first entry, and according to the Action indicated it 635 will be forwarded to BID2, corresponding to a given care-of address 636 (IP3), as shown below. Any traffic that is not TCP, but has as 637 source address IPx will match the second entry, and according to the 638 associated Action it will be discarded. Note that any TCP traffic 639 with source address IPx will match the first entry and thus it will 640 be forwarded as per that entry. 642 The third entry is marked as Inactive since the BID 4 does not exist 643 in the ordered list of BID entries below. Inactive entries do not 644 affect traffic, i.e., packets are not matched against them. 646 Any UDP traffic that does not match any of the earlier entries will 647 match the forth rule and according to the Action indicated, it will 648 be replicated and forwarded to BIDs 1 and 3, corresponding to care-of 649 addresses IP1 and IP2 shown below. 651 Finally any remaining packets that do not match any of the entries 652 above will be simply forwarded to the care-of address indicated by 653 the highest order BID in the table below. In the example, such 654 packets will be forwarded to BID1 corresponding to care-of address 655 IP1. 657 BID-PRI BID CoA 658 --------- --- --- 659 20 1 IP1 660 30 3 IP2 661 30 2 IP3 663 Ordered BID Entries 665 Mobility agent and corresponding node implementations should take 666 care to avoid flow binding rules affecting the fundamental operation 667 of Mobile IPv6 and its extensions. In particular, flow binding rules 668 MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 669 and corresponding nodes communicating with a given mobile node, since 670 that could adversely affect the operation of the protocol. Other, 671 non Mobile IPv6 traffic generated by these entities SHOULD be matched 672 against the mobile node's flow binding rules as normal. 674 5. Protocol operations 676 5.1. General 678 This specification introduces a flow bindings list of entries and an 679 ordered list of flow binding identifiers, allowing mobile nodes to 680 associate flow binding policies with the registered care-of 681 addresses. 683 The flow identification mobility option defines how the mobile node 684 can control a set of flow binding entries maintained in a mobility 685 agent, or correspondent node. The fields of the flow identification 686 mobility option are necessary for ordering flow identification 687 mobility options, indicating the sort of action that should be 688 undertaken to the recipient's flow binding list of entries or for 689 carrying the results of such a petition. 691 This specification allows mobile nodes to direct flows to a 692 particular care-of address. The granularity of what constitutes a 693 flow depends on the traffic selector used. 695 The remainder of this section discusses how mobile nodes can use the 696 options and sub-options defined in this document when sending binding 697 updates to the correspondent node, home agent, or mobility anchor 698 point. In addition, refresh, deletion, and modification of flow 699 binding entries are all discussed below. 701 5.1.1. Preferred Care-of address 703 Any node that supports this specification MUST maintain an ordered 704 list of care-of addresses for each mobile node it maintains a list of 705 flow bindings for. The ordered list of care-of addresses is built 706 based on the BID-PRI field of the binding identifier mobility option 707 (see Section 4.1). 709 The ordered list of BIDs is used to determine how to forward a packet 710 to a given mobile node when the packet does not match any of the flow 711 binding entries defined in Section 4.3. A packet that does not match 712 any of the flow binding entries SHOULD be forwarded to the care-of 713 address identified by the BID with the highest priority i.e., lowest 714 BID-PRI value. 716 5.2. Mobile Node Considerations 718 This specification allows the mobile node to maintain several 719 bindings with its mobility agent, and correspondent nodes and to 720 direct packets to different care-of addresses according to flow 721 bindings. This section details the mobile node operations necessary 722 to implement this specification. 724 The mobility agent and correspondent node list of flow bindings is 725 manipulated by the mobile node, via flow identification and flow 726 summary mobility options included in binding update messages. Each 727 flow binding update can add, modify, refresh, or delete a given 728 binding. More than one flow identification mobility options MAY be 729 included in the same binding update but each of them MUST include a 730 different FID. In other words, two flow identification options in 731 the same message can not be about the same flow binding. 733 All flow binding state MUST be refreshed in every binding update the 734 mobile node sends. Any previously registered flow binding that is 735 not included in a given binding update will be deleted. So, any flow 736 bindings that are not added or modified by a flow identification 737 mobility option, but have previously registered and need to be 738 maintained MUST be included in a flow summary mobility option. Only 739 one flow summary mobility option can be included in a given binding 740 update. 742 5.2.1. Sending BU with BID Options 744 This specification (see Section 4.1) updates the definition of the 745 binding identifier mobility option, originally defined in [RFC5648]. 746 According to this specification the BID option includes a BID-PRI 747 field assigning each registered care-of address a priority, and thus 748 placing them in an ordered list as also described in Section 4.3. 750 Mobile nodes supporting this specification MUST use the BID option 751 format defined in Section 4.1. Mobile nodes MUST also register all 752 care-of addresses using the updated BID option format, either in the 753 same BU as any flow identification mobility options using them, or in 754 earlier BUs. 756 5.2.2. Sending BU with Flow Identification Mobility Options 758 5.2.2.1. New Flow Bindings 760 When adding a new flow binding, a mobile node sends the flow 761 identification mobility option in the binding update, with the FID 762 field set to a value that is not already present in the list of flow 763 binding entries maintained by the receiver. The care-of address(es) 764 associated with each flow identification mobility options in the 765 binding update, must be logically registered by this binding update, 766 or must have already been registered by the receiver of the binding 767 update in an earlier binding update, as defined in Section 5.2.1. 769 The flow identification mobility option MUST include a unique flow 770 identifier in the FID field. The FID needs only be unique for the 771 receiver of the binding update and for the same sender, i.e. the same 772 FID can be used across different receivers of the binding update, for 773 the same sender. 775 The FID-PRI field is set to the desired unique priority of the 776 FID, defining the order of the flow binding to be added in the 777 list of flow binding entries as defined in Section 4.3. 779 The Action field is set to one of the defined action codes (see 780 Section 4.2). 782 The Status field is set to zero in all binding update messages. 784 Since this flow identification mobility option is requesting the 785 addition of a new flow binding in the list of flow bindings 786 maintained by the receiver, the mobile node MUST include exactly one 787 Traffic Selector sub-option (see Section 4.2.1.4) describing the flow 788 associated with the new flow binding. The TS Format field of the 789 Traffic Selector sub-option MUST be set to the non-zero value of the 790 format used by the mobile node. 792 The mobile node MAY also include up to one BID Reference sub-option 793 (see Section 4.2.1.3) to associate the flow binding with a given set 794 of BIDs and corresponding CoAs. Depending on the Action field of the 795 flow identification mobility option, the following rules MUST be 796 followed with respect to the binding reference sub-option: 798 - if the Action indicates 'Discard', the binding reference sub- 799 option SHOULD NOT be included. If it is included it will be 800 ignored by the receiver. 802 - if the Action indicates 'Forward', a single binding reference 803 sub-option with one or more BIDs MUST be included. 805 5.2.2.2. Updating Flow Bindings 807 Flow binding modification is essentially a process where parameters 808 associated with an existing flow binding in the list of flow binding 809 entries is replaced by parameters included in the flow identification 810 mobility option, and the same FID is maintained. With this procedure 811 the mobile node can change the action, the priority, the BID, and/or 812 the traffic selector associated with a flow binding. 814 To modify an existing flow binding the mobile node MUST send a 815 binding update with a flow identification option, with the FID field 816 set to one of the FID values already in the list of flow binding 817 entries. 819 The FID-PRI and Action fields MUST be set to the priority value 820 for the flow binding entry. 822 The Status field is set to zero since this option is in a binding 823 update. 825 The mobile node MAY include exactly one traffic selector sub-option 826 (see Section 4.2.1.4) describing the updated flow to be associated 827 with the flow binding. The mobile node MAY, however, omit the 828 traffic selector sub-option if it wants the traffic selector 829 currently associated with the flow binding entry identified by the 830 FID field to be maintained. 832 The mobile node MAY include exactly one binding reference sub-option 833 (see Section 4.2.1.3) to associate the existing flow binding with a 834 new set of CoAs. If the mobile node includes a binding reference 835 sub-option then it should follow the rules described in 836 Section 5.2.2.1. The mobile node MAY omit the binding reference sub- 837 option if it wants the BIDs currently associated with the flow 838 binding entry identified by the FID field to be maintained. 840 Note that it is also possible for the mobile node to effectively 841 modify the effect of a flow binding entry without actually changing 842 the entry itself. This can be done by changing the CoA associated 843 with a given BID, which is a process defined in detail in [RFC5648]. 845 5.2.3. Sending BU with a Flow Summary Option 847 When the mobile node sends a binding update it MUST refresh all flow 848 bindings it wants to maintain even if it does not want to change any 849 of their parameters. 851 To refresh an existing flow binding the mobile node MUST send a 852 binding update with a flow summary option. The flow summary option 853 MUST include one or more FID fields as indicated in Section 4.2.2. 854 Each FID field included MUST be set to one of the FID values already 855 in the list of flow binding entries. 857 Any flow bindings (active or inactive) that are not included in a 858 binding update will be removed from the list of flow binding entries. 860 Note that any inactive flow bindings, i.e., flow bindings without 861 associated BIDs that are marked as Inactive in the list of flow 862 binding entries (see Section 4.3), MUST also be refreshed, or 863 modified, to be maintained. If they are not included in a BU they 864 will be removed. 866 5.2.4. Removing flow bindings 868 Removal of flow binding entries is performed implicitly by omission 869 of a given FID from a binding update. 871 To remove a flow binding the MN simply sends a binding update that 872 includes flow identification and flow summary mobility options for 873 all the FIDs that need to be refreshed, modified, or added, and 874 simply omits any FIDs that need to be removed. 876 Note that a mobile node can also render a flow binding inactive by 877 removing the BIDs associated with it, without removing the flow 878 binding itself. The procedure for removing a BID is defined in 879 detail in [RFC5648]. 881 When all the BIDs associated with a flow binding are removed, the 882 flow binding MUST be marked as inactive in the list of flow binding 883 entries as shown in Section 4.3. In other words the state associated 884 with the flow binding MUST be maintained but it does no longer affect 885 the mobile node's traffic. The MN can return an inactive flow 886 binding to the active state by using the flow binding modification 887 process described in Section 5.2.2.2, to associate it again with one 888 or more valid BIDs. Remember that flow bindings indicating a 889 'Discard' action do not take BIDs and thus cannot be rendered 890 inactive. Instead these entries can only be removed by omitting 891 their FID from a subsequent BU. 893 5.2.5. Returning Home 895 This specification is compatible to the home registration procedures 896 defined in [RFC3775] and [RFC5648]. More specifically, if the mobile 897 node performs an [RFC3775] style deregistration, all of its bindings, 898 including flow bindings are deleted. If the mobile node, however, 899 performs an [RFC5648] style home registration, then the home link is 900 associated with a specific BID and so, as far as this specification 901 is concerned, it is treated as any other link associated with a given 902 BID. 904 5.2.6. Receiving Binding Acknowledgements 906 According to [RFC3775] all nodes are required to silently ignore 907 mobility options not understood while processing binding updates. As 908 such a mobile node receiving a Binding Acknowledgement in response to 909 the transmission of a binding update MUST determine if the Binding 910 Acknowledgement contains a copy of every flow identification mobility 911 options included in the binding update. A Binding Acknowledgement 912 without flow identification option(s), in response to a Binding 913 Update with flow identification mobility option, would indicate 914 inability (or unwillingness) on behalf of the source node to support 915 the extensions presented in this document. 917 If a received Binding Acknowledgement contains a copy of each flow 918 identification mobility option that was sent within the binding 919 update, the status field of each flow identification option indicates 920 the status of the flow binding on the distant node. 922 5.2.7. Return Routability Procedure 924 A mobile node may perform route optimization with correspondent nodes 925 as defined in [RFC3775]. Route optimization allows a mobile node to 926 bind a care-of address to a home address in order to allow the 927 correspondent node to direct the traffic to the current location of 928 the mobile node. Before sending a Binding Update to correspondent 929 node, the Return Routability Procedure needs to be performed between 930 the mobile node and the correspondent node. 932 This procedure is not affected by the extensions defined in this 933 document. However, since a binding update message is secured with 934 the key generated based on the home address and care-of address test, 935 a mobile node MUST NOT bind a flow to a care-of address whose keygen 936 token (see RFC3775 [RFC3775]) was not used to generate the key for 937 securing the Binding Update. This limitation prohibits the sender 938 from requesting the 'Forward' action for multiple addresses before 939 having registered each care-of address one by one. 941 5.3. HA, MAP, and CN Considerations 943 This specification allows the mobility agents (Home Agents and 944 Mobility Anchor Points), and correspondent nodes to maintain several 945 flow bindings for a given home address and to direct packets to 946 different care-of addresses according to flow bindings. This section 947 details the home agent operations necessary to implement this 948 specification. These operations are identical for MAPs and CNs 949 unless otherwise stated. 951 Note that route optimization is only defined for mobile nodes (MIPv6 952 [RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these 953 sections only apply to correspondent nodes with respect to mobile 954 nodes and not for mobile routers. 956 5.3.1. Handling Binding Identifier Mobility Options 958 This specification (see Section 4.1) updates the definition of the 959 binding identifier mobility option, originally defined in [RFC5648]. 960 According to this specification the BID option includes a BID-PRI 961 field assigning each registered care-of address a priority, and thus 962 placing them in an ordered list (see Section 4.3). 964 Home agents receiving BUs including BID options and flow 965 identification options MUST logically process BID options first. 966 This is because BID Reference sub-options included in the flow 967 identification mobility options might refer to BIDs defined in BID 968 options included in the same message. 970 The BID option is processed as defined in [RFC5648] but then the BID 971 to care-of address mapping is placed in an ordered list according to 972 the BID-PRI field of the BID option. 974 Binding Identifier registrations and deregistrations indirectly 975 affect the MN's flow binding entries. The home agent MUST update the 976 flow binding entries table accordingly as BIDs are added or removed ( 977 [RFC5648]). For example, as discussed in Section 4.3, if all of the 978 BIDs associated with a given flow binding entry are removed (i.e., 979 become invalid) the entry MUST be marked as inactive. While if any 980 of the invalid BIDs associated with an inactive flow binding entry 981 are registered (i.e., become valid), the entry MUST be marked as 982 active. 984 5.3.2. Handling Flow Identification Mobility Options 986 When the home agent receives a binding update which includes at least 987 one flow identification mobility option, it first performs the 988 operation described in section 10.3.1 of RFC3775, followed by the 989 operations defined in Section 5.3.1 of this document. 991 Home agents that do not support this specification will ignore the 992 flow identification mobility options and all their sub-options, 993 having no effect on the operation of the rest of the protocol. 995 If the binding update is accepted, and the home agent is willing to 996 support flow bindings for this MN, the home agent checks the flow 997 identification mobility options. 999 If more than one flow identification mobility option in the same BU, 1000 has the same value in the FID field, all the flow identification 1001 mobility options MUST be rejected. 1003 If all FID fields have different values the flow identification 1004 mobility options can be processed further and in any order, as 1005 defined by the following subsections. 1007 5.3.2.1. Handling new FIDs 1009 If the FID field of the flow identification mobility option is not 1010 already present in the list of flow binding entries for this mobile 1011 node, then this is a request for a new entry. 1013 If the flow identification mobility option does not include a traffic 1014 selector sub-option, the home agent MUST reject this request by 1015 copying the flow identification mobility option in the BA, and 1016 setting the Status field to the value defined in Figure 2 for "Flow 1017 identification option malformed". 1019 If the flow identification option does include a traffic selector 1020 sub-option, but the format indicated in the TS Format field is not 1021 supported, the home agent MUST reject this request by copying the 1022 flow identification mobility option in the BA, and setting the Status 1023 field to the value defined in Figure 2 for "Traffic Selector format 1024 not supported". 1026 Then the home agent MUST check the Action field in combination with 1027 the Binding Reference sub-option if present. 1029 - if the Action indicates 'Discard', 1031 Any binding reference sub-options that might be present SHOULD be 1032 ignored. 1034 The home agent SHOULD add a new entry in the mobile node's list of 1035 flow binding entries, as defined below. 1037 - if the Action indicates 'Forward", 1039 If the Binding reference sub-option is not included, the home 1040 agent MUST reject this request by copying the flow identification 1041 mobility option in the BA, and setting the Status field to the 1042 value defined for "Flow identification mobility option malformed" 1043 in Section 4.2. 1045 If the binding reference sub-option is present and includes one or 1046 more BIDs that are not present in the binding cache of the mobile 1047 node the home agent MUST reject this request by copying the flow 1048 identification option in the BA, and setting the Status field to 1049 the value defined for "BID not found" in Section 4.2. 1051 If the binding reference sub-option is present and includes one or 1052 more BIDs, and the BIDs exist in the mobile node's binding cache, 1053 the home agent SHOULD add a new entry in the mobile node's list of 1054 flow binding entries, as defined below. 1056 When the home agent decides to add an entry in the mobile node's list 1057 of flow binding entries, as discussed above, it MUST do it according 1058 to the following rules: The entry MUST be placed according to the 1059 order indicated by the FID-PRI field of the flow identification 1060 mobility option and it MUST include: 1062 the FID as a key to the entry 1064 The traffic selector included in the corresponding sub-option 1066 the action indicated in the Action field 1068 the BIDs, depending on action field, indicated in the binding 1069 reference sub-option 1071 the entry MUST be marked as Active, as shown in Section 4.3 1073 5.3.2.2. Handling known FIDs 1075 If the FID field of the flow identification mobility option is 1076 already present in the list of flow binding entries for this mobile 1077 node, then this is a request to update the existing entry. 1079 The flow binding modification is essentially a process where 1080 parameters associated with an existing flow binding entry are 1081 replaced by the parameters included in a flow identification mobility 1082 option with the same FID as the existing entry. 1084 The home agent MUST: 1086 Change the priority of the entry according to the FID-PRI field of 1087 the flow identification mobility option. 1089 Change the action associated with the entry according to the 1090 Action field of the flow identification mobility option. 1092 Since this flow identification mobility option is designed to update 1093 an existing entry it may not include a traffic selector sub-option. 1095 If a traffic selector sub-option is not included in the flow 1096 identification mobility option, then the traffic selector already 1097 associated with entry MUST be maintained, 1099 otherwise the traffic selector in the entry MUST be replaced by 1100 the traffic selector in the sub-option. 1102 Like Section 5.3.2.1, if the Action field in the flow identification 1103 mobility option is set to 'Discard' if a binding reference sub-option 1104 is included in the option, it SHOULD be ignored; and any BIDs 1105 associated with the existing flow binding entry SHOULD be removed. 1107 Unlike Section 5.3.2.1, however, if the Action field in the flow 1108 identification mobility option is set to 'Forward', and since this 1109 flow identification mobility option is designed to update an existing 1110 entry, it may not include a binding reference sub-option. 1112 If a binding reference sub-option is not included in the flow 1113 identification mobility option, then the BIDs already associated 1114 with entry MUST be maintained, 1116 otherwise the BIDs in the entry MUST be replaced by the BIDs in 1117 the sub-option. 1119 5.3.3. Handling Flow Summary Mobility Option 1121 When the home agent receives a binding update which includes a flow 1122 summary mobility option, it first performs the operation described in 1123 section 10.3.1 of RFC3775. Binding update messages including more 1124 than one flow summary mobility option MUST be rejected. A de- 1125 registration binding update (with a zero lifetime) would result in 1126 deleting all bindings, including all flow bindings regardless of the 1127 presence of the flow summary mobility option. 1129 If the value of any of the FID fields included in the flow summary 1130 mobility option is not present in the list of flow binding entries 1131 for this mobile node, the home agent MUST reject this flow binding 1132 refresh by including a flow identification mobility option in the BA 1133 for each FID that is not found, and by setting the FID field to the 1134 value of the FID that is not found and the Status field to the value 1135 defined for "FID not found" in Section 4.2. 1137 If the value of the FID field is present in the mobile nodes list of 1138 flow binding entries the, home agent SHOULD refresh the flow binding 1139 entry identified by the FID without changing any of the other 1140 parameters associated with it. 1142 5.3.4. Flow Binding Removals 1144 Removal of flow bindings is performed implicitly by omission of a 1145 given FID from a binding update. 1147 When a valid binding update is received, any registered FIDs that are 1148 not explicitly referred to in a flow identification mobility option 1149 or in a flow summary mobility option, MUST be removed from the list 1150 of flow binding entries for the mobile node. 1152 5.3.5. Sending Binding Acknowledgements 1154 Upon the reception of a binding update, the home agent is required to 1155 send back a Binding Acknowledgment. The status code in the Binding 1156 Acknowledgement must be set as recommended in [RFC3775]. This status 1157 code does not give information on the success or failure of flow 1158 bindings. 1160 In order to inform the mobile node about the status of the flow 1161 binding(s) requested by a mobile node, flow identification options 1162 SHOULD be included in the Binding Acknowledgement message. 1163 Specifically, the home agent SHOULD copy each flow identification 1164 mobility option received in the binding update and set its status 1165 code to an appropriate value. If an operation requested in a flow 1166 identification option by a mobile node is performed successfully by 1167 the home agent, the status field on the copied flow identification 1168 mobility option in the BA, SHOULD be set to the value defined for 1169 "Flow binding successful" in Section 4.2, otherwise it SHOULD be set 1170 to one of the rejection codes also defined in Section 4.2. 1171 Section 5.3.2 identifies a number of cases where specific error codes 1172 should be used. 1174 Home agents that support this specification MAY refuse to maintain 1175 flow bindings by setting the status field of any flow identification 1176 mobility options to the value defined for "Administratively 1177 prohibited" in Section 4.2, or by just ignoring all the flow binding 1178 options. 1180 Note that BID options and their Status field are handled as defined 1181 in [RFC5648]. 1183 5.3.6. Packet Processing 1185 This section defines packet processing rules according to this 1186 specification. This specification does not change any of the packet 1187 interception rules defined in [RFC3775], and [RFC5555]. These rules 1188 apply to HAs, MAPs, and CNs, as part of the routing process for any 1189 packet with destination address set to a valid home address of the 1190 mobile node. For nodes other than CNs this also applies to packets 1191 with destination address set to an address under any of the 1192 registered prefixes. These rules apply equally to IPv6 packets as 1193 well as to IPv4 packets as per [RFC5555]. 1195 Before a packet is forwarded to the mobile node it MUST be matched 1196 against the ordered list of flow bindings stored in the list of flow 1197 binding entries for this mobile node (see Section 4.3). A match is 1198 attempted with the traffic selector included in the first line 1199 (highest order) of the table. If the packet matches the traffic 1200 selector, the action defined by the action parameter of the table 1201 SHOULD be performed. 1203 - if the Action indicates 'Discard', the packet is silently 1204 discarded 1206 - if the Action indicates 'Forward", a copy of the packet is 1207 forwarded to each of the care-of addresses associated with the 1208 BIDs indicated in the same line of the table. 1210 If the action indicated in one of the entries in the list of flow 1211 bindings is 'Discard' then, no BIDs need to be indicated in the same 1212 entry since the packet is not forwarded. If, however, the action 1213 indicated in an entry of the list of flow bindings is 'Forward", the 1214 entry should indicate one or more valid BIDs. For 'Forward' if any 1215 of the BIDs indicated does not correspond to a valid care-of address, 1216 e.g., the BID was deregistered then that BID has no effect on the 1217 traffic. In other words, packets matching the flow binding are 1218 forwarded to the remaining BIDs, pointing to registered care-of 1219 addresses. If none of the BIDs pointed to in a flow binding entry is 1220 valid then the entry is considered to be inactive (as defined in 1221 Section 4.3) and is skipped. In other words packets should not be 1222 matched against that entry. 1224 If a packet does not match any of the active flow binding entries for 1225 the given MN, the packet SHOULD be forwarded to the care-of address 1226 associated with the BID with the highest BID-PRI. 1228 If a packet is fragmented, only the first fragment contains all IP 1229 and transport layer headers, while subsequent fragments only contain 1230 an IP header without transport layer headers. For this reason it is 1231 possible that subsequent fragments do not match the same traffic 1232 selector as the initial fragment of such a packet. Unless specific 1233 measures are taken the likely outcome is that the initial fragment is 1234 routed as the MN intended while subsequent fragments are routed 1235 differently, and probably based on the default flow binding. HAs, 1236 MAPs, and CNs SHOULD take care to forward all fragments of a given 1237 packet the same way, and in accordance to the flow binding matching 1238 the first fragment of said packet. This should be possible given the 1239 fact that fragment headers include enough information to identify a 1240 fragment as part of a specific packet, but the details of how this is 1241 ensured are implementation specific and are not defined in this 1242 specification. 1244 6. Security considerations 1246 This draft introduces a new option that adds more granularity to the 1247 binding update message. The new option allows the mobile node to 1248 associate some flows to one interface and other flows to another 1249 interface. Since the flow identification mobility option is part of 1250 the mobility header, it uses the same security as the Binding Update, 1251 whether it is sent to a mobility agent, or to a correspondent node. 1253 7. IANA Considerations 1255 This specification requires the following IANA assignments on 1256 existing namespaces as well as the creation of some new namespaces. 1258 1) New Mobility Options [RFC3775]: This registry is available from 1259 http://www.iana.org under "Mobile IPv6 parameters". The following 1260 type numbers need to be assigned for: 1262 Flow Identification Mobility Option, define in Section 4.2 1264 Flow Summary Mobility Option, defined in Section 4.2.2 1266 2) New "Flow Identification Mobility Option Action codes" 1267 namespace needs to be created. The following 'Action' codes are 1268 defined in this specification, in Section 4.2: 1270 0 Reserved 1272 1 Discard 1274 2 Forward 1276 3-255 reserved and available for allocation based on Expert 1277 Review 1279 3) New "Flow Identification Mobility Option Status codes" 1280 namespace needs to be created. The following 'Status' codes are 1281 defined in this specification, in Section 4.2: 1283 0-127 reserved for success codes 1285 128-255 reserved for reject codes 1287 a number of specific codes have been defined in Section 4.2 1289 4) New "Flow Identification Sub-Options" namespace for the Flow 1290 Identification Mobility Option. The sub-option space is defined 1291 in Figure 3. The following Sub-option Type values are defined in 1292 this specification: 1294 0 Pad 1296 1 PadN 1298 2 BID Reference 1299 3 Traffic Selector 1301 4-255 reserved and available for allocation based on Expert 1302 Review 1304 5) New "Traffic Selector Format" namespace for the Traffic 1305 Selector sub-option. The traffic selector format space is defined 1306 by the TS Format field in Figure 5. The following values are 1307 defined in this specification: 1309 0 Reserved 1311 1-255 reserved and available for allocation based on Expert 1312 Review 1314 Similar to the procedures specified for Mobile IPv6 [RFC3775] number 1315 spaces, future allocations from the new number spaces requires Expert 1316 Review as defined i [RFC5226]. 1318 8. Contributors 1320 We would like to explicitly acknowledge the following person who co- 1321 authored one of the documents used as source material for this 1322 document. 1324 Nikolaus A. Fikouras, niko@comnets.uni-bremen.de 1326 9. Acknowledgements 1328 We would also like to acknowledge the following people in 1329 alphabetical order for their contributions to this specification: C. 1330 Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- 1331 Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. 1332 Also, Gabor Fekete for the analysis that led to the inclusion of the 1333 BIDRef sub-option, and Henrik Levkowetz for suggesting support for 1334 other ways of describing flows. 1336 10. References 1338 10.1. Normative References 1340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1341 Requirement Levels", BCP 14, RFC 2119, March 1997. 1343 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1344 in IPv6", RFC 3775, June 2004. 1346 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1347 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1348 RFC 3963, January 2005. 1350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1351 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1352 May 2008. 1354 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1355 Routers", RFC 5555, June 2009. 1357 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1358 and K. Nagami, "Multiple Care-of Addresses Registration", 1359 RFC 5648, October 2009. 1361 10.2. Informative References 1363 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1364 McManus, "Requirements for Traffic Engineering Over MPLS", 1365 RFC 2702, September 1999. 1367 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1368 RFC 3753, June 2004. 1370 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1371 Terminology", RFC 4885, July 2007. 1373 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1374 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1375 Management", RFC 5380, October 2008. 1377 Authors' Addresses 1379 Hesham Soliman 1380 Elevate Technologies 1382 Email: hesham@elevatemobile.com 1384 George Tsirtsis 1385 Qualcomm 1387 Email: tsirtsis@gmail.com 1389 Nicolas Montavont 1390 Institut Telecom / Telecom Bretagne 1391 2, rue de la chataigneraie 1392 Cesson Sevigne 35576 1393 France 1395 Phone: (+33) 2 99 12 70 23 1396 Email: nicolas.montavont@telecom-bretagne.eu 1397 URI: http://www.rennes.enst-bretagne.fr/~nmontavo// 1399 Gerardo Giaretta 1400 Qualcomm 1402 Email: gerardog@qualcomm.com 1404 Koojana Kuladinithi 1405 University of Bremen 1406 ComNets-ikom,University of Bremen. 1407 Otto-Hahn-Allee NW 1 1408 Bremen, Bremen 28359 1409 Germany 1411 Phone: +49-421-218-8264 1412 Fax: +49-421-218-3601 1413 Email: koo@comnets.uni-bremen.de 1414 URI: http://www.comnets.uni-bremen.de/~koo/