Network Working Group F. Xia Internet-Draft B. Sarikaya Intended status: Standards Track Huawei USA Expires: September 5, 2007 March 4, 2007 Using DHCPv6 and AAA Server for Mobile Station Prefix Delegation 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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires September 5, 2007 [Page 1] Internet-Draft Prefix Delegation March 2007 Abstract In the 802.16 Per-MS prefix model, one prefix can only be assigned to one mobile station by an access router and different mobile stations can't share a prefix. Managing Per-MS prefixes is likely to increase the processing load at the access router. Based on the idea that DHCPv6 servers can manage prefixes as well as addresses, we propose a new technique in which the access router offloads delegation and release tasks of the prefixes to an DHCPv6 server. The access router first requests a prefix for an incoming mobile station to the DHCPv6 server. The access router next advertises the prefix information to the mobile station with a Router Advertisement message. When the mobile station leaves, the prefix is returned to the DHCPv6 server. We also describe how prefix delegation can be done by AAA servers as an alternative technique. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . . . . 4 3.1. Prefix Request Procedure for Stateless Address Configuration . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Prefix Request Procedure for Stateful Address Configuration . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Prefix Release Procedure . . . . . . . . . . . . . . . . . 6 3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1. Renumbering Through Renew Message . . . . . . . . . . 6 3.4.2. Server Initiated Reconfiguration . . . . . . . . . . . 7 3.5. Miscellaneous Considerations . . . . . . . . . . . . . . . 7 3.5.1. Triggers for an AR to initiate prefix request procedure . . . . . . . . . . . . . . . . . . . . . . 7 3.5.2. How to generate IAID . . . . . . . . . . . . . . . . . 7 3.5.3. Policy to delegate prefixes . . . . . . . . . . . . . 7 4. Prefix Delegation Using RADIUS and Diameter . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Xia & Sarikaya Expires September 5, 2007 [Page 2] Internet-Draft Prefix Delegation March 2007 1. Introduction Figure 1 illustrates the key elements of a typical IEEE 802.16d/e access network. Customer | Access Provider | Service Provider Premise | | (Backend Network) +-----+ +-----+ +------+ +--------+ | MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP +-----+ +-----+ |Router| | Router +==>Network +--+---+ +--------+ +-----+ +-----+ | | +------+ | Mss |--(802.16)--| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 1: Key elements of a typical IEEE 802.16d/e access network Mobile stations (MS) attach to a base station (BS) through 802.16d/e air interface. A BS manages connectivity of MSs and extend connections to an Access Router (AR). The Access router is the first IP hop router of MSs. As to IPv6 addressing, there are two models, shared prefix and Per-MS prefix. In the shared prefix model, an IPv6 prefix is shared by multiple MSs. While in the Per-MS prefix model, a prefix is only assigned to one MS. Different MSs can't share a prefix, and an MS can have multiple prefixes. [I-D.ietf-16ng-ipv6-link-model-analysis] briefly compares the two models. Per-MS model has some advantages, such as, no complicated duplicate address detection (DAD), fit naturally to the point-to- point links and so on. In Per-MS prefix model, prefix management is an issue. When an MS attaches an AR, the AR requests one or more prefixes for the MS. When the MS detaches the AR, the prefixes should be released. When the MS becomes idle, the AR should hold the prefixes allocated. When an operator wants to renumber its network, prefixes with different lifetime are advertised to the MS. DHCPv6 is a preferable way to manage the prefixes. At the same time, AAA protocols, RADIUS and Diameter, are also alternatives for prefix delegation. Xia & Sarikaya Expires September 5, 2007 [Page 3] Internet-Draft Prefix Delegation March 2007 2. Terminology 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 BCP 14 [RFC2119]. This document uses the terminology defined in [RFC3315], [RFC3633] and [I-D.ietf-16ng-ps-goals]. 3. Prefix Delegation Using DHCPv6 3.1. Prefix Request Procedure for Stateless Address Configuration +-------+ +-------+ +-----------+ | MS | | AR | |DHCP Server| +-------+ +-------+ +-----------+ | | | | 1 N/W Entry & Auth | | |<--------------------->| | | |2 Relay-forward/Solicit| | |---------------------> | | | | | |3 Relay-reply/Advertise| | |<--------------------- | | | | | |4 Relay-forward/Request| | |---------------------> | | | | | |5 Relay-reply/Reply | | |<--------------------- | |6 Transport Connection | | | Established | | |<--------------------->| | | | | | 7 Router Advertisement| | |---------------------->| | | | | | 8 MLD Join | | |---------------------->| | | | | | 9 DAD Procedure | | |<--------------------->| | | | | Figure 2: Prefix request There are two function modules in the AR, DHCP Client and DHCP Relay. Xia & Sarikaya Expires September 5, 2007 [Page 4] Internet-Draft Prefix Delegation March 2007 DHCP messages should be relayed if the AR and a DHCP server are not connected directly, otherwise DHCP relay function in the AR is not necessary. Figure 2 illustrates the scenario that the AR and the DHCP Server aren't connected directly: 1. An MS performs initial network entry and authentication procedures. 2. On successful completion of Step 1, the AR initiates DHCP Solicit procedure to request prefixes for the MS. The AR 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. The AR creates an IA_PD and assigns it an IAID. The AR MUST include the IA_PD option in the Solicit message. 3. The DHCP server sends an Advertise message to the AR in the same way as described in section 17.2.2, "Creation and transmission of Advertise messages" of RFC 3315. 4. The AR 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. The AR 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. AR stores the prefix information it received in the Reply message. 6. A transport connection is established, and thus a virtual link is created and becomes active. An transport connection can be viewed as a virtual link. 7. The AR advertises prefixes to MS with RA once the virtual link is active. 8. The MS constructs a solicited node multicast address for the corresponding Link Local Address and sends MLD Join request for the solicited node multicast address. 9. The MS starts verifying address uniqueness by sending a DAD NS on the virtual link. AR can check the address uniqueness within the virtual link scope. 3.2. Prefix Request Procedure for Stateful Address Configuration After the initial network entry and authentication, a transport connection is established for the MS. DHCPv6 client at the MS sends DHCP Request to DHCP Relay function at AR. DHCP Relay sends DHCP Request with DHCP Forward message to DHCP Server. AR MUST set the link-address field of DHCP Forward to the aggregate prefix. DHCP Server assigns an address and a unique prefix for MS and replies with DHCP Reply message which is relayed to DHCP Relay in Relay-reply message and AR sends DHCP Reply message with the new prefix to MS. Xia & Sarikaya Expires September 5, 2007 [Page 5] Internet-Draft Prefix Delegation March 2007 MS configures its interface with the address assigned by DHCP server in DHCP Reply message. 3.3. Prefix Release Procedure +-------+ +-------+ +-----------+ | MS | | AR | |DHCP Server| +-------+ +-------+ +-----------+ | | | | 1 De-registration | | | Handover, or others | | |<--------------------->| | | |2 Relay-forward/Release| | |---------------------->| | | | | |3 Relay-reply/Reply | | |<--------------------- | | | | | | | Figure 3: Prefix Release 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 MS when the prefix ages, and the DHCP Server can delegate it to another MS. A prefix lifetime is delivered from the DHCPv6 server to the MS through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information option [I-D.ietf-ipv6-2461bis]. Figure 3 illustrates how the AR releases prefixes to an DHCP Server which isn't connected directly: 1. An MS detachment signaling, such as switch-off or handover, triggers prefix release procedure. 2. The AR initiates a Release message to give back the prefixes to the DHCP server. 3. The server responds with a Reply message, and then the prefixes can be reused by other MSs. 3.4. Renumbering 3.4.1. Renumbering Through Renew Message To extend the valid and preferred lifetimes for the prefixes associated with an MS, the MS sends a Renew message to the DHCP server. The server determines new lifetimes for the prefixes. The server MAY add new prefixes to the MS for renumbering. For a more detailed description, see [I-D.ietf-ipv6-rfc2462bis] Xia & Sarikaya Expires September 5, 2007 [Page 6] Internet-Draft Prefix Delegation March 2007 3.4.2. Server Initiated Reconfiguration DHCP server initiates a configuration message exchange with the AR by sending a Reconfigure message. The reconfigure message triggers the AR to send Renew message as described in Section 3.4.1. 3.5. Miscellaneous Considerations 3.5.1. Triggers for an AR to initiate prefix request procedure There are some other triggers for an AR to initiate prefix request procedure besides network entry and authentication, such as, when an AR receives handover initiate (HI) message in FMIPv6 [RFC4068], or other handover signaling. After getting an incoming MS' necessary information (such as MAC address), the AR SHOULD initiate prefix request procedure as soon as possible. 3.5.2. How to generate IAID IAID is 4 bytes in length and should be unique in an AR scope. We can use an MS' MAC address as a part to generate IAID. An IAID generation algorithm should be designed. 3.5.3. Policy to delegate prefixes AR should broadcast the prefix(es) dynamically upstream as the route information of all the MSs connected to this AR. In point-to-point links, this causes high routing protocol traffic (IGMP, OSPF, etc.) due to Per-MS prefixes. To solve the problem, route aggregation should be used. For example, each AR can be assigned a /48 or /32 prefix (aggregate prefix) while each MS can be assigned a /64 prefix. The /64 prefix is an extension of /48 one, for example, an AR's /48 prefix is 3FFE:FFFF:0::/48, an MS is assigned 3FFE:FFFF:0:2::/64 prefix. The AR only broadcasts it's /48 or /32 prefix information to Internet. This policy can be enforced as follows: DHCP Relay MUST set the link- address field in the Relay Forward message to the aggregate prefix (/48, /32, or /16 prefix assigned to the AR). 4. Prefix Delegation Using RADIUS and Diameter [I-D.ietf-radext-delegated-prefix] defines a RADIUS attribute Delegated-IPv6-Prefix that carries an IPv6 prefix to be delegated. This attribute is usable within either RADIUS or Diameter. In the bootstraping procedure, an AR as RADIUS client sends Access-Request message with an MS' information to RADIUS server. If the MS passes Xia & Sarikaya Expires September 5, 2007 [Page 7] Internet-Draft Prefix Delegation March 2007 the authentication, the RADIUS server sends Access-Accept message with prefix information to the AR. The attribute MAY appear in an Access-Request packet as a hint by the AR to the RADIUS server that it would prefer a prefix, for example, a /48 prefix. The RADIUS server MAY delegate a /64 prefix which is an extension of the /48 prefix in an Access-Accept message containing Delegated-IPv6-Prefix attribute. The attribute can appear multiple times when RADIUS server assigns multiple prefixes to MS. When Diameter is used, an AR as Diameter client sends AA-Request message. AA-Request message MAY contain Delegated-IPv6-Prefix attribute. Diameter server replies with AA-Answer message. AA- Answer message MAY contain Delegated-IPv6-Prefix attribute. The attribute can appear multiple times when Diameter server assigns multiple prefixes to MS. The Delegated-IPv6-Prefix attribute MAY appear in an AA-Request packet as a hint by the AR to the Diameter server that it would prefer a prefix, for example, a /48 prefix. Diameter server MAY delegate in an AA-Answer message with a /64 prefix which is an extension of the /48 prefix. For RADIUS, when the MS hands off or switches off, the AR release the MS' prefixes through Accounting Stop message [RFC2866]. For Diameter, the AR release prefixes through Accounting- Request[RFC3588]. AR MUST advertize the prefix(es) to MS in RtrAdv message. Site renumbering is an open issue for RADIUS/ Diameter protocols to manage prefixes. [RFC3576] MAY be used for renumbering. 5. Security Considerations This draft introduces no additional messages. Comparing to [RFC3633], [RFC2865] and [RFC3588] there is no additional threats to be introduced. DHCPv6, RADIUS and Diameter security procedures apply. 6. References 6.1. Normative References [I-D.ietf-16ng-ps-goals] Jee, J., "IP over 802.16 Problem Statement and Goals", draft-ietf-16ng-ps-goals-01 (work in progress), February 2007. Xia & Sarikaya Expires September 5, 2007 [Page 8] Internet-Draft Prefix Delegation March 2007 [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-10 (work in progress), January 2007. [I-D.ietf-ipv6-rfc2462bis] Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [I-D.ietf-radext-delegated-prefix] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", draft-ietf-radext-delegated-prefix-05 (work in progress), October 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [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. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. 6.2. Informative References [I-D.ietf-16ng-ipv6-link-model-analysis] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", Xia & Sarikaya Expires September 5, 2007 [Page 9] Internet-Draft Prefix Delegation March 2007 draft-ietf-16ng-ipv6-link-model-analysis-03 (work in progress), February 2007. Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Email: sarikaya@ieee.org Xia & Sarikaya Expires September 5, 2007 [Page 10] Internet-Draft Prefix Delegation March 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). Xia & Sarikaya Expires September 5, 2007 [Page 11]