idnits 2.17.1 draft-yokota-mext-ha-init-flow-binding-00.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 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 470 has weird spacing: '... Modify a flo...' == Line 471 has weird spacing: '...Refresh a fl...' == 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 'SHOULD not' in this paragraph: In some cases the mobile node manually decides to move an IP Flow from one interface, e.g. 3GPP to another e.g. WLAN. The home agent receives such a request to forward a flow and performs the action. We recognize that the manual intervention is always possible and generally has precedence to other policies. On such a flow HA-initiated move operation SHOULD not be used. If used, MN will move it back and a set of ping-pong move operations will take place. Home agent SHOULD move such a flow only if network conditions require it to be moved such as congestion on the current interface because such conditions can best be detected by the home agent only and not by the mobile nodes. -- The document date (June 24, 2011) is 4661 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) == Missing Reference: 'RFC5846' is mentioned on line 514, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 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 Expires: December 26, 2011 KDDI Lab 5 B. Sarikaya 6 F. Xia 7 Huawei USA 8 June 24, 2011 10 Home Agent Initiated Flow Binding for Mobile IPv6 11 draft-yokota-mext-ha-init-flow-binding-00 13 Abstract 15 There are scenarios in which home agent initiated flow binding 16 operations towards the mobile node is needed such as revoking a flow 17 binding or moving a flow from one interface to another because of 18 network resource availability. This document defines one new 19 Mobility Header, two messages, several actions and two new sub- 20 options to perform home agent initiated interactions for flow 21 bindings in a mobile node. Home agent initiated flow bindings are 22 supported for both IPv4 and IPv6 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 December 26, 2011. 41 Copyright Notice 43 Copyright (c) 2011 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. Default 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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 7 73 6. Flow Binding Messages and Options . . . . . . . . . . . . . . 8 74 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.2.1. New Actions in Flow Identification Mobility Option . . 11 80 6.2.2. Target Care-of-Address sub-option . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 9.2. Informative references . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 [RFC6089] allows a mobile node to bind a particular flow to a care-of 91 address without affecting other flows using the same home address. 92 Binding Update (BU)/Binding Acknowledgement(BA) messages are extended 93 for the mobile node to add, modify, remove and refresh flow binding 94 in a home agent. The operations are always initiated by the mobile 95 node. 97 In some cases, the home agent would like to initiate flow binding 98 operations. e.g, the home agent revokes a flow binding for reasons 99 such as accounting insufficiency of the mobile node; for the mobile 100 node equipped with multiple interfaces, the home agent moves a flow 101 binding from one interface to another based on network resource 102 availability; the home agent provisions default flow binding rules to 103 the mobile node based on the mobile node's default profile. 105 This document defines one new Mobility Header and two new messages 106 for the home agent to control flow bindings in the mobile node. Flow 107 mobility for the mobile nodes with IPv4 home address and IPv4 address 108 of the home agent as described in [RFC5555] is also supported. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The terminology in this document is based on the definitions in 117 [RFC3775] and [RFC6089]. 119 3. Use Cases 121 3.1. Default Flow Binding Provisioning 123 Michael purchases a dual mode phone equipped with both 3GPP and WiFi 124 interfaces. He also signs a Service Level Agreement(SLA) with an 125 operator including the following information: 127 o 3GPP access takes priority over WiFi access when providing Voice- 128 over-IP (VoIP) service. That is, the 3GPP network is always used 129 when Michael makes a call if the network is accessible. 130 o WiFi access is primarily selected to serve IPTV service. 131 o Peer-to-peer (p2p) download is only allowed through WiFi access. 133 Michael's default profile can be downloaded through the home agent to 134 its mobile node when registering. 136 3.2. Traffic Offload 138 The 3G operator may want to move traffic flows from the 3G access to 139 another due to ever-increasing traffic load in the 3G access network. 140 Fine-grained traffic offload is desirable. For example, IMS-based 141 VoIP flows must stay in the mobile core network while video streaming 142 flows provided by servers on the Internet could bypass the mobile 143 core network via WiFi access. Since the network knows more about its 144 conditions and has access to the policy server, more timely and well- 145 controlled traffic offloading is possible. To this end, already 146 established sessions are moved by the home agent by sending down an 147 updated flow descriptor to the mobile node. 149 3.3. Flow Binding Revocation 151 For administrative reasons, such as the utilization of CPU of a home 152 agent reaches a threshold or the home agent needs to reboot some of 153 it line cards, sometimes it becomes necessary to inform the mobile 154 node that its flow binding has been revoked and the mobile node is no 155 longer able to receive IP mobility service for a given flow. Apart 156 from revocation, the home agent may decide to delete a flow binding 157 with a delete operation. 159 3.4. Exceeding traffic quota 161 The 3G operator offers a mobile broadband service with a flat rate 162 subscription limited to 5G Byte per month. Once the quota is reached 163 the service is downgraded to 64 K bit per second. This limitation 164 does not prevent the user from using the 3G access for mobile 165 broadband services and there is no reason for the operator to change 166 the policy since the service is still available. However, since the 167 operator has more information available than the user, the operator 168 can indicate this to the user by sending modified flow descriptors to 169 the user as a proposal to change access for an ongoing session. 171 Please observe that there is no need for the HA to say which 172 interface to use. The operator may have this information, but if no 173 such information is available then sending an existing flow 174 descriptor excluding the BID could serve as an indication for the 175 mobile node to take action and change access for a specific flow. 177 4. Protocol Operation 179 [RFC6089] makes use of Binding Update (BU) /Binding 180 Acknowledgement(BA) signalling to forward, i.e. register or discard a 181 flow binding in a home agent. That is, flow binding operations are 182 always initiated from the mobile node. The mechanism specified in 183 this document is complimentary to the method described in [RFC6089]. 184 It is assumed that the home agent has already created Binding Cache 185 entries for the mobile node before launching flow binding operations. 187 In this document, one new Mobility Header and two new messages are 188 defined, that is, Flow Binding Indication (FBI) Section 6.1.1 and 189 Flow Binding Acknowledgement (FBA)Section 6.1.2. FBI is used by the 190 home agent to initiate flow binding operations, while FBA is used for 191 acknowledging FBI. 193 4.1. Adding flow bindings 195 Adding the flow binding implies associating a flow with a particular 196 care-of address for the mobile node. The care-of address concerned 197 with the flow binding is present in the destination address of the 198 packet or the alternate care-of address option. Alternatively, the 199 care-of address may be indicated by the Target Care-of Address sub- 200 option defined in Section 6.2.2. Binding Identification number (BID) 201 described in [RFC5648] is not used in the flows initiated by the home 202 agent. 204 When adding a new flow binding, the home agent sends a FBI with a 205 Flow Identification Mobility option to the mobile node. The Flow 206 Identification Mobility option defined in [RFC6089] includes a unique 207 Flow Identifier (FID). The Action field of the option MUST indicate 208 an Add operation defined in Section 6.2.1. The FID needs only be 209 unique for the receiver of the message that adds a flow, i.e. the 210 same FID can be used across different receivers of the message. A 211 lifetime value is included to indicate the remaining lifetime of the 212 flow binding. 214 4.2. Deleting flow bindings 216 When removing a flow binding, the home agent node sends a FBI with a 217 Flow Identification Mobility option in which Action field indicates 218 Delete operation. The Flow Identification Mobility option includes a 219 unique FID for the mobile node to locate the flow binding and remove 220 it. 222 The trigger for the delete operation is MN sending a BU with Flow 223 Identification Mobility Option that registers a new flow. Using the 224 delete operation the home agent deletes the new flow registered by 225 MN. 227 4.3. Modifying flow bindings 229 When modifying a flow binding (either the care-of address or other 230 attributes of the flow), the home agent sends the mobile node a FBI 231 message with Flow Identification Mobility option. The option 232 includes the FID for the binding being modified. A Traffic Selector 233 sub-option may come with the Flow Identification Mobility Option and 234 contain the new attributes needed to classify the flow such as in 235 [RFC6088]. Hence, flow modification is essentially a process where 236 an existing flow definition is removed and a new flow (included in 237 the option) is added and given the same FID as the flow that was 238 removed. 240 4.4. Refreshing flow bindings 242 A flow binding is refreshed by simply including the Flow 243 Identification Mobility option with Refresh Action field in the FBI 244 message. The message should be sent before the expiration of the 245 flow binding. The message updates existing bindings with new 246 information. Hence, all information previously sent in the last 247 refreshing message need to be resent, otherwise such information will 248 be lost. 250 4.5. Moving flow bindings 252 The home agent can move a flow associated to one interface of the 253 multi-interfaced mobile node to another by sending a FBI message to 254 the mobile node. A Flow Identification Mobility option whose Action 255 field is set to Move is included. The address of the target 256 interface is also included in the Flow Identification Mobility option 257 in Target Care-of Address sub-option. 259 In some cases the mobile node manually decides to move an IP Flow 260 from one interface, e.g. 3GPP to another e.g. WLAN. The home agent 261 receives such a request to forward a flow and performs the action. 262 We recognize that the manual intervention is always possible and 263 generally has precedence to other policies. On such a flow HA- 264 initiated move operation SHOULD not be used. If used, MN will move 265 it back and a set of ping-pong move operations will take place. Home 266 agent SHOULD move such a flow only if network conditions require it 267 to be moved such as congestion on the current interface because such 268 conditions can best be detected by the home agent only and not by the 269 mobile nodes. 271 4.6. Revoking flow bindings 273 Home agent revokes a flow binding registration by the mobile node, 274 i.e. flow identification mobility option sent by MN with action set 275 to forward. One possible reason is the home agent is overloaded. 276 There could be other reasons. 278 HA sends the mobile node a FBI message with flow identification 279 mobility option. HA includes the flow identification mobility option 280 received from MN. HA sets the action field to Revoke. 282 MN MUST send a FBA message to indicate that it has received FBI 283 message of flow revocation. If MN accepts the revocation it MUST set 284 the status code to 0 for success. 286 5. Handling of the Flow Bindings List 288 Flow bindings list defined in [RFC6089] needs to be modified after 289 each protocol operation defined above as follows: 291 If FBI contains a flow binding add operation and if the corresponding 292 FBA has a status code equal to zero, home agent MUST add a new entry 293 to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action 294 fields are taken from the Flow Identification Mobility Option. BID 295 is copied from the Binding Reference sub-option. Active/Inactive 296 Flag is set to Active. Note that if BID is not available it may be 297 replaced by Care-of-Address. 299 If FBI contains a flow binding delete 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 delete the 302 entry. 304 If the home agent sends a Binding Revocation Indication message with 305 Flow Mobility Option where the action field is set to Revoke and if 306 the corresponding Binding Revocation Acknowledgement message 307 indicates acceptance, home agent MUST locate the list entry 308 corresponding to this flow and then delete the entry. 310 If FBI contains a flow binding modify operation and if the 311 corresponding FBA has a status code equal to zero, home agent MUST 312 delete the list entry corresponding to this flow and then add a new 313 entry setting the values as defined in the Flow Identification 314 Mobility Option. 316 If FBI contains a flow binding refresh operation and if the 317 corresponding FBA has a status code equal to zero, home agent MUST 318 locate the list entry corresponding to this flow and then set Active/ 319 Inactive Flag to Active. 321 If FBI contains a flow binding move operation and if the 322 corresponding FBA has a status code equal to zero, home agent MUST 323 locate the list entry corresponding to this flow and then change the 324 BID value to the Care-of-Address in the Flow Identification Mobility 325 Option. 327 If FBI contains a flow binding switch operation and if the 328 corresponding FBA has a status code equal to zero, home agent MUST 329 locate the list entry corresponding to this flow and then delete the 330 entry. 332 Flow binding operations apply equally to IPv6 packets as well as IPv4 333 packets as in Dual-Stack Mobile IPv6 [RFC5555]. 335 6. Flow Binding Messages and Options 337 6.1. Mobility Header 339 The messages described below follow the Mobility Header format 340 specified in Section 6.1 of [RFC3775]. 342 6.1.1. Flow Binding Indication 344 The Flow Binding Indication messages are used by the home agent to 345 initiate flow binding operations to the mobile node. The Flow 346 Binding Indication messages use the MH Type value (IANA-TBD1) for 347 Flow Binding message and a Flow Binding Type value of 1, and the 348 format of the Message Data field in the Mobility Header is as 349 follows: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Flow Binding Type = 1 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Sequence # | Trigger |A| Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 . . 359 . Mobility options . 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 1: Flow Binding Indication Message Type 365 Sequence # 367 A 16-bit unsigned integer used by the home agent to match a 368 returned Flow Binding Acknowledgement with this Flow Binding 369 Indication. It could be a random number. 370 Trigger 372 8-bit unsigned integer indicating the event which triggered the 373 home agent to send the Flow Binding Indication message. The 374 following Trigger values are currently defined: 375 0 Reserved 376 1 Unspecified 377 2 Administrative Reason 378 3 Possible Out-of Sync BCE State 379 250-255 Reserved For Testing Purposes only 380 All other values are Reserved 382 Acknowledge (A) 384 The Acknowledge (A) bit is set by the home agent to request a Flow 385 Binding Acknowledgement be returned upon receipt of the Flow 386 Binding Indication. 387 Reserved 389 These fields are unused. They MUST be initialized to zero by the 390 sender and MUST be ignored by the receiver. 391 Mobility Options 393 Variable-length field of such length that the complete Mobility 394 Header is an integer multiple of 8 octets long. Flow 395 Identification Mobility Options are included in this field. 397 6.1.2. Flow Binding Acknowledgement 399 The Flow Binding Acknowledgement is used to acknowledge receipt of a 400 Flow Binding Indication. The mobile node sends FBA message to 401 acknowledge the reception of FBI to Add, Delete, Modify, Refresh, 402 Move, or Switch a flow binding. On receiving messages with Flow 403 Identification Mobility Option(s), the mobile node should copy each 404 Flow Identification Mobility Option to the Acknowledgement messages. 405 The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1) 406 for Flow Binding message and a Flow Binding Type value of 2. When 407 this value is indicated in the MH Type field, the format of the 408 Message Data field in the Mobility Header is as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Flow Binding Type = 2 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Sequence # | Status | Reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 . . 419 . Mobility options . 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 2: Flow Binding Acknowledgement Message Type 425 Sequence # 427 The sequence number in the Flow Binding Acknowledgement is copied 428 from the Sequence Number field in the Flow Binding Indication. 429 Status 431 8-bit unsigned integer indicating the result of processing the 432 Flow Binding Indication message by the receiving mobile node. 433 Values of the Status field less than 128 indicate that the Flow 434 Binding Indication was processed successfully by the receiving 435 node. Values greater than or equal to 128 indicate that the Flow 436 Binding Indication was rejected by the receiving node. The 437 following status values are currently defined: 438 0 success 439 128 Binding Does NOT Exist 440 All other values are Reserved 441 Mobility Options 443 Variable-length field of such length that the complete Mobility 444 Header is an integer multiple of 8 octets long. This field 445 contains zero or more TLV-encoded mobility options. Flow 446 Identification Mobility Options are included in this field. 448 6.1.3. Flow Binding Revocation Extensions 450 This specification enables Binding Revocation Indication and Binding 451 Revocation Acknowledgement messages to carry Flow Identification 452 Mobility Options as defined in [RFC6089] with extensions defined in 453 this document. 455 6.2. New Options 457 6.2.1. New Actions in Flow Identification Mobility Option 459 This specification defines new actions to be carried in Action 460 parameter of the Flow Identification Mobility Option defined in 461 [RFC6089]. 463 Action 465 This is a 8-bit field that describes the required processing for 466 the option. It can be assigned one of the following new values in 467 addition to 0-2 already assigned: 468 11 Add a flow binding 469 12 Delete a flow binding 470 13 Modify a flow binding 471 14 Refresh a flow binding 472 15 Move a flow binding 473 16 Revoke a flow binding 474 All other values are reserved 476 6.2.2. Target Care-of-Address sub-option 478 This section introduces the Target Care-of-Address, which may be 479 included in the Flow Identification Mobility Option. This sub-option 480 is used to indicate the mobile node to move a flow binding from one 481 interface to another. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |Sub-opt Type | Sub-opt Len | Reserved | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Target Care-of-Address | 488 . . 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3: Target Care-of-Address Sub-option 493 Sub-opt Type 495 To be assigned by IANA 496 Sub-opt Len 498 Length of the sub-option in 8-octet units 500 Reserved 502 This field is unused. It MUST be initialized to zero by the 503 sender and MUST be ignored by the receiver. 504 Target Care-of-Address 506 The address of an interface that the flow is moved to. This 507 address could be IPv4 or IPv6 address. 509 7. Security Considerations 511 Security issues for this document follow those of [RFC6088], 512 [RFC6089] and [RFC5846]. This specification allows the home agent to 513 manipulate only the binding of a flow(s) that is currently registered 514 with it, which is the same principle described in [RFC5846]. No 515 additional security issue specific to this document is identified. 517 8. IANA considerations 519 This document defines one new Mobility Header and two new mobility 520 options to be used in Flow Binding Initiate and Flow Binding 521 Acknowledge messages. A new Mobility Header Type and new mobility 522 option values (IANA-TBD1 and IANA-TBD2) need to be assigned by IANA. 524 9. References 526 9.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 532 Routers", RFC 5555, June 2009. 534 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 535 in IPv6", RFC 3775, June 2004. 537 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 538 "Traffic Selectors for Flow Bindings", RFC 6088, 539 January 2011. 541 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 542 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 543 Network Mobility (NEMO) Basic Support", RFC 6089, 544 January 2011. 546 9.2. Informative references 548 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 549 and K. Nagami, "Multiple Care-of Addresses Registration", 550 RFC 5648, October 2009. 552 Authors' Addresses 554 Hidetoshi Yokota 555 KDDI Lab 556 2-1-15 Ohara 557 Fujimino 558 Saitama, Japan 356-8502 560 Phone: 561 Email: yokota@kddilabs.jp 563 Dae-Sun Kim 564 KDDI Lab 565 2-1-15 Ohara 566 Fujimino 567 Saitama, Japan 356-8502 569 Phone: 570 Email: da-kim@kddilabs.jp 572 Behcet Sarikaya 573 Huawei USA 574 5340 Legacy Drive Building 3 575 Plano, TX 75024 577 Phone: +1 469-277-5839 578 Email: sarikaya@ieee.org 580 Frank Xia 581 Huawei USA 582 5430 Legacy Dr. Building 3 583 Plano, TX 75024 585 Phone: 586 Email: xiayangsong@huawei.com