Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: August 5, 2010 Huawei USA February 1, 2010 Local Mobility Anchor Initiated Flow Binding for Proxy Mobile IPv6 draft-sarikaya-netext-lma-init-flow-binding-00 Abstract In network based mobility, flow mobility also should be network based. This document defines two new Mobility Headers for a Local Mobility Anchor to control flow binding in a mobile node. The proxy binding update messages containing these mobility headers are exchanged with Mobile Access Gateways. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2010. Copyright Notice Copyright (c) 2010 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 Sarikaya & Xia Expires August 5, 2010 [Page 1] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Adding flow bindings . . . . . . . . . . . . . . . . . . . 4 3.2. Deleting flow bindings . . . . . . . . . . . . . . . . . . 4 3.3. Modifying flow bindings . . . . . . . . . . . . . . . . . 4 3.4. Refreshing flow bindings . . . . . . . . . . . . . . . . . 5 3.5. Moving flow bindings . . . . . . . . . . . . . . . . . . . 5 3.6. Switching flow bindings . . . . . . . . . . . . . . . . . 5 3.7. Acknowledging flow bindings . . . . . . . . . . . . . . . 5 4. Handling of the Flow Bindings List . . . . . . . . . . . . . . 6 5. Mobile Access Gateway Considerations . . . . . . . . . . . . . 6 6. IPv4 Flow Mobility Support . . . . . . . . . . . . . . . . . . 7 7. Flow Binding messages and options . . . . . . . . . . . . . . 7 7.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 7 7.1.1. Proxy Flow Binding Indication . . . . . . . . . . . . 8 7.1.2. Proxy Flow Binding Acknowledgement . . . . . . . . . . 10 7.2. New Options . . . . . . . . . . . . . . . . . . . . . . . 11 7.2.1. Flow Attribute option . . . . . . . . . . . . . . . . 11 7.2.2. Alternate Local Mobility Anchor sub-option . . . . . . 13 7.2.3. Target Care-of-Address sub-option . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative references . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Sarikaya & Xia Expires August 5, 2010 [Page 2] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 1. Introduction In Mobile IPv6, [I-D.ietf-mext-flow-binding] allows a mobile node to bind a particular flow to a care-of address without affecting other flows using the same home address. Binding Update (BU)/Binding Acknowledgement (BA) messages are extended for the mobile node to forward or discard a flow binding in a home agent. The operations are always initiated by the mobile node. In Proxy Mobile IPv6, mobility of the mobile node is managed by the network. Managing flow mobility by the network is inline with the way mobility is managed in PMIPv6. The local mobility anchor would like to initiate flow binding operations, e.g, the local mobility anchor revokes a flow binding because of accounting insufficiency of the mobile node; the local mobility anchor moves a flow binding from one interface to another based on network resource availability; the local mobility anchor provisions default flow binding rules to the mobile node based on the mobile node's default profile. Flow binding operations are sent to Mobile Access Gateway. In some cases they are sent to more than one: the current and future destination MAGs. How these operations are communicated to MNs are out of scope with this document. This document defines two new Mobility Headers and several operations for the local mobility anchor to control flow binding in the mobile node. It is assumed that flow binding state is previously created by Mobile Access Gateways sending Proxy Binding Update (PBU) messages that contain Flow Identification Mobility Options with action field set to 'forward'. LMA forwards such a flow to Proxy-CoA of the mobile node, i.e. MAG's address. 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 [RFC3775] and [I-D.ietf-mext-flow-binding]. 3. Protocol Operation It is assumed that the local mobility anchor has already created Binding Cache entries for the mobile node before launching flow binding operations. Mobile access gateways establish flow binding Sarikaya & Xia Expires August 5, 2010 [Page 3] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 state making use of Proxy Binding Update (PBU) /Proxy Binding Acknowledgement(PBA) signalling to forward or discard flow binding at the local mobility anchor as described in [I-D.xia-netext-flow-binding]. In this document, two Mobility Headers are defined, that is, Proxy Flow Binding Indication (PFBI) in Section 7.1.1 and Proxy Flow Binding Acknowledgement (PFBA) in Section 7.1.2. PFBI is used by the local mobility anchor to initiate flow binding operations, while PFBA is used for acknowledging PFBI. 3.1. Adding flow bindings Adding the flow binding means associating a flow with a particular Proxy-CoA for the mobile node. LMA determines this address as follows internally based on the flow and the technology of the interface. LMA first determines Proxy-CoA and the searches the binding cache to find the corresponding care-of address of MN's interface that connects to this interface. LMA must include Care-of address in Target Care-of-Address sub-option defined in Section 7.2.3. PFBI is sent to Proxy-CoA. When adding a new flow binding, the local mobility anchor sends a PFBI with a Flow Attribute option to the MAG. The Flow Attribute option includes a unique FID. The PRO field of the option MUST indicate an add operation. The FID needs only be unique for the mobile node that PFBI belongs, i.e. the same FID can be used across different mobile nodes to identify different flows. A lifetime value is included to indicate the remaining lifetime of the flow binding. Target care-of address sub-option must be included. 3.2. Deleting flow bindings When removing a flow binding, the local mobility anchor node sends a FBI with a Flow Attribute option whose PRO field indicates Delete operation. The Flow Attribute option includes a unique FID that was assigned when the flow was created to locate the flow binding and remove it. 3.3. Modifying flow bindings When modifying a flow binding (either care-of address or other attributes of the flow), the local mobility anchor sends to the MAG a PFBI message with Flow Attribute option. The option includes the FID for the binding being modified. A flow description option may come with the Flow Attribute option and contain the new attributes needed to classify the flow. Hence, flow modification is essentially a process where an existing flow definition is removed and a new flow Sarikaya & Xia Expires August 5, 2010 [Page 4] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 (included in the option) is added and given the same FID as the flow that was removed. 3.4. Refreshing flow bindings A flow binding is refreshed by simply including the Flow Attribute option with Refresh PRO field in the FBI message. The message should be sent before the expiration of the flow binding. The message updates existing bindings with new information. Hence, all information previously sent in the last refresh message need to be resent, otherwise such information will be lost. 3.5. Moving flow bindings The local mobility anchor can move a flow associated to one interface of the multi-interfaced mobile node to another by sending a FBI message to the MAGs. A Flow Attribute option whose PRO field is Move is included. The address of the target interface of MN is also included in the Flow Attribute option's Target Care-of-Address sub- option. This message must be sent to both the current and future destination MAGs of the flow. LMA finds MAG addresses by searching the binding cache for this MN. 3.6. Switching flow bindings Here are some example scenarios where a local mobility anchor signal to the mobile node that it should acquire a new local mobility anchor for some specific flows: o The local mobility anchor is overloaded. o An operator may wish to balance the load among local mobility anchors. o Operators do periodic maintenance in order to maintain reliability o ... ... The local mobility anchor sends the MAG a PFBI with Flow Attribute option to indicate that the mobile node should bind a flow to a new local mobility anchor. The Alternate Local Mobility Anchor sub- option is included for the MAG to initiate the flow binding to a new local mobility anchor. 3.7. Acknowledging flow bindings The mobile access gateway sends PFBA message to acknowledge the reception of Add, Delete, Modify, Refresh, Move, or Switch a flow binding. On receiving messages with Flow Attribute option(s), the mobile access gateway should copy each flow Attribute to the acknowledging message. Sarikaya & Xia Expires August 5, 2010 [Page 5] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 4. Handling of the Flow Bindings List Flow bindings list defined in [I-D.ietf-mext-flow-binding] consisting of flow attribute options for each flow associated with this mobile node ordered with FID-PRI and FID values needs to be modified after each protocol operation defined above as follows: If PFBI contains a flow binding add operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST add a new entry to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action fields are taken from the Flow Attribute Option. Care-of address is taken from Target Care-of- Address sub-option. If PFBI contains a flow binding delete operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST locate the list entry corresponding to this flow and then delete the entry. If PFBI contains a flow binding modify operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST delete the list entry corresponding to this flow and then add a new entry setting the values as defined in the Flow Attribute Option with care-of address set to the value in Target Care-of Address sub-option. If PFBI contains a flow binding refresh operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST locate the list entry corresponding to this flow and then set Active/Inactive Flag to Active. If PFBI contains a flow binding move operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST locate the list entry corresponding to this flow and then change the careof address to the the value in Target Care-of Address sub-option. If PFBI contains a flow binding switch operation and if the corresponding PFBA has a status code equal to zero, local mobility anchor MUST locate the list entry corresponding to this flow and then delete the entry. 5. Mobile Access Gateway Considerations MAG MUST keep flow bindings list. Mobile Access Gateway receives Proxy Flow Binding Indication messages from local mobility anchor. MAG adds the flow to the list of PRO field is an add operation. MAG Sarikaya & Xia Expires August 5, 2010 [Page 6] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 deletes the flow if PRO field is a delete operation. MAG starts LMA switch operations if PRO field is a switch operation. MAG action for move operation depends on if the MAG is the source or the destination of the move. If the MAG is the source then it deletes the flow from the list and if the MAG is the destination , it adds the flow to the list. MAG searches the care-of address in the Target Care-of-Address sub-option in its binding update list for this MN to determine that the corresponding Proxy-CoA is this MAG's address. If the operation is modify, MAG searches flow bindings list and deletes the current entry and adds a new one and sets its parameters as given in the flow attribute option. After PFBI message is successfuly processed MAG sends a Proxy Flow Binding Acknowledgement message to the LMA that sent PFBI message and sets status field to zero. 6. IPv4 Flow Mobility Support PMIPv6 supports IPv4-only mobile nodes as described in [I-D.ietf-netlmm-pmip6-ipv4-support]. LMA-initiated flow mobility protocol defined in this document also supports IPv4. Care-of addresses can IPv4. This happens when the mobile node attaches to a MAG and gets an IPv4 address (IPv4-MN-HoA). There could be IPv4 transport between MAG and LMA. When this happens, MAG uses IPv4-Proxy-CoA. In all these cases IPv4-MN-HoA and IPv4-Proxy- CoA are stored in the binding cache at the local mobility anchor and binding update list at the mobile access gateway. During PFBI and PFBA exchanges between local mobility anchor and mobile access gateway, LMA sets care-of address in Target Care-of Address sub-option to IPv4-MN-HoA if MN's interface is IPv4 and sends PFBI as an IPv6 packet encapsulated in an IPv4 header to IPv4-Proxy- CoA if the IPv4 transport is used. 7. Flow Binding messages and options 7.1. Mobility Header The messages described below follow the Mobility Header format specified in Section 6.1 of [RFC3775]: Sarikaya & Xia Expires August 5, 2010 [Page 7] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.1.1. Proxy Flow Binding Indication The Proxy Flow Binding Indication messages are used by the local mobility anchor to initiate flow binding operations to the mobile access gateway. The Proxy Flow Binding Indication messages use the MH Type value (IANA-TBD1), and the format of the Message Data field in the Mobility Header is as follows: Sarikaya & Xia Expires August 5, 2010 [Page 8] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Triger |A| Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence # A 16-bit unsigned integer used by the local mobility anchor to match a returned Proxy Flow Binding Acknowledgement with this Proxy Flow Binding Indication. It could be a random number. Trigger 8-bit unsigned integer indicating the event which triggered the local mobility anchor to send the Proxy Flow Binding Indication message. The following Revocation 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 Reserved Acknowledge (A) The Acknowledge (A) bit is set by the local mobility anchor to request a Proxy Flow Binding Acknowledgement be returned upon receipt of the Proxy 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 Attribute options defined in this document are included in this field. Sarikaya & Xia Expires August 5, 2010 [Page 9] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 7.1.2. Proxy Flow Binding Acknowledgement The Proxy Flow Binding Acknowledgement is used to acknowledge receipt of a Flow Binding Indication. The Proxy Flow Binding Acknowledgement has the MH Type value (IANA-TBD1). When this value is indicated in the MH Type field, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence # The sequence number in the Proxy Flow Binding Acknowledgement is copied from the Sequence Number field in the Proxy Flow Binding Indication. Status 8-bit unsigned integer indicating the result of processing the Proxy Flow Binding Indication message by the receiving mobile node. Values of the Status field less than 128 indicate that the Proxy Flow Binding Indication was processed successfully by the receiving node. Values greater than or equal to 128 indicate that the Proxy Flow Binding Indication was rejected by the receiving node. The following status values are currently defined: 0 success 1 partial success 128 Binding Does NOT Exist All other values are Reserved 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 Attribute options defined in this document are included in this field. Sarikaya & Xia Expires August 5, 2010 [Page 10] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 7.2. New Options 7.2.1. Flow Attribute option This is a Mobility option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | PRO | PRI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Sub-options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Description ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Len Length of option in 8-octet units PRO This is a 4-bit field that describes the required processing for the option. It can be assigned one of the following values: 0 Reserved 1 Add a flow binding 2 Delete a flow binding 3 Modify a flow binding 4 Refresh a flow binding 5 Move a flow binding 6 Switch a flow binding to alternative local mobility anchors All other values are reserved PRI This is a 8-bit priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be in those cases. A lower number in this field indicates a higher Sarikaya & Xia Expires August 5, 2010 [Page 11] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 priority. FID The Flow Identifier field is an 16-bit unsigned integer that includes the identifier for the flow binding. This field is used to refer to an existing binding or to create a new binding. Status This field indicates the success or failure of the flow binding operation for the particular flow in the option. Values from 0 to 127 indicate success; Values of 128 and higher indicate failure. This field is only relevant when included in the Proxy Flow Binding Acknowledgement message and must be ignored in the Proxy Flow Binding Indication message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Lifetime 16-bit unsigned integer. One time unit is 4 seconds. Except Deleting and Switching processing which the lifetime field is ignored, the lifetime in other PROs has the following meanings: Add, the time remaining before the flow binding expired Modify, the lifetime of the modified flow binding Refresh, the lifetime of the refreshed flow binding Move, the lifetime of the moved flow binding Sub-options One or more sub-options may be included. These variable length options are defined in later sections. Flow Description Variable length field including attributes defining a flow. Sarikaya & Xia Expires August 5, 2010 [Page 12] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 7.2.2. Alternate Local Mobility Anchor sub-option This section introduces the Alternate Local Mobility Anchor sub- option, which may be included in the Flow Attribute option. This sub-option is used to indicate the MAG to switch a flow binding from one local mobility anchor 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 Len | # of Addresses | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Mobility Anchor Addresses | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Opt Type 1 Sub-Opt Len Length of option in 8-octet units # of Addresses The number of IPv6 local mobility anchor addresses in this sub-option. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Local Mobility Anchor Addresses Alternative local mobility anchor addresses to which the MAG is going to switch its flow bindings. 7.2.3. Target Care-of-Address sub-option This section introduces the Target Care-of-Address, which may be included in the Flow Attribute option. This sub-option is used to indicate the Proxy-CoA to move a flow binding from one interface to another. Sarikaya & Xia Expires August 5, 2010 [Page 13] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 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 Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 or IPv6 Target Care-of-Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Opt Type 2 Sub-Opt Len Sub-Opt len is 12 if IPv4 address is stored. Otherwise, the length value must be 16 for IPv6 address. 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. 8. Security Considerations TBD. 9. IANA considerations TBD. 10. Acknowledgements TBD. 11. References Sarikaya & Xia Expires August 5, 2010 [Page 14] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 (work in progress), September 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 11.2. Informative references [I-D.ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-04 (work in progress), November 2009. [I-D.xia-netext-flow-binding] Xia, F., "Flow Binding in Proxy Mobile IPv6", draft-xia-netext-flow-binding-00 (work in progress), February 2009. [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-10 (work in progress), April 2009. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-14 (work in progress), Sarikaya & Xia Expires August 5, 2010 [Page 15] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 May 2009. [I-D.larsson-mext-flow-distribution-rules] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R. Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes", draft-larsson-mext-flow-distribution-rules-02 (work in progress), February 2009. Sarikaya & Xia Expires August 5, 2010 [Page 16] Internet-Draft LMA Initiated Flow Binding for PMIPv6 February 2010 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires August 5, 2010 [Page 17]