idnits 2.17.1 draft-guo-softwire-6rd-radius-attrib-00.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 date (Oct 18, 2010) is 4933 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dayong Guo 2 Internet Draft Sheng Jiang 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 R. Despres 5 RD-IPtech 6 Expires: April 25, 2011 Oct 18, 2010 8 RADIUS Attribute for 6rd 10 draft-guo-softwire-6rd-radius-attrib-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on April 25, 2011. 29 Copyright Notice 31 Copyright (c) 2010 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Abstract 46 6rd is One of the most popular methods to provide both IPv4 and IPv6 47 connectivity services simultaneously during the IPv4/IPv6 co-existing 48 period. The DHCP 6rd option has been defined to configure 6rd CPE. 49 But in many networks, the configuration information may be stored in 50 AAA servers while user configuration is mainly from Broadband Network 51 Gateway (BNG) through DHC protocol. This document defines a RADIUS 52 attribute that carries 6rd configuration information from AAA server 53 to BNG. 55 Table of Contents 57 1. Introduction................................................3 58 2. Terminology.................................................3 59 3. 6rd Configuration with RADIUS................................3 60 4. Attributes..................................................4 61 4.1. 6rd Attribute..........................................4 62 4.2. Table of attributes.....................................5 63 5. Diameter Considerations......................................6 64 6. Security Considerations......................................6 65 7. IANA Considerations.........................................6 66 8. Acknowledgments.............................................6 67 9. Change Log [RFC Editor please remove]........................6 68 10. References.................................................7 69 10.1. Normative References...................................7 70 10.2. Informative References.................................7 72 1. Introduction 74 Recently providers start to deploy IPv6 and consider how to transit 75 to IPv6. 6rd [RFC5969] is one of the most popular methods to provide 76 both IPv4 and IPv6 connectivity services simultaneously during the 77 IPv4/IPv6 co-existing period. 6rd is used to provide IPv6 78 connectivity service through legacy IPv4-only infrastructure. 6rd 79 adopt DHCP as auto-configuring protocol. The 6rd CPE extends DHCP 80 option to discover 6rd border relay and to configure IPv6 prefix and 81 address. 83 In many networks, user configuration information may be managed by 84 AAA servers, together with user Authentication, Authorization, and 85 Accounting (AAA). Current AAA servers communicate using the RADIUS 86 (Remote Authentication Dial In User Service, [RFC2865]) protocol. 87 In a fixed line broadband network, the Broadband Network Gateways 88 (BNGs) act as the access gateway of users (hosts or CPEs). The BNGs 89 are assumed to embed a DHCP server function that allows them to 90 locally handle any DHCP requests issued by hosts. 92 Since the 6rd configuration information is stored in AAA servers and 93 user configuration is mainly through DHC protocol between BNGs and 94 hosts. New RADIUS attributes are needed to propagate the information 95 from AAA servers to BNGs. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119 [RFC2119]. 103 3. 6rd Configuration with RADIUS 105 The below Figure 1 illustrates how the RADIUS protocol and DHCP are 106 cooperated to provide users/hosts with 6rd configuration. 108 User/host BNG AAA Server 109 | | | 110 |-------DHCPDISCOVER------>| | 111 | |---Request(6rd Attribute)--->| 112 | | | 113 | |<---Accept(6rd Attribute)----| 114 |<-------DHCPOFFER---------| | 115 | | | 116 |-------DHCPREQUEST------->| | 117 | (6rd Option) | | 118 |<--------DHCPACK----------| | 119 | (6rd option) | | 120 | | | 121 DHCP RADIUS 122 Figure 1: the cooperation between DHCP and RADIUS 124 BNGs act as a bridge between user and AAA server. First, a BNG 125 receives a user DHCPDISCOVER. It initiates the BNG to request 126 correspondent user authentication relevant from an AAA server using 127 RADIUS protocol. A 6rd request may be also sent in the same message. 128 If the user authentication is approved by the AAA server, an Accept 129 message is acknowledged with the 6rd Attribute, defined in the next 130 Section. After the BNG responds to the user with an Advertise 131 message, the user requests for a 6rd Option. Then, the BNG can reply 132 the user using DHCP protocol. 134 4. Attributes 136 This section defines 6rd attribute which is used in the 6rd scenario. 138 4.1. 6rd Attribute 140 The 6rd Attribute is structured as follows: 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Type | Length | IPv4MaskLen | 6rdPrefixLen | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 | 6rdPrefix | 149 | | 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 6rdBRIPv4Address(es) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Type TBD 157 Length the length of the DHCP option in octets (22 octets 158 with one BR IPv4 address). 160 IPv4MaskLen The number of high-order bits that are identical 161 across all CE IPv4 addresses within a given 6rd 162 domain. This may be any value between 0 and 32. 163 Any value greater than 32 is invalid. 165 6rdPrefixLen The IPv6 Prefix length of the Service Provider's 166 6rd IPv6 prefix in number of bits. The 167 6rdPrefixLen MUST be less than or equal to 128. 169 6rdPrefix The Service Provider's 6rd IPv6 prefix represented 170 as a 16 octet IPv6 address. The bits after the 171 6rdPrefixlen number of bits in the prefix SHOULD 172 be set to zero. 174 6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border 175 Relay(s) for a given 6rd domain. 177 4.2. Table of attributes 179 The following table provides a guide to which attributes may be found 180 in which kinds of packets, and in what quantity. 182 Request Accept Reject Challenge Accounting # Attribute 183 Request 184 0+ 0+ 0 0 0+ TBD 6rd 186 5. Diameter Considerations 188 This attribute is usable within either RADIUS or Diameter [RFC3588]. 189 Since the Attributes defined in this document will be allocated from 190 the standard RADIUS type space, no special handling is required by 191 Diameter entities. 193 6. Security Considerations 195 In 6rd scenarios, the RADIUS protocol is run over IPv4. Known 196 security vulnerabilities of the RADIUS protocol are discussed in RFC 197 2607 [RFC2607], RFC 2865 [RFC2865], and RFC 2869 [RFC2869]. Use of 198 IPsec [RFC4301] for providing security when RADIUS is carried in IPv6 199 is discussed in RFC 3162 [RFC3162]. 201 Security considerations for the Diameter protocol are discussed in 202 RFC 3588 [RFC3588]. 204 7. IANA Considerations 206 This document requires the assignment of two new RADIUS Attribute 207 Types in the "Radius Types" registry (currently located at 208 http://www.iana.org/assignments/radius-types for the following 209 attributes: 211 o 6rd 213 IANA should allocate these numbers from the standard RADIUS 214 Attributes space using the "IETF Review" policy [RFC5226]. 216 8. Acknowledgments 218 The authors would like to thank Maglione Roberta, Telecom Italia, for 219 valuable comments. 221 9. Change Log [RFC Editor please remove] 223 draft-guo-softwire-6rd-radiusattrib-00, renaming and deleting DS-lite 224 contents, 2010-10-18. 226 draft-guo-radext-softwire-concentrator-00, original version, 2010-07- 227 05. 229 10. References 231 10.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 237 "Remote Authentication Dial In User Service (RADIUS)", RFC 238 2865, June 2000. 240 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 241 3162, August 2001. 243 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J., 244 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 246 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 247 Internet Protocol", RFC 4301, December 2005. 249 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 250 Considerations Section in RFCs", RFC 5226, May 2008. 252 [RFC5969] Townsley W., et al., "IPv6 Rapid Deployment on IPv4 253 Infrastructures (6rd) -- Protocol Specification", RFC5969, 254 August 2010. 256 10.2. Informative References 258 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 259 Implementation in Roaming", RFC 2607, June 1999. 261 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 262 Extensions", RFC 2869, June 2000. 264 Author's Addresses 266 Dayong Guo 267 Huawei Technologies Co., Ltd 268 Huawei Building, No.3 Xinxi Rd., 269 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 270 P.R. China 271 Email: guoseu@huawei.com 273 Sheng Jiang 274 Huawei Technologies Co., Ltd 275 Huawei Building, No.3 Xinxi Rd., 276 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 277 P.R. China 278 Email: shengjiang@huawei.com 280 Remi Despres 281 RD-IPtech 282 3 rue du President Wilson 283 Levallois, 284 France 285 Email: remi.despres@free.fr