idnits 2.17.1 draft-yokota-mext-ha-init-flow-binding-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2012) is 4304 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft D. Kim 4 Intended status: Standards Track KDDI Lab 5 Expires: January 15, 2013 B. Sarikaya 6 F. Xia 7 Huawei USA 8 July 14, 2012 10 Home Agent Initiated Flow Binding for Mobile IPv6 11 draft-yokota-mext-ha-init-flow-binding-02 13 Abstract 15 There are scenarios in which the home agent needs to trigger flow 16 binding operations towards the mobile node such as moving a flow from 17 one access network to another based on the network resource 18 availability. In order for the home agent to be able to initiate 19 interactions for flow bindings with the mobile node, this document 20 defines new signaling messages and sub-options for Mobile IPv6. Home 21 agent initiated flow bindings are supported for both IPv4 and IPv6 22 enabled mobile nodes. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 15, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Over-the-air Flow Binding Provisioning . . . . . . . . . . 3 62 3.2. Traffic Offload . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Flow Binding Revocation . . . . . . . . . . . . . . . . . 4 64 3.4. Exceeding traffic quota . . . . . . . . . . . . . . . . . 4 65 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Adding flow bindings . . . . . . . . . . . . . . . . . . . 5 67 4.2. Deleting flow bindings . . . . . . . . . . . . . . . . . . 5 68 4.3. Modifying flow bindings . . . . . . . . . . . . . . . . . 5 69 4.4. Refreshing flow bindings . . . . . . . . . . . . . . . . . 6 70 4.5. Moving flow bindings . . . . . . . . . . . . . . . . . . . 6 71 4.6. Revoking flow bindings . . . . . . . . . . . . . . . . . . 6 72 5. Handling of the Flow Bindings List . . . . . . . . . . . . . . 6 73 6. Flow Binding Messages and Options . . . . . . . . . . . . . . 7 74 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 7 75 6.1.1. Flow Binding Indication . . . . . . . . . . . . . . . 8 76 6.1.2. Flow Binding Acknowledgement . . . . . . . . . . . . . 9 77 6.1.3. Flow Binding Revocation Extensions . . . . . . . . . . 10 78 6.2. New Options . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.2.1. Flow binding action sub-option . . . . . . . . . . . . 10 80 6.2.2. Target Care-of-Address sub-option . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 8. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 12 83 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 [RFC6089] allows a mobile node to bind a particular flow to a care-of 92 address without affecting other flows using the same home address. 93 Binding Update (BU)/Binding Acknowledgement(BA) messages are extended 94 for the mobile node to add, modify, remove and refresh flow binding 95 in a home agent. The operations are always initiated by the mobile 96 node. 98 In some cases, the home agent would like to initiate flow binding 99 operations. e.g, the home agent revokes a flow binding for reasons 100 such as accounting insufficiency of the mobile node; for the mobile 101 node equipped with multiple interfaces, the home agent moves a flow 102 binding from one interface to another based on network resource 103 availability; the home agent provisions default flow binding rules to 104 the mobile node based on the mobile node's default profile. 106 This document defines one new Mobility Header and two new messages 107 for the home agent to control flow bindings in the mobile node. Flow 108 mobility for the mobile nodes with IPv4 home address and IPv4 address 109 of the home agent as described in [RFC5555] is also supported. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 The terminology in this document is based on the definitions in 118 [RFC3775] and [RFC6089]. 120 3. Use Cases 122 3.1. Over-the-air Flow Binding Provisioning 124 When a new subscriber purchases a dual mode phone equipped with both 125 3GPP and WiFi interfaces, depending on the services that the 126 subscriber can use, the operator provisions the mobile phone over the 127 air with the following information: 129 o 3GPP access takes priority over WiFi access when providing Voice- 130 over-IP (VoIP) service. That is, when making a call, the 3GPP 131 network is always used as far as the network is accessible. 132 o WiFi access is primarily selected to serve IPTV service. 134 o Peer-to-peer (p2p) download is only allowed through WiFi access. 136 The above profile can be downloaded through the home agent to the 137 mobile node when registering. 139 3.2. Traffic Offload 141 The 3G operator may want to move traffic flows from the 3G access to 142 another due to ever-increasing traffic load in the 3G access network. 143 Fine-grained traffic offload is desirable. For example, IMS-based 144 VoIP flows must stay in the mobile core network while video streaming 145 flows provided by servers on the Internet could bypass the mobile 146 core network via WiFi access. Since the network knows more about its 147 conditions and has access to the policy server, more timely and well- 148 controlled traffic offloading is possible. To this end, already 149 established sessions are moved by the home agent by sending down an 150 updated flow descriptor to the mobile node. 152 3.3. Flow Binding Revocation 154 For administrative reasons, such as the utilization of CPU of a home 155 agent reaches a threshold or the home agent needs to reboot some of 156 it line cards, sometimes it becomes necessary to inform the mobile 157 node that its flow binding has been revoked and the mobile node is no 158 longer able to receive IP mobility service for a given flow. Apart 159 from revocation, the home agent may decide to delete a flow binding 160 with a delete operation. 162 3.4. Exceeding traffic quota 164 The 3G operator offers a mobile broadband service with a flat rate 165 subscription limited to 5G Byte per month. Once the quota is reached 166 the service is downgraded to 64 K bit per second. This limitation 167 does not prevent the user from using the 3G access for mobile 168 broadband services and there is no reason for the operator to change 169 the policy since the service is still available. However, since the 170 operator has more information available than the user, the operator 171 can indicate this to the user by sending modified flow descriptors to 172 the user as a proposal to change access for an ongoing session. 174 4. Protocol Operation 176 [RFC6089] makes use of Binding Update (BU) /Binding 177 Acknowledgement(BA) signalling to forward, i.e. register or discard a 178 flow binding in a home agent. That is, flow binding operations are 179 always initiated from the mobile node. The mechanism specified in 180 this document is complimentary to the method described in [RFC6089]. 182 It is assumed that the home agent has already created Binding Cache 183 entries for the mobile node before launching flow binding operations. 185 In this document, one new Mobility Header and two new messages are 186 defined, that is, Flow Binding Indication (FBI) Section 6.1.1 and 187 Flow Binding Acknowledgement (FBA)Section 6.1.2. FBI is used by the 188 home agent to initiate flow binding operations, while FBA is used for 189 acknowledging FBI. 191 Due to access network change on the mobile node side, some interface 192 that used to be active may not be valid at the time of flow binding 193 operation by the home agent, in which case, even if the HA sends the 194 FBI to the MN, the FBA will not return. After retransmitting the 195 FBIs for MAX_FBI_RETRIES times and not receiving the FBA, the HA 196 determines that the target interface is not available. 198 4.1. Adding flow bindings 200 Adding the flow binding implies associating a flow with a particular 201 care-of address for the mobile node. The care-of address concerned 202 with the flow binding is present in the destination address of the 203 packet or the alternate care-of address option. Alternatively, the 204 care-of address may be indicated by the Target Care-of Address sub- 205 option defined in Section 6.2.2. Binding Identification number (BID) 206 described in [RFC5648] is not used in the flows initiated by the home 207 agent. 209 When adding a new flow binding, the home agent sends a FBI with a 210 Flow Identification Mobility option to the mobile node. The Flow 211 Identification Mobility option defined in [RFC6089] includes a unique 212 Flow Identifier (FID). The Flow binding action sub-option MUST 213 indicate Add operation defined in Section 6.2.1. The FID needs only 214 be unique for the receiver of the message that adds a flow, i.e. the 215 same FID can be used across different receivers of the message. 217 4.2. Deleting flow bindings 219 When removing a flow binding, the home agent sends a FBI with a Flow 220 Identification Mobility option in which the Flow binding action sub- 221 option indicates Delete operation. The Flow Identification Mobility 222 option includes a unique FID for the mobile node to locate the flow 223 binding and remove it. 225 4.3. Modifying flow bindings 227 When modifying a flow binding (either the care-of address or other 228 attributes of the flow), the home agent sends the mobile node a FBI 229 message with Flow Identification Mobility option. The option 230 includes the FID for the binding being modified. A Traffic Selector 231 sub-option may come with the Flow Identification Mobility Option and 232 contain the new attributes needed to classify the flow such as DS 233 (Differential Services) values in [RFC6088]. Hence, flow 234 modification is essentially a process where an existing flow 235 definition is removed and a new flow (included in the option) is 236 added with the same FID as the flow that was removed. 238 4.4. Refreshing flow bindings 240 A flow binding is refreshed by simply including the Flow 241 Identification Mobility option with Refresh Action field in the FBI 242 message. The message should be sent before the expiration of the 243 flow binding. The message updates existing bindings with new 244 information. Hence, all information previously sent in the last 245 refreshing message need to be resent, otherwise such information will 246 be lost. 248 4.5. Moving flow bindings 250 The home agent can move a flow associated to one interface of the 251 multi-interfaced mobile node to another by sending a FBI message to 252 the mobile node. A Flow Identification Mobility option whose Action 253 field is set to Move is included. The address of the target 254 interface is also included in the Flow Identification Mobility option 255 in Target Care-of Address sub-option. 257 4.6. Revoking flow bindings 259 When the home agent or the network attached to it is overloaded, the 260 home agent can revoke a flow binding registered by the mobile node. 261 The home agent sends the mobile node a FBI message with a Flow 262 Identification Mobility option in which the Flow binding action sub- 263 option indicates Revoke operation. When the MN receives the FBI 264 message with Revoke operation, it returns the FBA and decides whether 265 the flow should be removed (de-registration) or moved to another 266 interface. The mobile node SHOULD take an action by sending a new BU 267 to, for example, deregister the flow. 269 5. Handling of the Flow Bindings List 271 Flow bindings list defined in [RFC6089] needs to be modified after 272 each protocol operation defined above as follows: 274 If FBI contains a flow binding add operation and if the corresponding 275 FBA has a status code equal to zero, home agent MUST add a new entry 276 to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action 277 fields are taken from the Flow Identification Mobility Option. BID 278 is copied from the Binding Reference sub-option. Active/Inactive 279 Flag is set to Active. Note that if BID is not available it may be 280 replaced by Care-of-Address. 282 If FBI contains a flow binding delete operation and if the 283 corresponding FBA has a status code equal to zero, home agent MUST 284 locate the list entry corresponding to this flow and then delete the 285 entry. 287 If the home agent sends a Binding Revocation Indication message with 288 Flow Mobility Option where the action field is set to Revoke and if 289 the corresponding Binding Revocation Acknowledgement message 290 indicates acceptance, home agent MUST locate the list entry 291 corresponding to this flow and then delete the entry. 293 If FBI contains a flow binding modify operation and if the 294 corresponding FBA has a status code equal to zero, home agent MUST 295 delete the list entry corresponding to this flow and then add a new 296 entry setting the values as defined in the Flow Identification 297 Mobility Option. 299 If FBI contains a flow binding refresh operation and if the 300 corresponding FBA has a status code equal to zero, home agent MUST 301 locate the list entry corresponding to this flow and then set Active/ 302 Inactive Flag to Active. 304 If FBI contains a flow binding move operation and if the 305 corresponding FBA has a status code equal to zero, home agent MUST 306 locate the list entry corresponding to this flow and then change the 307 BID value to the Care-of-Address in the Flow Identification Mobility 308 Option. 310 If FBI contains a flow binding switch operation and if the 311 corresponding FBA has a status code equal to zero, home agent MUST 312 locate the list entry corresponding to this flow and then delete the 313 entry. 315 Flow binding operations apply equally to IPv6 packets as well as IPv4 316 packets as in Dual-Stack Mobile IPv6 [RFC5555]. 318 6. Flow Binding Messages and Options 320 6.1. Mobility Header 322 The messages described below follow the Mobility Header format 323 specified in Section 6.1 of [RFC3775]. 325 6.1.1. Flow Binding Indication 327 The Flow Binding Indication messages are used by the home agent to 328 initiate flow binding operations to the mobile node. The Flow 329 Binding Indication messages use the MH Type value (IANA-TBD1) for 330 Flow Binding message and a Flow Binding Type value of 1, and the 331 format of the Message Data field in the Mobility Header is as 332 follows: 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 | Flow Binding Type = 1 | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Sequence # | Trigger |A| Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 . . 342 . Mobility options . 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 1: Flow Binding Indication Message Type 348 Sequence # 349 A 16-bit unsigned integer used by the home agent to match a 350 returned Flow Binding Acknowledgement with this Flow Binding 351 Indication. It could be a random number. 353 Trigger 354 8-bit unsigned integer indicating the event which triggered the 355 home agent to send the Flow Binding Indication message. The 356 following Trigger values are currently defined: 358 0 Reserved 359 1 Unspecified 360 2 Administrative Reason 361 3 Possible Out-of Sync BCE State 362 250-255 Reserved For Testing Purposes only 363 All the other values are reserved 365 Acknowledge (A) 366 The Acknowledge (A) bit is set by the home agent to request a Flow 367 Binding Acknowledgement be returned upon receipt of the Flow 368 Binding Indication. 370 Reserved 371 These fields are unused. They MUST be initialized to zero by the 372 sender and MUST be ignored by the receiver. 374 Mobility Options 375 Variable-length field of such length that the complete Mobility 376 Header is an integer multiple of 8 octets long. Flow 377 Identification Mobility Options are included in this field. 379 6.1.2. Flow Binding Acknowledgement 381 The Flow Binding Acknowledgement is used to acknowledge receipt of a 382 Flow Binding Indication. The mobile node sends FBA message to 383 acknowledge the reception of FBI to Add, Delete, Modify, Refresh, 384 Move, or Switch a flow binding. On receiving messages with Flow 385 Identification Mobility Option(s), the mobile node should copy each 386 Flow Identification Mobility Option to the Acknowledgement messages. 387 The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1) 388 for Flow Binding message and a Flow Binding Type value of 2. When 389 this value is indicated in the MH Type field, the format of the 390 Message Data field in the Mobility Header is as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Flow Binding Type = 2 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Sequence # | Status | Reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 . . 400 . Mobility options . 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 2: Flow Binding Acknowledgement Message Type 406 Sequence # 407 The sequence number in the Flow Binding Acknowledgement is copied 408 from the Sequence Number field in the Flow Binding Indication. 410 Status 411 8-bit unsigned integer indicating the result of processing the 412 Flow Binding Indication message by the receiving mobile node. 413 Values of the Status field less than 128 indicate that the Flow 414 Binding Indication was processed successfully by the receiving 415 node. Values greater than or equal to 128 indicate that the Flow 416 Binding Indication was rejected by the receiving node. The 417 following status values are currently defined: 419 0 success 420 128 Binding Does NOT Exist 421 All the other values are reserved 423 Mobility Options 424 Variable-length field of such length that the complete Mobility 425 Header is an integer multiple of 8 octets long. This field 426 contains zero or more TLV-encoded mobility options. Flow 427 Identification Mobility Options are included in this field. 429 6.1.3. Flow Binding Revocation Extensions 431 This specification enables Binding Revocation Indication and Binding 432 Revocation Acknowledgement messages to carry Flow Identification 433 Mobility Options as defined in [RFC6089] with extensions defined in 434 this document. 436 6.2. New Options 438 This specification defines two Flow Indication sub-options that is 439 included in Flow Identification Mobility Option specified in 440 [RFC6089]. 442 6.2.1. Flow binding action sub-option 444 This section defines a new sub-option for flow binding actions, which 445 must be included in the Flow Identification Mobility Option as shown 446 in Figure 3. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |Sub-opt Type | Sub-opt Len | Reserved | Action | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 3: Flow binding action Sub-option 456 Sub-opt Type 457 To be assigned by IANA (IANA-TBD2) 459 Sub-opt Len 460 Length of the sub-option in 8-octet units 462 Action 463 This is a 8-bit field that describes the required processing for 464 the option. It can be assigned one of the following new values: 466 11 Add a flow binding 467 12 Delete a flow binding 468 13 Modify a flow binding 469 14 Refresh a flow binding 470 15 Move a flow binding 471 16 Revoke a flow binding 472 All the other values are reserved for future use 474 6.2.2. Target Care-of-Address sub-option 476 This section introduces the Target Care-of-Address sub-option, which 477 may be included in the Flow Identification Mobility Option. This 478 sub-option is used to indicate the mobile node to move a flow binding 479 from one interface to another. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 |Sub-opt Type | Sub-opt Len | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Target Care-of-Address | 486 . . 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 4: Target Care-of-Address Sub-option 491 Sub-opt Type 492 To be assigned by IANA (IANA-TBD3) 494 Sub-opt Len 495 Length of the sub-option in 8-octet units 497 Reserved 498 This field is unused. It MUST be initialized to zero by the 499 sender and MUST be ignored by the receiver. 501 Target Care-of-Address 502 The address of an interface that the flow is moved to. This 503 address could be IPv4 or IPv6 address. This sub-option MUST be 504 included when the action taken is "15 Move a flow binding". 506 7. Security Considerations 508 Security issues for this document follow those of [RFC6088],[RFC6089] 509 and [RFC5846]. This specification allows the home agent to 510 manipulate only the binding of a flow(s) that is currently registered 511 with it, which is the same principle described in [RFC5846]. No 512 additional security issue specific to this document is identified. 514 8. Protocol constants 516 Maximum FBI retries (MAX_FBI_RETRIES) 517 This variable specifies the maximum number of times the HA MAY 518 retransmit a Flow Binding Indication message when FBA is not 519 returned within the time period specified by MAX_FBA_TIMEOUT. The 520 default value for this parameter is 3. 522 Maximum FBA timeout (MAX_FBA_TIMEOUT) 523 This variable specifies the maximum time in seconds the HA MUST 524 wait before retransmitting another FBI message. The default for 525 this parameter is 3 seconds. 527 9. IANA considerations 529 This document defines one new Mobility Header and two new mobility 530 options to be used in Flow Binding Initiate and Flow Binding 531 Acknowledge messages. A new Mobility Header Type and two new sub-opt 532 type values (IANA-TBD1, IANA-TBD2 and IANA-TBD3) need to be assigned 533 by IANA. 535 10. References 537 10.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 543 Routers", RFC 5555, June 2009. 545 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 546 in IPv6", RFC 3775, June 2004. 548 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 549 and P. Yegani, "Binding Revocation for IPv6 Mobility", 550 RFC 5846, June 2010. 552 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 553 "Traffic Selectors for Flow Bindings", RFC 6088, 554 January 2011. 556 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 557 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 558 Network Mobility (NEMO) Basic Support", RFC 6089, 559 January 2011. 561 10.2. Informative references 563 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 564 and K. Nagami, "Multiple Care-of Addresses Registration", 565 RFC 5648, October 2009. 567 Authors' Addresses 569 Hidetoshi Yokota 570 KDDI Lab 571 2-1-15 Ohara 572 Fujimino 573 Saitama, Japan 356-8502 575 Phone: 576 Email: yokota@kddilabs.jp 578 Dae-Sun Kim 579 KDDI Lab 580 2-1-15 Ohara 581 Fujimino 582 Saitama, Japan 356-8502 584 Phone: 585 Email: da-kim@kddilabs.jp 587 Behcet Sarikaya 588 Huawei USA 589 5340 Legacy Drive Building 3 590 Plano, TX 75024 592 Phone: +1 469-277-5839 593 Email: sarikaya@ieee.org 595 Frank Xia 596 Huawei USA 597 5430 Legacy Dr. Building 3 598 Plano, TX 75024 600 Phone: 601 Email: xiayangsong@huawei.com