idnits 2.17.00 (12 Aug 2021) /tmp/idnits3672/draft-yeh-dhc-dhcpv6-authorization-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 25, 2012) is 3671 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 244, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2869 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Yeh, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Boucadair 5 Expires: October 27, 2012 France Telecom 6 T. Lemon 7 Nominum, Inc 8 April 25, 2012 10 RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server 11 draft-yeh-dhc-dhcpv6-authorization-opt-01 13 Abstract 15 The DHCPv6 RADIUS option provides a communication mechanism between 16 relay agent and the server. This mechanism can help the centralized 17 DHCPv6 server to select the right configuration for the client based 18 on the authorization information received from a separate RADIUS 19 server which is not located at the same place of DHCPv6 server in the 20 cases where the NAS acts as DHCPv6 relay agent and RADIUS client 21 simultaneously. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 27, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Language . . . . . . . . . . . . . . . . . . . 3 59 3. Network Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. OPTION_RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 62 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 DHCPv6 provides a mechanism that allows the server to assign or 75 delegate both stateful and stateless configuration parameters to the 76 clients. The stateful configuration parameters include IPv6 address 77 [RFC3315], IPv6 prefix [RFC3633], and etc. The stateless 78 configuration parameters [RFC3736] include, for example, DNS 79 [RFC3646]. The DHCPv6 server is typically deployed in the central 80 part of an ISP network. 82 RADIUS [RFC2865], an essentially stateless protocol, is used widely 83 as the centralized authentication, authorization and user management 84 mechanism for the service provision in Broadband access network. 85 [RFC3162], [RFC4818] and [ietf-radext-ipv6-access-06] specify 86 attributes that supports the provision of service for IPv6 access. 87 RADIUS authorizes that the NAS assigns an IPv6 address or prefix from 88 the indicated pool, or assigns an IPv6 address or prefix with an 89 explicitly indicated value in the attributes for the subscribers. 91 These mechanisms work well in the deployment scenario where the NAS 92 acts as the distributed DHCPv6 server. In this case the NAS responds 93 as the indication conveyed by the attributes in the Access-Accept 94 message from the RADIUS server. These mechanisms also work in the 95 scenario where the centralized DHCPv6 server is co-located with the 96 RADIUS server, where they can share the same database of the users. 97 But when the NAS acts as the relay agent and RADIUS client 98 simultaneously, and the centralized DHCPv6 server is not located in 99 the same place as the RADIUS server, a new communication mechanism is 100 needed for the relay agent to transfer the authorization information 101 indicated by the RADIUS attributes to the DHCPv6 server. 103 2. Terminology and Language 105 This document specifies a DHCPv6 option for the distributed Relay 106 Agent to transfer the authorization information of RADIUS attributes 107 received in the Access-Accept message to the centralized DHCPv6 108 server. This document should be read in conjunction with the 109 following specifications: [RFC2865], [RFC2869], [RFC3315] and 110 [RFC4818]. These specifications will help the reader to understand 111 how DHCPv6 and RADIUS work together to provide IPv6 service. 112 Definitions for terms and acronyms not specified in this document are 113 defined in [RFC2865], [RFC2869], [RFC3315] and [RFC4818]. 115 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 116 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 117 document, are to be interpreted as described in BCP 14, [RFC2119]. 119 3. Network Scenarios 121 Figure 1 and Figure 2 shows the typical network scenarios where the 122 communication mechanism introduced in this document is necessary. In 123 these scenarios, the centralized DHCPv6 server is not co-located with 124 the RADIUS server, but both of them are in the same administrative 125 domain. The NAS acts as the relay agent and the RADIUS client 126 simultaneously. Figure 1 shows the sequence of DHCPv6 and RADIUS 127 messages for IPoE access mode. Figure 2 shows the sequence of DHCPv6 128 and RADIUS messages for PPPoE access mode. 130 +-------+ +-------+ +-------+ 131 |DHCPv6 | Access Mode: | NAS | |Radius | 132 |Client | IPoE |(DHCPv6| |Server | 133 | | | Relay)| | | 134 +-------+ +-------+ +-------+ 135 | | | 136 |---Solicit---------------->| | 137 |---Access-Request---------->| 138 |<--Access-Accept------------| 139 | (e.g. Framed-Pool) 140 | (e.g. Delegated-IPv6-Prefix) 142 DHCPv6 messages RADIUS messages 144 | +-------+ 145 | |DHCPv6 | 146 | |Server | 147 | | | 148 | +-------+ 149 |---Relay-Forward----------->| 150 | (OPTION_RADIUS) 151 | 152 |<--Relay-Reply -------------| 153 |<--Advertise---------------| 154 (e.g. Prefix, Address) | 155 |---Request---------------->| 156 (e.g. Prefix, Address) | 157 |---Relay-Forward----------->| 158 | (OPTION_RADIUS) 159 | 160 |<--Relay-Reply -------------| 161 |<--Reply-------------------| 162 (e.g. Prefix, Address) | 164 DHCPv6 messages DHCPv6 messages 166 Figure 1: Network scenario and message sequence when employing DHCPv6 167 RADIUS option in IPoE access 169 +-------+ +-------+ +-------+ 170 |DHCPv6 | Access Mode: | NAS | |Radius | 171 |Client | PPPoE |(DHCPv6| |Server | 172 | | | Relay)| | | 173 +-------+ +-------+ +-------+ 174 | | | 175 |--PPP LCP Config-Request-->| | 176 |---Access-Request---------->| 177 |<--Access-Accept------------| 178 | (e.g. Framed-Pool) 179 | (e.g. Delegated-IPv6-Prefix) 180 | 181 |<----PPP LCP Config-ACK----| 183 PPP messages RADIUS messages 185 | +-------+ 186 | |DHCPv6 | 187 | |Server | 188 | | | 189 | +-------+ 190 |---Solicit---------------->| | 191 |---Relay-Forward----------->| 192 | (OPTION_RADIUS) 193 | 194 |<--Relay-Reply -------------| 195 |<--Advertise---------------| 196 (e.g. Prefix, Address) | 197 |---Request---------------->| 198 (e.g. Prefix, Address) | 199 |---Relay-Forward----------->| 200 | (OPTION_RADIUS) 201 | 202 |<--Relay-Reply -------------| 203 |<--Reply-------------------| 204 (e.g. Prefix, Address) | 206 DHCPv6 messages DHCPv6 messages 208 Figure 2: Network scenario and message sequence when employing DHCPv6 209 RADIUS option in PPPoE access 211 If the authorization through RADIUS fails, the associated message 212 sequences will stop. The DHCPv6 relay will not forward the message 213 from the client to the server. 215 4. OPTION_RADIUS 217 The OPTION_RADIUS is a stateless DHCPv6 option, and is used by the 218 relay agent to carry the authorization information of RADIUS 219 attributes received in the Access-Accept message. 221 The format of the OPTION_RADIUS option is defined as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | OPTION_RADIUS | option-length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | RADIUS Attributes... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 option-code TBD 232 option-length Length of the option-data in Octets 233 option-data One or a list of RADIUS Attributes 235 The option-data of OPTION_RADIUS is one or a list of RADIUS 236 attributes received in the Access-Accept message from the RADIUS 237 server. As the same method in [RFC4014], only the attributes listed 238 in the table below may be included in the OPTION_RADIUS. 240 Type Code Attribute Reference 241 26 Vendor-Specific [RFC2865] 242 88 Framed-Pool [RFC2869] 243 123 Delegated-IPv6-Prefix [RFC4818] 244 [TBD] Framed-IPv6-Address [ietf-radext-ipv6-access-06] 246 Note: The above table might have more attributes in the future. 248 5. Relay Agent Behavior 250 The DHCPv6 relay agent may include OPTION_RADIUS in the RELAY-FORW 251 message. When the value in the attributes of Framed-Pool (88), (or 252 Stateful-IPv6-Address-Pool, Delegated-IPv6-Prefix-Pool,) Delegated- 253 IPv6-Prefix (123) and Framed-IPv6-Address in the Access-Accept 254 message replied from RADIUS server are valid, the relay agent that 255 supports OPTION_RADIUS SHOULD include these RADIUS attributes in the 256 container option, OPTION_RADIUS. The relay agent MUST ignore 257 OPTION_RADIUS if received. 259 6. Server Behavior 261 Upon receipt of the RELAY-FORW message with OPTION_RADIUS from a 262 relay agent, the DHCPv6 server SHOULD extract and interpret the 263 RADIUS attributes in the OPTION_RADIUS, and use that information in 264 selecting configuration parameters for the requesting client. If the 265 DHCPv6 server does not support OPTION_RADIUS, the DHCPv6 server 266 SHOULD ignore this option. The DHCPv6 server MUST NOT include 267 OPTION_RADIUS in RELAY-REPL messages. 269 7. Client Behavior 271 OPTION_RADIUS option is only exchanged between the relay agents and 272 the servers. DHCPv6 clients are not aware of the usage of 273 OPTION_RADIUS. DHCPv6 Client MUST NOT send OPTION_RADIUS, and MUST 274 ignore OPTION_RADIUS if received. 276 8. Security Considerations 278 Known security vulnerabilities of the DHCPv6 and RADIUS protocol may 279 apply to its options. Security issues related with DHCPv6 are 280 described in section 23 of [RFC3315]. Security issues related with 281 RADIUS are described in section 8 of [RFC2865], section 5 of 282 [RFC3162]. 284 9. IANA Considerations 286 The authors of this document request to assign a new DHCPv6 option 287 code for OPTION_RADIUS. 289 10. Acknowledgements 291 Expert comments from Bernie Volz and Tomek Mrugalski for the 292 discussion on the technology selection in the mailing list are 293 appreciated. 295 11. References 297 11.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 303 "Remote Authentication Dial In User Service (RADIUS)", 304 RFC 2865, June 2000. 306 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 307 Extensions", RFC 2869, June 2000. 309 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 310 and M. Carney, "Dynamic Host Configuration Protocol for 311 IPv6 (DHCPv6)", RFC 3315, July 2003. 313 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 314 (DHCP) Service for IPv6", RFC 3736, April 2004. 316 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication 317 Dial-In User Service (RADIUS) Attributes Suboption for the 318 Dynamic Host Configuration Protocol (DHCP) Relay Agent 319 Information Option", RFC 4014, February 2005. 321 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 322 Attribute", RFC 4818, April 2007. 324 11.2. Informative References 326 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 327 RFC 3162, August 2001. 329 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 330 Host Configuration Protocol (DHCP) version 6", RFC 3633, 331 December 2003. 333 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 334 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 335 December 2003. 337 [ietf-radext-ipv6-access-06] 338 Lourdelet, B., Dec, W., Sarikaya, B., Zorn, G., and D. 339 Miles, "RADIUS attributes for IPv6 Access Networks", 340 July 2011. 342 Authors' Addresses 344 Leaf Y. Yeh (editor) 345 Huawei Technologies 346 P. R. China 348 Email: leaf.y.yeh@huawei.com 350 Mohamed Boucadair 351 France Telecom 352 France 354 Email: mohamed.boucadair@orange.com 356 Ted Lemon 357 Nominum, Inc 358 USA 360 Email: Ted.Lemon@nominum.com