diff options
Diffstat (limited to 'doc/rfc/rfc7109.txt')
| -rw-r--r-- | doc/rfc/rfc7109.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7109.txt b/doc/rfc/rfc7109.txt new file mode 100644 index 0000000..f826751 --- /dev/null +++ b/doc/rfc/rfc7109.txt @@ -0,0 +1,1011 @@ + + + + + + +Independent Submission H. Yokota +Request for Comments: 7109 KDDI Lab +Category: Experimental D. Kim +ISSN: 2070-1721 JEJU Technopark + B. Sarikaya + F. Xia + Huawei + February 2014 + + + Flow Bindings Initiated by Home Agents for Mobile IPv6 + +Abstract + + There are scenarios in which the home agent needs to trigger flow + binding operations towards the mobile node, such as moving a flow + from one access network to another based on network resource + availability. In order for the home agent to be able to initiate + interactions for flow bindings with the mobile node, this document + defines new signaling messages and sub-options for Mobile IPv6. Flow + bindings initiated by a home agent are supported for mobile nodes + enabled by both IPv4 and IPv6. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This is a contribution to the RFC Series, independently + of any other RFC stream. The RFC Editor has chosen to publish this + document at its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7109. + + + + + + + + + + + +Yokota, et al. Experimental [Page 1] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. Use Cases .......................................................3 + 3.1. QoS Provisioning ...........................................3 + 3.2. Traffic Offload from Congested Network .....................4 + 3.3. Flow Movement or Deletion in an Emergency Situation ........4 + 3.4. Service-Specific Data Cap ..................................4 + 4. Protocol Operation ..............................................4 + 4.1. Adding Flow Bindings .......................................5 + 4.2. Deleting Flow Bindings .....................................6 + 4.3. Modifying Flow Bindings ....................................6 + 4.4. Refreshing Flow Bindings ...................................6 + 4.5. Moving Flow Bindings .......................................7 + 4.6. Revoking Flow Bindings .....................................7 + 5. Handling of the Flow Bindings List ..............................8 + 6. Flow Binding Messages and Options ...............................9 + 6.1. Mobility Header ............................................9 + 6.1.1. Flow Binding Indication .............................9 + 6.1.2. Flow Binding Acknowledgement .......................10 + 6.1.3. Flow Binding Revocation Extensions .................11 + 6.2. New Options ...............................................12 + 6.2.1. Flow Binding Action Sub-Option .....................12 + 6.2.2. Target Care-of Address Sub-Option ..................13 + 7. Security Considerations ........................................13 + 8. Protocol Constants .............................................14 + 9. IANA Considerations ............................................14 + 10. References ....................................................16 + 10.1. Normative References .....................................16 + 10.2. Informative References ...................................17 + + + + + + + + +Yokota, et al. Experimental [Page 2] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +1. Introduction + + [RFC6089] allows a mobile node (MN) to bind a particular flow to a + care-of address (CoA) without affecting other flows using the same + home address. BU/BA (Binding Update / Binding Acknowledgement) + messages are extended for the mobile node to add, delete, modify, + move, refresh, and revoke flow bindings in a home agent (HA). The + operations are always initiated by the mobile node. + + While the mobile node manipulates flow bindings by, e.g., the user + interaction or the change of the attached link condition, these + operations are also required for network-related reasons such as + dynamic QoS control in the network, load balancing, or maintenance in + mobility agent nodes. For the latter case, the mobile node is not + very aware of the transport network condition away from it or of the + policy and charging status controlled by the operator; thus, the + network needs to request that the mobile node handle proper flow + bindings. + + This document defines a new Mobility Header and messages in order for + the home agent to request that the mobile node initiate flow bindings + in a timely manner. Flow mobility is also supported for mobile nodes + with an IPv4 home address and an IPv4 address of the home agent, as + described in [RFC5555]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The terminology in this document is based on the definitions in + [RFC6275] and [RFC6089]. + +3. Use Cases + +3.1. QoS Provisioning + + When the user launches a video chat application and starts sending + voice and video to the other end, the network may need to provide + different QoS treatments to these media based on the operator's + policy. In such a case, the network needs to request the user or + mobile node to establish separate flows for voice and video. + + + + + + + + +Yokota, et al. Experimental [Page 3] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +3.2. Traffic Offload from Congested Network + + The 3G operator may want to move traffic flows from the 3G access + network to another network (e.g., Wi-Fi network) due to instantaneous + traffic increases in the 3G access network. Fine-grained traffic + offload is desirable. For example, Voice over IP (VoIP) flows based + on IP Multimedia Subsystems (IMS) must stay in the mobile core + network while video-streaming flows provided by servers on the + Internet could bypass the mobile core network via Wi-Fi access. + Since the network knows more about its conditions and has access to + the policy server, more timely and well-controlled traffic offloading + is possible. The home agent sends an updated flow descriptor to be + offloaded to the mobile node. + +3.3. Flow Movement or Deletion in an Emergency Situation + + In an emergency situation caused by a natural disaster, it is + necessary to accept as many voice calls as possible for inquiries to + confirm the safety status of family and friends, while non-critical + services such as gaming would be considered lower priority. In order + to save the 3G / Long Term Evolution (LTE) radio resources for + emergency services, non-critical services may need to be moved to + another access network or closed down. The home agent requests that + the mobile node use Wi-Fi access for non-critical application flows + or terminate them gracefully, e.g., by letting it notify the user of + possible QoS degradation or ask him/her to finish the corresponding + applications before taking any action. + +3.4. Service-Specific Data Cap + + The mobile operator offers a mobile broadband service with a flat + rate subscription limited to 5 GB per month. Once the allotment is + used up, the service is downgraded to 64 kbits/s. This limitation, + however, is not applied to IMS-based services (e.g., Voice over LTE + (VoLTE)), while video conversations over the Internet will be + affected. The operator can indicate this to the user by sending + modified flow descriptors as a proposal to adjust the communication + data rate or change access for an ongoing session. + +4. Protocol Operation + + [RFC6089] makes use of BU/BA signaling to forward, i.e., register or + discard, a flow binding in a home agent. Flow binding operations are + always initiated from the mobile node. The basic principle of this + specification is that the home agent prompts the mobile node to + perform flow binding operations. For this purpose, a new Mobility + Header and two new messages, that is, Flow Binding Indication (FBI) + and Flow Binding Acknowledgement (FBA), are defined. An FBI is used + + + +Yokota, et al. Experimental [Page 4] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + by the home agent to request flow binding operations to the mobile + node, and an FBA is used for acknowledging an FBI. In order for the + flow binding operation to be complete, a BU/BA exchange MUST be + initiated by the mobile node after an FBI/FBA exchange. + + It is assumed that the home agent has already created binding cache + entries for the mobile node before launching flow binding operations. + + Due to access-network change on the mobile-node side, some interfaces + that used to be active may not be valid at the time of the flow + binding operation by the home agent, in which case, even if the HA + sends the FBI to the MN, the FBA will not return. After + retransmitting the FBIs for MAX_FBI_RETRIES times and not receiving + the FBA, the HA determines that the target interface is not + available. + + If the mobile node does not support the FBI message, it responds with + a Binding Error message with status set to 2 (unrecognized Mobility + Header (MH) type value) as described in [RFC6275]. When the Binding + Error message with status set to 2 is received in response to an FBI + message, the home agent MUST NOT use an FBI message with that mobile + node again. + +4.1. Adding Flow Bindings + + Adding the flow binding implies associating a particular flow with + one of the care-of addresses on the mobile node. The care-of address + concerned with the flow binding is present in the destination address + of the packet or the alternate care-of address option. + Alternatively, the care-of address may be indicated by the Target + Care-of Address sub-option defined in Section 6.2.2. + + When adding a new flow binding, the home agent sends an FBI with a + Flow Identification Mobility option to the mobile node. In Figure 1, + which is shown as an example for this operation, the mobile node + exchanges both voice and video over FID#1 (Flow Identifier #1). + Based on the operator's policy, the network determines if it needs to + provide separate QoS for the video flow, and the home agent sends the + FBI to the mobile node. The Flow Identification Mobility option + defined in [RFC6089] includes the current FID and the Traffic + Selector (TS) to specify the video flow. The Flow Binding Action + sub-option MUST indicate the Add operation defined in Section 6.2.1. + The mobile node returns the FBA to the home agent with the same + options. The BU/BA exchange follows afterwards to perform the actual + flow binding as defined in [RFC6088], and the video traffic is + exchanged over FID#2. + + + + + +Yokota, et al. Experimental [Page 5] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + +----+ +----+ + | MN | | HA | + +----+ +----+ + | FID#1(voice+video) | + |/==============================\| + |\==============================/| + | | + | FBI(add,FID#1,TS[video]) | + |<-------------------------------| + | FBA(FID#1,TS[video]) | + |------------------------------->| + | BU(FID#2,TS[video]) | + |------------------------------->| + | BA(FID#2,TS[video]) | + |<-------------------------------| + | | + | FID#1(voice) | + |<==============================>| + | FID#2(video) | + |<==============================>| + + Figure 1: Example Call Flow for Adding a Flow Binding + +4.2. Deleting Flow Bindings + + When removing a flow binding, the home agent sends an FBI with a Flow + Identification Mobility option in which the Flow Binding Action sub- + option indicates the Delete operation. The Flow Identification + Mobility option includes a unique FID for the mobile node to locate + the flow binding and remove it. + +4.3. Modifying Flow Bindings + + When modifying a flow binding (e.g., changing QoS attributes of the + flow as defined in [PMIP6-QOS]) is needed, the home agent sends the + mobile node an FBI message with the Flow Identification Mobility + option. The option includes the FID to be modified. A Traffic + Selector sub-option MAY come with the Flow Identification Mobility + option and contain new attributes, e.g., the in Quality of Service + option. + +4.4. Refreshing Flow Bindings + + A flow binding is refreshed by simply including the Flow + Identification Mobility option with the Refresh Action field in the + FBI message. The message should be sent before the expiration of the + flow binding. The message updates existing bindings with new + + + + +Yokota, et al. Experimental [Page 6] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + information. Hence, all information previously sent in the last + refreshing message need to be resent; otherwise, such information + will be lost. + +4.5. Moving Flow Bindings + + The home agent can request to move a flow associated with one + interface of the multi-interfaced mobile node to another by sending + an FBI message to the mobile node. The Action field of the Flow + Binding Action sub-option is set to Move, and the address of the + target interface is also included in the Target Care-of Address sub- + option. After the FBA is returned to the home agent, the flow + mobility is performed by the mobile node. Figure 2 shows the + movement of a flow label as FID from the interface with sCoA to that + with tCoA, which is stored in the Binding Identity Mobility option. + + +----+ +----+ + | MN | | HA | + +----+ +----+ + |<=sCoA | + | |<=tCoA | + | | FBI(FID,tCoA) | + |<--------------------------------| + | | FBA(FID,tCoA) | + |-------------------------------->| + | | | + | | BU(BID[tCoA],FID) | + | |------------------------------>| + | | BA(BID[tCoA],FID) | + | |<------------------------------| + | | | + + Figure 2: Example Call Flow for Moving a Flow Binding + +4.6. Revoking Flow Bindings + + When the home agent or the network attached to it is overloaded, the + home agent can revoke a flow binding registered by the mobile node. + The home agent sends the mobile node an FBI message with a Flow + Identification Mobility option in which the Flow Binding Action sub- + option indicates the Revoke operation. When the MN receives the FBI + message with the Revoke operation, it decides whether the flow should + be removed (de-registration) or moved to another interface and + returns the FBA with an appropriate status code. The mobile node + SHOULD take an action by sending a new BU, for example, to deregister + the flow. + + + + + +Yokota, et al. Experimental [Page 7] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + The difference between revoking and deleting flow bindings + (Section 4.2) is that the target flow may be revoked by the network + with the procedures defined in [RFC5846] even if the mobile node does + not take any action. + +5. Handling of the Flow Bindings List + + The flow bindings list defined in [RFC6089] needs to be updated as + follows after each protocol operation defined above is performed: + + If an FBI contains a flow binding Add operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST add a new entry to the flow bindings list. The FID, Flow + Descriptor, FID-PRI, and Action fields are taken from the Flow + Identification Mobility option. The binding identifier (BID) is + copied from the Binding Reference sub-option. The Active/Inactive + Flag is set to Active. Note that if BID is not available, it may be + replaced by Target Care-of Address. + + If an FBI contains a flow binding Delete operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST locate the list entry corresponding to this flow and then delete + the entry. + + If the home agent sends a Binding Revocation Indication message with + the Flow Identification Mobility option with the action field set to + Revoke and if the corresponding Binding Revocation Acknowledgement + message indicates acceptance, the home agent MUST locate the list + entry corresponding to this flow and then delete the entry. + + If an FBI contains a flow binding Modify operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST delete the list entry corresponding to this flow and then add a + new entry, setting the values as defined in the Flow Identification + Mobility option. + + If an FBI contains a flow binding Refresh operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST locate the list entry corresponding to this flow and then set + the Active/Inactive Flag to Active. + + If an FBI contains a flow binding Move operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST locate the list entry corresponding to this flow and then change + the BID value to the care-of address in the Flow Identification + Mobility option. + + + + + +Yokota, et al. Experimental [Page 8] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + If an FBI contains a flow binding Revoke operation and if the + corresponding FBA has a status code equal to zero, the home agent + MUST locate the list entry corresponding to this flow and then delete + the entry. + + Flow binding operations apply equally to IPv4 packets and IPv6 + packets as per Dual-Stack Mobile IPv6 [RFC5555]. In order to support + the situation where there is a NAT/firewall between the mobile node + and home agent, NAT detection and NAT keepalive mechanisms defined in + [RFC5555] MUST be used. When the mobile node and home agent are in + IPv6-only and IPv4-only networks respectively and NAT64 [RFC6146] + resides in between, each node would behave as if the other node was + in the same network domain. Even though this scenario is not fully + described in [RFC5555], the initial mobility binding is always + performed by the mobile node, and the binding cache is created in the + home agent. The destination address of the FBI SHALL be the mobile + node's IPv4 care-of address in the binding cache entry. + +6. Flow Binding Messages and Options + +6.1. Mobility Header + + The messages described below follow the Mobility Header format + specified in Section 6.1 of [RFC6275]. + +6.1.1. Flow Binding Indication + + Flow Binding Indication messages are used by the home agent to + initiate flow binding operations to the mobile node. Flow Binding + Indication messages use the MH Type value (21) for Flow Binding + messages and a Flow Binding Type value of 1, and the format of the + Message Data field in the Mobility Header is as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flow Binding Type = 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Trigger |A| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility options . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Flow Binding Indication Mobility Header Format + + + + +Yokota, et al. Experimental [Page 9] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + Sequence # + A 16-bit unsigned integer used by the home agent to match a + returned Flow Binding Acknowledgement with the Flow Binding + Indication. It could be a random number. + + Trigger + 8-bit unsigned integer indicating the event that triggered the + home agent to send the Flow Binding Indication message. The + following Trigger values are currently defined: + + 0 Reserved + + 1 Unspecified + + 2 Administrative Reason + + 3 Possible Out-of-Sync BCE State + + 250-255 Reserved for Testing Purposes Only + + All other values are unassigned. + + Acknowledge (A) + The Acknowledge (A) bit is set by the home agent to request that a + Flow Binding Acknowledgement be returned upon receipt of the Flow + Binding Indication. + + Reserved + These fields are unused. They MUST be initialized to zero by the + sender and MUST be ignored by the receiver. + + Mobility options + Variable-length field of such length that the complete Mobility + Header is an integer multiple of 8 octets long. Flow + Identification Mobility options are included in this field. + +6.1.2. Flow Binding Acknowledgement + + The Flow Binding Acknowledgement is used to acknowledge receipt of a + Flow Binding Indication. The mobile node sends an FBA message to + acknowledge the reception of an FBI to add, delete, modify, refresh, + move, or revoke a flow binding. On receiving messages with Flow + Identification Mobility option(s), the mobile node should copy each + Flow Identification Mobility option to the Acknowledgement message. + The Flow Binding Acknowledgement has the MH Type value (21) for Flow + Binding messages and a Flow Binding Type value of 2. When this value + is indicated in the MH Type field, the format of the Message Data + field in the Mobility Header is as follows: + + + +Yokota, et al. Experimental [Page 10] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flow Binding Type = 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Status | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility options . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Flow Binding Acknowledgement Mobility Header Format + + Sequence # + The sequence number in the Flow Binding Acknowledgement is copied + from the Sequence Number field in the Flow Binding Indication. + + Status + 8-bit unsigned integer indicating the result of processing the + Flow Binding Indication message by the receiving mobile node. + Values less than 128 in the Status field indicate that the Flow + Binding Indication was processed successfully by the receiving + node. Values greater than or equal to 128 indicate that the Flow + Binding Indication was rejected by the receiving node. The + following status values are currently defined: + + 0 Success + + 128 Binding (target CoA) Does NOT Exist + + 129 Action NOT Authorized + + All other values are unassigned. + + Mobility options + Variable-length field of such length that the complete Mobility + Header is an integer multiple of 8 octets long. This field + contains zero or more TLV-encoded mobility options. Flow + Identification Mobility options are included in this field. + +6.1.3. Flow Binding Revocation Extensions + + This specification enables Binding Revocation Indication and Binding + Revocation Acknowledgement messages to carry Flow Identification + Mobility options as defined in [RFC6089] with the extensions defined + in this document. + + + +Yokota, et al. Experimental [Page 11] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +6.2. New Options + + This document defines new Flow Identification sub-options that are + included in the Flow Identification Mobility option specified in + [RFC6089]. + +6.2.1. Flow Binding Action Sub-Option + + This section defines a new sub-option for flow binding actions, which + MUST be included in the Flow Identification Mobility option when it + is sent from the home agent to the mobile node via the FBI message. + The format of this sub-option is shown in Figure 5. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Sub-opt Type |Sub-opt Length | Reserved | Action | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Flow Binding Action Sub-Option + + Sub-opt Type + 4 + + Sub-opt Length + Length of the sub-option in octets, excluding the Sub-opt Type and + Sub-opt Length fields. + + Action + This is a 8-bit field that describes the required processing for + the option. It can be assigned one of the following new values: + + 11 Add a flow binding + + 12 Delete a flow binding + + 13 Modify a flow binding + + 14 Refresh a flow binding + + 15 Move a flow binding + + 16 Revoke a flow binding + + All other values are unassigned. + + + + + + +Yokota, et al. Experimental [Page 12] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +6.2.2. Target Care-of Address Sub-Option + + This section introduces the Target Care-of Address sub-option, which + may be included in the Flow Identification Mobility option. This + sub-option is used to indicate to the mobile node that a flow binding + is to be moved from one interface to another. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Sub-opt Type |Sub-opt Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Target Care-of Address | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Target Care-of Address Sub-Option + + Sub-opt Type + 5 + + Sub-opt Length + Length of the sub-option in octets, excluding the Sub-opt Type and + Sub-opt Length fields. + + Reserved + This field is unused. It MUST be initialized to zero by the + sender and MUST be ignored by the receiver. + + Target Care-of Address + The address of an interface that the flow is moved to. This + address could be an IPv4 or IPv6 address. This sub-option MUST be + included when the action taken is "15 Move a flow binding". + +7. Security Considerations + + Security issues for this document follow those of [RFC6088], + [RFC6089], and [RFC5846]. This specification allows the home agent + to manipulate only the binding of a flow(s) that is currently + registered with it, which is the same principle described in + [RFC5846]. No additional security issue specific to this document is + identified. + + + + + + + + + +Yokota, et al. Experimental [Page 13] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +8. Protocol Constants + + Maximum FBI retries (MAX_FBI_RETRIES) + This variable specifies the maximum number of times the HA MAY + retransmit a Flow Binding Indication message when the FBA is not + returned within the time period specified by MAX_FBA_TIMEOUT. The + default value for this parameter is 3. + + Maximum FBA timeout (MAX_FBA_TIMEOUT) + This variable specifies the maximum time in seconds the HA MUST + wait before retransmitting another FBI message. The default for + this parameter is 3 seconds. + +9. IANA Considerations + + IANA has taken the actions described below. + + Action-1 + This specification defines a new Mobility Header Type, "Flow + Binding Message". This Mobility Header message is described in + Section 6.1, and the type value for this messages is 21, which has + been assigned in the "Mobility Header Types - for the MH Type + field in the Mobility Header" registry. + + Action-2 + This specification defines "Flow Binding Type". IANA has created + a new sub-registry within the "Mobile IPv6 parameters" registry. + Flow Binding Type is described in Sections 6.1.1 and 6.1.2, which + reserve the following values: + + +-------+------------------------------+--------------+ + | Value | Description | Reference | + +-------+------------------------------+--------------+ + | 0 | Unassigned | | + +-------+------------------------------+--------------+ + | 1 | Flow Binding Indication | [RFC7109] | + +-------+------------------------------+--------------+ + | 2 | Flow Binding Acknowledgement | [RFC7109] | + +-------+------------------------------+--------------+ + | 3-255 | Unassigned | | + +--------------------------------------+--------------+ + + Future assignments in the "Flow Binding Type" registry are to be + made through RFC Required [RFC5226]. + + + + + + + +Yokota, et al. Experimental [Page 14] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + Action-3 + This specification defines "Flow Binding Indication Triggers". + IANA has created a new sub-registry within the "Mobile IPv6 + parameters" registry. The trigger values are described in + Section 6.1.1, which reserves the following values: + + +---------+------------------------------------+--------------+ + | Value | Description | Reference | + +---------+------------------------------------+--------------+ + | 0 | Reserved | [RFC7109] | + +---------+------------------------------------+--------------+ + | 1 | Unspecified | [RFC7109] | + +---------+------------------------------------+--------------+ + | 2 | Administrative Reason | [RFC7109] | + +---------+------------------------------------+--------------+ + | 3 | Possible Out-of-Sync BCE State | [RFC7109] | + +---------+------------------------------------+--------------+ + | 4-249 | Unassigned | | + +---------+------------------------------------+--------------+ + | 250-255 | Reserved for Testing Purposes Only | [RFC7109] | + +----------------------------------------------+--------------+ + + Future assignments in the "Flow Binding Indication Triggers" + registry are to be made through RFC Required [RFC5226]. + + Action-4 + This specification defines "Flow Binding Acknowledgement Status + Codes". IANA has created a new sub-registry within the "Mobile + IPv6 parameters" registry. The status codes are described in + Section 6.1.2, which reserves the following values: + + +---------+-------------------------------------+--------------+ + | Value | Description | Reference | + +---------+-------------------------------------+--------------+ + | 0 | Success | [RFC7109] | + +---------+-------------------------------------+--------------+ + | 1-127 | Unassigned | | + +---------+-------------------------------------+--------------+ + | 128 | Binding (target CoA) Does NOT Exist | [RFC7109] | + +---------+-------------------------------------+--------------+ + | 129 | Action NOT Authorized | [RFC7109] | + +---------+-------------------------------------+--------------+ + | 130-255 | Unassigned | | + +---------+-------------------------------------+--------------+ + + Future assignments in the "Flow Binding Acknowledgement Status + Codes" are to be made through RFC Required [RFC5226]. + + + + +Yokota, et al. Experimental [Page 15] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + + Action-5 + This specification defines two new Flow Identification sub- + options: the "Flow Binding Action" sub-option and "Target Care-of + Address" sub-option. These sub-options are described in Sections + 6.2.1 and 6.2.2, and the sub-option values are 4 and 5, + respectively, as assigned in the "Flow Identification Sub-options" + registry. + + Action-6 + This specification defines "Flow Binding Action Values". IANA has + created a new sub-registry within the "Mobile IPv6 parameters" + registry. The action values are described in Section 6.2.1, which + reserves the following values: + + +--------+-------------------------------------+--------------+ + | Value | Description | Reference | + +--------+-------------------------------------+--------------+ + | 0-10 | Unassigned | | + +--------+-------------------------------------+--------------+ + | 11 | Add a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 12 | Delete a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 13 | Modify a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 14 | Refresh a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 15 | Move a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 16 | Revoke a flow binding | [RFC7109] | + +--------+-------------------------------------+--------------+ + | 17-255 | Unassigned | | + +--------+-------------------------------------+--------------+ + + Future assignments in the "Flow Binding Action Values" registry + are to be made through RFC Required [RFC5226]. + + + + + + + + + + + + + + + +Yokota, et al. Experimental [Page 16] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts + and Routers", RFC 5555, June 2009. + + [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., + and P. Yegani, "Binding Revocation for IPv6 Mobility", + RFC 5846, June 2010. + + [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. + Montavont, "Traffic Selectors for Flow Bindings", RFC + 6088, January 2011. + + [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., + and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and + Network Mobility (NEMO) Basic Support", RFC 6089, + January 2011. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from + IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, July 2011. + +10.2. Informative References + + [PMIP6-QOS] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. + Gundavelli, "Quality of Service Option for Proxy Mobile + IPv6", Work in Progress, December 2013. + + + + + + + + + + + + +Yokota, et al. Experimental [Page 17] + +RFC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 + + +Authors' Addresses + + Hidetoshi Yokota + KDDI Lab + 2-1-15 Ohara + Fujimino, Saitama 356-8502 + Japan + + EMail: yokota@kddilabs.jp + + + Dae-Sun Kim + JEJU Technopark + 217, Jungang-ro (St) + Jejusi, Jeju Special Self-Governing Province 690-787 + Korea + + EMail: dskim@jejutp.or.kr + + + Behcet Sarikaya + Huawei USA + 5340 Legacy Drive, Building 3 + Plano, TX 75024 + US + + Phone: +1 469-277-5839 + EMail: sarikaya@ieee.org + + + Frank Xia + Huawei Technologies Co., Ltd. + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + Phone: +86-25-56625443 + EMail: xiayangsong@huawei.com + + + + + + + + + + + + + +Yokota, et al. Experimental [Page 18] + |