Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: January 14, 2010 Huawei USA July 13, 2009 BU/BA Based Prefix Delegation Support for Mobile Networks draft-sarikaya-mext-bu-prefixdelegation-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 January 14, 2010. 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 Sarikaya & Xia Expires January 14, 2010 [Page 1] Internet-Draft Prefix Delegation Support July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Sarikaya & Xia Expires January 14, 2010 [Page 2] Internet-Draft Prefix Delegation Support July 2009 Abstract This document defines prefix delegation support for mobile networks. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation or by other means and reply to the Mobile Router with Binding Acknowledgement. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Nemo Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . 6 3.1. Home Link Support . . . . . . . . . . . . . . . . . . . . 7 3.2. Prefix Renew Procedure . . . . . . . . . . . . . . . . . . 9 3.3. Prefix Release Procedure . . . . . . . . . . . . . . . . . 9 4. Nemo Prefix Delegation Using Other Means . . . . . . . . . . . 10 5. Prefix to Interface Mapping at the MR . . . . . . . . . . . . 10 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 11 6.1. Rapid Commit Option . . . . . . . . . . . . . . . . . . . 11 6.2. Implicit/Explicit Modes . . . . . . . . . . . . . . . . . 11 6.3. Advertising Delegated Prefixes . . . . . . . . . . . . . . 11 6.4. DHCP Server Issues . . . . . . . . . . . . . . . . . . . . 11 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Home Network Prefix Option . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative references . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Sarikaya & Xia Expires January 14, 2010 [Page 3] Internet-Draft Prefix Delegation Support July 2009 1. Introduction Nemo Basic Support Protocol requires that IPv6 prefixes called Mobile Network Prefix(es) delegated to a Mobile Router and be advertized in the Mobile Network [RFC3963]. However the protocol does not provide any means of provisioning Mobile Network Prefixes (MNPs) dynamically. Prefix delegation is widely discussed in IETF 16NG, MEXT, and NETLMM Working Groups. Corresponding solutions are also introduced. NEMO deals with synchronization of Mobile Network prefixes between a Mobile Router and a Home Agent, while the method is agnostic to the way that a Home Agent gets prefixes from back end servers. [RFC3633] defines Prefix Delegation options and procedures to provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). In Proxy Mobile IPv6 [RFC5213] home network prefix (HNP) is used by MN to assign a home address. Mobile access gateway (MAG) needs to emulate MN's home network on the access link and therefore needs to learn HNP. The design decision was made to learn this from the proxy binding acknowledgement message sent by the local mobility agent (LMA) (See Section 6.7 in [RFC5213]). For this purpose, proxy binding update and acknowledgement messages are extended with Home Network Prefix Option to carry HNP and its length. However, how LMA gets prefixes is not currently defined yet. In Nemo MNP provisioning problem, MR, like MAG needs to get MNP, like HNP from HA, like LMA in order for MR to advertise MNP on its downstream link(s). Because of this similarity, this document proposes to use the binding update/acknowledgement exchanged with HA to carry MNPs similar to proxy binding update/acknowledgement messages of Proxy Mobile IPv6. NEMO home agents may be provisioned in different ways to provide MNPs to MRs. In one deployment scenario, DHCPv6 prefix delegation (PD) is proposed to be used for HA to get prefixes from DHCP server with HA as the requesting router (RR) and DHCP server as the delegating router (DR) [RFC3633]. AAA based deployment scenarios are also possible. AAA server can assign and authorize prefixes to the MRs. When MR is on the home link, MR gets authenticated first and then gets the configuration settings including MNPs from the policy store. This document describes an IKEv2 and EAP authentication based home link configuration but other solutions are also possible. MR uses IKEv2 exchanges to receive prefixes for its home link only and not for MNPs. Sarikaya & Xia Expires January 14, 2010 [Page 4] Internet-Draft Prefix Delegation Support July 2009 MR requests MNP from HA using the binding update message as in the visited link. A successful EAP authentication can trigger MR to send BU with Home Link Exchange flag set to HA. HA MAY then use DHCPv6 PD interactions to get MNPs and send them to MR using BA. HA has other options such as AAA provisioning. BU/BA based prefix delegation support differs from the solution described in [I-D.ietf-nemo-dhcpv6-pd] in several aspects: 1. In [I-D.ietf-nemo-dhcpv6-pd] DHCPv6 PD is executed between MR as Requesting Router (RR) and HA as Delegating Router (DR). BU/BA based prefix delegation support offers different deployment choices where DHCPv6 PD executed between HA as Requesting Router (RR) and DHCP Server as Delegating Router (DR) is one choice and AAA based prefix assignment and authorization is another choice. 2. Prefix(es) are exchanged in BU/BA using HNP Option in BU/BA based prefix delegation support which is already used in Proxy Mobile IPv6 [RFC5213]. In [I-D.ietf-nemo-dhcpv6-pd], prefix(es) are carried in DHCP messages as defined in [RFC3633]. 3. Because of (1) the MR in [I-D.ietf-nemo-dhcpv6-pd] becomes more complicated as it needs to support DHCP on its upstream interface. 4. Because of (2) visited link operation in [I-D.ietf-nemo-dhcpv6-pd] is much more complicated. [I-D.ietf-nemo-dhcpv6-pd] requires that DHCPv6 Relay agent implemented on MR's upstream interface. 5. In terms of deployment, BU/BA based prefix delegation support offers more flexibility and it is much simpler since DHCP server could be on the same link as HA in which case HA only needs to have DHCP Client. In case DHCP server is located on a different network, HA can accomodate this having a DHCP Relay on the same link or colocated with HA. MR does not have any requirement to support DHCP on its upstream interface. HA may even be provisioned by AAA in which case no DHCPv6 prefix delegation server is needed. 6. In terms of deployment, the solution described in [I-D.ietf-nemo-dhcpv6-pd] requires MR to support both DHCPv6 Client and Relay on its upstream interface. Also since DHCP Relays can not be chained, HA has to support DHCPv6 Prefix Delegation Server. 7. BU/BA based provisoning of MNPs offers another advantage compared with the approach in [I-D.ietf-nemo-dhcpv6-pd] because it also integrates the movement, i.e. when MR moves it registers its new care-of address with BU/BA exchange and at the same time MR receives the new MNPs. Sarikaya & Xia Expires January 14, 2010 [Page 5] Internet-Draft Prefix Delegation Support July 2009 2. Terminology This document uses the terminology defined in [RFC3315], [RFC3633], [RFC4886], [RFC3775], [RFC4306] and [RFC5213]. 3. Nemo Prefix Delegation Using DHCPv6 We assume that the prefixes are managed by an authority that owns the Home Network and subnets it into MNPs that it assigns to the MRs. An MNP can be preassigned to the associated MR (e.g. manually or automatically with a provisioning system), or assigned dynamically by a server such as a DHCP Prefix Delegation server. In this architecture, HA is the requesting router and the DHCP Server is the delegating router. HA needs to be collocated with a DHCP Client to solicit/request prefixes from the DHCP Server. The delegating router could be a backend DHCP Server. In a visited link, Mobile Router(MR) requests its Mobile Network Prefixes from its Home Agents dynamically using Binding Update message. When BU message contains one or more Home Network Prefix Options, this triggers HA to start DHCPv6 PD with DHCP Server. Figure 1 shows the process that a Mobile Router requests prefixes from a Home Agent. MR HA DHCP Server | | | |------->| | 1. BU with Home Network Prefix Option | |------->| 2. DHCP Solicit | |<-------| 3. DHCP Advertise | |------->| 4. DHCP Request (MNP) | |<-------| 5. DHCP Reply (MNP) |<-------| | 6. BA with Home Network Prefix Option Figure 1: Prefix Delegation in NEMO 1. Home Network Prefix option defined in [RFC5213] included in the Binding Update(BU) and R flag in the binding update are used to indicate to the Home Agent (HA) that the MR wishes to get new prefixes assigned to it for use as Mobile Network Prefixes. MR MUST set the R bit in Home Network Prefix option Section 7.1 to indicate a prefix request. 2. DHCP Client at the HA initiates DHCP Solicit procedure to request prefixes for the MN. HA creates and transmits a Solicit message as described in sections 17.1.1, "Creation of Solicit Messages" and 17.1.2, "Transmission of Solicit Messages" of RFC 3315. HA Sarikaya & Xia Expires January 14, 2010 [Page 6] Internet-Draft Prefix Delegation Support July 2009 creates an IA_PD and assigns it an IAID. HA assigns a different IAID for each Home Network Prefix option it receives in a BU. HA MUST include the IA_PD option in the Solicit message. 3. The DHCP server sends an Advertise message to HA in the same way as described in section 17.2.2, "Creation and transmission of Advertise messages" of RFC 3315. 4. HA uses the same message exchanges as described in section 18, "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to obtain or update prefixes from a DHCP server. HA and the DHCP server use the IA_PD Prefix option to exchange information about prefixes in much the same way as IA Address options are used for assigned addresses. 5. HA stores the prefix information including prefix lifetime it received in the Reply message in the Prefix Table [RFC3963]. 6. HA sends the prefixes received to MR in a Binding Acknowledgement message. Home Network Prefix option defined in [RFC5213] is included in the Binding Acknowledgement. One Home Network Prefix option is included for each prefix received. MR sets prefix length and home network prefix values to ALL_ZERO in Home Network Prefix option of BU MR sends to HA. If MR bootstrapped in the home link MR sets prefix length and home network prefix values to the values received in the BA with Home Link Exchange Flag (C flag) defined in [I-D.devarapalli-mext-mipv6-home-link] set as in Section 3.1. In subsequent BUs, MR sets these fields to the values received in the previous BA from HA. When advertizing MNPs in Router Advertisement messages, MR MAY set the prefix lifetime value to any value chosen at its own discretion. The value may be bound to the lifetime of MR's binding with HA. The value may also be set by a value taken from MR's policy profile. Prefixes MUST be renewed by MR sending a BU that contains one or more Home Link Prefix Options, see Section 3.2. The specification requires that MNPs received in BUs be advertized using RAs at the MR. The details of how the MNPs MR receives will be sent in Router Advertisements will not be described in this document, it is left out as an implementation detail. 3.1. Home Link Support If MR boots in the home link, DHCPv6 prefix delegation operation is as shown in Figure 2. 1. An MR boots up in the network. DHCP Server in Figure 2 is not involved in the network entry procedures. Sarikaya & Xia Expires January 14, 2010 [Page 7] Internet-Draft Prefix Delegation Support July 2009 2. MR starts IKEv2 procedures [RFC4306] to establish a security association with the HA [I-D.ietf-dime-mip6-split]. 3. MR requests prefix(es) to configure its home link using CFG_REQUEST payload in the message. MR includes a zero length INTERNAL_IP6_SUBNET attribute in the CFG_REQUEST payload to request a prefix. MR MUST include multiple instances of INTERNAL_IP6_SUBNET attribute to request multiple prefixes to be assigned by HA. 4. MR and HA authenticate each other using EAP. 5. If authentication succeeds HA is ready to assign prefix(es) using DHCP PD. 6. HA includes the prefixes for MR's home link in the payload in CFG_REPLY. CFG_REPLY contains more than one instances of INTERNAL_IP6_SUBNET attribute each containing home link prefix and its length. MR uses these prefixes for its home link. 7. MR sends BU with Home Link Exchange (C) Flag on and includes Home Network Prefix Option in order to get MNPs from HA. 8. HA as the requesting router starts DHCPv6 Prefix Delegation exchange with the Delegating Router. Step 2 in Figure 1. 9. Step 3 in Figure 1. 10. Step 4 in Figure 1. 11. Step 5 in Figure 1. 12. HA sends BA back to MR. BA has Home Link Exchange (C) Flag set and it contains Home Network Prefix Option containing MNPs for the mobile devices in the NEMO. After Step 5, HA MAY execute DHCP PD procedures with DHCP Server to request prefixes for MR's home link configuration. At Step 6, HA sets CFG_REPLY INTERNAL_IP6_SUBNET attribute values to the prefixes obtained from DHCP Server. HA MUST use a different IA_ID for the prefixes to be used in home link configuration of MR. MR HA DHCP Server AAA Server |--------|----------------------| 1. Network Entry |<-------|--------------------->| 2. SA establishment |------->| | 3. Config Request |<-------|--------------------->| 4. EAP Authentication |<-------|----------------------| 5. EAP Success |<-------| | 6. Config Reply |------->| | | 7. BU with C flag and Q bit set | |------->| | 8. DHCP Solicit | |<-------| | 9. DHCP Advertise | |------->| | 10. DHCP Request (MNP) | |<-------| | 11. DHCP Reply (MNP) |<-------| | | 12. BA with C flag and Q bit set Sarikaya & Xia Expires January 14, 2010 [Page 8] Internet-Draft Prefix Delegation Support July 2009 Figure 2: Home Link Prefix Delegation IKEv2 based EAP authentication described above is informational. The description serves to demonstrate a method of obtaining home network prefixes for MR to HA link. 3.2. Prefix Renew Procedure To extend MNP lifetimes, HA sends a Renew message to the DHCP server. The server determines new lifetimes for the prefixes and returns the prefix to HA in a Reply message. The DHCP server MAY add new prefixes to the MR for renumbering in its Reply message. Prefix renew request can also be received from MR. MR sends BU with HNP set to the prefix already assigned to HA. The Release (R) bit MUST not be set in HNP Option. If this happens, HA sends a Renew message to the DHCP server to renew the MNP. After receiving the Reply message, HA sends a BA with HNP set to the prefix assigned and with Q bit set to 1. Setting Q bit in BA indicates reception of a renewed prefix. 3.3. Prefix Release Procedure Prefixes can be released in two ways, prefix aging or DHCP release procedure. In the former way, a prefix SHOULD not be used by an MR when the prefix ages, and the DHCP Server can delegate it to another MR. A prefix lifetime is delivered from the DHCPv6 server to the requesting router (HA) through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information option [RFC4861]. Mobile Router can initiate the prefix release procedure based on deregistration of the nodes in the mobile network. Figure 3 can be used to release prefixes. MR HA DHCPS -->| | | 1. Deregistration event |------->| | 2. BU with R bit set | |------->| 3. DHCP Release (MNP) | |<-------| 4. DHCP Reply |<-------| | 2. BA with R bit set | | | Figure 3: Prefix release HA MUST release the mobile network prefix when MR signals to do so. The prefix release signaling is as shown in Figure 3. Sarikaya & Xia Expires January 14, 2010 [Page 9] Internet-Draft Prefix Delegation Support July 2009 1. A local mobile node (LMN) or visiting mobile node (VMN) leaves the mobile network. If such a node was the only user for MNP or if all LMNs/VMNs left the mobile network then MR starts MNP release procedure. 2. MR sends a BU with HNP option to HA. In the HNP option, MR MUST set the R bit to one. 3. HA receives BU and checks the R bit. If R bit is set, HA as the requesting router sends DHCPv6 Release message to the delegating router. HA MUST include the mobile network prefix to be released in IA_PD by copying it from the home network prefix option of BU it received from MR. 4. DR sends back DHCPv6 Rely message confirming the release. 5. HA sends BA to confirm the prefix release. MR MUST stop advertizing the MNP in the mobile network. 4. Nemo Prefix Delegation Using Other Means Prefixes may be assigned and authorized to MR using means other than DHCPv6 Prefix Delegation. AAA server techniques may provision prefixes at the home agent. If other means are used the scenarios similar to the ones described in Section 3 can be used. In the scenarios, DHCP interactions MUST be replaced by AAA interactions if AAA based prefix authorization is used. If the prefixes are provisioned at the HA then DHCP interactions MUST be replaced by corresponding internal home agent operations on the prefixes. 5. Prefix to Interface Mapping at the MR This section describes management of multiple prefixes corresponding to multiple downstream interfaces of MR. This specification requires a separate BU/BA exchange for each set of MNPs assigned to a given downstream interface of MR in order to facilitate mapping of MNPs to MR interfaces. MR can track BUs and their corresponding BAs using the mechanisms described in [RFC3775]. In order to allow better synchronization between MR and HA, A bit defined in Figure 4 in home network prefix mobility option can be used. MR MUST set the A-bit if MR wants to receive all MNPs delegated to MR in the same BA message. HA MUST send all MNPs delegated to this MR in the BA message. HA MUST set A-bit in the BA. If A-bit is not set, HA MUST look at the other bits and reply to prefix requests or release requests. If A-bit is set the other bits Sarikaya & Xia Expires January 14, 2010 [Page 10] Internet-Draft Prefix Delegation Support July 2009 are ignored. 6. Miscellaneous Considerations 6.1. Rapid Commit Option 4-way exchange between HA as requesting router (RR) and DHCP server as delegating router (DR) in Figure 1 and Figure 2 MAY be reduced into a two message exchange using the Rapid Commit option [RFC3315]. HA includes a Rapid Commit option in the Solicit message. DR then sends a Reply message containing one or more prefixes. 6.2. Implicit/Explicit Modes If MRs operate in implicit mode then MR MUST not include Mobile Network Prefix option in BUs nor Home Network Prefix Option. This is because MR and HA will run a dynamic routing protocol to manage prefixes. HA MAY use DHCPv6 prefix delegation as requesting router to request prefixes for the mobile network from the DHCP server acting as delegating router. NEMO explicit mode is recommended to use all aspects of the protocol defined in this document. 6.3. Advertising Delegated Prefixes HA should broadcast the prefix(es) dynamically upstream as the route information of all the MRs connected to this HA. This might cause high routing protocol traffic (IGMP, OSPF, etc.) due to large number of prefixes. To solve the problem, route aggregation SHOULD be used. For example, each HA can be assigned a /48 or /32 prefix (aggregate prefix) while each interface of MR can be assigned a /64 prefix. The /64 prefix is an extension of /48 one, for example, an HA's /48 prefix is 3FFE:FFFF:0::/48, an interface of MR is assigned 3FFE:FFFF: 0:2::/64 prefix. The HA only broadcasts it's /48 or /32 prefix information to Internet. 6.4. DHCP Server Issues The delegating router should normally be located in Home Agent's network. In that case HA needs only a DHCP Client to communicate with DHCP server. If the delegating router is not local HA needs DHCP Relay Agent to forward multicast packets to DHCP server. DHCP Relay Agent should be located in the same link as HA and it needs to be configured with the address of DHCP server. Sarikaya & Xia Expires January 14, 2010 [Page 11] Internet-Draft Prefix Delegation Support July 2009 7. Message Formats This document requires CFG_REQUEST and CFG_REPLY defined in [RFC4306] contain one or more INTERNAL_IP6_SUBNET attributes. This document requires Binding Update and Binding Acknowledgement messages defined in [RFC3775] to contain one or more Home Network Prefix Options defined in [RFC5213]. This document requires Binding Update and Binding Acknowledgement messages defined in [RFC3775] to contain the Home Link Exchange (C) flag defined in [I-D.devarapalli-mext-mipv6-home-link] when BU and BAs are exchanged at the home link. C flag MUST be set to one when MR is at the home link. C flag MUST be set to zero when BU and BAs are exchanged at the visited links. 7.1. Home Network Prefix Option This section defines modifications to Home Network Prefix Option defined in [RFC5213]. 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 |Reserved |A|Q|R| Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Home Network Prefix Option Sarikaya & Xia Expires January 14, 2010 [Page 12] Internet-Draft Prefix Delegation Support July 2009 Type 22 Length, Prefix Length and Home Network Prefix as defined in RFC 5213 Reserved This is a 5-bit field which is unused Release (R) The R bit is set to release a prefix Request (Q) The Q bit is set to request a prefix A bit is used to request all the MNPs delegated to MR from HA. 8. Security Considerations This document does not by itself introduce any security issues. 9. IANA Considerations This specification defines 3 flags in the reserved field of Home Network Prefix mobility option defined in [RFC5213]. 10. Acknowledgements This revision (-02) was made based on the comments by Arnaud Ebalard and communicated to us in French. Many thanks Arnaud. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Sarikaya & Xia Expires January 14, 2010 [Page 13] Internet-Draft Prefix Delegation Support July 2009 [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [I-D.ietf-dime-mip6-split] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", draft-ietf-dime-mip6-split-17 (work in progress), April 2009. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [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. [I-D.devarapalli-mext-mipv6-home-link] Devarapalli, V., Kant, N., and H. Lim, "Mobile IPv6 Home Link Operation over SDO point-to-point links", draft-devarapalli-mext-mipv6-home-link-01 (work in progress), February 2008. [I-D.ietf-nemo-dhcpv6-pd] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-ietf-nemo-dhcpv6-pd-03 (work in progress), December 2007. 11.2. Informative references Sarikaya & Xia Expires January 14, 2010 [Page 14] Internet-Draft Prefix Delegation Support July 2009 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 January 14, 2010 [Page 15]