Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: March 19, 2009 Huawei USA September 15, 2008 BU/BA Based Prefix Delegation Support for Mobile Networks draft-sarikaya-mext-bu-prefixdelegation-00.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 March 19, 2009. Sarikaya & Xia Expires March 19, 2009 [Page 1] Internet-Draft Prefix Delegation Support September 2008 Abstract This document defines prefix delegation support for a mobile network. 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 and reply to the Mobile Router with Binding Acknowledgement. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Nemo Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . 4 4. Home Link Support . . . . . . . . . . . . . . . . . . . . . . 5 5. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 6 5.1. Rapid Commit Option . . . . . . . . . . . . . . . . . . . 6 5.2. Implicit/Explicit Modes . . . . . . . . . . . . . . . . . 7 5.3. Advertising Delegated Prefixes . . . . . . . . . . . . . . 7 5.4. DHCP Server Issues . . . . . . . . . . . . . . . . . . . . 7 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative references . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Sarikaya & Xia Expires March 19, 2009 [Page 2] Internet-Draft Prefix Delegation Support September 2008 1. Introduction Nemo Basic Support Protocol requires that IPv6 prefixes called Home Network Prefix(es) delegated to a Mobile Router and 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 [RFC5213] home network prefix (HNP) is used by MN to assign a home address. Mobility 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, like proxy binding update/acknowledgement messages exchanged with HA to carry MNPs. 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]. 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. 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 then uses DHCPv6 PD interactions to get MNPs and send them to MR using BA. Sarikaya & Xia Expires March 19, 2009 [Page 3] Internet-Draft Prefix Delegation Support September 2008 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. 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 creates an IA_PD and assigns it an IAID. HA MUST include the IA_PD option in the Solicit message. Sarikaya & Xia Expires March 19, 2009 [Page 4] Internet-Draft Prefix Delegation Support September 2008 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. 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 4. 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 refreshed by MR sending a BU that contains one or more Home Link Prefix Options. 4. 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. 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. Sarikaya & Xia Expires March 19, 2009 [Page 5] Internet-Draft Prefix Delegation Support September 2008 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 CGF_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. 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 | |------->| | 8. DHCP Solicit | |<-------| | 9. DHCP Advertise | |------->| | 10. DHCP Request (MNP) | |<-------| | 11. DHCP Reply (MNP) |<-------| | | 12. BA Figure 2: Home Link Prefix Delegation 5. Miscellaneous Considerations 5.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. Sarikaya & Xia Expires March 19, 2009 [Page 6] Internet-Draft Prefix Delegation Support September 2008 5.2. Implicit/Explicit Modes MRs operate in implicit mode, i.e. MR MUST not include Mobile Network Prefix option in BUs. This is because MRs following this specification will include Home Network Prefix Option instead. 5.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. 5.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. 6. 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. Sarikaya & Xia Expires March 19, 2009 [Page 7] Internet-Draft Prefix Delegation Support September 2008 7. Security Considerations This document does not by itself introduce any security issues. 8. IANA Considerations None. 9. Acknowledgements TBD. 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. [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. [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 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-10 (work in progress), July 2008. Sarikaya & Xia Expires March 19, 2009 [Page 8] Internet-Draft Prefix Delegation Support September 2008 [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. 10.2. Informative references Sarikaya & Xia Expires March 19, 2009 [Page 9] Internet-Draft Prefix Delegation Support September 2008 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 March 19, 2009 [Page 10] Internet-Draft Prefix Delegation Support September 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. Sarikaya & Xia Expires March 19, 2009 [Page 11]