Network Working Group N. Neumann Internet-Draft X. Fu Expires: September 10, 2009 J. Lei University of Goettingen G. Zhang Huawei Technologies Co., Ltd. March 9, 2009 Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 Domains draft-neumann-netlmm-inter-domain-02 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 September 10, 2009. Copyright Notice Copyright (c) 2009 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. Neumann, et al. Expires September 10, 2009 [Page 1] Internet-Draft Inter-Domain PMIP March 2009 Abstract This document specifies mechanisms to setup and maintain handover and data forwarding procedures that allow a mobile node to move between different domains that provide (localized) network-based mobility support based on Proxy Mobile IPv6 for that node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Finding the Session Mobility Anchor . . . . . . . . . . . 5 3.1.1. Direct Location . . . . . . . . . . . . . . . . . . . 5 3.1.2. Indirect Location . . . . . . . . . . . . . . . . . . 6 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 4. Inter-Domain Mobility Support . . . . . . . . . . . . . . . . 7 4.1. Registration of a new Mobile Node . . . . . . . . . . . . 7 4.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 8 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 8 5.1. Support to find the Session Mobility Anchor . . . . . . . 8 5.1.1. Direct SMA Location . . . . . . . . . . . . . . . . . 9 5.1.1.1. Processing of an Initial Binding Registration . . 9 5.1.1.2. Querying the Common Database . . . . . . . . . . . 9 5.2. Processing Proxy Binding Updates . . . . . . . . . . . . . 9 5.2.1. LMA to SMA PBU . . . . . . . . . . . . . . . . . . . . 9 5.2.2. MAG to LMA PBU . . . . . . . . . . . . . . . . . . . . 9 5.2.3. MAG to SMA PBU . . . . . . . . . . . . . . . . . . . . 9 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 10 6.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 11 6.3. Session Destination Address Option . . . . . . . . . . . . 11 6.4. Session Mobilty Anchor Address Option . . . . . . . . . . 12 7. Inter-Domain Security . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.1. Intra-domain securtiy considerations . . . . . . . . . . . 14 9.2. Inter-domain security considerations . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Neumann, et al. Expires September 10, 2009 [Page 2] Internet-Draft Inter-Domain PMIP March 2009 1. Introduction A mobile node in the current Internet needs to maintain a fixed endpoint when it moves to allow for seamless connectivity with its corresponding nodes. When the mobile nodes moves between network- based mobility domains that are under different administrative control, this becomes challenging. One network is responsible for the communication endpoint while the other network provides the actual mobility services to the mobile node. This document proposes an approach to solve this problem by using inter-domain signaling to setup session handover and data forwarding between the different domains. A network-based localized mobility management solution like Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides a mobile node with mobility within the PMIPv6-enabled domain it is deployed in. When the mobile node leaves the network, however, the mobility support breaks since the mobile node moves out of the administrative reach of the local mobility solution. 2. Conventions & Terminology 2.1. Conventions used in this document 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 RFC 2119 [RFC2119]. 2.2. Terminology Mobility Session The period of time in which the mobile node needs mobility support from the network. If the mobile node reaches a state where it currently does not need mobility support, the mobility session can safely be reset. During a mobility session the network-based mobility solution described in this document offers the mobile a fixed end-point for its communications, namely the session mobility anchor, which stays valid even when the mobile node moves between Proxy Mobile IP domains. Session Mobility Anchor A fixed end-point which relays all the communication for the mobile node. This is the local mobility anchor of the first Proxy Mobile IP domain that a mobile node is connected to during a mobility session. Neumann, et al. Expires September 10, 2009 [Page 3] Internet-Draft Inter-Domain PMIP March 2009 3. Overview In order to provide continuous mobility support for a mobile nodes that is moving between different mobility domains, a steady anchor point has to be provided for corresponding nodes. In Mobile IP, for example, this is the home agent while in Proxy Mobile IP this is the local mobility anchor (LMA). This anchor point allows the mobile node to change its point of attachment to a network without its corresponding nodes noticing that. All the mobile node's traffic is routed through the local mobility anchor which then forwards the traffic to the mobile node. When a mobile node leaves a Proxy Mobile IP domain, however, it moves beyond the control of the local mobility anchor and therefore its mobility breaks. When a mobile node initially attaches to a Proxy Mobile IP domain, the local mobility anchor becomes the session mobility anchor (SMA) for the mobile node. For the duration of the mobility session this session mobility anchor will handle all incoming and outgoing connections for the mobile node. As long as the mobile node stays within the local Proxy Mobile IP domain, this only includes regular Proxy Mobile IPv6 operations as described in [RFC5213]. When the mobile node leaves the local Proxy Mobile IP domain, however, the new Proxy Mobile IP domain's local mobility anchor will initialize a tunnel to the session mobility anchor to allow the session mobility anchor to continue serving as an anchor point for the mobile node as shown in Figure 1. Within the new Proxy Mobile IP domain all regular Proxy Mobile IP operations still apply with the exception that all traffic for the mobile node is tunneled from the new local mobility anchor to the session mobility anchor which in turn communicates with the correspondent node. [CN] || || [LMA_1 >===========================================> [LMA_3] = SMA]] >=================> [LMA_2] Tunnel | | Tunnel | | | | | | | | | | | [MAG] [MAG] [MAG] | | | MN ------------------------> MN ----------------------> MN Movement Movement Figure 1: Movement Neumann, et al. Expires September 10, 2009 [Page 4] Internet-Draft Inter-Domain PMIP March 2009 For all intends and purposes from the point of view of the session mobility anchor, the current local mobility anchor of a mobile node can be seen as a mobile access gateway which performs the corresponding operations. 3.1. Finding the Session Mobility Anchor When a mobile node attaches to a Proxy Mobile IP domain, the local mobility anchor of this domain has to locate the session mobility anchor for this mobile node and initiate a tunnel between itself and the session mobility anchor. In case the Proxy Mobile IP domain is the first domain the mobile node attaches to within its mobility session, the current local mobility anchor becomes the session mobility anchor and continues with its regular Proxy Mobile IP operations. If the mobile node already has been attached to a different Proxy Mobile IP domain, it's session mobility anchor resides within this previous domain and the local mobility anchor needs to establish a binding with the session mobility anchor in order to send and receive the data for the mobile node through its session mobility anchor. Depending on the scenario, the local mobility anchor can directly or indirectly locate the session mobility anchor for a mobile node. 3.1.1. Direct Location Direct location of a session mobility anchor for a mobile node requires some kind of look-up between associated Proxy Mobile IP domains. For example, this can be achieved by maintaining a common database where session mobility anchors deposit the information for which mobile node they are responsible for. Such a database can be established by service level agreements between the operators of Proxy Mobile IP domains. For a local mobility anchor to locate the session mobility anchor for a mobile node it will send a look-up request to the database using the mobile node's identity (e.g. its Network Access Identifier (NAI) [RFC4282]) as the look-up key. If the database does not have an entry for the mobile node, the local mobility anchor becomes the session mobility anchor for the mobility session of the mobile node. This common database can be implemented as a virtual mobility anchor (VMA) as shown in Figure 2. The virtual mobility anchor is shared across all mobility domains and processes specific proxy binding updates from their local mobility anchors. It is called virtual mobility anchor since it does not relay any traffic for mobile nodes. When a mobile node attaches to a PMIP domain the corresponding local mobility anchor sends a Proxy Binding Update to the virtual mobility anchor which includes the mobile node's identity (e.g. its Network Access Identifier (NAI) [RFC4282]) or it's link layer address) and Neumann, et al. Expires September 10, 2009 [Page 5] Internet-Draft Inter-Domain PMIP March 2009 the S flag set to 1 (see Section 6.1). It also includes the Session Destination option set to the global address of the local mobility anchor. If the virtual mobility anchor already has a binding for the mobile node, it forwards the Proxy Binding Update to the particular session mobility anchor. The session mobility anchor updates it's own bindings and responds with a Proxy Binding Acknowledgment to the virtual mobility anchor which also has the S flag set and includes a Session Mobility Anchor Address option which is set to the global address of the session mobility anchor (see Section 6.2). If the virtual mobility anchor does not have a binding for the particular mobile node, it creates one and replies with Proxy Binding Acknowledgment that indicates that no session mobility anchor was found by including a Session Mobility Anchor Address option which is set to an empty address. The local mobility anchor then regards itself as the session mobility anchor. /---[VMA]---\ /---/ / \ \---\ / / \ \ / /----/ \----\ \ 3. / / 2. 1. \ \ 4. PBA / / PBU PBU \ \ PBA / / \ \ [SMA] >=================> [LMA_2] | 5. Tunnel | | | | | | | [MAG] [MAG] | | MN ------------------------> MN Movement Figure 2: Direct location of the session mobility anchor using a virtual mobility anchor 3.1.2. Indirect Location If no common database exists between Proxy Mobile IP domains, the local mobility anchor can use an indirect scheme to locate the session mobility anchor of a mobile node. For this purpose, the local mobility anchor infers the session mobility anchor assigned IP address of the mobile node and uses this address to send its session transfer request to. Since the session mobility anchor is responsible for this IP address, the local mobility anchor will Neumann, et al. Expires September 10, 2009 [Page 6] Internet-Draft Inter-Domain PMIP March 2009 indirectly reach the session mobility anchor. If there is no reply to the request, the local mobility anchor must assume that no previous session mobility anchor exists and itself become the session mobility anchor for the mobility session of the mobile node. The session mobility anchor assigned IP address of a mobile node is the IP address the mobile node got assigned when it initially attached to a Proxy Mobile IP domain. The local mobility anchor can try to infer this IP address, for example, by analyzing the mobile node's Router Solicitation messages [RFC4861] or DHCP requests [RFC3315]. 3.2. Assumptions This document assumes that there are some operational agreements between the operators of the different Proxy Mobile IP domains. Part of this agreement are, for example, the conditions under which users are allowed to move between domains and the location method that is used to find the session mobility anchor. 4. Inter-Domain Mobility Support 4.1. Registration of a new Mobile Node When a new mobile node attaches to a Proxy Mobile IP domain, the corresponding local mobility anchor registers itself as the new local mobility anchor for the mobile node with the session mobility anchor of the mobile node. [MN] [MAG] [LMA] [SMA] | | | | Attaches | | | | | | | |--Rtr Sol ->| | | | | | | | |--PBU----->| | | | | | | | |------PBU--->| | | | | | | |<-----PBA----| | | |===Tunnel====| | | | | | |<---PBA----| | | |==Tunnel===| | | | | | |<--Rtr Adv--| | | | | | | Neumann, et al. Expires September 10, 2009 [Page 7] Internet-Draft Inter-Domain PMIP March 2009 Figure 3: Signal Flow Figure 3 shows the signaling flow when a mobile node attaches to a Proxy Mobile IP domain. As in the normal Proxy Mobile IP case, the mobile node sends a Router Solicitation message that is received by the local mobile access gateway. The mobile access gateway then sends its Proxy Binding Update (PBU) to the local mobility anchor. To register itself with the session mobility anchor as the new local mobility anchor for the mobile node, the local mobility anchor forwards this Proxy Binding Update to the session mobility anchor. The session mobility anchor then determines the corresponding policies for the mobile node as it would for a local mobile node and constructs the Proxy Binding Acknowledgment (PBA). The Proxy Binding Acknowledgment is then sent to the local mobility anchor as if it were a local mobile access gateway and a bi-directional tunnel is established between the session mobility anchor and the local mobility anchor. The local mobility anchor forwards the received Proxy Binding Acknowledgment to its mobile access gateway which in turn uses the Proxy Binding Acknowledgment to configure the mobile node. Also, the local mobility anchor establishes the bi-direct tunnel to this mobile access gateway. All traffic for the mobile node is then routed from the session mobility anchor through the local mobility anchor and the mobile access gateway. All future movements of the mobile node within the new Proxy Mobile IPv6 domain are covered by local mobility operations as described in [RFC5213]. 4.2. Local Routing Traffic might occur between nodes that are currently allocated in the same mobility domain but are associated with session mobility anchors outside this domain. The local mobility anchor of the domain MAY optimize the delivery of this traffic by locally routing the packets instead of sending them over the corresponding session mobility anchor(s). The flag EnableMAGLocalRouting MAY be used for controlling this behavior. For further local routing considerations, see Section 6.10.3. of the Proxy Mobile IPv6 (PMIPv6) document [RFC5213]. 5. Local Mobility Anchor Considerations 5.1. Support to find the Session Mobility Anchor The LMA is responsible to either act as a SMA for nodes that attach to its domain originally or to locate the corresponding SMA for nodes that move to its domain from another domain. In the first case, the LMA needs to support operations that allow it to be found and queried by other LMAs for mobility session related data. In the later case, Neumann, et al. Expires September 10, 2009 [Page 8] Internet-Draft Inter-Domain PMIP March 2009 the LMA needs to perform these locating and querying operations itself. This document describes two operating schemes for this purpose: the direct location of the SMA and the indirect location of the SMA. 5.1.1. Direct SMA Location As explained in Section 3.1.1 the direct location of the SMA is performed using a common database between the participating PMIP domains. 5.1.1.1. Processing of an Initial Binding Registration Upon the reception of an Initial Binding Registration (cf. Section 5.3.2. [RFC5213]) the LMA MUST query the common database for a SMA for the corresponding mobile node. If a SMA is returned the LMA will act as a visited LMA and send a corresponding PBU to the SMA. If not SMA is returned, the LMA will act as a SMA for the mobile node and update the database accordingly. Afterwards the LMA processes the Initial Binding Registration as specified in [RFC5213]. 5.1.1.2. Querying the Common Database ... 5.2. Processing Proxy Binding Updates 5.2.1. LMA to SMA PBU If a SMA receives a PBU from a LMA it MUST assume that the mobile node moved to the PMIP domain the LMA is responsible for. The SMA MUST process the PBU as it would process a PBU from any of the MAGs in its own domain. 5.2.2. MAG to LMA PBU If a LMA that is not the SMA for a mobile node receives a PBU which is not part of an Initial Binding Registration it MUST process the PBU as it would process any other PBU. If the PBU is successful it MUST also send a Binding Lifetime Extension PBU to the SMA. 5.2.3. MAG to SMA PBU If a SMA receives a PBU from a MAG within its own domain it MUST process it like it would process the PBU as a LMA. Neumann, et al. Expires September 10, 2009 [Page 9] Internet-Draft Inter-Domain PMIP March 2009 6. Message Formats This section defines extensions to the Proxy Mobile IPv6 [RFC5213] protocol messages. 6.1. Proxy Binding Update Message 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 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A new flag (S) is included in the Binding Update message. The rest of the Binding Update message format remains the same as defined in [RFC5213]. Session Forwarding Flag (S) A new flag (S) is included in the Binding Update message to indicate that the Binding Update message is a request from a local mobility anchor to a session mobility anchor to forward all data for a particular mobile node to the local mobility anchor. The flag MUST be set to 1 in case a local mobility anchor requests a session forwarding and to 0 otherwise. Mobility Options In addition to the mobility options specified in [RFC5213] there can be at most one instance of the Session Destination Address option included in a Proxy Binding Update Message. Neumann, et al. Expires September 10, 2009 [Page 10] Internet-Draft Inter-Domain PMIP March 2009 6.2. Proxy Binding Acknowledgement Message 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|Reserv.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A new flag (S) is included in the Binding Acknowledgement message. The rest of the Binding Acknowledgement message format remains the same as defined in [RFC5213]. Session Forwarding Flag (S) A new flag (S) is included in the Binding Acknowledgement message to indicate that the local mobility anchor that processed the corresponding Proxy Binding Update message supports session forwarding. The flag is set to a value of 1 only if the corresponding Proxy Binding Update had the Session Forwarding Flag (S) set to value of 1. Mobility Options In addition to the mobility options specified in [RFC5213] there can be at most one instance of the Session Mobility Anchor Address option included in a Proxy Binding Acknowledgement. 6.3. Session Destination Address Option The Session Destination option indicates where a local mobility requests the data to be send in a session forwarding request. The Session Destination Address option is encoded in type-length- value (TLV) format as follows: Neumann, et al. Expires September 10, 2009 [Page 11] Internet-Draft Inter-Domain PMIP March 2009 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 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Session Destination Address The destination address for the session data of the mobile node. This is usually the address of the local mobility anchor which is responsible for the mobile node. This address MUST be a unicast routable address. 6.4. Session Mobilty Anchor Address Option The Session Mobility Anchor Address option indicates the address of the session mobility anchor which is ultimately responsible for a Proxy Binding Update request. The Session Mobility Anchor Address option is encoded in type-length- value (TLV) format as follows: Neumann, et al. Expires September 10, 2009 [Page 12] Internet-Draft Inter-Domain PMIP March 2009 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 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session Mobilty Anchor Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Session Mobility Anchor Address The address of the session mobility anchor. This address MUST be a unicast routable address. 7. Inter-Domain Security This document introduces signaling and data forwarding between different Proxy Mobile IP domains which needs to be protected. Proxy Mobile IP itself recommends using IPsec with established security associations to protect the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgment message exchanges between the mobile access gateway and the local mobility anchor. This document extends this recommendation for all message exchanges between the session mobility anchor and the local mobility anchor including forwarded data for the mobile node. How the IPsec associations are established is beyond this document. 8. IANA Considerations Neumann, et al. Expires September 10, 2009 [Page 13] Internet-Draft Inter-Domain PMIP March 2009 9. Security Considerations This section deals with the considerations related to intra-domain security within one Proxy Mobile IP domain and inter-domain security between different Proxy Mobile IP domains that are involved in managing a mobile nodes mobility. 9.1. Intra-domain securtiy considerations This document does not change any intra-domain mobility procedures and therefore does not introduce additional intra-domain security risks. The security considerations in [RFC5213] cover security risks inside a Proxy Mobile IPv6 domain. 9.2. Inter-domain security considerations The signaling and data forwarding between different Proxy Mobile IP domains where the session mobility anchor resides in one domain and the current local mobility anchor for a mobile node resides in the other domain is recommended to be protected by using IPsec with established security associations. This means that the local mobility anchor establishes and maintains an IPsec tunnel to the session mobility anchor which is used for communications. How these security associations are established is beyond this document. It is recommended, however, to establish some kind of service agreements between service providers to specify security constraints and to arrange the valid endpoints (i.e. the local mobility anchor and session mobility anchor addresses). In opposite to plain Proxy Mobile IPv6, the signaling between the session mobility anchor and the mobile node traverses not only the Internet but also the local network of the current Proxy Mobile IP domain. The signaling between the session mobility anchor and the mobile node is, therefore, at least exposed to the current local mobility anchor, and the corresponding mobile access gateways in the current Proxy Mobile IP domain. Especially for applicable authentication procedures between the session mobility anchor and the mobile node, the session mobility anchor is recommended to only use procedures that cannot be exploited by overhearing parties. 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. Neumann, et al. Expires September 10, 2009 [Page 14] Internet-Draft Inter-Domain PMIP March 2009 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 10.2. Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Appendix A. Open Issues o better definition of mobility session (when to start a new session) o extend inter domain security issues o De-Registration of a MN Authors' Addresses Niklas Neumann University of Goettingen Computer Networks Group Goldschmidtstrasse 7 Goettingen 37077 Germany Email: neumann@cs.uni-goettingen.de Xiaoming Fu University of Goettingen Computer Networks Group Goldschmidtstrasse 7 Goettingen 37077 Germany Email: fu@cs.uni-goettingen.de Neumann, et al. Expires September 10, 2009 [Page 15] Internet-Draft Inter-Domain PMIP March 2009 Jun Lei University of Goettingen Computer Networks Group Goldschmidtstrasse 7 Goettingen 37077 Germany Email: lei@cs.uni-goettingen.de Gong Zhang Huawei Technologies Co., Ltd. Corporate Research Department B-1 Building, Longgang Shenzhen 518129 P.R.China Email: Nicholas@huawei.com Neumann, et al. Expires September 10, 2009 [Page 16]