Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: August 25, 2008 Huawei USA J. Korhonen TeliaSonera Corporation February 22, 2008 Problem Statement and Requirements for Diameter Prefix Delegation Application draft-sarikaya-dime-prefix-delegation-ps-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 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Sarikaya, et al. Expires August 25, 2008 [Page 1] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 Abstract This document provides problem statement for Diameter prefix delegation application. The document also identifies application scenarios and requirements on Diameter prefix delegation application. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 4.1. Prefix Management in Access Routers . . . . . . . . . . . 4 4.2. Prefix Management in Local Mobility Anchors . . . . . . . 5 4.3. Prefix Management for Mobile Routers . . . . . . . . . . . 5 5. Requirements on AAA-based Prefix Delegation Application . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Sarikaya, et al. Expires August 25, 2008 [Page 2] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 1. Introduction and Motivation Prefix assignment for an IPv6 node (host or router) is essential to IPv6 address formulation. Even though IPv6 address space is large enough, it still makes sense for operators to manage addresses in a central way, e.g. using central DHCPv6 servers or AAA servers. Delegating prefix from a central server to a prefix user (e.g. a router) needs communication between different network entities. Prefix delegation is widely discussed in IETF 16NG, NEMO, and NETLMM Working Groups. Corresponding solutions are also introduced. But these solutions only solve a part of the problem. In 16NG, an Access Router allocates a mobile node's prefix using Router Advertisement message defined in [RFC4861]. There is no discussion about how the Access Router acquires prefixes from external entity. 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. In Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6], Proxy Binding Update and Proxy Binding Acknowledgement messages are used to allocate prefixes from a Local Mobile Anchor to a mobile node, but how the Local Mobile Anchor gets prefixes from external server is out of the scope. [RFC3633] defines Prefix Delegation options and procedures to provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). But there is no existing mechanism to manage prefixes dynamically by an AAA server. Making use of AAA infrastructure for prefix management can solve the aforementioned problems in a uniform way. 2. Terminology Prefix Delegation (PD): The process by which a router obtains a prefix dynamically. 3. Problem Statement AAA servers managing IP address is a convention. [RFC2865] defines attribute Framed-IP-Address for allocating IPv4 address for a host. AAA servers statically configuring IPv6 prefixes is also a convention. [RFC3162] introduces Framed-IPv6-Prefix attribute for configuring IPv6 prefixes for a host. This configuration is static because Framed-IPv6-Prefix carries a number of prefixes only. Lifetime values for each prefix can not be carried. Sarikaya, et al. Expires August 25, 2008 [Page 3] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix delegation. [RFC4818] designs Delegated-IPv6-Prefix attribute which is used for delegating prefixes. However in [RFC4818], the recommended usage scenario is AAA server configures the delegating server with some prefixes and then DHCP Prefix Delegation [RFC3633] can be used to delegate these prefixes to the requesting router. Also Delegated-IPv6-Prefix carries a number of prefixes only. Lifetime values for each prefix can not be carried. In a prefix delegation application, the requesting router requests prefixes from the delegating server. The delegating server replies with one or more prefixes. When the lifetime of the prefix(es) expires, the requesting router renews its request for the prefix(es). 4. Application Scenarios Diameter prefix delegation application has the applications that are described in this section. 4.1. Prefix Management in Access Routers [RFC4968] provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. As to IPv6 addressing, there are two models, shared link model and point-to-point link model. In the former model, an IPv6 prefix is shared by multiple MNs. While in the latter model, a prefix is only assigned to one interface of MN. Different MNs can't share a prefix, and an interface can have multiple prefixes. [RFC5121] specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet convergence sub-layer of IEEE Std 802.16e [802.16e], and point-to-point link model is recommended. Also, 3GPP/3GPP2 have earlier adopted the point-to-point link model [RFC3314]. A mobile node and an Access Router are connected via a point-to-point connection at the IPv6 layer. Hence each mobile node can be considered to be on a separate subnet. The prefixes for the mobile node are advertised through Router Advertisement message [RFC4861]. When an MN attaches an Access Router(AR), the AR requests one or more prefixes for the MN from an external server or a local prefix pool. When the MN detaches the AR, the prefixes should be released. When an operator wants to renumber its network, prefixes with different lifetime are advertised to the MN. Sarikaya, et al. Expires August 25, 2008 [Page 4] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 Diameter prefix delegation application can be the mechanism to deal with how AR acquires and manages these prefixes. 4.2. Prefix Management in Local Mobility Anchors [I-D.ietf-netlmm-proxymip6] enables mobility support to a host without requiring its participation in any mobility related signaling. Point-to-point access link is supported. It assumes that the mobile node and the Mobile Access Gateway (MAG) are the only two nodes on the access link. Figure 1 shows a typical process for MN to request it's home network prefix. MN MAG LMA Server |------>| | | 1. RtSol | |------->| | 2. PBU (HNP=0) | | |<------>| 3. Prefix Exchange | |<-------| | 4. PBA (HNP) |<------| | | 5. RA(HNP) Figure 1: Prefix Delegation in Proxy Mobile IPv6 1. An MN solicits a router advertisement (RtSol) for stateless address configuration. 2. The Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU) message to Local Mobility Anchor (LMA) and with Home Network Prefix (HNP) to zero. 3. No details are provided in [I-D.ietf-netlmm-proxymip6] on how LMA manages prefixes. This is one of the motivations to design a Diameter application for prefix delegation. 4. The LMA replies PBU with Proxy Binding Acknowledgement (PBA) and sets MN's prefix to HNP field of PBA. 5. MAG advertises prefixes to MN with Router Advertisement (RA) for stateless address configuration. 4.3. Prefix Management for Mobile Routers [I-D.ietf-nemo-prefix-delegation] specifies mechanism for a Mobile Router(MR) to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. Figure 2 shows the process that a Mobile Router requests prefixes from a Home Agent. Sarikaya, et al. Expires August 25, 2008 [Page 5] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 MR HA Server | | | |------->| | 1. BU | | | | |<------>| 2. Prefix Exchange | | | |<-------| | 3. BA | | | Figure 2: Prefix Delegation in NEMO 1. Mobile Network Prefix request option defined in [I-D.ietf-nemo-prefix-delegation] is included in the Binding Update(BU) to indicate to the Home Agent(HA) that the MR wishes to get new prefixes assigned to it for use as Mobile Networks Prefixes. 2. The HA requests prefix from an external entity. There is no further description in [I-D.ietf-nemo-prefix-delegation]. The problem can also be solved by defining a new Diameter application. 3. Mobile Network Prefix Confirm option defined in [I-D.ietf-nemo-prefix-delegation] is included in the Binding Acknowledgement to allocate prefixes to the MR. Mobile Network Prefix Confirm option carries the prefix lifetime. Prefixes can be refreshed either by MR sending a BU or by HA sending a BA. 5. Requirements on AAA-based Prefix Delegation Application AAA-based prefix delegation (PD) application MUST run between a requesting router (RR), e.g. AR, LMA, MR, etc. and a delegating server (DS) which MUST be AAA server. AAA-based PD application MUST support the AAA client as RR to request prefixes from an AAA server as DS. AAA-based PD application MUST support the client as RR to give back the prefixes to AAA server as DS. If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices connected to the requesting router (RR), the certificate or the information needed to obtain a certificate entitling RR to advertise the prefix delegated to it SHOULD be sent by the delegating router. In point-to-point link operation, the requesting router MUST identify the interface of MN in its request. The requesting router MAY Sarikaya, et al. Expires August 25, 2008 [Page 6] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 provide a prefix hint, e.g. of length /48 to which the delegating server MUST reply with one or more prefixes, e.g. of length /64. In point-to-point operation, the delegating server MAY assign the prefix(es) and related parameters such as the lifetime and the certificates to MN from MN's profile. AAA-based prefix delegation application SHOULD support prefix release procedures. The AAA client as RR is responsible for renewing the prefixes when the lifetime expires. The AAA client as RR SHOULD be able to extend the lifetime of the prefixes using messages designed for this purpose. It SHOULD be possible to renumber the prefixes delegated by AAA server. The AAA server as DS SHOULD initiate prefix renumbering process. 6. Security Considerations This document is a problem statement that does not by itself introduce any security issues. 7. IANA Considerations None. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Sarikaya, et al. Expires August 25, 2008 [Page 7] Internet-Draft PS:Diameter Prefix Delegation Application February 2008 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 9.2. Informative references [802.16e] Institute of Electrical and Electronics Engineer, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE 802.16e/D12. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007. [I-D.ietf-nemo-prefix-delegation] Kniveton, T. and P. Thubert, "Mobile Network Prefix Delegation", draft-ietf-nemo-prefix-delegation-02 (work in progress), August 2007. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), February 2008. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Sarikaya, et al. Expires August 25, 2008 [Page 8] Internet-Draft PS:Diameter Prefix Delegation Application February 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 Jouni Korhonen TeliaSonera Corporation P.O.Box 970 FI-00051 Sonera, FINLAND Email: Jouni.korhonen@teliasonera.com Sarikaya, et al. Expires August 25, 2008 [Page 9] Internet-Draft PS:Diameter Prefix Delegation Application 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). Sarikaya, et al. Expires August 25, 2008 [Page 10]