idnits 2.17.1 draft-gundavelli-mip4-multiple-tunnel-support-03.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 : ---------------------------------------------------------------------------- == 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 (July 12, 2010) is 5034 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 1117, but no explicit reference was found in the text == Unused Reference: 'RFC3024' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'RFC3519' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mext-flow-binding' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC5177' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC5648' is defined on line 1162, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-05) exists of draft-ietf-mext-binary-ts-04 == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-06 Summary: 2 errors (**), 0 flaws (~~), 10 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: January 13, 2011 G. Tsirtsis 6 Qualcomm 7 H. Soliman 8 Elevate Technologies 9 A. Petrescu 10 CEA LIST 11 July 12, 2010 13 Flow Binding Support for Mobile IPv4 14 draft-gundavelli-mip4-multiple-tunnel-support-03.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 to IETF 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), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 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 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 13, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 71 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Alternate-CoA Extension . . . . . . . . . . . . . . . . . 5 76 4.2. Flow Identification Extension . . . . . . . . . . . . . . 7 77 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16 78 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 17 79 5.1.1. Using the Alternate-CoA extension . . . . . . . . . . 17 80 5.1.2. Using the Flow Identification Extension . . . . . . . 18 81 5.2. Home Agent Considerations . . . . . . . . . . . . . . . . 19 82 5.2.1. Handling Alternate-CoA extensions . . . . . . . . . . 19 83 5.2.2. Handling Flow Identification Extensions . . . . . . . 20 84 6. Routing Considerations . . . . . . . . . . . . . . . . . . . . 23 85 7. Protocol Configuration Variables . . . . . . . . . . . . . . . 23 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 94 1. Introduction 96 With the ubiquitous availability of wireless networks supporting 97 different access technologies, mobile devices are now equipped with 98 multiple wireless interfaces and have the ability to connect to the 99 network over any of those interfaces and access the network. It is 100 desirable for the mobile node to leverage all the available network 101 connections for accessing network services. 103 The operation defined in the Mobile IP Protocol [RFC3344], allows a 104 mobile node to continue to use its home address as it moves around 105 the internet. Based on the mode of operation, there will be a tunnel 106 that will be set up between the home agent and the mobile node, or 107 between the home agent and the foreign agent where the mobile node is 108 attached. In both of these modes, there will only be one interface 109 on the mobile node that is receiving the traffic from the home agent. 110 However, this is not efficient and requires an approach where the 111 mobile node can use more than one interfaces for reaching the home 112 network. The objective being efficient use of all available links to 113 obtain higher aggregated bandwidth for the tunneled traffic between 114 the home agent and the mobile node. 116 This specification defines extensions to Mobile IPv4 protocol for 117 allowing a mobile node with multiple interfaces to register a care-of 118 address for each of its network interfaces and to simultaneously 119 establish multiple Mobile IP tunnels with its home agent. 120 Furthermore, this specification also defines extensions to allow the 121 mobile node and the home agent to optionally negotiate flow policies 122 for binding individual traffic flows with the registered care-of 123 addresses. 125 2. Conventions & Terminology 127 2.1. Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2.2. Terminology 135 All the mobility related terms used in this document are to be 136 interpreted as defined in [RFC3344] and [RFC3753]. In addition this 137 document uses the following terms. 139 Binding Identifier (BID) 140 It is an identifier for a specific binding of a mobile node. A 141 mobile node, when it registers multiple bindings with its home 142 agent using different care-of addresses, each of those bindings 143 are given a unique identifier and this identifier is called the 144 binding identifier. The identifier is unique within all the 145 bindings for a given mobile node. 147 Flow Identifier (FID) 149 It is an identifier for a given IP flow, uniquely identified by 150 source address, destination address, protocol type, source port 151 and destination port. 153 3. Overview 155 This document presents extensions to the Mobile IP protocol for 156 allowing a mobile node to register multiple care-of addresses over 157 which it can be reachable. Each of the registered care-of address 158 will be identified by a unique binding identifier (BID). There will 159 be multiple tunnels between the mobile node and the home agent, one 160 tunnel for each of the registed bindings. These multiple tunnel 161 paths can be used for load balancing the mobile node's home address 162 traffic based on the negotiated traffic policies. The extensions 163 specified in this document additionally allow the mobile node and the 164 home agent negotiate flow policies for binding individual traffic 165 flows to the registered care-of addresses. In the absence of any 166 negotiated traffic policies, these multiple tunnel paths appear to 167 the home agent and the mobile node as alternate routing paths and the 168 default IP forwarding behavior of per-flow load balancing will 169 leverage all the available wireless links and will result in a larger 170 aggregated egress traffic throughput. 172 HoA-1 173 | 174 +=====+ +=====+ 175 | | CoA-1 Tunnel-1 | | 176 | |---===={ WIFI }=================\ | | 177 | | \ | | 178 | | CoA-2 Tunnel-2 \ | | 179 | MN |---===={ LTE }=====================----| HA | 180 | | / | | 181 | | FA-CoA-3 Tunnel-3 / | | 182 | |---{ CDMA }---[FA]==============/ | | 183 | | | | 184 +=====+ +=====+ 185 Figure 1: Mobile Node with multiple tunnels to the home agent 187 Figure 1, illustrates a mobile node attached to the network over 188 three different access technologies, WiFI, LTE and CDMA. The mobile 189 node is assigned home address, HoA-1, has care-of addresses CoA-1, 190 CoA-2 and CoA-3 and has established tunnels Tunnel-1, Tunnel-2 and 191 Tunnel-3 with its home agent. 193 +-------+----------------------+------------------------------------+ 194 | Flow | CoA/Tunnel/BID | Negotiated Flow Policy | 195 | Id | | | 196 +-------+----------------------+------------------------------------+ 197 | 1. | CoA-1/Tunnel-1/BID-1 | All SIP Flows over WiFI | 198 | 2. | CoA-2/Tunnel-2/BID-2 | All HTTP Flows over LTE value | 199 | 3. | CoA-3/Tunnel-3/BID-3 | All SSH Flows over CDMA | 200 +-------+----------------------+------------------------------------+ 202 Table 1: Flow Binding Table 204 The above table is an example of how the individual flows are bound 205 to different care-of addresses registered with the home agent. 207 4. Message Extensions 209 This specification defines the following new extensions. 211 4.1. Alternate-CoA Extension 213 A new skippable extension to the Mobile IPv4 header in accordance to 214 the short extension format of [RFC3344] is defined here. This 215 extension is for requesting the home agent to register the care-of 216 address present in this extension as one of the alternate care- 217 addresses through which the mobile node can be reached. 219 This extension MAY be added to the Registration Request only by the 220 mobile node. This extension MUST NOT be added by the home agent or 221 by the foreign agent either to the Registration Request or to the 222 Registration Reply. There can be more than one instance of this 223 extension present in the message. 225 This extension should be protected by Mobile Home Authentication 226 extension [RFC3344]. As per Section 3.2 and 3.6.1.3 of [RFC3344], 227 the mobile node MUST place this Extension before the Mobile-Home 228 Authentication Extension in the registration messages, so that this 229 extension is integrity protected. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | Length | BID |Priority/Status| 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Care-of Address (CoA) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Interface-Type| Reserved | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: Alternate-CoA Extension 243 Type 245 Alternate-CoA Extension (skippable type range to be assigned by 246 IANA) 248 Length 250 Indicates the length (in bytes) of the extension. The length does 251 NOT include the Type and Length bytes. 253 BID (Binding ID) 255 The BID field in an 8-bit unsigned integer that identifies the 256 binding to the CoA included in this extension and it can be used 257 to point to an Alternate-CoA that was registered earlier. 259 Priority/Status 261 When this extension is in a Registration Request this field 262 specifies the priority field assigned to the care-of address. The 263 Priority field is an 8-bit unsigned integer. The receiver can 264 utilize this priority to determine the preference of the CoA used 265 to deliver packets. The lower the value the higher priority. A 266 value of 255 indicates that the CoA indicated should be 267 deregistered. 269 When this extension is in a Registration Reply this field 270 indicates the status of the CoA. The Status field is an 8-bit 271 unsigned integer. The possible status codes are listed in 272 Table 2. 274 For the Status field values 0-127 indicate success and values 275 between 128 and 255 indicate failure. The following values are 276 defined for the Status field: 278 +-------------------+--------+--------------------------------------+ 279 | Status | Value | Comments | 280 +-------------------+--------+--------------------------------------+ 281 | Accepted | 0 | The CoA is registered | 282 | BID Changed | 1 | The BID associated with an existing | 283 | | | CoA was changed to the new value | 284 | Reject | 128 | The CoA is rejected | 285 | Unknown BID | 129 | The BID was not recognized | 286 +-------------------+--------+--------------------------------------+ 288 Table 2: Values for the Alternate-CoA Status field 290 Care-Of Address (CoA) 292 The CoA field is an 32-bit ipaddr. Set to an alternative care-of 293 address to the one included in the Registration Request header. 294 This field may not be included if the extension is included in a 295 Registration Request and if the BID field is set to the BID of CoA 296 registered earlier. In addition this field may not be included if 297 the extension is included in a Registration Reply message. 299 Interface Type 301 Type of interface through which the mobile node is connected. The 302 permitted values for this are from the Access Technology Type 303 registry defined in [RFC5213]. 305 Reserved 307 This field is unused for now. The value MUST be initialized to 0 308 by the sender and MUST be ignored by the receiver. 310 4.2. Flow Identification Extension 312 A new skippable extension to the Mobile IPv4 header in accordance to 313 the short extension format of [RFC3344] is defined here. This 314 extension is included in the Registration Request and Registration 315 Reply messages. This extension contains information that allows the 316 home agent to identify a traffic flow and route it to a given 317 address. There can be more than one instance of this extension 318 present in the message. 320 This extension should be protected by Mobile Home Authentication 321 extension [RFC3344]. As per Section 3.2 and 3.6.1.3 of [RFC3344], 322 the mobile node MUST place this Extension before the Mobile-Home 323 Authentication Extension in the registration messages, so that this 324 extension is integrity protected. 326 A Flow Identification extension is designed to populate and edit a 327 mobile node classifier in the home agent. A classifier selects 328 packets based on the content of packet headers according to defined 329 rules. The Flow Identification extension defines a line in such a 330 classifier. 332 The Flow Identification extension has a flexible format that allows 333 different fields to appear in the extension based on the way the 334 mobile node chooses to represent the flow. The flags following the 335 length field indicate which of the fields used to identify the flow 336 are present in the extension. As a result, there is no fixed format 337 for the flow identification extension. This may result in slight 338 complexity in the implementation; however, this extension will 339 minimize the total length of the extension sent, which is 340 particularly important for bandwidth-limited wireless links. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | FID |Priority/Status| 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Action | F-Type | Filter Descriptor... 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | BIDs ... 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 3: Flow Identification Extension 354 Type 356 Flow Identification Extension (skippable type range. Two values 357 to be assigned for IPv4 and IPv6 by IANA) 359 Length 361 Indicates the length (in bytes) of the extension. The length does 362 NOT include the Type and Length bytes. 364 FID 366 The Flow Identifier field is an 8-bit unsigned integer identifying 367 a flow. This field is used to refer to an existing flow or to 368 identify a new flow. 370 Priority/Status 371 The Priority field is an 8-bit unsigned integer. When this 372 extension is in a Registration Request this field specifies the 373 priority field assigned to the filter rule defined by this 374 extension. The receiver can utilize this priority to determine 375 the order of application of the filter rules defined by the 376 sender. The lower the value the higher priority (i.e., it is 377 checked earlier against each packet). A value of 255 indicates 378 that the filter rule indicated should be deregistered. 380 The Status field is an 8-bit unsigned integer. When this 381 extension is in a registration reply this field indicates the 382 status of the filter rule. The possible status codes are listed 383 in Table 3. 385 For the Status field values 0-127 indicate success and values 386 between 128 and 255 indicate failure. The following values are 387 defined for the Status field: 389 +-------------------+--------+--------------------------------------+ 390 | Status | Value | Comments | 391 +-------------------+--------+--------------------------------------+ 392 | Accepted | 0 | Flow binding successful | 393 | Reject | 128 | Flow binding rejected, reason | 394 | | | unspecified. | 395 | Poorly Formed | 129 | Flow Identification extension poorly | 396 | | | formed | 397 | Admin Prohibited | 130 | Administratively prohibited | 398 | Unknown FID | 131 | The FID is not recognized | 399 | Unknown BID | 132 | A BID included in the extension is | 400 | | | not registered. | 401 +-------------------+--------+--------------------------------------+ 403 Table 3: Values for the Flow Identification Status field 405 Action 407 When this extension is in a Registration Request this field 408 specifies the action that needs to be taken by the receiver. The 409 field SHOULD be set to zero by the home agent in the registration 410 reply and SHOULD be ignored by the mobile node. See defined 411 values in Table 4. 413 The following values are reserved for the Action field. 415 +---------+-------+-------------------------------------------------+ 416 | Action | Value | Comments | 417 +---------+-------+-------------------------------------------------+ 418 | Drop | 0 | Drop matching packets. A filter rule | 419 | | | indicating a drop action MUST include a single | 420 | | | BID byte, the value of which MAY be set to 255 | 421 | | | by the sender and the value of which SHOULD be | 422 | | | ignored by the receiver. | 423 | Forward | 1 | Forward matching packets to the 1st BID in the | 424 | | | list of BIDs the filter rule is pointing to. | 425 | | | If the 1st BID becomes invalid (i.e., the | 426 | | | corresponding CoA is deregistered) use the next | 427 | | | BID in the list. | 428 | X-Cast | 2 | Forward one copy of each matching packet to the | 429 | | | list of BIDs this filter rule is pointing to. | 430 +---------+-------+-------------------------------------------------+ 432 Table 4: Values for the IPv4 and IPv6 Flow Descriptor Action field 434 F-Type 436 The Filter Type (F-Type) field identifies the type of Filter 437 Descriptor included in the extension. Filter Descriptors in 438 addition to the ones defined in this document can be defined in 439 other documents but all Filter Descriptors MUST indicate their own 440 length. 442 The following values are defined. 444 +-----------+-------+-----------------------------------------------+ 445 | F-Type | Value | Comments | 446 +-----------+-------+-----------------------------------------------+ 447 | Do not | 0 | The already registered filter for the FID of | 448 | Change | | the extension must be used | 449 | IPv4 | 1 | An IPv4 Filter Descriptor follows, see | 450 | Filter | | Figure 4 | 451 | IPv6 | 2 | An IPv6 Filter Descriptor follows, see | 452 | Filter | | Figure 5 | 453 +-----------+-------+-----------------------------------------------+ 455 Table 5 457 Filter Descriptor 459 The Filter Descriptor field defines a filter. This field is 460 further defined in Figure 4 and in Figure 5 depending on the value 461 of the F-Type field of this extension. 463 BIDs 465 Indicates the BIDs to which the Filter Rule Descriptor points to, 466 in order of appearance. Note that if a filter rule does not point 467 to any valid BIDs, the filter rule itself becomes invalid. 469 +---------+-------+-------------------------------------------------+ 470 | BID | Value | Comments | 471 +---------+-------+-------------------------------------------------+ 472 | Do not | 0 | The already registered filter for the FID of | 473 | Change | | the extension must be used | 474 | BID | 1-254 | These values point to one of BIDs registered | 475 | | | with Alternate-CoA extension, in order of | 476 | | | appearance. Multiple BID bytes can be included | 477 | | | to point to more than one BIDs | 478 | Default | 255 | the default set of BIDs, registered with | 479 | List | | Alternate-CoA extensions MUST be used | 480 +---------+-------+-------------------------------------------------+ 482 Table 6 484 If the Type field of the Flow Identification extension indicates an 485 IPv4 Flow then the Filter Rule Descriptor is as specified below. 486 This fields in the message are identical to the format specified in 487 Section 3.1 of [I-D.ietf-mext-binary-ts]. Please refer to that 488 document for parameter description. 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |A|B|C|D|E|F|G|H|I|K|L| Rsvd |Z| (A)TOS | (B)Protocol | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | (C)Source Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | (D)Destination Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | (H)Source port - High | (I)Dst port - Low | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | (K)Dst port - High | (L)SPI | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | (L)SPI | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 4: IPv4 Filter Rule Descriptor 510 Flags (A-L) 511 Each flag indicates whether the corresponding field is present in 512 the message 514 (A)TOS - Type of Service 516 The TOS field in the data packet as seen by the home agent. 518 (B)Protocol 520 An 8-bit unsigned integer representing the value of the transport 521 protocol number associated with the port numbers in data packets. 523 (C)Source Address 525 This field identifies the source address of data packets as seen 526 by the home agent that is, the 32-bit IPv4 address of the 527 correspondent node. 529 (D)Destination Address 531 This field identifies the destination address of data packets as 532 seen by the home agent. When included this field must be set to 533 one of the registered home addresses of the mobile node. It is a 534 32-bit IPv4 address. 536 (E)Source Prefix Length 538 This field includes the prefix length for the source address. 539 This field can only be included if the Source Address field is 540 included. 542 (F)Destination Prefix Length 544 This field includes the prefix length for the destination address. 545 If The Destination Address field is included then it refers to 546 that field; otherwise it refers to the home address field of the 547 Registration Request header. 549 (G)Source Port - Low 551 This field identifies the lowest source port number within a range 552 of port numbers that will be used in data packets, as seen by the 553 home agent. 555 (H)Source Port - High 556 This field identifies the highest source port number within a 557 range of port numbers that will be used in data packets, as seen 558 by the home agent. If a single port is indicated then this field 559 SHOULD NOT be included. If it is included it SHOULD be set to the 560 value of the Source Port ? Low field. 562 (I)Destination Port - Low 564 This field identifies the lowest destination port number within a 565 range of port numbers that will be used in data packets as seen by 566 the home agent. 568 (K)Destination Port - High 570 This field identifies the highest destination port number within a 571 range of port numbers that will be used in data packets as seen by 572 the home agent. If a single port is indicated then this field 573 SHOULD NOT be included. If it is included it SHOULD be set to the 574 value of the Dst Port ? Low field. 576 (L)SPI - Security Parameter Index 578 The SPI field in the data packet as seen by the home agent. 580 If the Type field of the Flow Identification extension indicates an 581 IPv6 Flow then the Filter Rule Descriptor is as as specified below. 582 The fields in the message are identical to the format specified in 583 Section 3.2 of [I-D.ietf-mext-binary-ts]. [I-D.ietf-mext-binary-ts]. 584 The descriptor format is presented below for convenience. specified 585 in [I-D.ietf-mext-binary-ts]. Its presented below for convenience. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |A|B|C|D|E|F|G|H|I|K|L|M| Rsv |Z| (A)CS | (B)Protocol | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 + + 594 | | 595 + (C)Source Address + 596 | | 597 + + 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 + + 602 | | 603 + (D)Destination Address + 604 | | 605 + + 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |(E)S. PrefLeng |(F)D. PrefLeng | (G)Source port - Low | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | (H)Source port - High | (I)Dst port - Low | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | (K)Dst port - High | (L)SPI | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | (L)SPI | (M)Flow Label | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | (M)Flow Label | 617 +-+-+-+-+-+-+-+-+ 619 Figure 5: IPv6 Filter Rule Descriptor 621 Flags (A-M) 623 Each flag indicates whether the corresponding field is present in 624 the message 626 CS - Class of Service 628 The CS field in the data packet as seen by the home agent. 630 (B)Protocol 632 An 8-bit unsigned integer representing value of the transport 633 protocol number associated with the port numbers in data packets. 635 (C)Source Address 637 This field identifies the source address of data packets as seen 638 by the home agent. That is, the address of the correspondent node 639 and it is a 128-bit IPv6 address. 641 (D)Destination Address 643 This field identifies the destination address of the data packet 644 as seen by the home agent. When included this field must be set 645 to one of the registered home addresses of the mobile node and it 646 is a 128-bit IPv6 address. 648 (E)Source Prefix Length 650 This field includes the prefix for the source address. This field 651 can only be included if the Source Address field is included . 653 (F)Destination Prefix Length 655 This field includes the prefix for the destination address. If 656 The Destination Address field is included then it refers to that 657 field otherwise it refers to the home address field of the 658 registration request header. 660 (G)Source Port - Low 662 This field identifies the lowest source port number within a range 663 of port numbers that will be used in data packets, as seen by the 664 home agent. 666 (H)Source Port - High 668 This field identifies the highest source port number within a 669 range of port numbers that will be used in data packets, as seen 670 by the home agent. If a single port is indicated then this field 671 SHOULD NOT be included. If it is included it SHOULD be set to the 672 value of the Source Port ? Low field. 674 (I)Destination Port - Low 676 This field identifies the lowest destination port number within a 677 range of port numbers that will be used in data packets as seen by 678 the home agent. 680 (K)Destination Port - High 681 This field identifies the highest destination port number within a 682 range of port numbers that will be used in data packets as seen by 683 the home agent. If a single port is indicated then this field 684 SHOULD NOT be included. If it is included it SHOULD be set to the 685 value of the Dst Port ? Low field. 687 (L)SPI - Security Parameter Index 689 The SPI field in the data packet as seen by the home agent. 691 (M)Flow Label 693 The Flow Label field in the data packet as seen by the home agent. 695 5. Protocol Operation 697 This specification allows a mobile node to register multiple CoAs 698 using the Alternate-CoA extension and associate different flows with 699 different CoAs by using the Flow Identification extension. 701 When multiple CoAs are registered without any specific flow 702 associated with them, the registered CoAs are treated as alternative 703 paths to the mobile's current location. The CoAs are ranked by the 704 Priority field in the Alternate-CoA extension and all traffic to the 705 mobile's registered HoA(s) SHOULD be sent to the CoA with the lowest 706 priority. If a CoA is deregistered, the CoA with the next lowest 707 priority SHOULD become the default path for the mobile's traffic. 709 Note that, the HA MAY be configured with a local policy that takes 710 advantage of multiple CoAs in a certain way. For example, x-casting 711 across the registered CoAs MAY be used by the HA without any further 712 signaling from the mobile; this is a configuration issue and outside 713 the scope of this document. 715 When the Flow Identification extensions are also used, however, the 716 mobile can indicate which flow is to be associated with which CoA. A 717 single flow MAY be associated with more than one CoAs, while many 718 flows MAY be associated with the same CoA. The effect of associating 719 flows with CoA ofcourse depends on the action defined for that flow. 721 The Flow Identification extension is variable length and several 722 fields might be omitted as required. When the extension is sent to 723 deregister a filter rule (Priority set to 255) only the first line of 724 Figure 3 needs to be sent (i.e., the first 4 bytes). If the priority 725 and/or action values need to be changed for an existing FID then the 726 F-Type MUST be set to 0 and one BID byte set to 0 MUST be included, 727 indicating no changes to the filter and the BIDs associated with it. 728 The Filter Descriptor of a given FID can be changed by sending the 729 extension including the new Filter Desctriptor and a single BID byte 730 set to 0. The BIDs associated with a given FID can be changed by 731 sending the extension with F-Type set to 0 (and not including a 732 Filter Descriptor). The F-Type (when not set to 0) indicates the 733 type of Filter Descriptor used. In this specification we define 734 Filter Descriptors for IPv4 and IPv6; other Filter Descriptors MAY be 735 defined in separate documents. 737 5.1. Mobile Node Considerations 739 A mobile MAY send an Alternate-CoA extension with the CoA field 740 matching the CoA field in the Mobile IP message header to check 741 whether the HA supports the extensions defined in this specification. 742 Since the extensions defined here are skippable, if the registration 743 reply does not include the Alternate-CoA extensions sent by the 744 mobile, the mobile knows that the HA does not support this 745 specification. If, however, the HA returns the Alternate-CoA 746 extensions in the reply, the HA does support this specification. 748 5.1.1. Using the Alternate-CoA extension 750 A mobile MAY include one or more Alternate-CoA extensions in each 751 Registration Request message. If the mobile has already registered a 752 CoA without using the Alternate-CoA extension and the mobile wants to 753 registered an additional CoA, the original and the new CoAs MUST be 754 sent in the new registration as Alternate-CoA extensions so that they 755 can be ranked with priorities and be associated with BIDs. In other 756 words the new message will include an Alternate-CoA with the CoA 757 field set to the CoA registered in the earlier message. 759 Unless multiple Alternate-CoA extensions are included in the same 760 Registration Request message, the different CoAs will have different 761 lifetimes associated with them. Each CoA MAY be refreshed 762 individually by sending a Registration Request with that CoA in an 763 Alternate-CoA extension. Alternatively, multiple CoAs can be 764 refreshed at the same time by sending a Registration Request with 765 multiple Alternate-CoA extensions. 767 If an earlier registered CoA is not included in a Registration 768 Request it does not mean that the CoA is deregistered. Instead CoAs 769 are deregistered when their lifetimes expire or when they are 770 explicitly deregistered by the mobile node. 772 A mobile MAY deregister any CoA by setting its priority to 255. Note 773 that the mobile can change the priority of a given CoA by sending an 774 Alternate-CoA extension with the BID field set to the BID of the CoA 775 in question, the priority field to the new value (or 255 for 776 deregistration), and without including the CoA field. 778 A mobile MAY replace the CoA associated with a given BID by sending 779 an Alternate-CoA with the BID field set to the BID of an existing CoA 780 and the priority and CoA fields to their new values. 782 5.1.2. Using the Flow Identification Extension 784 The Flow Identification extensions allow a mobile to control a mobile 785 specific classifier table present in the Home Agent memory. Each 786 Flow Identification extension defines one filter rule line in that 787 classifier, the output of which is one or more BIDs pointing to one 788 or more of the registered CoAs. 790 Each filter rule in the classifier table can be referenced by the FID 791 of the Flow Identification extension that created it. If the mobile 792 wants to change the priority of a filter rule it can send a Flow 793 Identification extension including the FID of the filter rule and 794 setting the Priority field to the new value (or 255 for 795 deregistration), and without including the Filter Rule Definition or 796 any BIDs. 798 Filter rules do not need to be refreshed explicitly. A filter rule 799 is valid as long as it points to a valid BID, i.e., a registered CoA. 800 If a filter rule does not point to any valid BIDs it will be removed. 802 Any filter rule in the classifier table can be replaced by a new 803 filter rule by sending a Flow Identification extension with the FID 804 field set to the FID of the filter rule to be replaced and the rest 805 of the extension defining the new filter rule, priority and the BIDs 806 it points to. 808 Each Flow Identification extension is ranked according to its 809 priority field. The lower the value of the priority field the higher 810 its priority (i.e., it is checked earlier against each packet). As 811 in most classifiers, filter rules with the same priority SHOULD be 812 non-overlapping, otherwise the result is undefined. Overlapping 813 filter rules SHOULD have different priorities. 815 Mobiles SHOULD define a default filter rule for traffic that does not 816 match any other rule. The default filter rule MAY be defined with a 817 Filter Identification extension with a high priority value (so it is 818 checked last) and with the Filter Descriptor with all the flags set 819 to 0 and the action field set to an appropriate value (e.g., 820 forward). Note that such a Filter Descriptor will match all packets. 822 A mobile node can use the Flow Identification extension to associate 823 a given flow with one or more of the registered CoAs. The mobile 824 MUST register its CoAs with the Alternate-CoA extension in order to 825 associate flows with them, using the BID as a handle. One or more 826 Flow Identification extensions and one or more Alternate-CoA 827 extensions MAY be present in the same message. 829 If a Flow Identification extension includes a BID field set to the 830 value 155 then the filter rule points to all the registered CoAs. 831 The order of the CoAs for such a filter rule is dictated by the 832 priority level of each BID, taken by the Priority field of the 833 Alternate-CoA used to register them. If one or more BIDs are present 834 in the Flow Identification extension then the filter rule points to 835 the specific BIDs included in the extension. Note that the list of 836 BIDs in the Flow Identification extension is ordered and its 837 significance depends on the action indicated by the action field in 838 the same extension. 840 5.2. Home Agent Considerations 842 5.2.1. Handling Alternate-CoA extensions 844 A Home Agent that supports this specification SHOULD ignore the "S" 845 flag (Simultaneous Bindings) in the Registration Request message 846 header when the same message includes Alternate-CoA extensions. In 847 other words, the mechanisms defined in this specification override 848 the mechanism defined by the "S" flag in [RFC3344]. 850 If an Alternate-CoA extension is received by an HA in a Registration 851 Request message, the HA SHOULD include a corresponding Alternate-CoA 852 extension in the registration reply message. The BID of Alternate- 853 CoA extension MUST be copied from the BID of the Alternate-CoA 854 extension in the corresponding Registration Request and the Status 855 field SHOULD be set to an appropriate value (e.g., indicating accept, 856 reject etc). 858 When a valid Registration Request message includes one or more 859 accepted Alternate-CoA extensions the HA MUST include the accepted 860 CoAs in the mobility bindings table which binds the registered home 861 address(es) with the registered CoAs together with their BIDs, 862 priorities and lifetimes. The BID and priority of a CoA is indicated 863 in the Alternate-CoA extension, while the lifetime is inherited from 864 the lifetime of the registration reply message that accepted them as 865 registered CoAs. Thus, different Alternate-CoAs will have different 866 lifetimes if they are registered with different registration request 867 messages, but they will have the same lifetime if they are included 868 in the same Registration Request. 870 The CoAs are ranked according to their priority; the lowest the value 871 of the priority field the higher their ranking. If an Alternate-CoA 872 is rejected then the HA MUST NOT include it in the mobility bindings 873 table. If the lifetime of an Alternate-CoA expires, the 874 corresponding CoA MUST be removed from the mobility bindings table. 876 If an Alternate-CoA extension is received with a BID that matches an 877 existing BID then: 879 The HA MUST check the priority field of the extension in quesiton. 880 If the priority field is set to 255 (indicating deregistration) 881 the CoA MUST be removed from the mobility bindings table and from 882 any filter rules that point to it. 884 If the priority is set to any other value, the HA MUST check the 885 CoA field of the same extension. If the CoA field is not 886 included, the priority of the CoA, identified by the BID included 887 in the extension, MUST be updated with the indicated value. 889 If the CoA field exists and matches the CoA that the BID field 890 points to in the HA mobility bindings table, the priority of that 891 CoA is again updated. 893 If the CoA field exists and is different from the CoA the BID 894 field points to in the HA mobility bindins table, the HA SHOULD 895 update its table with the new CoA and priority for that BID. 897 If an Alternate-CoA extension is received with a BID that does not 898 match an existing BID then: 900 The HA MUST check the CoA field of the extension. If the CoA 901 field is not included, the HA SHOULD include an Alternate-CoA 902 extension in the registration reply with a BID copied from the 903 corresponding extension in the request message and the Status 904 field set to "Unknown BID." 906 If the CoA field exists, the HA MUST store the BID, CoA and 907 priority values in the mobility bindings table for the mobile. 908 The CoA MUST be ranked with the other registered CoAs according to 909 the value of the priority field. 911 If the CoA field exists but it matches a CoA that is already 912 registered with a different BID the HA MAY replace the old BID 913 with the new BID and indicate a "BID changed" in the Status field 914 of the corresponding Alternate-CoA extension included in the 915 registration reply message. 917 5.2.2. Handling Flow Identification Extensions 919 If a Flow Identification extension is received by an HA in a 920 Registration Request message, the HA SHOULD include a corresponding 921 Flow Identification extension in the registration reply message. The 922 FID of the Flow Identification extension in the reply message MUST be 923 copied from the FID of the Flow Identification extension in the 924 corresponding Registration Request and the Status field SHOULD be set 925 to an appropriate value (e.g., indicating accept, reject etc). 927 When a valid Registration Request message includes one or more 928 accepted Filter Identification extensions the HA MUST include the 929 accepted filter rules in the mobile specific classifier table which 930 associates the order list of filter rules with the BIDs they point 931 to. The priority of a filter rule, the description of the filter 932 rule, the action and the BID(s) the filter rule is associated with 933 are indicated in the Flow Identification extension. 935 The filter rules are ranked according to their priority. Filter 936 rules MUST be ranked from lowest to higher priority. If a filter 937 rule is rejected then it MUST NOT included in the mobile specific 938 classifier. 940 Each filter rules in the mobile specific classifier is valid as long 941 as points to a valid BID, i.e., a registered CoA. If a filter rule 942 does not point to any valid BIDs the HA MUST remove it from the 943 mobile specific classifier. 945 If the HA receives a Flow Identification extension, it SHOULD first 946 check the FID field of that extension. 948 If the value of the FID field does not match any of the FIDs in 949 the mobile specific classifier, the HA SHOULD include the filter 950 rule described in the extension in the mobile specific classifier 951 table. The new filter rule MUST be ranked according to the 952 priority field indicated in the Flow Identification extension. 954 If a one or more BIDs are included then the filter rule MUST 955 point to the list of BIDs in the order they appear. 957 If any of the including BIDs do not match one of the registered 958 BIDs in the mobile bindings table for this mobile the HA MUST 959 disregard the Flow Identification extension and MUST return a 960 reply message with a Flow Identification extension that 961 includes the FID of the corresponding extension in the request 962 message and the Status field set to an appropriate value e.g., 963 "Unknown BID." 965 If a BID of value 255 is included, the filter rule MUST point 966 to the default list of BIDs. This is the list of BIDs in the 967 mobility bindings table for this mobile. 969 If a BID of value 0 is included the HA MUST disregard the Flow 970 Identification extension and MUST return a reply message with a 971 Flow Identification extension that includes the FID of the 972 corresponding extension in the request message and the Status 973 field set to an appropriate value e.g., "Unknown BID." 975 If the value of the FID field matches any of the FIDs in the 976 mobile specific classifier the HA SHOULD then check the priority 977 field of the Flow Identification extension. If the priority field 978 is set to 255 then the filter rule associated with the FID in the 979 Flow Identification extensions MUST be removed from the mobile 980 specific classifier table. 982 If the priority field, however, is set to a value other than 983 255 the HA SHOULD check the Filter Description field of the 984 Flow Identification extension. 986 If the Filter Description is not included (F-Type field set to 987 0) and the BID field is set to 0, the HA MUST adjust the 988 ranking of the filter rule corresponding to the FID according 989 to the priority field in the Flow Identification extension. 991 If any BIDs are also included in the Flow Identification 992 extensions then the list of BIDs associated with that filter 993 rule MUST also be replaced by the list provided in the Flow 994 Identification extension. If a BID field set to 255 is 995 included then the filter rules MUST be re-pointed to the 996 default list of BIDs registered with Alternate-CoA extensions. 998 Note a BID field set to 0 is included the BIDs list for this 999 filter rule in the mobility specific classifier table MUST NOT 1000 be changed. 1002 If the priority field, however, is set to a value other than 255 1003 and the Filter Description field is included then the HA MUST 1004 replace the corresponding filter rule in the mobile specific 1005 classifier table with the filter rule in the Flow Identification 1006 extension. 1008 If any BIDs are also included in the Flow Identification 1009 extensions then the list of BIDs associated with that filter 1010 rule MUST also be replaced by the list provided in the Flow 1011 Identification extension. If a BID field set to 255 is 1012 included then the filter rules MUST be re-pointed to the 1013 default list of BIDs registered with Alternate-CoA extensions. 1015 Note that if a BID field set to 0 is included the BIDs field, 1016 the list of BIDs this filter rule points to MUST NOT be changed 1017 from its previous configuration. 1019 6. Routing Considerations 1021 This document allows the mobility entities to optionally exchange 1022 flow policies. In the absence of negotiated traffic flow policies, 1023 this document recommends the use of per-flow load balancing. 1025 Most IP devices support the two alternative traffic load-balancing 1026 schemes, Per-flow and Per-packet load balancing. These load 1027 balancing schemes allow the forwarding device to evenly distribute 1028 traffic based on the criteria of per-packet or on a per-flow basis, 1029 across all the available equal-cost links through which a destination 1030 can be reached. The default forwarding behavior of Per-flow load 1031 balancing will ensure a given flow always takes the same path and 1032 will eliminate any packet re-ordering issues and that is critical for 1033 delay sensitive traffic. Whereas the per-destination load balancing 1034 scheme leverages all the paths much more affectively, but with the 1035 potential issue of packet re-ordering on the receiver end. A host 1036 can choose to enable any of these approaches. 1038 7. Protocol Configuration Variables 1040 The following protocol configuration variables are required for 1041 system management and these variables MUST be configurable on all the 1042 mobility entities. The configured values for these protocol 1043 variables MUST survive service restarts. 1045 EnableMultipleTunnelSupport. 1047 This flag indicates whether or not the mobility entity on which 1048 this protocol variable is configured needs to enable Multiple 1049 Tunnel support feature. This protocol variable is applicable to 1050 home agent, foreign agent and the mobile node. 1052 The default value for this flag is set to value of 1, indicating 1053 that the multiple tunnel support SHOULD be enabled. 1055 When the value for this flag is set to value of 0, multiple tunnel 1056 support SHOULD be disabled. 1058 8. IANA Considerations 1060 This document proposes two new extensions that require a type number 1061 to be assigned by IANA. 1063 Section 4.1 defines a new Mobile IP extension, the Alternate-CoA 1064 Extension. Its a skippable extension to the Mobile IPv4 header in 1065 accordance to the short extension format of [RFC3344]. The type 1066 number for this extension needs to be assigned by IANA. 1068 Section 4.2 defines a new Mobile IP extension, the Flow 1069 Identification Extension. Its a skippable extension to the Mobile 1070 IPv4 header in accordance to the short extension format of [RFC3344]. 1071 The type number for this extension needs to be assigned by IANA. 1073 9. Security Considerations 1075 This specification allows a mobile node to establish multiple tunnels 1076 with the home agent, by registering a care-of address for each of its 1077 active roaming interfaces. This essentially allows the mobile node's 1078 home address to be reachable through all of its active and registered 1079 roaming interfaces. This specification also allows the mobile node 1080 to bind traffic flows to the registered care-of addresses. This new 1081 capability has no impact on the protocol security. 1083 The Mobile IP message extensions, defined in this document are to be 1084 carried in Mobile IP Registration messages and these messages are 1085 authenticated and integrity protected as described in [RFC3344]. 1087 Therefore, this specification does not weaken the security of Mobile 1088 IP Protocol, or, introduce any new vulnerabilities. 1090 10. Contributors 1092 This document reflects discussions and contributions from the 1093 following people: 1095 Srinivasa Kanduru 1097 skanduru@gmail.com 1099 Vince Park 1101 vpark@qualcomm.com 1103 11. Acknowledgements 1105 We like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui 1106 Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen 1107 and Antti Makela for their review and comments on this draft. 1109 12. References 1111 12.1. Normative References 1113 [RFC2119] Bradner, S., "Key words for use in RFCs 1114 to Indicate Requirement Levels", 1115 BCP 14, RFC 2119, March 1997. 1117 [RFC2784] Farinacci, D., Li, T., Hanks, S., 1118 Meyer, D., and P. Traina, "Generic 1119 Routing Encapsulation (GRE)", RFC 2784, 1120 March 2000. 1122 [RFC3024] Montenegro, G., "Reverse Tunneling for 1123 Mobile IP, revised", RFC 3024, 1124 January 2001. 1126 [RFC3344] Perkins, C., "IP Mobility Support for 1127 IPv4", RFC 3344, August 2002. 1129 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile 1130 IP Traversal of Network Address 1131 Translation (NAT) Devices", RFC 3519, 1132 April 2003. 1134 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, 1135 V., Chowdhury, K., and B. Patil, "Proxy 1136 Mobile IPv6", RFC 5213, August 2008. 1138 12.2. Informative References 1140 [I-D.ietf-mext-binary-ts] Tsirtsis, G., Giaretta, G., Soliman, 1141 H., and N. Montavont, "Traffic 1142 Selectors for Flow Bindings", 1143 draft-ietf-mext-binary-ts-04 (work in 1144 progress), February 2010. 1146 [I-D.ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, 1147 N., Giaretta, G., and K. Kuladinithi, 1148 "Flow Bindings in Mobile IPv6 and NEMO 1149 Basic Support", 1150 draft-ietf-mext-flow-binding-06 (work 1151 in progress), March 2010. 1153 [RFC3753] Manner, J. and M. Kojo, "Mobility 1154 Related Terminology", RFC 3753, 1155 June 2004. 1157 [RFC5177] Leung, K., Dommety, G., Narayanan, V., 1158 and A. Petrescu, "Network Mobility 1159 (NEMO) Extensions for Mobile IPv4", 1160 RFC 5177, April 2008. 1162 [RFC5648] Wakikawa, R., Devarapalli, V., 1163 Tsirtsis, G., Ernst, T., and K. Nagami, 1164 "Multiple Care-of Addresses 1165 Registration", RFC 5648, October 2009. 1167 Authors' Addresses 1169 Sri Gundavelli (editor) 1170 Cisco 1171 170 West Tasman Drive 1172 San Jose, CA 95134 1173 USA 1175 EMail: sgundave@cisco.com 1177 Kent Leung 1178 Cisco 1179 170 West Tasman Drive 1180 San Jose, CA 95134 1181 USA 1183 EMail: kleung@cisco.com 1185 George Tsirtsis 1186 Qualcomm 1188 EMail: tsirtsis@qualcomm.com 1190 Hesham Soliman 1191 Elevate Technologies 1193 EMail: hesham@elevatemobile.com 1194 Alexandru Petrescu 1195 CEA LIST 1196 Communicating Systems Laboratory, Point Courrier 94 1197 Gif-sur-Yvette F-91191 1198 France 1200 Phone: +33 169089223 1201 EMail: alexandru.petrescu@cea.fr