idnits 2.17.1 draft-ietf-mip4-multiple-tunnel-support-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2013) is 4075 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) == Unused Reference: 'RFC2784' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'RFC3024' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'RFC3519' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC5177' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RFC5648' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'RFC6089' is defined on line 1143, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IPv4 Working Group S. Gundavelli, Ed. 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: August 4, 2013 G. Tsirtsis 6 Qualcomm 7 H. Soliman 8 Elevate Technologies 9 A. Petrescu 10 CEA LIST 11 January 31, 2013 13 Flow Binding Support for Mobile IPv4 14 draft-ietf-mip4-multiple-tunnel-support-05.txt 16 Abstract 18 This specification defines extensions to Mobile IPv4 protocol for 19 allowing a mobile node with multiple interfaces to register a care-of 20 address for each of its network interfaces and to simultaneously 21 establish multiple Mobile IP tunnels with its home agent. This 22 essentially allows the mobile node to utilize all the available 23 network interfaces and build an higher aggregated data pipe with the 24 home agent for its home address traffic. Furthermore, these 25 extensions also allow the mobile node and the home agent to negotiate 26 flow policies for binding individual traffic flows with the 27 registered care-of addresses. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 4, 2013. 46 Copyright Notice 48 Copyright (c) 2013 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 Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 65 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Alternate-CoA Extension . . . . . . . . . . . . . . . . . 5 70 4.2. Flow Identification Extension . . . . . . . . . . . . . . 7 71 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16 72 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 17 73 5.1.1. Using the Alternate-CoA extension . . . . . . . . . . 17 74 5.1.2. Using the Flow Identification Extension . . . . . . . 18 75 5.2. Home Agent Considerations . . . . . . . . . . . . . . . . 19 76 5.2.1. Handling Alternate-CoA extensions . . . . . . . . . . 19 77 5.2.2. Handling Flow Identification Extensions . . . . . . . 20 78 6. Routing Considerations . . . . . . . . . . . . . . . . . . . . 23 79 7. Protocol Configuration Variables . . . . . . . . . . . . . . . 23 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 With the ubiquitous availability of wireless networks supporting 91 different access technologies, mobile devices are now equipped with 92 multiple wireless interfaces and have the ability to connect to the 93 network over any of those interfaces and access the network. It is 94 desirable for the mobile node to leverage all the available network 95 connections for accessing network services. 97 The operation defined in the Mobile IP Protocol [RFC5944], allows a 98 mobile node to continue to use its home address as it moves around 99 the internet. Based on the mode of operation, there will be a tunnel 100 that will be set up between the home agent and the mobile node, or 101 between the home agent and the foreign agent where the mobile node is 102 attached. In both of these modes, there will only be one interface 103 on the mobile node that is receiving the traffic from the home agent. 104 However, this is not efficient and requires an approach where the 105 mobile node can use more than one interfaces for reaching the home 106 network. The objective being efficient use of all available links to 107 obtain higher aggregated bandwidth for the tunneled traffic between 108 the home agent and the mobile node. 110 This specification defines extensions to Mobile IPv4 protocol for 111 allowing a mobile node with multiple interfaces to register a care-of 112 address for each of its network interfaces and to simultaneously 113 establish multiple Mobile IP tunnels with its home agent. 114 Furthermore, this specification also defines extensions to allow the 115 mobile node and the home agent to optionally negotiate flow policies 116 for binding individual traffic flows with the registered care-of 117 addresses. 119 2. Conventions & Terminology 121 2.1. Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2.2. Terminology 129 All the mobility related terms used in this document are to be 130 interpreted as defined in [RFC5944] and [RFC3753]. In addition this 131 document uses the following terms. 133 Binding Identifier (BID) 134 It is an identifier for a specific binding of a mobile node. A 135 mobile node, when it registers multiple bindings with its home 136 agent using different care-of addresses, each of those bindings 137 are given a unique identifier and this identifier is called the 138 binding identifier. The identifier is unique within all the 139 bindings for a given mobile node. 141 Flow Identifier (FID) 143 It is an identifier for a given IP flow, uniquely identified by 144 source address, destination address, protocol type, source port 145 and destination port. 147 3. Overview 149 This document presents extensions to the Mobile IP protocol for 150 allowing a mobile node to register multiple care-of addresses over 151 which it can be reachable. Each of the registered care-of address 152 will be identified by a unique binding identifier (BID). There will 153 be multiple tunnels between the mobile node and the home agent, one 154 tunnel for each of the registed bindings. These multiple tunnel 155 paths can be used for load balancing the mobile node's home address 156 traffic based on the negotiated traffic policies. The extensions 157 specified in this document additionally allow the mobile node and the 158 home agent negotiate flow policies for binding individual traffic 159 flows to the registered care-of addresses. In the absence of any 160 negotiated traffic policies, these multiple tunnel paths appear to 161 the home agent and the mobile node as alternate routing paths and the 162 default IP forwarding behavior of per-flow load balancing will 163 leverage all the available wireless links and will result in a larger 164 aggregated egress traffic throughput. 166 HoA-1 167 | 168 +=====+ +=====+ 169 | | CoA-1 Tunnel-1 | | 170 | |---===={ WIFI }=================\ | | 171 | | \ | | 172 | | CoA-2 Tunnel-2 \ | | 173 | MN |---===={ LTE }=====================----| HA | 174 | | / | | 175 | | FA-CoA-3 Tunnel-3 / | | 176 | |---{ CDMA }---[FA]==============/ | | 177 | | | | 178 +=====+ +=====+ 179 Figure 1: Mobile Node with multiple tunnels to the home agent 181 Figure 1, illustrates a mobile node attached to the network over 182 three different access technologies, WiFI, LTE and CDMA. The mobile 183 node is assigned home address, HoA-1, has care-of addresses CoA-1, 184 CoA-2 and CoA-3 and has established tunnels Tunnel-1, Tunnel-2 and 185 Tunnel-3 with its home agent. 187 +-------+----------------------+------------------------------------+ 188 | Flow | CoA/Tunnel/BID | Negotiated Flow Policy | 189 | Id | | | 190 +-------+----------------------+------------------------------------+ 191 | 1. | CoA-1/Tunnel-1/BID-1 | All SIP Flows over WiFI | 192 | 2. | CoA-2/Tunnel-2/BID-2 | All HTTP Flows over LTE value | 193 | 3. | CoA-3/Tunnel-3/BID-3 | All SSH Flows over CDMA | 194 +-------+----------------------+------------------------------------+ 196 Table 1: Flow Binding Table 198 The above table is an example of how the individual flows are bound 199 to different care-of addresses registered with the home agent. 201 4. Message Extensions 203 This specification defines the following new extensions. 205 4.1. Alternate-CoA Extension 207 A new skippable extension to the Mobile IPv4 header in accordance to 208 the short extension format of [RFC5944] is defined here. This 209 extension is for requesting the home agent to register the care-of 210 address present in this extension as one of the alternate care- 211 addresses through which the mobile node can be reached. 213 This extension MAY be added to the Registration Request only by the 214 mobile node. This extension MUST NOT be added by the home agent or 215 by the foreign agent either to the Registration Request or to the 216 Registration Reply. There can be more than one instance of this 217 extension present in the message. 219 This extension should be protected by Mobile Home Authentication 220 extension [RFC5944]. As per Section 3.2 and 3.6.1.3 of [RFC5944], 221 the mobile node MUST place this Extension before the Mobile-Home 222 Authentication Extension in the registration messages, so that this 223 extension is integrity protected. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | BID |Priority/Status| 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Care-of Address (CoA) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Interface-Type| Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: Alternate-CoA Extension 237 Type 239 Alternate-CoA Extension (skippable type range to be assigned by 240 IANA) 242 Length 244 Indicates the length (in bytes) of the extension. The length does 245 NOT include the Type and Length bytes. 247 BID (Binding ID) 249 The BID field in an 8-bit unsigned integer that identifies the 250 binding to the CoA included in this extension and it can be used 251 to point to an Alternate-CoA that was registered earlier. 253 Priority/Status 255 When this extension is in a Registration Request this field 256 specifies the priority field assigned to the care-of address. The 257 Priority field is an 8-bit unsigned integer. The receiver can 258 utilize this priority to determine the preference of the CoA used 259 to deliver packets. The lower the value the higher priority. A 260 value of 255 indicates that the CoA indicated should be 261 deregistered. 263 When this extension is in a Registration Reply this field 264 indicates the status of the CoA. The Status field is an 8-bit 265 unsigned integer. The possible status codes are listed in 266 Table 2. 268 For the Status field values 0-127 indicate success and values 269 between 128 and 255 indicate failure. The following values are 270 defined for the Status field: 272 +-------------------+--------+--------------------------------------+ 273 | Status | Value | Comments | 274 +-------------------+--------+--------------------------------------+ 275 | Accepted | 0 | The CoA is registered | 276 | BID Changed | 1 | The BID associated with an existing | 277 | | | CoA was changed to the new value | 278 | Reject | 128 | The CoA is rejected | 279 | Unknown BID | 129 | The BID was not recognized | 280 +-------------------+--------+--------------------------------------+ 282 Table 2: Values for the Alternate-CoA Status field 284 Care-Of Address (CoA) 286 The CoA field is an 32-bit ipaddr. Set to an alternative care-of 287 address to the one included in the Registration Request header. 288 This field may not be included if the extension is included in a 289 Registration Request and if the BID field is set to the BID of CoA 290 registered earlier. In addition this field may not be included if 291 the extension is included in a Registration Reply message. 293 Interface Type 295 Type of interface through which the mobile node is connected. The 296 permitted values for this are from the Access Technology Type 297 registry defined in [RFC5213]. 299 Reserved 301 This field is unused for now. The value MUST be initialized to 0 302 by the sender and MUST be ignored by the receiver. 304 4.2. Flow Identification Extension 306 A new skippable extension to the Mobile IPv4 header in accordance to 307 the short extension format of [RFC5944] is defined here. This 308 extension is included in the Registration Request and Registration 309 Reply messages. This extension contains information that allows the 310 home agent to identify a traffic flow and route it to a given 311 address. There can be more than one instance of this extension 312 present in the message. 314 This extension should be protected by Mobile Home Authentication 315 extension [RFC5944]. As per Section 3.2 and 3.6.1.3 of [RFC5944], 316 the mobile node MUST place this Extension before the Mobile-Home 317 Authentication Extension in the registration messages, so that this 318 extension is integrity protected. 320 A Flow Identification extension is designed to populate and edit a 321 mobile node classifier in the home agent. A classifier selects 322 packets based on the content of packet headers according to defined 323 rules. The Flow Identification extension defines a line in such a 324 classifier. 326 The Flow Identification extension has a flexible format that allows 327 different fields to appear in the extension based on the way the 328 mobile node chooses to represent the flow. The flags following the 329 length field indicate which of the fields used to identify the flow 330 are present in the extension. As a result, there is no fixed format 331 for the flow identification extension. This may result in slight 332 complexity in the implementation; however, this extension will 333 minimize the total length of the extension sent, which is 334 particularly important for bandwidth-limited wireless links. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | FID |Priority/Status| 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Action | F-Type | Filter Descriptor... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | BIDs ... 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 3: Flow Identification Extension 348 Type 350 Flow Identification Extension (skippable type range. Two values 351 to be assigned for IPv4 and IPv6 by IANA) 353 Length 355 Indicates the length (in bytes) of the extension. The length does 356 NOT include the Type and Length bytes. 358 FID 360 The Flow Identifier field is an 8-bit unsigned integer identifying 361 a flow. This field is used to refer to an existing flow or to 362 identify a new flow. 364 Priority/Status 365 The Priority field is an 8-bit unsigned integer. When this 366 extension is in a Registration Request this field specifies the 367 priority field assigned to the filter rule defined by this 368 extension. The receiver can utilize this priority to determine 369 the order of application of the filter rules defined by the 370 sender. The lower the value the higher priority (i.e., it is 371 checked earlier against each packet). A value of 255 indicates 372 that the filter rule indicated should be deregistered. 374 The Status field is an 8-bit unsigned integer. When this 375 extension is in a registration reply this field indicates the 376 status of the filter rule. The possible status codes are listed 377 in Table 3. 379 For the Status field values 0-127 indicate success and values 380 between 128 and 255 indicate failure. The following values are 381 defined for the Status field: 383 +-------------------+--------+--------------------------------------+ 384 | Status | Value | Comments | 385 +-------------------+--------+--------------------------------------+ 386 | Accepted | 0 | Flow binding successful | 387 | Reject | 128 | Flow binding rejected, reason | 388 | | | unspecified. | 389 | Poorly Formed | 129 | Flow Identification extension poorly | 390 | | | formed | 391 | Admin Prohibited | 130 | Administratively prohibited | 392 | Unknown FID | 131 | The FID is not recognized | 393 | Unknown BID | 132 | A BID included in the extension is | 394 | | | not registered. | 395 +-------------------+--------+--------------------------------------+ 397 Table 3: Values for the Flow Identification Status field 399 Action 401 When this extension is in a Registration Request this field 402 specifies the action that needs to be taken by the receiver. The 403 field SHOULD be set to zero by the home agent in the registration 404 reply and SHOULD be ignored by the mobile node. See defined 405 values in Table 4. 407 The following values are reserved for the Action field. 409 +---------+-------+-------------------------------------------------+ 410 | Action | Value | Comments | 411 +---------+-------+-------------------------------------------------+ 412 | Drop | 0 | Drop matching packets. A filter rule | 413 | | | indicating a drop action MUST include a single | 414 | | | BID byte, the value of which MAY be set to 255 | 415 | | | by the sender and the value of which SHOULD be | 416 | | | ignored by the receiver. | 417 | Forward | 1 | Forward matching packets to the 1st BID in the | 418 | | | list of BIDs the filter rule is pointing to. | 419 | | | If the 1st BID becomes invalid (i.e., the | 420 | | | corresponding CoA is deregistered) use the next | 421 | | | BID in the list. | 422 | X-Cast | 2 | Forward one copy of each matching packet to the | 423 | | | list of BIDs this filter rule is pointing to. | 424 +---------+-------+-------------------------------------------------+ 426 Table 4: Values for the IPv4 and IPv6 Flow Descriptor Action field 428 F-Type 430 The Filter Type (F-Type) field identifies the type of Filter 431 Descriptor included in the extension. Filter Descriptors in 432 addition to the ones defined in this document can be defined in 433 other documents but all Filter Descriptors MUST indicate their own 434 length. 436 The following values are defined. 438 +-----------+-------+-----------------------------------------------+ 439 | F-Type | Value | Comments | 440 +-----------+-------+-----------------------------------------------+ 441 | Do not | 0 | The already registered filter for the FID of | 442 | Change | | the extension must be used | 443 | IPv4 | 1 | An IPv4 Filter Descriptor follows, see | 444 | Filter | | Figure 4 | 445 | IPv6 | 2 | An IPv6 Filter Descriptor follows, see | 446 | Filter | | Figure 5 | 447 +-----------+-------+-----------------------------------------------+ 449 Table 5 451 Filter Descriptor 453 The Filter Descriptor field defines a filter. This field is 454 further defined in Figure 4 and in Figure 5 depending on the value 455 of the F-Type field of this extension. 457 BIDs 459 Indicates the BIDs to which the Filter Rule Descriptor points to, 460 in order of appearance. Note that if a filter rule does not point 461 to any valid BIDs, the filter rule itself becomes invalid. 463 +---------+-------+-------------------------------------------------+ 464 | BID | Value | Comments | 465 +---------+-------+-------------------------------------------------+ 466 | Do not | 0 | The already registered filter for the FID of | 467 | Change | | the extension must be used | 468 | BID | 1-254 | These values point to one of BIDs registered | 469 | | | with Alternate-CoA extension, in order of | 470 | | | appearance. Multiple BID bytes can be included | 471 | | | to point to more than one BIDs | 472 | Default | 255 | the default set of BIDs, registered with | 473 | List | | Alternate-CoA extensions MUST be used | 474 +---------+-------+-------------------------------------------------+ 476 Table 6 478 If the Type field of the Flow Identification extension indicates an 479 IPv4 Flow then the Filter Rule Descriptor is as specified below. 480 This fields in the message are identical to the format specified in 481 Section 3.1 of [RFC6088]. Please refer to that document for 482 parameter description. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |A|B|C|D|E|F|G|H|I|K|L| Rsvd |Z| (A)TOS | (B)Protocol | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | (C)Source Address | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | (D)Destination Address | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | (H)Source port - High | (I)Dst port - Low | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | (K)Dst port - High | (L)SPI | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | (L)SPI | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 4: IPv4 Filter Rule Descriptor 504 Flags (A-L) 505 Each flag indicates whether the corresponding field is present in 506 the message 508 (A)TOS - Type of Service 510 The TOS field in the data packet as seen by the home agent. 512 (B)Protocol 514 An 8-bit unsigned integer representing the value of the transport 515 protocol number associated with the port numbers in data packets. 517 (C)Source Address 519 This field identifies the source address of data packets as seen 520 by the home agent that is, the 32-bit IPv4 address of the 521 correspondent node. 523 (D)Destination Address 525 This field identifies the destination address of data packets as 526 seen by the home agent. When included this field must be set to 527 one of the registered home addresses of the mobile node. It is a 528 32-bit IPv4 address. 530 (E)Source Prefix Length 532 This field includes the prefix length for the source address. 533 This field can only be included if the Source Address field is 534 included. 536 (F)Destination Prefix Length 538 This field includes the prefix length for the destination address. 539 If The Destination Address field is included then it refers to 540 that field; otherwise it refers to the home address field of the 541 Registration Request header. 543 (G)Source Port - Low 545 This field identifies the lowest source port number within a range 546 of port numbers that will be used in data packets, as seen by the 547 home agent. 549 (H)Source Port - High 550 This field identifies the highest source port number within a 551 range of port numbers that will be used in data packets, as seen 552 by the home agent. If a single port is indicated then this field 553 SHOULD NOT be included. If it is included it SHOULD be set to the 554 value of the Source Port ? Low field. 556 (I)Destination Port - Low 558 This field identifies the lowest destination port number within a 559 range of port numbers that will be used in data packets as seen by 560 the home agent. 562 (K)Destination Port - High 564 This field identifies the highest destination port number within a 565 range of port numbers that will be used in data packets as seen by 566 the home agent. If a single port is indicated then this field 567 SHOULD NOT be included. If it is included it SHOULD be set to the 568 value of the Dst Port ? Low field. 570 (L)SPI - Security Parameter Index 572 The SPI field in the data packet as seen by the home agent. 574 If the Type field of the Flow Identification extension indicates an 575 IPv6 Flow then the Filter Rule Descriptor is as as specified below. 576 The fields in the message are identical to the format specified in 577 Section 3.2 of [RFC6088]. The descriptor format is presented below 578 for convenience. 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |A|B|C|D|E|F|G|H|I|K|L|M| Rsv |Z| (A)CS | (B)Protocol | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | | 586 + + 587 | | 588 + (C)Source Address + 589 | | 590 + + 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 + + 595 | | 596 + (D)Destination Address + 597 | | 598 + + 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | (H)Source port - High | (I)Dst port - Low | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | (K)Dst port - High | (L)SPI | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | (L)SPI | (M)Flow Label | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | (M)Flow Label | 610 +-+-+-+-+-+-+-+-+ 612 Figure 5: IPv6 Filter Rule Descriptor 614 Flags (A-M) 616 Each flag indicates whether the corresponding field is present in 617 the message 619 CS - Class of Service 621 The CS field in the data packet as seen by the home agent. 623 (B)Protocol 625 An 8-bit unsigned integer representing value of the transport 626 protocol number associated with the port numbers in data packets. 628 (C)Source Address 630 This field identifies the source address of data packets as seen 631 by the home agent. That is, the address of the correspondent node 632 and it is a 128-bit IPv6 address. 634 (D)Destination Address 636 This field identifies the destination address of the data packet 637 as seen by the home agent. When included this field must be set 638 to one of the registered home addresses of the mobile node and it 639 is a 128-bit IPv6 address. 641 (E)Source Prefix Length 643 This field includes the prefix for the source address. This field 644 can only be included if the Source Address field is included . 646 (F)Destination Prefix Length 648 This field includes the prefix for the destination address. If 649 The Destination Address field is included then it refers to that 650 field otherwise it refers to the home address field of the 651 registration request header. 653 (G)Source Port - Low 655 This field identifies the lowest source port number within a range 656 of port numbers that will be used in data packets, as seen by the 657 home agent. 659 (H)Source Port - High 661 This field identifies the highest source port number within a 662 range of port numbers that will be used in data packets, as seen 663 by the home agent. If a single port is indicated then this field 664 SHOULD NOT be included. If it is included it SHOULD be set to the 665 value of the Source Port ? Low field. 667 (I)Destination Port - Low 669 This field identifies the lowest destination port number within a 670 range of port numbers that will be used in data packets as seen by 671 the home agent. 673 (K)Destination Port - High 674 This field identifies the highest destination port number within a 675 range of port numbers that will be used in data packets as seen by 676 the home agent. If a single port is indicated then this field 677 SHOULD NOT be included. If it is included it SHOULD be set to the 678 value of the Dst Port ? Low field. 680 (L)SPI - Security Parameter Index 682 The SPI field in the data packet as seen by the home agent. 684 (M)Flow Label 686 The Flow Label field in the data packet as seen by the home agent. 688 5. Protocol Operation 690 This specification allows a mobile node to register multiple CoAs 691 using the Alternate-CoA extension and associate different flows with 692 different CoAs by using the Flow Identification extension. 694 When multiple CoAs are registered without any specific flow 695 associated with them, the registered CoAs are treated as alternative 696 paths to the mobile's current location. The CoAs are ranked by the 697 Priority field in the Alternate-CoA extension and all traffic to the 698 mobile's registered HoA(s) SHOULD be sent to the CoA with the lowest 699 priority. If a CoA is deregistered, the CoA with the next lowest 700 priority SHOULD become the default path for the mobile's traffic. 702 Note that, the HA MAY be configured with a local policy that takes 703 advantage of multiple CoAs in a certain way. For example, x-casting 704 across the registered CoAs MAY be used by the HA without any further 705 signaling from the mobile; this is a configuration issue and outside 706 the scope of this document. 708 When the Flow Identification extensions are also used, however, the 709 mobile can indicate which flow is to be associated with which CoA. A 710 single flow MAY be associated with more than one CoAs, while many 711 flows MAY be associated with the same CoA. The effect of associating 712 flows with CoA ofcourse depends on the action defined for that flow. 714 The Flow Identification extension is variable length and several 715 fields might be omitted as required. When the extension is sent to 716 deregister a filter rule (Priority set to 255) only the first line of 717 Figure 3 needs to be sent (i.e., the first 4 bytes). If the priority 718 and/or action values need to be changed for an existing FID then the 719 F-Type MUST be set to 0 and one BID byte set to 0 MUST be included, 720 indicating no changes to the filter and the BIDs associated with it. 721 The Filter Descriptor of a given FID can be changed by sending the 722 extension including the new Filter Desctriptor and a single BID byte 723 set to 0. The BIDs associated with a given FID can be changed by 724 sending the extension with F-Type set to 0 (and not including a 725 Filter Descriptor). The F-Type (when not set to 0) indicates the 726 type of Filter Descriptor used. In this specification we define 727 Filter Descriptors for IPv4 and IPv6; other Filter Descriptors MAY be 728 defined in separate documents. 730 5.1. Mobile Node Considerations 732 A mobile MAY send an Alternate-CoA extension with the CoA field 733 matching the CoA field in the Mobile IP message header to check 734 whether the HA supports the extensions defined in this specification. 735 Since the extensions defined here are skippable, if the registration 736 reply does not include the Alternate-CoA extensions sent by the 737 mobile, the mobile knows that the HA does not support this 738 specification. If, however, the HA returns the Alternate-CoA 739 extensions in the reply, the HA does support this specification. 741 5.1.1. Using the Alternate-CoA extension 743 A mobile MAY include one or more Alternate-CoA extensions in each 744 Registration Request message. If the mobile has already registered a 745 CoA without using the Alternate-CoA extension and the mobile wants to 746 registered an additional CoA, the original and the new CoAs MUST be 747 sent in the new registration as Alternate-CoA extensions so that they 748 can be ranked with priorities and be associated with BIDs. In other 749 words the new message will include an Alternate-CoA with the CoA 750 field set to the CoA registered in the earlier message. 752 Unless multiple Alternate-CoA extensions are included in the same 753 Registration Request message, the different CoAs will have different 754 lifetimes associated with them. Each CoA MAY be refreshed 755 individually by sending a Registration Request with that CoA in an 756 Alternate-CoA extension. Alternatively, multiple CoAs can be 757 refreshed at the same time by sending a Registration Request with 758 multiple Alternate-CoA extensions. 760 If an earlier registered CoA is not included in a Registration 761 Request it does not mean that the CoA is deregistered. Instead CoAs 762 are deregistered when their lifetimes expire or when they are 763 explicitly deregistered by the mobile node. 765 A mobile MAY deregister any CoA by setting its priority to 255. Note 766 that the mobile can change the priority of a given CoA by sending an 767 Alternate-CoA extension with the BID field set to the BID of the CoA 768 in question, the priority field to the new value (or 255 for 769 deregistration), and without including the CoA field. 771 A mobile MAY replace the CoA associated with a given BID by sending 772 an Alternate-CoA with the BID field set to the BID of an existing CoA 773 and the priority and CoA fields to their new values. 775 5.1.2. Using the Flow Identification Extension 777 The Flow Identification extensions allow a mobile to control a mobile 778 specific classifier table present in the Home Agent memory. Each 779 Flow Identification extension defines one filter rule line in that 780 classifier, the output of which is one or more BIDs pointing to one 781 or more of the registered CoAs. 783 Each filter rule in the classifier table can be referenced by the FID 784 of the Flow Identification extension that created it. If the mobile 785 wants to change the priority of a filter rule it can send a Flow 786 Identification extension including the FID of the filter rule and 787 setting the Priority field to the new value (or 255 for 788 deregistration), and without including the Filter Rule Definition or 789 any BIDs. 791 Filter rules do not need to be refreshed explicitly. A filter rule 792 is valid as long as it points to a valid BID, i.e., a registered CoA. 793 If a filter rule does not point to any valid BIDs it will be removed. 795 Any filter rule in the classifier table can be replaced by a new 796 filter rule by sending a Flow Identification extension with the FID 797 field set to the FID of the filter rule to be replaced and the rest 798 of the extension defining the new filter rule, priority and the BIDs 799 it points to. 801 Each Flow Identification extension is ranked according to its 802 priority field. The lower the value of the priority field the higher 803 its priority (i.e., it is checked earlier against each packet). As 804 in most classifiers, filter rules with the same priority SHOULD be 805 non-overlapping, otherwise the result is undefined. Overlapping 806 filter rules SHOULD have different priorities. 808 Mobiles SHOULD define a default filter rule for traffic that does not 809 match any other rule. The default filter rule MAY be defined with a 810 Filter Identification extension with a high priority value (so it is 811 checked last) and with the Filter Descriptor with all the flags set 812 to 0 and the action field set to an appropriate value (e.g., 813 forward). Note that such a Filter Descriptor will match all packets. 815 A mobile node can use the Flow Identification extension to associate 816 a given flow with one or more of the registered CoAs. The mobile 817 MUST register its CoAs with the Alternate-CoA extension in order to 818 associate flows with them, using the BID as a handle. One or more 819 Flow Identification extensions and one or more Alternate-CoA 820 extensions MAY be present in the same message. 822 If a Flow Identification extension includes a BID field set to the 823 value 155 then the filter rule points to all the registered CoAs. 824 The order of the CoAs for such a filter rule is dictated by the 825 priority level of each BID, taken by the Priority field of the 826 Alternate-CoA used to register them. If one or more BIDs are present 827 in the Flow Identification extension then the filter rule points to 828 the specific BIDs included in the extension. Note that the list of 829 BIDs in the Flow Identification extension is ordered and its 830 significance depends on the action indicated by the action field in 831 the same extension. 833 5.2. Home Agent Considerations 835 5.2.1. Handling Alternate-CoA extensions 837 A Home Agent that supports this specification SHOULD ignore the "S" 838 flag (Simultaneous Bindings) in the Registration Request message 839 header when the same message includes Alternate-CoA extensions. In 840 other words, the mechanisms defined in this specification override 841 the mechanism defined by the "S" flag in [RFC5944]. 843 If an Alternate-CoA extension is received by an HA in a Registration 844 Request message, the HA SHOULD include a corresponding Alternate-CoA 845 extension in the registration reply message. The BID of Alternate- 846 CoA extension MUST be copied from the BID of the Alternate-CoA 847 extension in the corresponding Registration Request and the Status 848 field SHOULD be set to an appropriate value (e.g., indicating accept, 849 reject etc). 851 When a valid Registration Request message includes one or more 852 accepted Alternate-CoA extensions the HA MUST include the accepted 853 CoAs in the mobility bindings table which binds the registered home 854 address(es) with the registered CoAs together with their BIDs, 855 priorities and lifetimes. The BID and priority of a CoA is indicated 856 in the Alternate-CoA extension, while the lifetime is inherited from 857 the lifetime of the registration reply message that accepted them as 858 registered CoAs. Thus, different Alternate-CoAs will have different 859 lifetimes if they are registered with different registration request 860 messages, but they will have the same lifetime if they are included 861 in the same Registration Request. 863 The CoAs are ranked according to their priority; the lowest the value 864 of the priority field the higher their ranking. If an Alternate-CoA 865 is rejected then the HA MUST NOT include it in the mobility bindings 866 table. If the lifetime of an Alternate-CoA expires, the 867 corresponding CoA MUST be removed from the mobility bindings table. 869 If an Alternate-CoA extension is received with a BID that matches an 870 existing BID then: 872 The HA MUST check the priority field of the extension in quesiton. 873 If the priority field is set to 255 (indicating deregistration) 874 the CoA MUST be removed from the mobility bindings table and from 875 any filter rules that point to it. 877 If the priority is set to any other value, the HA MUST check the 878 CoA field of the same extension. If the CoA field is not 879 included, the priority of the CoA, identified by the BID included 880 in the extension, MUST be updated with the indicated value. 882 If the CoA field exists and matches the CoA that the BID field 883 points to in the HA mobility bindings table, the priority of that 884 CoA is again updated. 886 If the CoA field exists and is different from the CoA the BID 887 field points to in the HA mobility bindins table, the HA SHOULD 888 update its table with the new CoA and priority for that BID. 890 If an Alternate-CoA extension is received with a BID that does not 891 match an existing BID then: 893 The HA MUST check the CoA field of the extension. If the CoA 894 field is not included, the HA SHOULD include an Alternate-CoA 895 extension in the registration reply with a BID copied from the 896 corresponding extension in the request message and the Status 897 field set to "Unknown BID." 899 If the CoA field exists, the HA MUST store the BID, CoA and 900 priority values in the mobility bindings table for the mobile. 901 The CoA MUST be ranked with the other registered CoAs according to 902 the value of the priority field. 904 If the CoA field exists but it matches a CoA that is already 905 registered with a different BID the HA MAY replace the old BID 906 with the new BID and indicate a "BID changed" in the Status field 907 of the corresponding Alternate-CoA extension included in the 908 registration reply message. 910 5.2.2. Handling Flow Identification Extensions 912 If a Flow Identification extension is received by an HA in a 913 Registration Request message, the HA SHOULD include a corresponding 914 Flow Identification extension in the registration reply message. The 915 FID of the Flow Identification extension in the reply message MUST be 916 copied from the FID of the Flow Identification extension in the 917 corresponding Registration Request and the Status field SHOULD be set 918 to an appropriate value (e.g., indicating accept, reject etc). 920 When a valid Registration Request message includes one or more 921 accepted Filter Identification extensions the HA MUST include the 922 accepted filter rules in the mobile specific classifier table which 923 associates the order list of filter rules with the BIDs they point 924 to. The priority of a filter rule, the description of the filter 925 rule, the action and the BID(s) the filter rule is associated with 926 are indicated in the Flow Identification extension. 928 The filter rules are ranked according to their priority. Filter 929 rules MUST be ranked from lowest to higher priority. If a filter 930 rule is rejected then it MUST NOT included in the mobile specific 931 classifier. 933 Each filter rules in the mobile specific classifier is valid as long 934 as points to a valid BID, i.e., a registered CoA. If a filter rule 935 does not point to any valid BIDs the HA MUST remove it from the 936 mobile specific classifier. 938 If the HA receives a Flow Identification extension, it SHOULD first 939 check the FID field of that extension. 941 If the value of the FID field does not match any of the FIDs in 942 the mobile specific classifier, the HA SHOULD include the filter 943 rule described in the extension in the mobile specific classifier 944 table. The new filter rule MUST be ranked according to the 945 priority field indicated in the Flow Identification extension. 947 If a one or more BIDs are included then the filter rule MUST 948 point to the list of BIDs in the order they appear. 950 If any of the including BIDs do not match one of the registered 951 BIDs in the mobile bindings table for this mobile the HA MUST 952 disregard the Flow Identification extension and MUST return a 953 reply message with a Flow Identification extension that 954 includes the FID of the corresponding extension in the request 955 message and the Status field set to an appropriate value e.g., 956 "Unknown BID." 958 If a BID of value 255 is included, the filter rule MUST point 959 to the default list of BIDs. This is the list of BIDs in the 960 mobility bindings table for this mobile. 962 If a BID of value 0 is included the HA MUST disregard the Flow 963 Identification extension and MUST return a reply message with a 964 Flow Identification extension that includes the FID of the 965 corresponding extension in the request message and the Status 966 field set to an appropriate value e.g., "Unknown BID." 968 If the value of the FID field matches any of the FIDs in the 969 mobile specific classifier the HA SHOULD then check the priority 970 field of the Flow Identification extension. If the priority field 971 is set to 255 then the filter rule associated with the FID in the 972 Flow Identification extensions MUST be removed from the mobile 973 specific classifier table. 975 If the priority field, however, is set to a value other than 976 255 the HA SHOULD check the Filter Description field of the 977 Flow Identification extension. 979 If the Filter Description is not included (F-Type field set to 980 0) and the BID field is set to 0, the HA MUST adjust the 981 ranking of the filter rule corresponding to the FID according 982 to the priority field in the Flow Identification extension. 984 If any BIDs are also included in the Flow Identification 985 extensions then the list of BIDs associated with that filter 986 rule MUST also be replaced by the list provided in the Flow 987 Identification extension. If a BID field set to 255 is 988 included then the filter rules MUST be re-pointed to the 989 default list of BIDs registered with Alternate-CoA extensions. 991 Note a BID field set to 0 is included the BIDs list for this 992 filter rule in the mobility specific classifier table MUST NOT 993 be changed. 995 If the priority field, however, is set to a value other than 255 996 and the Filter Description field is included then the HA MUST 997 replace the corresponding filter rule in the mobile specific 998 classifier table with the filter rule in the Flow Identification 999 extension. 1001 If any BIDs are also included in the Flow Identification 1002 extensions then the list of BIDs associated with that filter 1003 rule MUST also be replaced by the list provided in the Flow 1004 Identification extension. If a BID field set to 255 is 1005 included then the filter rules MUST be re-pointed to the 1006 default list of BIDs registered with Alternate-CoA extensions. 1008 Note that if a BID field set to 0 is included the BIDs field, 1009 the list of BIDs this filter rule points to MUST NOT be changed 1010 from its previous configuration. 1012 6. Routing Considerations 1014 This document allows the mobility entities to optionally exchange 1015 flow policies. In the absence of negotiated traffic flow policies, 1016 this document recommends the use of per-flow load balancing. 1018 Most IP devices support the two alternative traffic load-balancing 1019 schemes, Per-flow and Per-packet load balancing. These load 1020 balancing schemes allow the forwarding device to evenly distribute 1021 traffic based on the criteria of per-packet or on a per-flow basis, 1022 across all the available equal-cost links through which a destination 1023 can be reached. The default forwarding behavior of Per-flow load 1024 balancing will ensure a given flow always takes the same path and 1025 will eliminate any packet re-ordering issues and that is critical for 1026 delay sensitive traffic. Whereas the per-destination load balancing 1027 scheme leverages all the paths much more affectively, but with the 1028 potential issue of packet re-ordering on the receiver end. A host 1029 can choose to enable any of these approaches. 1031 7. Protocol Configuration Variables 1033 The following protocol configuration variables are required for 1034 system management and these variables MUST be configurable on all the 1035 mobility entities. The configured values for these protocol 1036 variables MUST survive service restarts. 1038 EnableMultipleTunnelSupport. 1040 This flag indicates whether or not the mobility entity on which 1041 this protocol variable is configured needs to enable Multiple 1042 Tunnel support feature. This protocol variable is applicable to 1043 home agent, foreign agent and the mobile node. 1045 The default value for this flag is set to value of 1, indicating 1046 that the multiple tunnel support SHOULD be enabled. 1048 When the value for this flag is set to value of 0, multiple tunnel 1049 support SHOULD be disabled. 1051 8. IANA Considerations 1053 This document proposes two new extensions that require a type number 1054 to be assigned by IANA. 1056 Section 4.1 defines a new Mobile IP extension, the Alternate-CoA 1057 Extension. Its a skippable extension to the Mobile IPv4 header in 1058 accordance to the short extension format of [RFC5944]. The type 1059 number for this extension needs to be assigned by IANA. 1061 Section 4.2 defines a new Mobile IP extension, the Flow 1062 Identification Extension. Its a skippable extension to the Mobile 1063 IPv4 header in accordance to the short extension format of [RFC5944]. 1064 The type number for this extension needs to be assigned by IANA. 1066 9. Security Considerations 1068 This specification allows a mobile node to establish multiple tunnels 1069 with the home agent, by registering a care-of address for each of its 1070 active roaming interfaces. This essentially allows the mobile node's 1071 home address to be reachable through all of its active and registered 1072 roaming interfaces. This specification also allows the mobile node 1073 to bind traffic flows to the registered care-of addresses. This new 1074 capability has no impact on the protocol security. 1076 The Mobile IP message extensions, defined in this document are to be 1077 carried in Mobile IP Registration messages and these messages are 1078 authenticated and integrity protected as described in [RFC5944]. 1080 Therefore, this specification does not weaken the security of Mobile 1081 IP Protocol, or, introduce any new vulnerabilities. 1083 10. Contributors 1085 This document reflects discussions and contributions from the 1086 following people: 1088 Srinivasa Kanduru 1090 skanduru@gmail.com 1092 Vince Park 1094 vpark@qualcomm.com 1096 11. Acknowledgements 1098 We like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui 1099 Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen 1100 and Antti Makela for their review and comments on this draft. 1102 12. References 1104 12.1. Normative References 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, March 1997. 1109 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1110 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1111 March 2000. 1113 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 1114 revised", RFC 3024, January 2001. 1116 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1117 Network Address Translation (NAT) Devices", RFC 3519, 1118 April 2003. 1120 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1121 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1123 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1124 RFC 5944, November 2010. 1126 12.2. Informative References 1128 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1129 RFC 3753, June 2004. 1131 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 1132 "Network Mobility (NEMO) Extensions for Mobile IPv4", 1133 RFC 5177, April 2008. 1135 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1136 and K. Nagami, "Multiple Care-of Addresses Registration", 1137 RFC 5648, October 2009. 1139 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 1140 "Traffic Selectors for Flow Bindings", RFC 6088, 1141 January 2011. 1143 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 1144 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 1145 Network Mobility (NEMO) Basic Support", RFC 6089, 1146 January 2011. 1148 Authors' Addresses 1150 Sri Gundavelli (editor) 1151 Cisco 1152 170 West Tasman Drive 1153 San Jose, CA 95134 1154 USA 1156 EMail: sgundave@cisco.com 1158 Kent Leung 1159 Cisco 1160 170 West Tasman Drive 1161 San Jose, CA 95134 1162 USA 1164 EMail: kleung@cisco.com 1166 George Tsirtsis 1167 Qualcomm 1169 EMail: tsirtsis@qualcomm.com 1171 Hesham Soliman 1172 Elevate Technologies 1174 EMail: hesham@elevatemobile.com 1176 Alexandru Petrescu 1177 CEA LIST 1178 Communicating Systems Laboratory, Point Courrier 94 1179 Gif-sur-Yvette F-91191 1180 France 1182 Phone: +33 169089223 1183 EMail: alexandru.petrescu@cea.fr