idnits 2.17.1 draft-ietf-mext-flow-binding-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '...d is unused. It MUST be initialized t...' RFC 2119 keyword, line 256: '... sender and MUST be ignored by th...' RFC 2119 keyword, line 279: '...ence sub-options MUST exist. The Bind...' RFC 2119 keyword, line 329: '...the same BU, but MUST be already known...' RFC 2119 keyword, line 346: '... option, this field MUST be set to 1....' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * 15: Remove a flow binding. This action enables a mobile node to remove the Flow Binding indicated by the FID on the targeted node. A mobile node MUST not issue a Flow Identifier with the PRO field set to 15 for a non existent FID. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2009) is 5548 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MEXT Working Group H. Soliman, Ed. 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track N. Montavont 5 Expires: August 17, 2009 GET/ENST-B 6 N. Fikouras 7 K. Kuladinithi 8 University of Bremen 9 February 13, 2009 11 Flow Bindings in Mobile IPv6 and Nemo Basic Support 12 draft-ietf-mext-flow-binding-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 17, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document introduces extensions to Mobile IPv6 and Nemo Basic 52 Support that allow nodes to bind one or more flows to a care-of 53 address. These extensions allow multihomed nodes to take full 54 advantage of the different properties associated with each of their 55 interfaces. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Flow Identification option . . . . . . . . . . . . . . . . 7 63 3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 10 64 3.3. Binding Cache and Binding Update list extensions . . . . . 11 65 4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 12 66 4.1. Interaction with the Multiple CoA bindings mechanism . . . 12 67 4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 13 68 4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 13 69 4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 13 70 4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 14 71 4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 15 72 4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15 73 4.8. Acknowledging flow identification options . . . . . . . . 15 74 5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18 76 6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 18 77 6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 18 78 6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 19 79 6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 20 80 6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 20 81 6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 6.3. Return Routability Procedure . . . . . . . . . . . . . . . 20 83 6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21 84 7. Applicability to Route Optimization . . . . . . . . . . . . . 22 85 7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22 86 8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24 87 8.1. Receiving Binding Update with the Flow Identification 88 option . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25 90 8.3. Deleting an entry in the binding cache . . . . . . . . . . 25 91 8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 26 92 9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 27 93 10. Security considerations . . . . . . . . . . . . . . . . . . . 28 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 95 12. Informative References . . . . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 98 1. Introduction 100 Mobile IPv6 (RFC3775) [RFC3775] and Nemo Basic Support (RFC3963) 101 [RFC3963] allow a mobile node / mobile router to manage its mobility 102 using the binding update message, which binds one care-of address to 103 one home address. The binding update message can be sent to the home 104 agent. In Mobile IPv6, the Binding Update can also be sent to 105 correspondent node or to a mobility anchor point (see RFC4140 106 [RFC4140]). The semantics of the binding update are limited to 107 address changes. That is, RFC3775 [RFC3775] and RFC3963 [RFC3963] do 108 not allow a mobile node / mobile router to bind more than one address 109 to the home address. Furthermore, the binding granularity is limited 110 to the address. Therefore, a mobile host cannot associate one of the 111 connections using the home address with a different care-of address. 112 In draft-ietf-monami6-multiplecoa Mobile IPv6 and Nemo Basic Support 113 are extended to allow the binding of more than one care-of address to 114 a home address. This specification extends Mobile IPv6 and Nemo 115 Basic Support to allow it to specify policies associated with each 116 binding. A policy can contain a request for a special treatment of a 117 particular flow. Hence, this specification allows a mobile node / 118 mobile router to bind a particular flow to a care-of address without 119 affecting other flows using the same home address. In addition, we 120 will see that this specification allows to bind a particular flow to 121 a particular care-of address directly with correspondent node and 122 mobility anchor point in the case of a single mobile node. 124 In this document, a flow is defined as one or more connections that 125 are identified by a flow identifier. A single connection is 126 typically identified by the source and destination IP addresses, 127 transport protocol number and the source and destination port 128 numbers. Alternatively a flow can be identified in a simpler manner 129 using the flow label field in the IPv6 header [RFC2460] or the 130 Security Parameter Index (SPI) when IPsec is used. 132 Flow bindings are useful in cases where the mobile node / mobile 133 router has more than one address, probably due to being multihomed, 134 and wants to direct certain flows to certain addresses. This may be 135 done because some flows are better suited to certain link layers or 136 simply to load balance flows between different interfaces. This 137 specification introduces the flow identifier option, which is 138 included in the binding update message and used to distribute 139 policies to the recipient of the binding update. However, this 140 document does not define the flow itself but only the action to take 141 on this flow. The flow description will be defined in another 142 document. This will allow to use the same flow description in 143 several protocols. Using the flow identifier option introduced in 144 this specification a mobile node / mobile router can bind one or more 145 flows to a care-of address while maintaining the reception of other 146 flows on another care-of address. Requesting the flow binding can be 147 decided based on local policies within the mobile node / mobile 148 router and based on the link characteristics and the types of 149 applications running at the time. Such policies are outside the 150 scope of this document. 152 It should be noted that the flow identification option can be 153 associated with any binding update, whether it is sent to a 154 correspondent node (in the case of Mobile IPv6), home agent or 155 mobility anchor point (in the case of Hierarchical Mobile IPv6). 157 In the rest of the document, the term "mobile node" is used to 158 designate either a mobile node as defined in RFC3775 [RFC3775] or a 159 mobile router as defined in RFC3963 [RFC3963] unless stated 160 otherwise. 162 2. Terminology 164 Terms used in this document are defined in [RFC3753] and 165 [I-D.ietf-nemo-terminology]. The following terms are also used in 166 this document: 168 Flow: A flow is identified as a set of data packets that are 169 exchanged between two distant hosts 171 Flow Description: A set of instructions that describes a flow. 173 Flow Identifier: Identifier of a flow binding. 175 Flow binding: A mobility binding extended with a flow identifier 176 and flow description. 178 3. Mobile IPv6 Extensions 180 This section introduces extensions to Mobile IPv6 that are necessary 181 for supporting the flow binding mechanism described in this document. 183 3.1. Flow Identification option 185 The Flow identification option is included in the binding update and 186 acknowledgement messages. This option contains information that 187 allows the receiver of a binding update to install policies on a 188 traffic flow and route it to a given address. Multiple options may 189 exist within a binding update message. The Flow identification 190 option must come with another option (that will be defined in another 191 document) that will describe the flow. This additional option is 192 called Flow Description in the remaining of this document. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Option Type | Option Len | PRI | FID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | FID | Action | Status | PRO | Res. | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Flow Description ... 203 Figure 1: The flow identification option 205 Option Type 207 TBD 209 Option Len 211 Length of option in 8-octet units 213 PRI 215 This is a 8-bit priority field to indicate the priority of a 216 particular option. This field is needed in cases where two 217 different flow descriptions in two different options overlap. 218 The priority field decides which policy should be in those 219 cases. A lower number in this field indicates a higher 220 priority. 222 FID 224 The Flow Identifier field is an 8-bit unsigned integer that 225 includes the identifier for the flow binding. This field is 226 used to refer to an existing binding or to create a new 227 binding. 229 Action 231 This field specifies the action that needs to be taken by the 232 receiver of the binding update containing the flow 233 identification option. 235 Status 237 This field indicates the success or failure of the flow binding 238 operation for the particular flow in the option. This field is 239 not relevant to the binding update message as a whole or to 240 other flow identification options. Values from 0 to 127 241 indicate success. Values of 128 and higher indicate failure. 242 This field is only relevant when included in the Binding 243 Acknowledgement message and must be ignored in the binding 244 update message. 246 PRO 248 This is a 4-bit field that describes the required processing 249 for the option. This field may indicate a request for adding, 250 deleting, modifying or refreshing the option. The details of 251 these requests are discussed below. 253 Res. 255 This field is unused. It MUST be initialized to zero by the 256 sender and MUST be ignored by the receiver. 258 The following values are reserved for the PRO field in this option: 260 0 Add a flow binding 262 1 Replace a flow binding 264 2 Refresh the current binding 266 15 Remove a flow binding 268 The following values are reserved for the Action field in this 269 option: 271 1 Forward. This value indicates a request to forward a flow to 272 the address included or referred by the option. 274 2 Discard. This value indicates a request to discard all packets 275 in the flow described by the option. 277 2 n-cast. his value indicates a request to replicate the flow to 278 several addresses. If this value is used, one or more Binding 279 Reference sub-options MUST exist. The Binding Reference sub- 280 option is described later in this specification 282 The following values are reserved for the status field within the 283 flow identification option: 285 0 Flow binding successful. 287 128 Flow binding rejected, reason unspecified. 289 129 Flow binding option poorly formed. 291 130 Administratively prohibited. 293 131 Flow identification by IPv6 prefix is not supported. 295 132 Flow identification by port numbers is not supported. 297 133 Flow identification with Flow label is not supported. 299 134 Flow identification with SPI is not supported. 301 135 FID already in use 303 136 FID not found 305 137 Classifier language not supported. 307 138 Discard function not supported. 309 139 N-cast function not supported. 311 It should be noted that per-packet load balancing has negative 312 impacts on TCP congestion avoidance mechanisms as it is desirable to 313 maintain order between packets belonging to the same TCP connection. 314 This behaviour is specified in RFC2702 [RFC2702]. Other negative 315 impacts are also foreseen for other types of real time connections 316 due to the potential variations in RTT between packets. Hence per- 317 packet load balancing is not allowed in this extension. However, the 318 MN can still request per-flow load balancing provided that the entire 319 flow is moved to the new interface. 321 3.2. The Binding Reference Sub-option 323 This section introduces the Binding Reference sub-option, which may 324 be included in the Flow identification option. The Binding Reference 325 sub-option includes one or more BIDs as defined in the MCoA document. 326 When this sub-option is included in the Flow identification option it 327 associates the flow described with one or more BIDs that where 328 already registered with the recipient of the BU. A BID sub-option is 329 not necessarily included in the same BU, but MUST be already known to 330 the receiver of the BU. The Binding Reference sub-option is shown 331 below. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |Sub-opt Type | Sub-Opt Len | BID | ...... 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | ........ 339 +-+-+-+- 341 Figure 2: The Binding Reference sub-option 343 Sub-opt Type 345 Indicates the Sub-option type. For the Binding Reference sub- 346 option, this field MUST be set to 1. 348 Sub-opt Len 350 Indicates the sub-option length in octets. This field includes 351 the entire length of the sub-option including the type and 352 length fields. 354 BID 356 The BID that the mobile node wants to associate with the flow 357 identification option. One or more BID fields can be included 358 in this sub-option. 360 3.3. Binding Cache and Binding Update list extensions 362 Flow bindings are conceptually stored in Binding Cache of home agent, 363 mobility anchor point and correspondent node, and in Binding Update 364 List of mobile node. These logical structures need to be extended to 365 include the following parameters (in addition to those described in 366 RFC3775 [RFC3775]): 368 * FID (Flow Identifier). For a given home address, the FID MUST 369 uniquely identify an entry, i.e. a unique flow binding. An FID 370 is only unique for a given home address. Different mobile 371 nodes can use the same FID value. 373 * Each attribute that constitutes the flow dsecription (and that 374 are defined in a separate document). 376 An entry in these structures is identified by the couple (home 377 address, FID). 379 4. Protocol operations 381 The flow identification option defines the controls on flow bindings. 382 The fields of the flow identification option are necessary for 383 indexing flow identification options, indicating the sort of action 384 that should be undertaken to the recipient's Binding Cache or for 385 carrying the results of such a petition. The flow description is 386 transported in another option that will be defined in another 387 document. This separation is made to use the same flow description 388 in various protocols. 390 This specification allows mobile nodes to direct flows to a 391 particular care-of address. This can be done by aggregating many 392 flows in the flow identification option (e.g. all TCP traffic), or by 393 uniquely identifying a flow in the flow identification option. 395 The remaining of this section discusses how mobile nodes can use the 396 flow identification option when sending binding updates to the 397 correspondent node, home agent or mobility anchor point. In 398 addition, deletion and modification of bindings are all discussed 399 below. 401 4.1. Interaction with the Multiple CoA bindings mechanism 403 Flow binding presented in this specification MUST be used with the 404 solution in draft-ietf-monami6-multiplecoa. The main reason why is 405 to avoid the duplication of the default binding to be used when none 406 of the registered rules can apply to a flow. As the multiple CoA 407 bindings document already defines a prority field which indicates 408 which care-of address is preferred, flow binding uses this priority 409 field in order to maintain a primary Care-of address (see below 410 section Section 4.3). 412 Moreover, combining the mechanism in this specification with the 413 multiple CoA bindings allows for further aggregation of bindings. 414 For example, if a mobile node has several flow identifiers bound to a 415 single Care-of address identified by a unique BID, the mobile node 416 can change the Care-of address for all these flows bindings just by 417 changing the Care-of address associated with the given BID. 419 Additionally, the combination of the two mechanisms allows for 420 additional features (e.g., n-casting) to take place with minimal 421 effort. Hence, this specification makes use of the BID option 422 described in draft-ietf-monami6-multiplecoa. 424 4.2. Flow binding storage 426 Home agent, correspondent node and mobility anchor point maintain 427 Binding Cache in order to record associations between home addresses 428 and care-of addresses of mobile nodes that are away from the home 429 link. Mobile nodes maintain binding update list to record binding 430 between home address and care-of address. RFC 3775 [RFC3775] allows 431 mobile nodes to register only one care-of address per home address. 432 Thus a binding cache entry is uniquely identified by the home 433 address. 435 This specification extends the binding cache and the binding update 436 list structures, and allows mobile node to (1) register multiple 437 care-of addresses for a given home address and (2) associate flow 438 binding policies with the registered care-of addresses. 440 New parameters are added to these conceptual structures in order to 441 list the particular rule associated with a standard binding. On one 442 hand, an entry is now identified by the pair (home address, FID) 443 because several Care-of addresses may be bound to a single home 444 address. On the other hand, the Care-of address is selected 445 according to the best match between the packets that need to be sent, 446 and the existing flow bindings. If no matching is found between the 447 flow bindings and the data packet, a preferred entry is used (see 448 next subsection). If a flow matches two different flow bindings, the 449 PRI field indicates which action is preferred by the mobile node. 451 4.3. Preferred Care-of address 453 Any distant node which supports the flow identification option MUST 454 maintain a default binding per home address. A default binding 455 indicates an association between a home address and a Care-of 456 address. In addition to the default binding, several bindings may 457 co-exist within a binding cache for the same home address, each of 458 them indicating different bindings between flows and Care-of 459 addresses. When a data flow is intercepted by a home agent or 460 initiated by a correspondent node, if the said data flow does not 461 match an existing flow identification option, the care-of address 462 indicated in the default binding is used as destination address for 463 the mobile node. The default binding is indicated by the Priority 464 field in the BID option described in draft-ietf-monami6-multiplecoa. 465 A mobile node is responsible for having a preferred care-of address 466 with the receiver of the flow identification option. 468 4.4. Adding flow bindings 470 When adding a new flow binding, a mobile node sends the flow 471 identification option in the binding update. The care-of address 472 concerned with this binding update must already be registered by the 473 receiver of the binding update (i.e., must already be associated with 474 a BID), or a BID sub-option MUST be present in the binding update (as 475 defined in draft-ietf-multiplecoa"). The flow identification option 476 MUST include a unique FID. The FID needs only be unique for the 477 receiver of the binding update, i.e. the same FID can be used across 478 different receivers of the binding update. The PRO field MUST 479 indicate an Add operation. Adding the flow binding implies 480 associating a flow with a particular care-of address for the mobile 481 node. The care-of address concerned with the flow binding is present 482 in the source address of the packet or the alternate care-of address 483 option. Alternatively, the care-of address may be indicated by the 484 BID (which is pointing to an existing care-of address) when the 485 Binding Reference sub-option of the Flow Identification option is 486 present. 488 The mobile node may need to define the flow partially or entirely 489 based on the source and destination addresses in packets. For 490 instance, a mobile node may choose to forward all flows from address 491 A to address B to a particular care-of address. Alternatively, more 492 granularity can be added by including port numbers and protocol. 493 These descriptions will be given in another document. 495 An Add operation implies that the FID is new and is not already used 496 by the mobile node for any other flow binding. If the Flow 497 identification option is sent without any flow description and with 498 the PRO field indicating an Add operation, this MUST be seen as a 499 wild card request by the sender. A wild card request implies that 500 all flows should be directed to the particular care-of address in the 501 packet. 503 4.5. Modifying flow bindings 505 When modifying a flow binding (either the care-of address or other 506 attributes of the flow), the mobile node sends the binding update 507 with a flow identification option. The option includes the FID for 508 the binding being modified, as well as the PRO field set to 1, 509 indicating a request to modify the binding. A flow description 510 option may come with the flow identification option and contain the 511 new attributes needed to classify the flow. Hence, flow modification 512 is essentially a process where an existing flow definition is removed 513 and a new flow (included in the option) is added and given the same 514 FID as the flow that was removed. 516 If one of the care-of addresses needs to be updated with a new one 517 (e.g., after a change of the IP point of attachment), the mobile node 518 may just need to register the new care-of address for the given BID. 520 4.6. Removing flow bindings 522 When removing a flow binding, the mobile node sends a binding update 523 message with the flow identification option. The PRO field MUST be 524 set to a value of 15, which indicates a request for removing a flow 525 binding. This will provide enough information for the receiver to 526 locate the flow binding using the FID and remove it. 528 4.7. Refreshing Flow Bindings 530 A flow binding is refreshed by simply including the Flow 531 identification option in the BU message. In this case the PRO field 532 is set to indicate a refresh operation. 534 The refresh operation is included in this specification due to the 535 nature of the BU message. The BU message updates existing bindings 536 with new information. Hence, all information previously sent in the 537 last BU message need to be resent in all new messages, otherwise such 538 information will be lost. 540 4.8. Acknowledging flow identification options 542 The home agent and mobility anchor point are required to ackowledge 543 the reception of Binding Update by sending Binding Acknowledgment. A 544 correspondent node SHOULD also acknowledge Binding Update. The 545 Binding Acknowledgement is extended by this specification to indicate 546 to the mobile node the success of the flow binding. If a Binding 547 Acknowledgement needs to be sent in response to a Binding Update that 548 contained flow identification option(s), a copy of each flow 549 identification MUST be included. Only the Status field needs to be 550 changed to the appropriate value. The absence of flow identification 551 option in Binding Acknwoledgement indicates that the sender does not 552 support the extension descibed in this document and therefore MUST be 553 interpreted as a negative acknowledgement. 555 5. Usage scenario 557 In this section, we highlight a use case of the flow identification 558 option. 560 Assume a mobile node equipped with two interfaces namely If1 and If2, 561 each connected to a different foreign network. The mobile node 562 configures one global IPv6 address on each interface, namely CoA1 and 563 CoA2 respectively. The mobile node runs Mobile IPv6 with a home 564 agent located in its home network. We assume that an existing IPsec 565 security association is set up betweeen the mobile node and its home 566 agent. We assume that the mobile node wants to exchange secure data 567 flows over CoA1 and insecure data flows over CoA2. To do so, the 568 mobile node may request its home agent to redirect packets intended 569 to the mobile node's home address to a different care-of address, 570 depending on the type of the communication. For example, port 571 numbers 22 (ssh) and 443 (https) may be tunneled to CoA1 while other 572 communications may be tunneled to CoA2. In order to set up these 573 flow bindings, the following messages are exchanged: 575 * The mobile node sends a Binding Update through If2, with the 576 source address set to CoA2. The Binding Update includes a BID 577 sub-option as described in draft-ietf-monami6-multiplecoa. 578 This sub-option intends to set the highest preference on the 579 given Care-of address. 581 * When the home agent receives the Binding Update, it first 582 validates the Binding Update as recommanded in section 10.3 of 583 [RFC3775]. If the Binding Update is accepted, the home agent 584 processes the BID sub-option as described in section 6.2 of 585 draft-ietf-monami6-multiplecoa. It then registers the source 586 address of the Binding Update as the preferred care-of address 587 for the given home address and sends back a Binding 588 Acknowledgement. 590 * Later, the mobile node sends additional Binding Update with 591 both Flow Identification options and BID sub-option. The BID 592 sub-option is used to indicate the priority of the new Care-of 593 address. In this example, the priority must be lower than the 594 priority of CoA2. The flow identification options are used to 595 indicate the Care-of address usage preferences. In order to 596 redirect source port numbers 22 and 443 to CoA1, two flow 597 identification options need to be transported as well in the 598 Binding Update. These flow identification options are set as 599 follows: PRI is set to 1, Action is set to 0 (forward), PRO is 600 set to 0 (add), FID is set to 1 (and 2 for the second option), 601 and the following flow description option should indicate port 602 number 22 and 443. 604 * When the home agent receives this second Binding Update, it 605 first checks the validity of the Binding Update as recommanded 606 in section 10.3 of [RFC3775] and section 6.2 of 607 draft-ietf-monami6-multiplecoa. If the Binding Update is 608 accepted, the Flow Identification options are treated. If 609 these options are accepted by the home agent, it will return a 610 Binding Acknowledgement with Flow Identification options, each 611 of them having the same first 8 bytes, and the Status field set 612 to 0 (success). 614 Thereafter, if a data flow is destinated to the home address of 615 the mobile node, the home agent will determine if the source 616 port number is equal to 22 or 443. If yes, the home agent will 617 tunnel the data flow to CoA1. If not, the data flow will be 618 forwarded to CoA2. 620 6. Mobile Node operations 622 6.1. Default Bindings 624 A default binding is always maintained between a MN and its peers 625 (home agent, correspondent node if RO is used and mobility anchor 626 point if applicable). The default entry indicates which care-of 627 address to use for a data flow that does not match any of the flow 628 bindings. The preferred care-of address is determined through the 629 BID option. 631 6.1.1. Managing Flow Bindings with the Home Agent and MAP 633 A mobile node may establish a Flow Binding by issuing a Binding 634 Update containing a Flow Identifier (possibly associated with a Flow 635 Description) in its mobility options. The Flow Identification option 636 MUST indicate valid FID, PRO, PRI (rule priority) and Action fields. 638 The PRO field of the Flow Identification option indicates the 639 processing that the targeted node has to perform to its Bindings 640 Cache List. A mobile node may request for any of the following 641 requests: 643 * 0: Add flow binding. Create a new Flow Binding with the 644 indicated FID and include the attached Flow. A mobile node 645 MUST NOT issue a Flow Identifier with the PRO field set to zero 646 for an existing FID. 648 * 1: Replace a flow binding. This request enables the mobile 649 node to replace attributes of the flow or the care-of address 650 associated with the FID. A mobile node MUST NOT issue a Flow 651 Identifier with the PRO field set to one for a non existent 652 FID. 654 * 2: Refresh a flow binding. This request allows the mobile node 655 to inform the receiver of the BU message that the flow binding 656 is still valid. This request does not modify the flow option. 657 A flow identification option MUST NOT contain this value in the 658 PRO field for a non-existent FID. 660 * 15: Remove a flow binding. This action enables a mobile node 661 to remove the Flow Binding indicated by the FID on the targeted 662 node. A mobile node MUST not issue a Flow Identifier with the 663 PRO field set to 15 for a non existent FID. 665 When adding a flow binding on the home agent or MAP, the mobile node 666 MUST ensure the following: 668 * The PRO field MUST be set to indicate an Add operation. 670 * The FID field includes a value that does not already exist in 671 the mobile node's binding update list. 673 * The PRI field is set to indicate the priority of the rule in 674 case of an overlap between rules. An overlap can occur when 675 one flow matches multiple flow description options. 677 * If the Action field is set to indicate N-cast, the Binding 678 Reference sub-option must be present and it must contain one or 679 more BIDs. If the Binding Update sub-option includes only one 680 BID, it must be pointing to a care-of address other than the 681 one included in the binding update. 683 6.1.2. Managing Flow Bindings in Correspondent nodes 685 When route optimisation is used (see RFC3775 [RFC3775]), a mobile 686 node sends the BU message to the correspondent node after the return 687 routability test procedure. When adding flow bindings in the BU sent 688 to the correspondent node, the mobile node MUST ensure the following: 690 * The FID field includes a value that is not already stored in 691 the binding update list with the correspondent node's address. 693 * The PRO field is set to indicate an Add operation. 695 A mobile node can also modify or delete flow bindings in a similar 696 manner to that described earlier with the home agent and MAP. When 697 Modifying a flow binding, the mobile node MUST ensure that the FID 698 used already exists. The rest of the rules for modifying flow 699 bindings are the same as those listed above for adding a flow 700 binding. 702 Refreshing and deleting flow bindings are done in the same manner as 703 that described for the home agent and MAP with one exception: the 704 mobile node MUST NOT refresh or delete bindings associated with any 705 care-of address other than the one included in the BU message. 707 6.1.3. Using Alternate Care-Of Address 709 If the Alternate Care-of Address option is used in the Binding 710 Update, it shall indicate the care-of address to be associated with 711 the Flow Identification options. The Flow Identification options 712 shall contain the FID to be allocated to the Flow Binding. 714 6.1.4. Receiving Binding Acknowledgements 716 According to [RFC3775] all nodes are required to silently ignore 717 mobility options not understood while processing Binding Updates. As 718 such a mobile node receiving a Binding Acknowledgement in response to 719 the transmission of a Binding Update MUST determine if the Binding 720 Acknowledgement contains a copy of the 8 bytes of every Flow 721 Identification options included in the Binding Update. A Binding 722 Acknowledgement without Flow Identification option(s) would indicate 723 inabillity on behalf of the source node to support the extensions 724 presented in this document. 726 If a received Binding Acknowledgement contains a copy of the 8 bytes 727 of each flow identification option that was sent within the Binding 728 Update, the status field of each flow identification option indicates 729 the status of the flow binding on the distant node. 731 6.2. Movement 733 When a MN changes its point of attachment to the Internet, its 734 Care-of address(es) may become invalid and need to be updated. All 735 the flow bindings that are attached to such an old Care-of address 736 need to be udpated with a new Care-of address. This can be achieved 737 by adding flow identification options in Binding Update. One flow 738 identification is needed per flow binding. The flow description may 739 not be needed if only the Care-of address is changed, and not the 740 filter itself. The FID must be set to the flow binding that needs to 741 be udpated and the PRO field MUST be set to 1 (i.e., MODIFY). 743 Another solution is to take advantage of the multiple care-of 744 addresses bindings to aggregate updates; the mobile node may only 745 need to update the care-of address associated with the given BID. 746 This would avoid to send a flow identification option per flow 747 binding. 749 6.3. Return Routability Procedure 751 A mobile node may perform route optimization with correpondent nodes. 752 Route optimization allows a mobile node to bind a care-of address to 753 a home address in order to allow the correspondent node to direct the 754 traffic to the current location of the mobile node. Before sending a 755 Binding Update to correspondent node, the Return Routability 756 Procedure needs to be performed between the mobile node and the 757 correspondent node. 759 This procedure is not affected by the extensions defined in this 760 document. However, since a Binding Update message is secured with 761 the key generated based on the home address and care-of address test, 762 a mobile node MUST NOT bind a flow to a care-of address whose keygen 763 token (see RFC3775 [RFC3775]) was not used to generate the key for 764 securing the Binding Update. This limitation prohibits the sender 765 from requesting the n-cast action before having registered each 766 care-of address one by one. 768 6.4. Returning Home 770 Whenever a mobile node acquires a point of attachment to the home 771 network and wishes to abolish all Flow Bindings associated with the 772 respective home address, it is required to act as described in 773 Section 11.5.4 of RFC3775 [RFC3775]. This will cause the home agent 774 to remove all bindings that are linked to the home address, including 775 the flow bindings. 777 7. Applicability to Route Optimization 779 The route optimization is only defined for mobile nodes (RFC3775 780 [RFC3775]), and not mobile router (RFC3963 [RFC3963]). Thus, this 781 section does not apply to mobile routers. This section describes the 782 correspondent node operations. 784 Every correspondent node is required to maintain a Binding Cache 785 containing records of associations between mobile node home addresses 786 and care-of addresses (bindings) as they roam away from the home 787 network. RFC3775 [RFC3775] allows mobile nodes to register only a 788 single binding per home address with each correspondent node. 790 This specification extends the binding cache structure, and enables 791 correspondent nodes to (i) maintain multiple bindings for a given 792 home address and (ii) to associate multiple Flow Identification / 793 description options with every binding, termed as Flow Binding. A 794 flow matching a Flow Description should be directed to the Care-of 795 address indicated by the Flow Binding. 797 7.1. Receiving Binding Udpate 799 When a correspondant node receives a Binding Update, it first 800 performs the same operation as defined in RFC3775 [RFC3775]. If the 801 Binding Update is valid and contains a Flow identification option, 802 the correspondent node needs to check the content of the PRO field. 803 If the PRO field contains a value indicating a request to add a new 804 flow binding, the following checks are done: 806 * The FID field includes a value that is not already stored in 807 the binding update list with the correspondent node's address. 809 * The PRO field is set to indicate an Add operation. 811 + The FID field needs to contain a value that does not already 812 exist. If the FID contains a value that already exists, the 813 correspondent node MUST reject the option by sending that 814 option back in its Binding Acknowledgement with a Status 815 field that contains an error value. 817 + If the Action field indicates a request to n-cast the flow, 818 the correspondent node MUST reject the option by sending the 819 option in its binding acknowledgement with an appropriate 820 error code. 822 + If both the FID and Action fields are valid, the 823 correspondent node checks the flow description that must 824 follow the flow identification option. If all of the checks 825 above indicated a valid option, the correspondent node 826 should add the flow binding to its binding cache. 828 + The FID MUST include a value that already exists. If the 829 FID cannot be found in the correspondent node's binding 830 cache, the flow identification option MUST be rejected with 831 an appropriate error code. 833 + If the Action field indicates a request to n-cast the flow, 834 the correspondent node MUST reject the option by sending the 835 option in its binding acknowledgement with an appropriate 836 error code. 838 + If the Binding Reference sub-option is present, the 839 correspondent node MUST ensure that the BID points to the 840 care-of address in the packet, or to an already authrozied 841 care-of address. Otherwise the option MUST be rejected with 842 an appropriate error code. 844 + If all of the above checks returned a valid result, the 845 correspondent node should modify the binding as requested. 847 If the PRO field in the option indicates a request to modify the 848 option, the following checks must be done by the correspondent node: 850 If the PRO field in the option contains a request to refresh a 851 binding, the correspondent node MUST ensure that the FID already 852 exists. If the FID does not exist, the correspondent node MUST 853 reject the option by sending it back in its binding acknowledgement 854 with an appropriate error code in the status field. Otherwise, if 855 the FID exists, the correspondent node must keep it in its binding 856 cache. No further checks need to be done in the option. 858 The correspondent node should reply with a Binding Acknowledgement 859 message. This Binding Acknowlegement message must contain a copy of 860 the 8 bytes of each flow identification option that was included in 861 the Binding Udpate. The Status field of each Flow Identification 862 option MUST be set to an appropriate value. 864 8. Home Agent operations 866 This specification allows the home agent to maintain several bindings 867 for a given home address and to direct packets to different care-of 868 addresses according to flow bindings. This section details the home 869 agent operations necessary to implement this specification. 871 8.1. Receiving Binding Update with the Flow Identification option 873 When the home agent receives a Binding Update which includes at least 874 one Flow Identification option, it first performs the operation 875 described in section 10.3.1 of RFC3775. If the Binding Update is 876 accepted, the home agent then checks the flow identification option. 877 If the PRO field in the option indicates an Add operation, the 878 following checks must be done: 880 * The FID field needs to contain a value that does not already 881 exist. If the FID contains a value that already exists, the 882 home agent MUST reject the option by sending that option back 883 in its Binding acknowledgement with a Status field that 884 contains an appropriate error value. 886 * If the FID field is valid, the home agent then checks the 887 Action field. If the Action field contains a request for 888 n-cast and the Binding Reference sub-option is not included in 889 the option, the flow binding MUST be rejected in the binding 890 acknowledgement containing an error code in the Status field. 892 * If both of the checks above indicate valid FID and Action 893 fields, the home agent checks the flow description following 894 the flow identification option, and identifies the filter that 895 needs to be set up. 897 * If the flow option includes an action field that requests 898 n-casting, the home agent MUST check for the presence of the 899 BID sub-option(s). If the sub-options are not present, the 900 flow identification option MUST be rejected as a poorly 901 formatted option. If one or more BIDs are present in the BID 902 Reference sub-option, the home agent needs to create multiple 903 logical entries in its binding cache. All flows matching the 904 one in the option would be n-cast to the care-of addresses 905 pointed to by the BIDs or the set of registered care-of 906 addresses. If only one BID were included in the Binding 907 Reference sub-option and it pointed to a different care-of 908 address from the one included in the packet, then packets 909 matching the flow would be bicast to those two addresses. 911 However, if only one BID is present and points to the same 912 address in the BU, the n-cast is essentially pointing to one 913 address and therefore cannot be performed. Such option MAY be 914 rejected as a poorly formatted option. 916 * If all of the checks above indicated a valid option, the home 917 agent should add the flow binding to its binding cache. 919 If the PRO field in the option contains a value indicating a request 920 to modify an existing binding, the following actions must be taken: 922 * The FID MUST include a value that already exists. If the FID 923 cannot be found in the home agent's binding cache, the flow 924 identification option MUST be rejected as a poorly formed 925 option. 927 * If the FID is valid, the home agent MUST perform the same steps 928 described above for the Add operation. 930 If the PRO field indicates a refresh operation, the home agent MUST 931 ensure that the FID in the option already exists. If the FID field 932 did not exist, the option MUST be rejected as a poorly formed option. 933 If the FID existed, the home agent MUST keep the current flow binding 934 in its binding cache. 936 8.2. Sending Binding Ackowledgement 938 Upon the reception of a Binding Update, the home agent is required to 939 send back a Binding Acknowledgment. The status code in the Binding 940 Acknowledgement must be set as recommanded in [RFC3775] and is not 941 modified by the extension defined in this specification. This status 942 code does not give information on the success or failure of the flow 943 binding. 945 In order to inform about the status of the flow binding that was 946 requested by a mobile node, a flow identification option MUST be set 947 in the Binding Acknowledgement message. The home agent must copy the 948 8 octets of each Flow Identification option received in the Binding 949 Update and set the status code to an approriate value. Each option 950 must be included in the Binding Acknowledgement message. 952 8.3. Deleting an entry in the binding cache 954 A home agent might delete an entry in its binding cache for two 955 reasons: either an entry expires, or the MN explicitly requests the 956 home agent to remove a specific entry. If an entry is going to 957 expire, the home agent SHOULD send a Binding Refresh Advice. 959 8.3.1. Removing Flow Bindings 961 If the home agent receives a valid Binding Update with a flow 962 Identification option where the PRO field is set to 15 (Remove), the 963 home agent MUST remove the corresponding entry. The home agent looks 964 up the entry corresponding to the FID of the Binding Update. If an 965 entry is found, the entry is removed from the Binding cache and a 966 Binding Acknowledgement is sent back to the mobile node with a 967 success value for the status of the flow Identification option (see 968 section Section 8.2. This operation does not modify any other 969 binding that may appear with the same home address. If the FID is 970 not present in the binding cache entry for the corresponding home 971 address, the home agent MUST send back to the mobile node a Binding 972 Acknowledgement with error code 137 (FID not found) in the flow 973 identification option. 975 9. Applicability to Hierarchical Mobile IPv6 977 This section describes the Mobility Anchor Point (MAP) operations. 978 The MAP operation is the same as the home agent operation. Flow 979 bindings sent to the MAP are associated with the regional care-of 980 address. 982 When a MAP receives a Binding Update that includes the flow 983 Identification option, it checks if such option is valid according to 984 the requirements in Section 8.1. If the option is valid, the MAP 985 installs the flow binding associated with the flow identified by the 986 flow description. The lifetime of the binding is the lifetime of the 987 Binding Update. Once the binding is successfully installed, the MAP 988 sends the binding acknowledgement and includes the flow 989 Identification option. The MAP sets the status field to a value 990 indicating success. 992 In all cases, a flow identification option SHOULD be included in the 993 Binding Acknowledgement to indicate success or failure of the flow 994 binding installation. 996 10. Security considerations 998 This draft introduces a new option that adds more granularity to the 999 Binding Update message. The new option allows the mobile node to 1000 associate some flows to an interface and other flows to another 1001 interface. Since the flow Identification option is part of the 1002 mobility header, it uses the same security as the Binding Update, 1003 whether it is sent to the home agent, correspondent node, or MAP. 1005 11. Acknowledgements 1007 We would like to thank all authors of initial I-Ds that were merged 1008 together to create this document; in alphabetical order: C. 1009 Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. 1010 Pavlidou. Thanks to George Tsirtsis and Vince Park for their 1011 thorough review and input to the draft. Gabor Fekete for the 1012 analysis that led to the inclusion of the BID support. Henrik 1013 Levkowetz for suggesting the equivalent of the CLS field to allow 1014 other ways of describing flows. 1016 12. Informative References 1018 [I-D.ietf-nemo-terminology] 1019 Ernst, T. and H. Lach, "Network Mobility Support 1020 Terminology", draft-ietf-nemo-terminology-06 (work in 1021 progress), November 2006. 1023 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1024 (IPv6) Specification", RFC 2460, December 1998. 1026 [RFC2702] "", 2005. 1028 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1029 RFC 3753, June 2004. 1031 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1032 in IPv6", RFC 3775, June 2004. 1034 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1035 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1036 RFC 3963, January 2005. 1038 [RFC4140] "RF", 2005. 1040 Authors' Addresses 1042 Hesham Soliman (editor) 1043 Elevate Technologies 1045 Email: hesham@elevatemobile.com 1047 Nicolas Montavont 1048 Ecole Nationale Superieure des telecommunications de Bretagne 1049 2, rue de la chataigneraie 1050 Cesson Sevigne 35576 1051 France 1053 Phone: (+33) 2 99 12 70 23 1054 Email: nicolas.montavont@enst-bretagne.fr 1055 URI: http://www-r2.u-strasbg.fr/~montavont/ 1057 Nikolaus A. Fikouras 1058 University of Bremen 1059 ComNets-ikom,University of Bremen. 1060 Otto-Hahn-Allee NW 1 1061 Bremen, Bremen 28359 1062 Germany 1064 Phone: +49-421-218-8264 1065 Fax: +49-421-218-3601 1066 Email: niko@comnets.uni-bremen.de 1067 URI: http://www.comnets.uni-bremen.de 1069 Koojana Kuladinithi 1070 University of Bremen 1071 ComNets-ikom,University of Bremen. 1072 Otto-Hahn-Allee NW 1 1073 Bremen, Bremen 28359 1074 Germany 1076 Phone: +49-421-218-8264 1077 Fax: +49-421-218-3601 1078 Email: koo@comnets.uni-bremen.de 1079 URI: http://www.comnets.uni-bremen.de/~koo/