Network Working Group B. Sarikaya Internet-Draft F. Xia Intended status: Standards Track Huawei USA Expires: September 10, 2009 March 9, 2009 RADIUS Support for Prefix Authorization draft-sarikaya-radext-prefix-authorization-03.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 September 10, 2009. 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 September 10, 2009 [Page 1] Internet-Draft RADIUS Prefix Authorization March 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 September 10, 2009 [Page 2] Internet-Draft RADIUS Prefix Authorization March 2009 Abstract This document specifies a new attribute for supporting prefix authorization. Using RADIUS protocol, a client requests prefixes from a server; the client gives back the prefixes to the server; the client is responsible for renewing the prefixes when the lifetime expires. The RADIUS server can also renumber prefixes. RADIUS clients can be home agents in MIPv6 and NEMO scenario, local mobile anchors in Proxy MIPv6 scenario, or common access routers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Prefix Authorization Usage Scenarios . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 4.1. Prefix Request . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Prefix Release . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Prefix Renew . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Prefix Renumbering . . . . . . . . . . . . . . . . . . . . 9 5. Use of Existing RADIUS Attributes . . . . . . . . . . . . . . 10 5.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Message Authenticator . . . . . . . . . . . . . . . . . . 11 5.4. Framed Interface Id . . . . . . . . . . . . . . . . . . . 11 5.5. IPv6 Prefix Information . . . . . . . . . . . . . . . . . 11 6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Prefix Authorization Type . . . . . . . . . . . . . . . . 11 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 12 8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. Registration of New AVPs . . . . . . . . . . . . . . . . . 13 9.2. New Registry: Prefix Authorization Type . . . . . . . . . 13 9.3. Addition of Existing Values . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative references . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Sarikaya & Xia Expires September 10, 2009 [Page 3] Internet-Draft RADIUS Prefix Authorization March 2009 1. Introduction 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. Authorizing the use of a prefix that a central server has by a prefix user needs communication between different network entities. [RFC4968] provides different IPv6 link models that are suitable for 802.16e [802.16e] 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 MN. Different MNs can't share a prefix, and an MN 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 and 3GPP2 have earlier adopted the point-to- point link model [RFC3314]. When an MN attaches an Access Router(AR), the AR requests one or more prefixes for the MN. When the MN detaches the AR, the prefixes should be released. When an operator wants to renumber its network, prefixes with different lifetimes are advertised to the MN. Using the mechanism defined in this document, AR can offload prefix management to a dedicated server. The prefix management method defined in this document is applicable to this scenario. Proxy Mobile IPv6 protocol enables mobility support to a host without requiring its participation in any mobility related signaling [RFC5213]. 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. Proxy Binding Update and Proxy Binding Acknowledgement are used by Local Mobility Anchor (LMA) to allocate the prefixes for the mobile node to MAG. How LMA gets these prefixes from external servers is out of scope of PMIPv6 protocol. The prefix management method defined here is also applicable to this scenario. [RFC3633] defines Prefix Delegation options to provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). [I-D.ietf-nemo-dhcpv6-pd] describes how DHCPv6 PD can be used by mobile routers and home agents in network mobility. In DHCPv6 PD, the delegating router can receive the prefixes from AAA Sarikaya & Xia Expires September 10, 2009 [Page 4] Internet-Draft RADIUS Prefix Authorization March 2009 server and Delegated-IPv6-Prefix RADIUS attribute was defined for this purpose [RFC4818]. In this case AAA server passively delegates the prefixes to the delegating router and it does not have any control over these prefixes in cases such as renumbering. This document describes how prefix authorization can be achieved using RADIUS [RFC2865] and [I-D.ietf-radext-design]. The message exchanges described in this document will enable full prefix authorization functionality to the AAA servers. 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 [RFC2119]. Authorized Prefixes: A collection of prefixes assigned to AAA client. Each has an associated User Identity. This concept is captured in pairs of Framed-Interface-Id and Framed-IPv6-Prefix- Lifetime attributes defined in [RFC3162] and [I-D.lourdelet-radext-ipv6-access], respectively. An AAA client may have more than one authorized prefix assigned to it; for example, one for each of access user's interface. Also each interface may be assigned more than one prefixes. User identifier: An identifier chosen by the client. Each user has an user identifier, which is chosen to be unique among all user identifiers for users belonging to that client. This concept is captured in Framed-Interface-Id attribute defined in [RFC3162]. Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast the prefixes (MNs route information) dynamically upstream, and this causes high routing protocol traffic (OSPF, etc.). To solve the problem, route aggregation should be used. For example, each AR can be assigned a /48 prefix, while an MN's /64 prefix is derived from the /48 prefix extension. The main, higher-level prefix is called the Aggregate Prefix. An AR only broadcasts the aggregate prefix upstream. Aggregate prefix is a pool of dedicated prefixes. Dedicated Prefix: A unique prefix used by MN in Point-to-Point Link Model. A dedicated prefix belongs to an aggregate prefix. Dedicated prefix information never be broadcasted by routing protocol. In this memo, AAA client requests dedicated prefix along with the corresponding aggregate prefix from AAA server. Using the corresponding aggregate prefix information, AAA client broadcasts upstream MN's route information. Sarikaya & Xia Expires September 10, 2009 [Page 5] Internet-Draft RADIUS Prefix Authorization March 2009 Prefix Authorization Client (PA Client): RADIUS Client which is responsible for exchange with a RADIUS Server to fulfill prefix request, release, renew and reconfiguration functions. In this document, it can be a HA for allocating prefix for mobile router, or a local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIPv6) scenario for managing dedicated prefix of MN, or an access router in point-to-point link model. Prefix Authorization Server (PA Server): RADIUS Server which is responsible for exchange with a RADIUS Client to fulfill prefix request, release, renew and reconfiguration functions. In this document, it can be collocated with a RADIUS authentication server, or it can be a separated server managing prefixes. Prefix Authorization User (PA User): The end user of prefixes. In this document, it can be MN which configures it's prefixes from LMA in PMIPv6 scenario, or a mobile router, or MN which requests it's prefix in a visited network. 3. Prefix Authorization Usage Scenarios Prefix authorization can be used in Simple IP, Mobile IP, Proxy Mobile IP and Network Mobility (NEMO) use cases. In Simple IP use case the user is not provided any mobility support, i.e. the sessions will not survive when the user changes its IP connectivity. Such a user MAY use stateless address configuration or address assignment may be carried over during network entry. If stateless address configuration is used, the access router MAY use prefix authorization defined in this document to get prefix(es) authorized for the user and then use router advertisements to advertise the prefix(es). This has to be done specifically for each user because of the point-to-point link model used on links such as IEEE 802.16e [RFC5121] or 3GPP . During network entry, the access router and AAA server communicate to authenticate the user. if authentication is successful, AR and AAA MAY use prefix authorization defined in this document to get prefix(es) authorized for the user. If stateful address configuration is used DHCP server assigns an address from the authorized prefix(es) to the user. In Mobile IP use case the user is a Mobile IP client. Mobile IP client or Mobile Node (MN) first gets a home address assigned by the Mobile IPv6 Home Agent (HA). The recommended procedure is to use IKEv2 exchange. Mobile Node includes the MIP6_HOME_PREFIX attribute in IKEv2 CFG_REQUEST message. Home agent MAY use prefix authorization defined in this document to get prefix(es) authorized Sarikaya & Xia Expires September 10, 2009 [Page 6] Internet-Draft RADIUS Prefix Authorization March 2009 for MN. The Home Agent, when it processes this message, MUST include in the CFG_REPLY payload prefix information for one prefix on the home link [RFC5026]. This represents another use case for prefix authorization defined in this document by the home agent to get prefix(es) authorized for the user. In Proxy Mobile IP, when the user enters the network, Mobile Access Gateway (MAG) sends a Proxy Binding Update message to Local Mobility Anchor (LMA) to request prefix(es) to be assigned for the user. LMA using prefix authorization defined in this document gets prefix(es) authorized for the user and returns prefix(es) in Proxy Binding Update message to MAG. MAG advertizes the prefixes on the link and MN creates a home address. In network mobility, the mobile router (MR) needs to assign mobile network prefix(es) to the local nodes in the mobile network. MR gets the mobile network prefix(es) from the home agent. This represents another use case for prefix authorization defined in this document by the home agent to get prefix(es) authorized for the local user in the mobile network. In network mobility, there is another use case. MR is a Mobile IP client and needs to get a home address. This case is already described above in Mobile IP use case. 4. Protocol Description Figure 1 shows the architecture of the solution described in this document. PA Client PA Server +----+ +--------+ +-------------+ | | | | RADIUS EAP | +--------+ | | PA |<--->| AR or |<--------------------------->|AAA-EAP | | |User| | LMA or| (Authentication) | +--------+ | | | | HA | | | +----+ | | | | | |RADIUS Prefix Authorization| +---------+ | | |<--------------------------->| AAA-PA | | | | (Authorization) | +---------+ | +--------+ +-------------+ Figure 1: Architecture Overview Sarikaya & Xia Expires September 10, 2009 [Page 7] Internet-Draft RADIUS Prefix Authorization March 2009 The use of EAP and the existence of the RADIUS support for EAP [RFC3579] has made the RADIUS community to separate the act of authentication from authorization, and in this case, prefix management is a type of authorization. This way, the peer (MN) and AAA client first run an EAP method with the AAA server using RADIUS support for EAP, followed by a service authorization process for prefixes. To explicitly authorize the prefixes, in this document, we define RADIUS support. RADIUS messages defined in [RFC2865] and in [RFC5176] are used. 4.1. Prefix Request A PA Client sends an Access-Request message containing identity of the user to a PA server for prefix request. The client is identified using Framed-Interface-Id defined in [RFC3162]. Access-Request message MUST contain Authorized-UserID-Prefix attribute. The client MAY request an aggregate prefix, and then MAY subnet the prefix to the users. It is also possible that the client only requests a dedicated prefix. The PA server allocates one or more prefixes for the client using Access-Accept. Lifetime of prefixes is included in Valid Lifetime field of Framed-IPv6-Prefix-Lifetime in this message. The lifetime value included is the value proposed by PA Client. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Request. PA Server replies with Access-Accept to PA Client. PA server MUST include pairs of Framed-IPv6-Prefix-Lifetime and Framed-Interface-Id attributes in Access-Accept. The server authorizes prefixes included in Framed-IPv6-Prefix-Lifetime to PA Client. The prefixes can be used during Valid Lifetime period. Access-Accept MUST contain Prefix-Authorization type attribute. The value MUST be set to Request. PA Server replies with Access-Accept if the prefix request can be satisfied. In case of a prefix request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access- Reject indicates an unsuccessful prefix request made by PA Client. Reply-Message attribute indicates the failure message. Prefix- Authorization type attribute MUST be set to Request. 4.2. Prefix Release When a PA User detaches a PA Client, the prefixes allocated to the user should be released. Access-Request is sent by a PA Client to a PA Server. The server replies with Access-Accept to confirm the reception and process of the prefix release. Sarikaya & Xia Expires September 10, 2009 [Page 8] Internet-Draft RADIUS Prefix Authorization March 2009 PA User and the prefixes to be released are identified in Access- Request and Access-Accept using Framed-Interface-Id attribute. Multiple occurrences of this attribute can be included to release multiple prefixes authorized to the same user or to release prefixes authorized to more than one user. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Release. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Release. PA Server replies with Access-Accept if the prefix release request can be satisfied. In case of a prefix release request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix release request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Release. 4.3. Prefix Renew When the lifetime of prefixes will expire, a PA client renews the prefix using Access-Request message. A PA server sends Access-Accept with the new lifetime of the prefixes. PA User and the prefixes to be renewed are identified in Access- Request and Access-Accept using Framed-Interface-Id attribute. Multiple occurrences of this attribute can be included to renew multiple prefixes authorized to the same user or to renew prefixes authorized to more than one user. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Renew. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Renew. PA Server replies with Access-Accept if the prefix renew request can be satisfied. In case of a prefix renew request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix renew request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Renew. 4.4. Prefix Renumbering Renumbering is an important feature of IPv6. A PA Server sends Change-of-Authorization-Request message to initiate prefix renumbering process. Once the message is received, a PA client replies with Change-of-Authorization-ACK and then starts the prefix renumber interactions to acquire new prefixes and reduce the lifetime of the old prefixes. The server sends Access-Accept with new Sarikaya & Xia Expires September 10, 2009 [Page 9] Internet-Draft RADIUS Prefix Authorization March 2009 prefixes, at the same time the old prefixes are also included in the message while the lifetime is reduced. The procedure is illustrated in Figure 2. +----------+ +----------+ | RADIUS | | RADIUS | | Client | | Server | +----------+ +----------+ | | | | | Change-of-Authorization-Request | |<----------------------------------| | | | Change-of-Authorization-ACK | |---------------------------------->| | | | Access-Request | |---------------------------------->| | Access-Accept | |<--------------------------------- | Figure 2: Renumbering Change-of-Authorization Request and Change-of-Authorization-ACK MUST contain Prefix-Authorization type with value set to Renumber. Access-Request MUST contain Prefix-Authorization type attribute. The value MUST be set to Renumber. Access-Accept MUST contain Prefix- Authorization type attribute. The value MUST be set to Renumber. PA Server replies with Access-Accept if the prefix renumber request can be satisfied. In case of a prefix renumber request that can not be fullfilled by PA Server, PA Server sends Access-Reject. Reception of an Access-Reject indicates an unsuccessful prefix renumber request made by PA Client. Reply-Message attribute indicates the failure message. Prefix-Authorization type attribute MUST be set to Renumber. 5. Use of Existing RADIUS Attributes This section defines existing attributes that are used in the messages of for supporting prefix authorization. Sarikaya & Xia Expires September 10, 2009 [Page 10] Internet-Draft RADIUS Prefix Authorization March 2009 5.1. Service-Type PA Client uses Session-Type to indicate that the session is for prefix authorization by setting the Session-Type attribute to "Authorize Only". 5.2. NAS-Port-Type NAS-Port-Type is used by AAA server (PA-Server) to distinguish the source of the Access-Request. When the Access-Request originates from an MIP6 HA or PMIP6 LMA, NAS- Port-Type MUST be included and its value set to HA6 as in [I-D.ietf-mip6-radius]. When the Access-Request originates from an access router such as ASN-GW of WiMAX or Serving Gateway of 3GPP, NAS-Port-Type MUST be included and its value set to AR6 (IANA-TBD1). 5.3. Message Authenticator Message-Authenticator attribute defined in [RFC3579] MUST be used to protect all messages used in Prefix Authorization. In the messages used for renumbering, Message-Authenticator attribute is calculated as described in [RFC5176]. 5.4. Framed Interface Id Framed-Interface-Id attribute defined in [RFC3162] MUST be used in all messages defined above in Section 4. 5.5. IPv6 Prefix Information Framed-IPv6-Prefix-Lifetime attribute defined in [I-D.lourdelet-radext-ipv6-access] MUST be used in all messages defined above in Section 4. 6. New Attributes This section defines new attributes. 6.1. Prefix Authorization Type Prefix-Authorization-Type attribute contains the type of prefix authorization operation needed by PA Client. The possible values are Request, Renew, Release and Renumber. Sarikaya & Xia Expires September 10, 2009 [Page 11] Internet-Draft RADIUS Prefix Authorization March 2009 Prefix-Authorization attribute is defined as follows. 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 | Prefix Authorization Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. Length The length, 4. Prefix Authorization Type is a 32-bit unsigned integer with the following values: 1 Request 2 Release 3 Renew 4 Renumber 7. Table of Attributes The following tables provides a guide to which attributes may be found in RADIUS messages and in what number. The following defines the meaning of the notation used in the following tables: 0 An instance of this attribute MUST NOT be present. 1 Exactly one instance of this attribute MUST be present 0-1 Zero or one instance of this attribute MAY be present. 0+ Zero or more instance of this attriubte MAY be present The table below describes the RADIUS messages used for bootstrapping and are exchanged between the NAS and the RADIUS Server. Request Accept Reject CoA Request # Attribute 1 1 1 1 TBA Prefix-Authorization-Type 0+ 0+ 0+ 0+ TBA Framed-IPv6-Prefix-Lifetime 0+ 0+ 0+ 0+ 96 Framed-Interface-Id Sarikaya & Xia Expires September 10, 2009 [Page 12] Internet-Draft RADIUS Prefix Authorization March 2009 8. Diameter Considerations Prefix-Authorization-Type attribute defined in this specification. Diameter compatibility is assured. 9. IANA considerations 9.1. Registration of New AVPs This specification defines the following new RADIUS attribute. Prefix-Authorization is set to PREFIX-AUTHORIZATION-TYPE 9.2. New Registry: Prefix Authorization Type This specification needs new values for Prefix-Authorization-Type. The value field is 4 octets. The current values are listed in Section 6.1. 9.3. Addition of Existing Values This specification requires a new value of AR6 to be assigned to NAS- Port-Type(61). 10. Security Considerations This document describes the extension of RADIUS for Prefix Authorization. The security considerations of the RADIUS protocol itself have been discussed in [RFC2865] and in [RFC5176]. Use of the attribute defined in this document MUST take into consideration the security issues and requirements of the RADIUS Base protocol. 11. Acknowledgements Madjid Nakhjiri provided help on RADIUS for which we are grateful. 12. References 12.1. Normative References [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, Sarikaya & Xia Expires September 10, 2009 [Page 13] Internet-Draft RADIUS Prefix Authorization March 2009 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [I-D.lourdelet-radext-ipv6-access] Lourdelet, B., Dec, W., and G. Zorn, "RADIUS attributes for IPv6 Access Networks", draft-lourdelet-radext-ipv6-access-00 (work in progress), March 2009. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. 12.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. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Sarikaya & Xia Expires September 10, 2009 [Page 14] Internet-Draft RADIUS Prefix Authorization March 2009 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [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. [I-D.ietf-radext-design] Weber, G. and A. DeKok, "RADIUS Design Guidelines", draft-ietf-radext-design-07 (work in progress), March 2009. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [I-D.ietf-mip6-radius] Lior, A., Chowdhury, K., and H. Tschofenig, "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-06 (work in progress), November 2008. Sarikaya & Xia Expires September 10, 2009 [Page 15] Internet-Draft RADIUS Prefix Authorization March 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 September 10, 2009 [Page 16]