Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: May 9, 2008 Huawei USA November 6, 2007 Problem Statement: Diameter Prefix Delegation Application draft-sarikaya-dime-prefix-delegation-ps-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 May 9, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Sarikaya & Xia Expires May 9, 2008 [Page 1] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 Abstract Point-to-point link model requires unique prefixes to be assigned to each interface of the mobile nodes. In NEMO, home agents need to assign unique prefixes to mobile routers. Prefix management in point-to-point links and in NEMO will be facilitated if AAA servers can delegate prefixes. This document identifies the following use cases where Diameter prefix delegation application is needed. In 16NG, prefix delegation only occurs between an Access Router and a mobile node, and there is no discussion about how an Access Router acquires prefix from an 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 prefix from back end servers. In Proxy Mobile IPv6, Proxy Binding Update and Proxy Binding Acknowledgement message pair is used to allocate prefix from a Local Mobile Anchor for a Mobile Node's interface but how a Local Mobile Anchor gets prefixes from external server is currently left open. Next, the document identifies requirements on a AAA-based prefix delegation application. Sarikaya & Xia Expires May 9, 2008 [Page 2] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 3.1. Prefix Management in Access Routers . . . . . . . . . . . 4 3.2. Prefix Management in Local Mobile Anchors . . . . . . . . 5 3.3. Prefix Management for Mobile Routers . . . . . . . . . . . 6 4. Requirements on AAA-based Prefix Delegation Application . . . 6 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Sarikaya & Xia Expires May 9, 2008 [Page 3] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 1. Terminology Prefix Delegation (PD): The process by which a router or a host obtains a prefix dynamically. 2. 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 host or router) needs communication between different network entities. Prefix delegation is widely discussed in IETF 16NG, NEMO, and NETLMM Working Group respectively. 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]. and 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], 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 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. 3. Problem Description 3.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 Sarikaya & Xia Expires May 9, 2008 [Page 4] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 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. [I-D.ietf-16ng-ipv6-over-ipv6cs] 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 in [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. there isn't any mechanism to deal with how AR acquires and manages these prefixes. 3.2. Prefix Management in Local Mobile 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 that MN requests 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 Mobile 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 exchange. Sarikaya & Xia Expires May 9, 2008 [Page 5] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 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 3.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. 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. 4. 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 Sarikaya & Xia Expires May 9, 2008 [Page 6] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 DS. In point-to-point link operation, the requesting router MUST identify the interface of MN in its request. The requesting router MAY 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. 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. 5. Conclusions AAA servers managing IP address is a convention. [RFC2865] defines attribute Framed-IP-Address for allocation IPv4 address for a host. [RFC3162] introduces some attributes for IPv6 address management. [RFC4818] designs Delegated-IPv6-Prefix attribute which is used for delegating prefixes for user. Prefix management is the natural extension of address management. Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix delegation. 6. Security Considerations This document is a problem statement that does not by itself introduce any security issues. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sarikaya & Xia Expires May 9, 2008 [Page 7] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 [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. [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. 8.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. [I-D.ietf-16ng-ipv6-over-ipv6cs] Patil, B., "IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-09 (work in progress), April 2007. [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-07 (work in progress), November 2007. [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 & Xia Expires May 9, 2008 [Page 8] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 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 May 9, 2008 [Page 9] Internet-Draft PS:Diameter Prefix Delegation Application November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 & Xia Expires May 9, 2008 [Page 10]