DHC Working Group L. Yeh, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track March 5, 2012 Expires: September 6, 2012 Authorization Option for DHCPv6 Relay Agents on Broadband Access Server draft-yeh-dhc-dhcpv6-authorization-opt-00 Abstract The DHCPv6 authorization option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information got from the s/got/received/ centralized RADIUS server which is not located at the same place of DHCPv6 server in the case when the NAS works as DHCPv6 relay agent and RADIUS client simultaneously. s/the centralized RADIUS server which is not located at the same place of DHCPv6 server/ /a separate RADIUS server/ s/in the case when the NAS works/in cases where the NAS acts/ Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Yeh Expires September 6, 2012 [Page 1] Internet-Draft DHCPv6 Authorization Option March 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Language . . . . . . . . . . . . . . . . . . . 3 3. Network Scenario . . . . . . . . . . . . . . . . . . . . . . . 4 4. Option_Authorization . . . . . . . . . . . . . . . . . . . . . 5 5. Sub-options of Option_Authorization . . . . . . . . . . . . . . 6 5.1. Option_Pool_Name . . . . . . . . . . . . . . . . . . . . . 6 5.2. Option_Address_Prefix_Auth . . . . . . . . . . . . . . . . 6 6. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Yeh Expires September 6, 2012 [Page 2] Internet-Draft DHCPv6 Authorization Option March 2012 1. Introduction DHCPv6 has been designed for the server to provide, assign or delegate both stateful and stateless configuration parameters to the s/has been designed for the server to/provides a mechanism that allows the server to/ clients. The stateful configuration parameters include IPv6 address s/to the clients/to clients/ [RFC3315], IPv6 prefix [RFC3633], and etc. The stateless configuration parameters include DNS [RFC3646], and etc [RFC3736]. s/The stateless configuration parameters include DNS [RFC3646], and etc [RFC3736]./ /Stateless configuration parameters [RFC3736] include, for example, DNS [RFC3646]./ The server could always be deployed as a centralized one in the ISP network. s/The server could always be deployed as a centralized one/ /DHCP servers are typically deployed in a central part of an ISP network./ Essentially as a stateless protocol, RADIUS [RFC2865] has been widely used as the centralized authentication, authorization and user s/Essentially as a stateless protocol, RADIUS [RFC2865] has been widely used/ /RADIUS, an essentially stateless protocol, is in wide use/ management method for the service provision in Broadband access s/method/mechanism/ network. [RFC3162], [RFC4818] and [ietf-radext-ipv6-access-06] has specified some attributes to support the service provision for IPv6 s/has specified some attributes to/specify attributes that/ s/the service provision/the provision of service/ access, which authorize NAS to assign IPv6 address or prefix from the s/, which authorize/. RADIUS authorizes the/ s/assign address or prefix/assigns an address or prefix/ indicated pool, or assign IPv6 address or prefix with the explicitly s/assign address or prefix/assigns an address or prefix/ s/the explicitly/an explicitly/ indicated value, for the users which also acts as a DHCPv6 client. s/, for the users which also acts as a DHCP client./ /XXX/ (I don't know what you mean here.) These mechanism can work fine with the deployment scenarios when NAS s/""/This mechanism works well in deployment scenarios where the NAS/ acts as the distributed DHCPv6 server, NAS can execute the indication shown in the attributes of the Access-Accept message of RADIUS. It s/, NAS can execute the indication shown/. In this case the NAS responds as indicated by the RADIUS server./ also might be fine with the network architecture when the centralized DHCPv6 server locates in the same place with the RADIUS server, where s/It also might be fine with the network architecture when the centralized DHCP server locates/ /This also works in the scenario where the DHCP server is located/ they could share the same database of the users. But when NAS acts s/, where they could share the same database of the users/ /: they can share the same database of users/ as the relay agent and RADIUS client simultaneously, and the centralized DHCPv6 server is not located in the same place with RADIUS server, a new communication mechanism is need for the relay s/with RADIUS/as the RADIUS/ s/is need/is needed/ agent to transfer the authorization information got from the RADIUS s/got from/indicated by/ attributes to the DHCPv6 server. s/to the DHCPv6 server// 2. Terminology and Language This document specified a DHCPv6 option for Relay Agent to provide s/specified/specifies/ the information got from RADIUS attributes to the DHCPv6 server. s/the information got from RADIUS attributes/information from some RADIUS attributes/ This document should be read in conjunction with the following specifications, [RFC2865], [RFC2869], [RFC3315] and [RFC4818] for understanding the complete mechanism of DHCPv6 and RADIUS with the s/for understanding/. These will help the reader to understand/ service provision of IPv6. Definitions for terms and acronyms not s/the complete mechanism of/how/ s/with the service provision/work together to provide IPv6 service/ specified in this document are defined in [RFC2865], [RFC2869], [RFC3315] and [RFC4818]. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, [RFC2119]. Yeh Expires September 6, 2012 [Page 3] Internet-Draft DHCPv6 Authorization Option March 2012 3. Network Scenario Figure 1 shows the typical network scenario where to adopt the s/where to adopt/where/ communication mechanism introduced in this document. In this s/document/document is necessary./ Scenario, the centralized DHCPv6 server is not located in the same s/Scenario/scenario/ place with RADIUS server but in the same administrative domain; and s/but in/but is in/ s/; and/. The/ NAS acts as the relay agent and RADIUS client simultaneously. On the s/acts as/acts both as/ s/RADIUS/the RADIUS/ s/simultaneously// other hand, Figure 1 also shows the message sequence of DHCPv6 and s/On the other hand, Figure one also/Figure one/ s/message sequence/sequence/ RADIUS messages when to employ the communication mechanism introduced in this document. s/when to employ/that must occur when employing/ +-------+ +-------+ +-------+ |DHCPv6 | Access Mode: | NAS | |Radius | |Client | PPPoE or IPoE |(DHCPv6| |Server | | | | Relay)| | | +-------+ +-------+ +-------+ | | | |---Solicit---------------->| | |---Access-Request---------->| |<--Access-Accept------------| | (e.g. Framed-Pool) | (e.g. Delegated-IPv6-Prefix) DHCPv6 messages RADIUS messages | +-------+ | |DHCPv6 | | |Server | | | | | +-------+ |---Relay-Forward----------->| | (Option_Authorization) |<--Relay-Reply -------------| |<--Advertise---------------| (e.g. Prefix, Address) | |---Request---------------->| (e.g. Prefix, Address) | |---Relay-Forward----------->| | (Option_Authorization) |<--Relay-Reply -------------| |<--Reply-------------------| (e.g. Prefix, Address) | DHCPv6 messages DHCPv6 messages Figure 1: Network Scenario and message sequence when employing Authorization option of DHCPv6 Yeh Expires September 6, 2012 [Page 4] Internet-Draft DHCPv6 Authorization Option March 2012 4. Option_Authorization The Option_Authorization is a stateless DHCPv6 option, which is used to carry the information got from the RADDIUS attributes. Those RADIUS attributes may include but not only Framed-Pool (88) defined in [RFC2869], Delegated-IPv6-Prefix (123) defined in [RFC4818], Framed-IPv6-Address, Stateful-IPv6-Address-Pool, Delegated-IPv6- Prefix-Pool defined in [ietf-radext-ipv6-access-06], and etc. The format of the Option_Authorization 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option_Authorization | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authorization-options or RADIUS Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code Option_Authorization (TBD) option-length Length of the option-data in Octets option-data sub-options associated with Option_Authorization Discussion: The option-data of Option_Authorization may have 2 kinds of alternative presentation: one is to define the associated stateless sub-option as usual in the container option; the other is to adopt the same method of [RFC4014], which directly includes the RADIUS attributes into the option-data of Option_Authorization. Design-1: Sub-option as option-data of Option_Authorization Pros: 1. define the new sub-option to meet the new requirement as usual, new requirement today is limited for the address & prefix assignment; 2. might have some kind of liberty, no much dependence on the development progress of RADIUS, to develop its own option within the DHCPv6 protocol; Cons: but need new parser for each new option. Section 5 adopts Design-1. Design-2: RADIUS attributes as option-data of Option_Authorization Pros: reuse the parser codes of RADIUS attributes; Cons: but need DHCPv6 server to support the parser codes of RADIUS for a list of attributes associated with DHCPv6. Yeh Expires September 6, 2012 [Page 5] Internet-Draft DHCPv6 Authorization Option March 2012 Design-2 is for the further discussion. *** There is no reason to use either suboptions or RADIUS options. The right thing to do is simply define a DHCP option to carry each RADIUS attribute that you think the DHCP server might need. Sub-options are common in DHCPv4 because there are only 256 option codes possible, but in DHCPv6 this is not a problem, and the additional complexity introduced by suboptions is undesirable. 5. Sub-options of Option_Authorization *** So, the following should all just be DHCPv6 options, and there should be no Option_Authorization option. 5.1. Option_Pool_Name The Option_Pool_Name is used to carry the name of IPv6 address or prefix pool got from the RADIUS attributes, including Framed-Pool (88) defined in [RFC2869], Stateful-IPv6-Address-Pool, Delegated- IPv6-Prefix-Pool defined in [ietf-radext-ipv6-access-06], from which the client's IPv6 address or prefix is assigned. Option_Pool_Name is the sub-option of Option_Authorization, one or more Option_Pool_Name may in the same container Option_Authorization. The format of the Option_Pool_Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option_Pool_Name | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pool Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code Option_Pool_Name (TBD) option-length Length of the field 'Pool Name' in Octets option-data String data type, contains the name of address pool or prefix pool configured on the DHCPv6 server. Discussion: There are 3 RADIUS attributes in string data type are associated with the IPv6 address and IPv6 prefix assignment through DHCPv6. They are Framed-Pool (88) defined in [RFC2869], Stateful- IPv6-Address-Pool, Delegated-IPv6-Prefix-Pool defined in [ietf-radext-ipv6-access-06]. Does it need a 'Type' field in the Option_Pool_Name? *** You need to say how the string is encoded; I'd suggest UTF8 or NVT-ASCII, whichever makes more sense to you. UTF8 is better if it's possible, but I don't know what the RADIUS spec says. 5.2. Option_Address_Prefix_Auth The Option_Address_Prefix_Auth is used to carry the IPv6 address or prefix specified for the clients according to the user information got from the RADIUS attributes, including Delegated-IPv6-Prefix (123) defined in [RFC4818], Framed-IPv6-Address defined in [ietf-radext- ipv6-access-06]. Option_Address_Prefix_Auth is the sub-option of Option_Authorization. The format of the Option_Address_Prefix_Auth is defined as follows: *** Why not have two options here, one an address and the other a prefix? Is there a reason why it makes sense to overload this (e.g., does RADIUS do it this way?) Yeh Expires September 6, 2012 [Page 6] Internet-Draft DHCPv6 Authorization Option March 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option_Address_Prefix_Auth | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-length | | +-+-+-+-+-+-+-+-+ | | ipv6-prefix-address | | (16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | +-+-+-+-+-+-+-+-+ option-code Option_Address_Prefix_Auth (TBD) option-length 17 in Octets prefix-length Length of the prefix in bits; if the prefix-length is 128, then the value in the following 'ipv6-prefix-address' field means an IPv6 address ipv6-prefix-address A specified delegated IPv6 prefix or an assigned IPv6 address 6. Relay Agent Behavior The DHCPv6 relay agent must include Option_Authorization in the relay-forward (12) message according to the authorization information on the specified pool configured, address assigned or prefix delegated in the Access-Accept message of RADIUS. When the value in the attributes of Framed-Pool (88), Stateful-IPv6-Address-Pool and Delegated-IPv6-Prefix-Pool included in the Access-Accept message replied from RADIUS server is valid, the relay agent shall include Option_Pool_Name in the container Option_Authorization; when the value in the attributes of Delegated-IPv6-Prefix (123) and Framed- IPv6-Address included in the Access-Accept message replied from RADIUS server is valid, the relay agent shall include Option_Address_Prefix_Auth in the container Option_Authorization. *** Okay, so RADIUS does it the same way I'd suggest doing it for DHCP. 7. Server Behavior The DHCPv6 sever must delegate IPv6 prefix or assign IPv6 address to the DHCPv6 client according to the information got from Option_Authorization. s/sever/server/ s/IPv6 Prefix/the IPv6 prefix/ s/IPv6 address/the IPv6 address/ *** This really isn't kosher. DHCP servers do address allocation, not relay agents. If the RADIUS server actually controls address allocation, there is no need for a DHCP server. What you have here is essentially a stateless-only DHCP server that is pretending to be stateful in order to support a particular deployment scenario. I think this is a bad idea. What you really want to do here is to have a truly stateless DHCPv6 server in the central location that can provide the stateless information, but have a stateful DHCPv6 server in the NAS, not a relay agent. So either the NAS does stateless DHCPv6 to get the configuration information and send it to the client, or else the client first does stateful DHCPv6 to get its address or prefix, and then does stateless to get other configuration parameters. I can see why you chose the solution you did. I'm objecting to your way of solving the problem, but the ways I have proposed are not really much better. It would also be possible to have the NAS forward the information needed to do the RADIUS lookup to the DHCP server, and then have the DHCP server do the RADIUS query, but the problem with this is that you still have a custom DHCP server, and this makes more sense in the NAS than in the center of the network. Anyway, this is something we can discuss in the working group. I think what you are trying to do here is a good idea; the question is, how to do it in such a way that we don't create a whole new kind of DHCP server? Yeh Expires September 6, 2012 [Page 7] Internet-Draft DHCPv6 Authorization Option March 2012 8. Client Behavior Option_Authorization is only exchanged between the relay agents and the servers, so clients are never aware of its use. 9. Security Considerations Known security vulnerabilities of the DHCPv6 protocol may apply to its options. Security issues related DHCPv6 are described in section 23 of [RFC3315] 10. IANA Considerations IANA is requested to assign the option code to Option_Authorization and its sub-options of Option_Pool_Name, Option_Address_Prefix_Auth from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 11. Acknowledgements TBD 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, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [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. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Yeh Expires September 6, 2012 [Page 8] Internet-Draft DHCPv6 Authorization Option March 2012 Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option", RFC 4014, February 2005. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. 12.2. Informative References [ietf-radext-ipv6-access-06] Lourdelet, B., Dec, W., Sarikaya, B., Zorn, G., and D. Miles, "RADIUS attributes for IPv6 Access Networks", July 2011. Author's Address Leaf Y. Yeh (editor) Huawei Technologies Shenzhen P. R. China Phone: +86-755-28978851 Email: leaf.y.yeh@huawei.com Yeh Expires September 6, 2012 [Page 9]