NetLMM Working Group M. Liebsch Internet-Draft L. Le Expires: August 28, 2008 NEC February 25, 2008 Inter-Technology Handover for Proxy MIPv6 draft-liebsch-netlmm-intertech-proxymip6ho-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Liebsch & Le Expires August 28, 2008 [Page 1] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Abstract The IETF is specifying Proxy Mobile IPv6 for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and hand over from one network interface to another network interface while remaining anchored at the same Local Mobility Anchor. This extension avoids that the LMA will prematurely forward data packets for the mobile node to the mobile node's new interface before the address configuration of this interface has completed. With the proposed extension, packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be avoided. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Functional Components . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4.1. IP address auto-configuration . . . . . . . . . . . . . . 6 4.2. Delay in setting up an access link . . . . . . . . . . . . 8 4.3. Procedural sequences on the LMA . . . . . . . . . . . . . 8 4.4. Demand for a general solution . . . . . . . . . . . . . . 10 5. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Description and use of extensions . . . . . . . . . . . . 11 5.2. Protocol extensions . . . . . . . . . . . . . . . . . . . 13 5.2.1. Impact to the binding management . . . . . . . . . . . 13 5.2.2. Signaling message extensions . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Proposal for a Binding Control and Indication (BCI) option . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Liebsch & Le Expires August 28, 2008 [Page 2] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 1. Requirements notation 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]. Liebsch & Le Expires August 28, 2008 [Page 3] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 2. Introduction The NetLMM WG is specifying Proxy Mobile IPv6 for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and hand over from one network interface to another network interface while remaining anchored at the same Local Mobility Anchor. Without such extension, inter-technology handover could result in tremendous packet loss. When an inter-technology handover occurs, the mobile node needs to perform address configuration for the new interface. For IPv6, this typically requires the mobile node to send a Router Solicitation and await a Router Advertisement. The mobile node may also need to perform duplicate address detection. During this time, the mobile node's new interface is not fully configured and not yet ready to receive data packets. If the LMA decides to forward data packets for the mobile node via the new MAG, severe packet delay and jitter as well as packet losses can occur. This document proposes an extension to Proxy Mobile IPv6 that allows classification of a new binding as 'preliminary' and to 'activate' such binding only when the MN's new interface is fully configured and ready to receive data packets. Thanks to this extension, the LMA will not prematurely forward data packets for the MN to the new MAG before the address configuration for the MN's new interface is not completed. The result of this proposed extension is that packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be avoided. Liebsch & Le Expires August 28, 2008 [Page 4] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 3. Terminology and Functional Components o MAG - Mobility Access Gateway. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. The MAG function is assumed to be located on the PMIPv6 domain's access routers. o LMA - Local Mobility Anchor. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. o pAR - Previous Access Router. Equivalent to current access router. In a layer 3 handover situation, the access router which the mobile node is leaving. o nAR - New Access Router. Equivalent to handover target access router. In a layer 3 handover situation, the access router towards which the mobile node is moving. o pMAG - previous MAG. In a layer 3 handover situation, the MAG function located on the previous access router o nMAG - new MAG. In a layer 3 handover situation, the MAG function located on the new access router. o IF - Interface. Any network interface, which offers an MN wireless or wired access to the network infrastructure. In case an MN has multiple interfaces implemented, they are numbered (IF1, IF2, ...) o Inter-RAT handover. Handover between different radio access technologies. Liebsch & Le Expires August 28, 2008 [Page 5] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 4. Problem Statement A problem that can occur during an inter-technology handover is that the MN's new interface or the associated access link may not be ready to receive or forward data packets immediately after the handover. This section evaluates some of these issues in more detail. 4.1. IP address auto-configuration One reason of delaying availability of an MN's network interface can be that the MN needs to perform certain protocol operations to configure its new interface and these operations can take time. In order to complete the address auto-configuration on its new interface, the MN needs to send a router solicitation and awaits a router advertisement. Upon receiving a router advertisement from the new MAG, the MN can complete its address configuration and the MN's new interface is now ready to receive packets. During the address configuration of the MN's interface, if the LMA and the new MAG have already established a tunnel and the LMA starts forwarding data packets for the MN to the new MAG, these data packets may get delayed or lost in case address configuration of the MN's new interface has not yet completed, hence it's not yet ready to receive data. However, delaying the registration signaling, which is sent from the new MAG to the LMA after the MN's new interface has attached to the network, is not possible, as the new MAG retrieves configuration data for the MN from the LMA. With host-based mobility protocols, such as Mobile IPv6 [RFC3775], MNs can easily control when a binding is updated. This is different for network-based mobility management, where hosts are not involved in IP mobility management [RFC4831] The aforementioned problem is illustrated in Figure 1, which assumes that the HNP will be assigned under control of the LMA. Hence, the HNP option in the PBU, which is sent by the new MAG to the LMA, is set to ALL_ZERO. An MN has attached to the network with interface IF1 and receives data on this interface. When the MN's new interface IF2 comes up and is detected by the new MAG, the new MAG sends a PBU and receives a PBA from the LMA. If the LMA decides to forward data packets for the MN via the new MAG, the new MAG has to buffer these packets until address configuration of the MN's new interface has completed and the MN's new interface is ready to receive packets. While setting up IF2, the MN may not reply to address resolution signaling, as sent by the new MAG (A). If the MAG's buffer overflows or the MN cannot reply to address resolution signaling for too long, data packets for the MN are dropped and the MN can experience severe packet losses during an inter-technology handover (B). Liebsch & Le Expires August 28, 2008 [Page 6] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - --- - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<--------------------|==================data============|-- | | | | | |- - - - - - - - --- - - - - - - - Attach | | | | |----------PBU-------->| | | | |<---------PBA---------| | | | |<-====data============|-- (A)?|<-----------NSol---------------------|<-====data============|-- | | | (B) ?|<-====data============|-- | | | ?|<-====data============|-- |-----------RtSol-------------------->|<-====data============|-- |<----------RtAdv---------------------| : | Addr. | | | : | Conf. | | | : | |<-----------NSol---------------------| : | |------------NAdv-------------------->| | !|<------------------------------------|======data============|-- | | | | | | | | | | Figure 1: Issue with inter-RAT mobility. Duplicate Address Detection (DAD) tests affect the delay, during which an MN's interface does not reply to Neighbor Solicitations, considerably. During such delay, MAGs must buffer all packets for the addressed MN until Neighbor Discovery has been performed completely to avoid packet loss. Normally, routers consider a neighbor queue size of 3 packets. Using this default setting on MAGs can easily result in packet loss in case completion of the Neighbor Discovery procedure is delayed. Even if the MN does not perform DAD tests (DAD_TRANSMITS = 0), some aspects of MN address configuration according to [RFC4862] can cause MNs missing the initial Neighbor Solicitation being sent from its new MAG. First of all, this can happen due to processing delay on MNs and in case the Neighbor Solicitation follows immediately after the Liebsch & Le Expires August 28, 2008 [Page 7] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Router Advertisement, which carries the HNP assigned to the MN's IF2. Relevant for successful Neighbor Discovery is that the MN's IF2 has joined the auto-configured IPv6 address' Solicited Node Multicast Address. According to [RFC4862], MNs delay joining a Solicited Node Multicast Address according to a randomly chosen interval between 0 and MAX_RTR_SOLICITATION_DELAY seconds. By default, the parameter MAX_RTR_SOLICITATION_DELAY is set to 1 second. If MNs follow this procedure, the MN's IF2 will very likely miss the initial Neighbor Solicitation. In case the MN's IF2 does not respond to an initial Neighbor Solicitation, the new MAG follows the procedure in [RFC4861] and waits RETRANS_TIMER milliseconds before it attempts to address a further Neighbor Solicitation to the Solicited Node Multicast Address of IF2. By default, RETRANS_TIMER is set to 1000 ms, which requires the new MAG to buffer all packets destined to the MN's IF2 during at least 1 second to avoid packet loss. 4.2. Delay in setting up an access link Another risk for a delay in forwarding data packets from a new MAG to the MN's IF2 can be some latency in setting up a particular access technology's radio bearer or access specific security associations after the new MAG received the MN's HNP from the LMA via the PBA signaling message. In case an access technology needs the MN's IP address or HNP to set up a radio bearer between an MN's IF2 and the network infrastructure, the responsible network component might have to wait until the nMAG has received the associated information from the LMA in the Proxy Binding Acknowledgment. Delay in forwarding packets from the nMAG to the MN's IF2 depends now on the latency in setting up the radio bearer. A similar problem can occur in case the set up of a required security association between the MN's IF2 and the network takes time and such set up can be performed only after the MN's IP address or HNP is available on the nMAG. 4.3. Procedural sequences on the LMA In case of an intra-technology handover it's beneficial for an MN to receive data packets after a handover as soon as possible after the MN's IF attached to the infrastructure and to the associated new MAG. Delay in address configuration is not an issue, as the IF has an IPv6 address configured and has already joined the associated Solicited Node Multicast Address. Hence, the MN's IF is prepared to reply to initial Neighbor Solicitations being sent by the new MAG. Liebsch & Le Expires August 28, 2008 [Page 8] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 According to the procedure described in [I-D.ietf-netlmm-proxymip6], an LMA updates its BCE and associated forwarding information after it received a PBU from a MAG and before it sends a PBA. In case of an inter-technology handover, such procedure can be disadvantageous because data packets, which arrive at the new MAG, may initiate the Neighbor Discovery Procedure before the new MAG can actually send the MN's HNP for IF2 in the previously solicited Router Advertisement. This will result in ignoring the initial Neighbor Solicitation and may cause an overflow in the nMAG's neighbor queue. In this context, we characterize such a procedure on the LMA as 'Forward-before- Signaling' (FbS), which is illustrated in Figure 2. +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |<--------------------|==================data============|-- | | | | | |- - - - - - - - --- - - - - - - - Attach | |------------RtSol------------------->| | | | |----------PBU-------->| | | | | [switch | | | | forward | | | | path] ?|<-----------NSol---------------------|<-====data============|-- | | | | |<-----------RtAdv--------------------|<---------PBA---------| Addr. | | ?|<-====data============|-- Conf. | | ?|<-====data============|-- | ?|<-====data============|-- |<-----------NSol---------------------| : | |------------NAdv-------------------->| : | !|<------------------------------------|======data============|-- | | | | | | | | | | Figure 2: Issue with Forward-before-Signaling for inter-RAT mobility. In case of an inter-technology handover, it could be beneficial if an LMA proceeds according to 'Forward-after-Signaling' (FaS). Such procedure considers replying to a PBU before the LMA switches the associated BCE's forwarding information. This could at least increase the probability, that the MN's IF2 receives HNP information before any request for address resolution. Liebsch & Le Expires August 28, 2008 [Page 9] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 4.4. Demand for a general solution To reduce the risk of packet loss, some settings on an MN could be chosen appropriately to speed up the process of network interface configuration. This could include omitting DAD tests (DAD_TRANSMITS = 0) and setting the parameter MAX_RTR_SOLICITATION_DELAY to 0, which allows joining the configured Solicited Node Multicast Address immediately. The latter optimization is acceptable in particular for point-to-point links and when the network assigns individual prefixes to MNs. Also following an FaS procedure on the LMA in case of an inter- technology handover can reduce the risk of packet loss. Furthermore, increasing the neighbor queue size on MAGs could help to reduce packet loss, but does not solve the jitter problem. Preferable is a general solution based on an extension to the Proxy MIPv6 base protocol. This document proposes an extension to Proxy Mobile IPv6 that provides the new MAG with a signaling mechanism to notify the LMA when the MN's new interface is fully configured and ready to receive data packets. Thanks to this signaling mechanism, the LMA will not prematurely forward data packets for the MN to the new MAG before the address configuration of the MN's new interface is not complete. The result of this proposed extension is that excessive packet buffering at the new MAG is not necessary and packet losses during an inter- technology handover can be avoided. Liebsch & Le Expires August 28, 2008 [Page 10] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 5. PMIPv6 Extensions This section describes an extension to [I-D.ietf-netlmm-proxymip6] to solve the problem of using a handover target technology before it is ready to receive and send IP packets. The key extension is to allow classification of an MN's binding cache entry on the LMA as 'preliminary' or 'active'. Classification can be performed either locally on the LMA or on a network component, which is not colocated with the LMA. An example about how classification can be controlled and signaled is described in Section 5.1, whereas Section 5.2 describes associated extensions to existing signaling and states. 5.1. Description and use of extensions In an inter-technology handover scenario, an MN activates a network interface, which is different from the currently used one. The new interface should serve as interface through which the MN sends and receives packets. After a handover, the MN shuts down the previously used interface. The extension to the base PMIPv6 protocol as described in this document forwards downlink packets to an MN's new interface only when the new interface is ready to receive and send IP packets. Figure 3 illustrates the components of a PMIPv6 network, which comprises the MN's LMA as well as its pMAG and the nMAG. The pMAG is supposed to support an access network, which conforms to the technology of Interface 1 (IF1) of the MN, whereas the nMAG supports an access network, which conforms to the technology of IF2. The MN attaches to the PMIPv6 network with IF1 according to the procedure in [I-D.ietf-netlmm-proxymip6]. The MN starts receiving data packets on IF1. When the MN activates IF2 to prepare an inter- technology handover, the nMAG receives an attach indication and sends the PBU to the LMA to retrieve configuration information for the MN (e.g. HNP). The LMA is able to identify a technology change for the MN's binding, for example by means of processing the Access Technology Type option, which comes along with the PBU. Also the MN Interface Identifier option helps the LMA also to identify an interface change. Alternative mechanisms to learn about the nature of a handover are possible, such as the explicit notification from the nMAG or from any other network component. This requires the LMA to maintain information about the MN's currently used technology into the MN's binding cache entry, as it is considered in [I-D.ietf-netlmm-proxymip6]. If the LMA detects a technology change for the same MN, it enters the nMAG as forwarding information into the binding cache, but classifies this binding as 'preliminary' (A). The status 'preliminary' causes Liebsch & Le Expires August 28, 2008 [Page 11] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 the LMA to keep using the previous binding as forwarding information until the preliminary binding will be activated. The LMA acknowledges the PBU by means of sending a PBA to the nMAG. The PBA carries the MN's HNP as well as a flag, which indicates the status 'preliminary' to the nMAG (B). The nMAG learns through the PBA, that an explicit activation of the binding is required. If explicit activation of the binding is expected from the nMAG, the nMAG should find out when the MN's new interface has been set up and configured completely. For example, the nMAG could listen to Neighbor Solicitations from the MN's IF2, which indicate that the MN has configured a global address at IF2 and performs duplicate address detection. Details about how the nMAG finds out that IF2 is ready for being used is out of scope of this version of the document. As soon as IF2 has been set up completely (C), the nMAG sends a further PBU to the LMA to 'activate' the previously as 'preliminary' classified binding. The PBU should indicate explicit activation of a binding. The activation causes the LMA to change forwarding information to refer to the nMAG and adjust the MN's binding cache entry accordingly (D). From that moment, downlink packets will be forwarded towards the MN's IF2 (E). Note: As the status 'preliminary' needs to be explicitly changed to 'active' before the LMA uses the new forwarding information, this example makes use of a further PBU/PBA handshake between the nMAG and the LMA. Alternative mechanisms are possible to activate the new state on the LMA. Liebsch & Le Expires August 28, 2008 [Page 12] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - --- - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<--------------------|==================data============|-- | | | | | |- - - - - - - - --- - - - - - - - Attach | | | | |----------PBU-------->(A) | | | (B) |<-----PBA(prelim)-----| | | | | | | |<--------------------|==================================|-- |------------RtSol------------------->| | |<-----------RtAdv--------------------| | Addr. | | | | Conf | | (C) | | |------------NSol-------------------->|----PBU(activate)---->(D) | | | |<-------PBA-----------| |<------------------------------------|======================|-- | | | (E) | | | | | | | | | | | | Figure 3: Solution for inter-RAT mobility. 5.2. Protocol extensions 5.2.1. Impact to the binding management The extension proposed in Section 5.1 requires maintenance of two forwarding entries on the LMA during an inter-technology handover procedure. One of these entries is marked as 'active', whereas the other one is 'preliminary'. Extensions to an MN's entry in the LMA's binding cache should comprise the interface identifier of the associated tunnel towards a MAG, as well as the associated access technology. The interface identifier and access technology type info can be take from the PBU received at the LMA and linked to each forwarding entry accordingly. Liebsch & Le Expires August 28, 2008 [Page 13] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 MAGs should maintain the status of an MN's binding in their binding update list. This is in particular important in case a new MAG needs to explicitly activate a binding after the associated MN's new interface has proven to be ready for IP traffic. 5.2.2. Signaling message extensions 5.2.2.1. Proxy Binding Update message The PBU message should carry a binding status flag to allow indication and control of a binding status. In the PBU, the flag can in particular be used from a MAG to signal activation of a binding after the MN's new interface or the associated access link has been set up completely. If a MAG is not sure about the status of a binding, the MAG should assume that sending the PBU will result in an active binding status and learn about the real status from the PBA sent by the LMA. As an alternative to a binding status flag in the PBU and the PBA and for discussion, we propose the use of a new Binding Control and Indication (BCI) option. The format and use of such an option is described in Appendix A. Figure 4 illustrates the Proxy Binding Update message with a binding status flag. 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 # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Binding Status Flag (S): A new flag (S) is included in the Proxy Binding Update message to indicate and control the status of a binding. A value of 1 indicates the status PRELIMINARY, whereas a value of 0 allows a MAG to ACTIVATE a binding. In case a MAG does Liebsch & Le Expires August 28, 2008 [Page 14] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 not know about the status of a binding when a Proxy Binding Update is sent, it MUST set the S-flag to a value of 0. The other fields of the Proxy Binding Update message are used according to [I-D.ietf-netlmm-proxymip6]. 5.2.2.2. Proxy Binding Acknowledgment message Also the PBA message should carry the binding status flag to allow indication of a binding status. In case the LMA classifies a binding as 'preliminary', it indicates the status to the MAG, which has sent the PBU, in the PBA. After a MAG explicitly activated a binding, which has been classified as 'preliminary' beforehand, the LMA should indicate the result of processing the PBU in the PBA by means of setting the binding status flag appropriately. Figure 5 illustrates the Proxy Binding Acknowlegdment message with a binding status flag. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|S| Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Binding Status Flag (S): A new flag is included in the Proxy Binding Acknowledgment message to indicate the status of a binding. A value of 1 indicates the status PRELIMINARY, whereas a status ACTIVE is indicated with value 0. The other fields of the Proxy Binding Acknowledgment message are used according to [I-D.ietf-netlmm-proxymip6]. Liebsch & Le Expires August 28, 2008 [Page 15] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 6. Security Considerations Signaling between MAGs and LMAs as well as information carried by PBU and PBA messages is protected and authenticated according to the mechanisms described in [I-D.ietf-netlmm-proxymip6]. In case MAGs or LMAs make use of a further protocol interface to an external component, the associated protocol must be protected and information must be authenticated. Such protocol interface may for example be used by an LMA or a MAG to learn about the nature of a handover or about the status of an MN's interface. Liebsch & Le Expires August 28, 2008 [Page 16] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 7. IANA Considerations In case a BCI option as proposed in Appendix A will be used for binding control and status indication, there is a need to assign a type to identify the BCI option. Liebsch & Le Expires August 28, 2008 [Page 17] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 8. Acknowledgments May thanks to Jun Awano for his valuable comments and the associated fruitful discussion about binding control and status indications. Liebsch & Le Expires August 28, 2008 [Page 18] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 9. Normative References [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11 (work in progress), February 2008. [I-D.muhanna-netlmm-pmipv6-support-transient-coa] Muhanna, A., Krishnan, S., Leung, K., and B. Patil, "Proxy MIPv6 support for transient registrations", draft-muhanna-netlmm-pmipv6-support-transient-coa-00 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Liebsch & Le Expires August 28, 2008 [Page 19] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Appendix A. Proposal for a Binding Control and Indication (BCI) option Section 5.2.2 proposes adding a Binding Status flag to the Proxy Binding Update message. In the context of preliminary bindings and possible future extensions, which may require binding control and binding status indication, we propose a new Binding Control and Indication (BCI) option. The use of such an option allows to omit the Binding Status flags in the PBU and the PBA messages. The BCI option is meant to complement the Handoff Indicator (HI) option, which is specified in [I-D.ietf-netlmm-proxymip6], and allows clear separation between handoff type indications and binding status indications. Furthermore, the BCI option can be used to control the binding according to a pre-defined procedure. One example is the controlled activation of a preliminary binding from a MAG. Further application scenarios are possible, such as the control of bindings to coordinate uplink traffic, as proposed in [I-D.muhanna-netlmm-pmipv6-support-transient-coa]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | BCI Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Type: Identifies the BCI option. To be assigned by IANA. Length: 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and the Length fields. Binding Control and Indication (BCI) Mask: Mask to control and indicate the status of a binding. For this draft, the following values are proposed: [0x0000]: Active Binding [0x0001]: Preliminary Binding Other bits of this mask must set to 0 and be ignored until their meaning is specified. Liebsch & Le Expires August 28, 2008 [Page 20] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Binding ID (BID): In case an LMA distinguishes BCEs and possibly multiple bindings per MN by means of a binding identifier, this field can be used to refer to a particular binding by means of the BID field. In case binding identifiers are not used beyond local management on an LMA, this field must be set to 0. Note 1: Using a BCI Mask allows simultaneous setting of multiple bits for control and indication in this option. Note 2: In case the binding identifiers are not used, alternatively this field and the preceding Reserved field can be omitted. The Length field of this option must be adjusted accordingly. Liebsch & Le Expires August 28, 2008 [Page 21] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@nw.neclab.eu Long Le NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342224 Email: le@nw.neclab.eu Liebsch & Le Expires August 28, 2008 [Page 22] Internet-Draft Inter-Technology Handover for Proxy MIPv6 February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Liebsch & Le Expires August 28, 2008 [Page 23]