idnits 2.17.1 draft-ietf-softwire-dslite-radius-ext-04.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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2011) is 4651 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 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 5176 == Outdated reference: A later version (-16) exists of draft-ietf-radext-ipv6-access-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 softwire R. Maglione 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track A. Durand 5 Expires: January 28, 2012 Juniper Networks 6 July 27, 2011 8 RADIUS Extensions for Dual-Stack Lite 9 draft-ietf-softwire-dslite-radius-ext-04 11 Abstract 13 Dual-Stack Lite is a solution to offer both IPv4 and IPv6 14 connectivity to customers which are addressed only with an IPv6 15 prefix. DS-Lite requires to pre-configure the DS-Lite Address Family 16 Transition Router tunnel information on the Basic Bridging BroadBand 17 element. In many networks, the customer profile information may be 18 stored in AAA servers while client configurations are mainly provided 19 through DHC protocol. This document specifies a new RADIUS attribute 20 to carry Dual-Stack Lite Address Family Transition Router Tunnel 21 name; the RADIUS attribute is defined based on the equivalent DHCPv6 22 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used 23 between the RADIUS Server and the NAS, it is not intended to be used 24 directly between the B4 element and the RADIUS Server. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 28, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. DS-Lite Configuration with RADIUS and DHCPv6 . . . . . . . . . 5 75 4. RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. DS-Lite-Tunnel-Name . . . . . . . . . . . . . . . . . . . 8 77 5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is a solution to 88 offer both IPv4 and IPv6 connectivity to customers which are 89 addressed only with an IPv6 prefix (no IPv4 address is assigned to 90 the attachment device). One of its key components is an IPv4-over- 91 IPv6 tunnel, but a DS-Lite Basic Bridging BroadBand (B4) will not 92 know if the network it is attached to offers Dual-Stack Lite support, 93 and if it did, would not know the remote end of the tunnel to 94 establish a connection. 96 To inform the B4 of the AFTR's location, a Fully Qualified Domain 97 Name (FQDN) may be used. Once this information is conveyed, the 98 presence of the configuration indicating the AFTR's location also 99 informs a host to initiate Dual-Stack Lite (DS-Lite) service and 100 become a Softwire Initiator. 102 [I-D.ietf-softwire-ds-lite-tunnel-option] specifies a DHCPv6 option 103 which is meant to be used by a Dual-Stack Lite client (Basic Bridging 104 BroadBand element, B4) to discover its Address Family Transition 105 Router (AFTR) name. In order to be able to populate such option the 106 DHCPv6 Server must be pre-provisioned with the Address Family 107 Transition Router (AFTR) name. 109 In Broadband environments, customer profile may be managed by AAA 110 servers, together with user Authentication, Authorization, and 111 Accounting (AAA). RADIUS protocol [RFC2865] is usually used by AAA 112 Servers to communicate with network elements. 113 [I-D.ietf-radext-ipv6-access] describes a typical broadband network 114 scenario in which the Network Access Server (NAS) acts as the access 115 gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6 116 Server function that allows it to locally handle any DHCPv6 requests 117 issued by the clients. 119 Since the DS-Lite AFTR information can be stored in AAA servers and 120 the client configuration is mainly provided through DHC protocol 121 running between the NAS and the requesting clients, a new RADIUS 122 attribute is needed to send AFTR information from AAA server to the 123 NAS. 125 This document aims at defining a new RADIUS attribute to be used for 126 carrying the DS-Lite Tunnel Name, based on the equivalent DHCPv6 127 option already specified in [I-D.ietf-softwire-ds-lite-tunnel-option] 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS- 136 Lite Address Family Transition Router element (AFTR) are defined in 137 [I-D.ietf-softwire-dual-stack-lite] 139 3. DS-Lite Configuration with RADIUS and DHCPv6 141 The Figure 1 illustrates how the RADIUS protocol and DHCPv6 work 142 together to accomplish DS-Lite configuration on the B4 element when a 143 PPP Session is used to provide connectivity to the user. 145 The Network Access Server (NAS) operates as a client of RADIUS and as 146 DHCP Server for DHC protocol. The NAS initially sends a RADIUS 147 Access Request message to the RADIUS server, requesting 148 authentication. Once the RADIUS server receives the request, it 149 validates the sending client and if the request is approved, the AAA 150 server replies with an Access Accept message including a list of 151 attribute-value pairs that describe the parameters to be used for 152 this session. This list may also contain the AFTR Tunnel Name. When 153 the NAS receives a DHCPv6 client request containing the DS-Lite 154 tunnel Option, the NAS shall use the name returned in the RADIUS DS- 155 Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME 156 option in the DHCPv6 reply message. 158 B4 NAS AAA 159 | | Server 160 | | | 161 |----PPP LCP Config Request------> | | 162 | | | 163 | |----Access-Request ---->| 164 | | | 165 | |<---- Access-Accept-----| 166 | | (DS-Lite-Tunnel-Name) | 167 |<-----PPP LCP Config ACK ----- | | 168 | | | 169 | | | 170 |------ PPP IPv6CP Config Req ---->| | 171 | | | 172 |<----- PPP IPv6CP Config ACK -----| | 173 | | | 174 |------- DHCPv6 Solicit -------->| | 175 | | | 176 |<-------DHCPv6 Advertisement -----| | 177 | (DHCPv6 OPTION_AFTR_NAME) | | 178 | | | 179 |------- DHCPv6 Request -------->| | 180 | | | 181 |<-------- DHCPv6 Reply --------- | | 182 | (DHCPv6 OPTION_AFTR_NAME) | | 184 DHCPv6 RADIUS 186 Figure 1: RADIUS and DHCPv6 Message Flow for a PPP Session 188 The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work 189 together to accomplish DS-Lite configuration on the B4 element when 190 an IP Session is used to provide connectivity to the user. 192 The only difference between this message flow and previous one is 193 that in this scenario the interaction between NAS and AAA/ RADIUS 194 Server is triggered by the DHCPv6 Solicit message received by the NAS 195 from the B4 acting as DHCPv6 client, while in case of a PPP Session 196 the trigger is the PPP LCP Config Request message received by the 197 NAS. 199 B4 NAS AAA 200 | | Server 201 |------ DHCPv6 Solicit ---------> | | 202 | | | 203 | |----Access-Request ---->| 204 | | | 205 | |<-Access-Accept---------| 206 | | (DS-Lite-Tunnel-Name) | 207 | | | 208 |<-------DHCPv6 Advertisement------| | 209 | (DHCPv6 OPTION_AFTR_NAME) | | 210 | | | 211 |------- DHCPv6 Request -------->| | 212 | | | 213 | | | 214 | <---- DHCPv6 Reply ---- | | 215 | (DHCPv6 OPTION_AFTR_NAME) | | 217 DHCPv6 RADIUS 219 Figure 2: RADIUS and DHCPv6 Message Flow for an IP Session 221 After receiving the DS-Lite-Tunnel-Name in the initial Access-Accept 222 the NAS MUST store the received AFTR Tunnel Name locally. When the 223 B4 sends a DHCPv6 Renew message to request an extension of the 224 lifetimes for the assigned address or prefix, the NAS does not have 225 to initiate a new Access-Request towards the AAA server to request 226 the AFTR tunnel name. The NAS retrieves the previously stored AFTR 227 tunnel name and uses it in its reply. 229 According to [RFC3315] if the DHCPv6 server to which the DHCPv6 Renew 230 message was sent at time T1 has not responded, the DHCPv6 client 231 initiates a Rebind/Reply message exchange with any available server. 232 In this scenario the NAS receiving the DHCPv6 rebind message MUST 233 initiate a new Access-Request towards the AAA server. The NAS MAY 234 include the DS-Lite-Tunnel-Name attribute in its Access-Request. 236 If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the 237 Access-Accept it MAY fallback to a pre-configured default tunnel 238 name, if any. If the NAS does not have any pre-configured default 239 tunnel name or if the NAS receives an Access-Reject, the tunnel 240 cannot be established and NAS MUST terminate the session towards the 241 B4. 243 4. RADIUS Attribute 245 This section specifies the format of the new RADIUS attribute. 247 4.1. DS-Lite-Tunnel-Name 249 Description 251 The DS-Lite-Tunnel-Name RADIUS attribute contains a Fully Qualified 252 Domain Name that refers to the AFTR the client is requested to 253 establish a connection with. The NAS SHALL use the name returned in 254 the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 255 OPTION_AFTR_NAME option [I-D.ietf-softwire-ds-lite-tunnel-option] 257 This attribute MAY be used in Access-Accept packets as a hint to the 258 RADIUS server; for example if the NAS is pre-configured with a 259 default tunnel name, this name MAY be inserted in the attribute. The 260 RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a 261 different AFTR tunnel name. 263 If the NAS includes the DS-Lite-Tunnel-Name attribute, but the AAA 264 server does not recognize it, this attribute MUST be ignored by the 265 AAA Server. 267 If the NAS does not receive DS-Lite-Tunnel-Name attribute in the 268 Access-Accept it MAY fallback to a pre-configured default tunnel 269 name, if any. If the NAS does not have any pre-configured default 270 tunnel name, the tunnel can not be established. 272 If the NAS is pre-provisioned with a default AFTR tunnel name and the 273 AFTR tunnel name received in Access-Accept is different from the 274 configured default, then the AFTR tunnel name received from the AAA 275 server MUST overwrite the pre-configured default on the NAS. 277 When the Access-request is triggered by a DHCPv6 Rebind message if 278 the AFTR tunnel name received in the Access-Accept is different from 279 the currently used one, the NAS MUST force the B4 to re-establish the 280 tunnel with new AFTR received from the AAA server. 282 The Change-of-Authorization (CoA) message [RFC5176] can be used to 283 modify the current established DS-Lite tunnel. When the NAS receives 284 a CoA message containing the DS-Lite-Tunnel-Name attribute, the NAS 285 MUST send a Reconfigure message to a B4 to inform the B4 that the NAS 286 has new or updated configuration parameters and that the B4 is to 287 initiate a Renew/Reply or Information-request/Reply transaction with 288 the NAS in order to receive the updated information. Upon receiving 289 the new AFTR tunnel name the B4 MUST terminate the current DS-Lite 290 tunnel and the B4 MUST establish a new DS-LITE tunnel with specified 291 AFTR. 293 The DS-Lite-Tunnel-Name RADIUS attribute MAY be present in 294 Accounting-Request records where the Acct-Status-Type is set to 295 Start, Stop or Interim-Update. The DS-Lite-Tunnel-Name RADIUS 296 attribute and MUST NOT appear more than once in a message. 298 A summary of the DS-Lite-Tunnel-Name RADIUS attribute format is shown 299 below. The fields are transmitted from left to right. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | DS-Lite-Tunnel-Name (FQDN) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | DS-Lite-Tunnel-Name (FQDN) (cont) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Type: 311 TBA1 for DS-Lite-Tunnel-Name. 312 Length: 313 This field indicates the total length in octets of this 314 attribute including the Type, the Length fields and the length 315 in octets of the DS-Lite-Tunnel-Name field 317 DS-Lite-Tunnel-Name: 318 A single Fully Qualified Domain Name of the remote tunnel 319 endpoint, located at the DS-Lite AFTR. 321 5. Table of attributes 323 The following tables provide a guide to which attributes may be found 324 in which kinds of packets, and in what quantity. 326 Access- Access- Access- Challenge Accounting # Attribute 327 Request Accept Reject Request 328 0-1 0-1 0 0 0-1 TBA1 DS-Lite-Tunnel-Name 330 CoA-Request CoA-ACK CoA-NACK # Attribute 331 0-1 0 0 TBA1 DS-Lite-Tunnel-Name 333 The following table defines the meaning of the above table entries. 335 0 This attribute MUST NOT be present in packet. 336 0+ Zero or more instances of this attribute MAY be present in 337 packet. 338 0-1 Zero or one instance of this attribute MAY be present in packet. 340 The data type of DS-Lite-Tunnel-Name is a string. 342 6. Security Considerations 344 This document has no additional security considerations beyond those 345 already identified in [RFC2865] 347 [I-D.ietf-softwire-dual-stack-lite] discusses DS-Lite related 348 security issues. 350 7. IANA Considerations 352 This document requests the allocation of a new Radius attribute types 353 from the IANA registry "Radius Attribute Types" located at 354 http://www.iana.org/assignments/radius-types 356 DS-Lite-Tunnel-Name - TBA1 358 8. References 360 8.1. Normative References 362 [I-D.ietf-softwire-ds-lite-tunnel-option] 363 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 364 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 365 draft-ietf-softwire-ds-lite-tunnel-option-10 (work in 366 progress), March 2011. 368 [I-D.ietf-softwire-dual-stack-lite] 369 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 370 Stack Lite Broadband Deployments Following IPv4 371 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 372 in progress), May 2011. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 378 "Remote Authentication Dial In User Service (RADIUS)", 379 RFC 2865, June 2000. 381 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 382 and M. Carney, "Dynamic Host Configuration Protocol for 383 IPv6 (DHCPv6)", RFC 3315, July 2003. 385 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 386 Aboba, "Dynamic Authorization Extensions to Remote 387 Authentication Dial In User Service (RADIUS)", RFC 5176, 388 January 2008. 390 8.2. Informative References 392 [I-D.ietf-radext-ipv6-access] 393 Lourdelet, B., Dec, W., Sarikaya, B., Zorn, G., and D. 394 Miles, "RADIUS attributes for IPv6 Access Networks", 395 draft-ietf-radext-ipv6-access-05 (work in progress), 396 July 2011. 398 Authors' Addresses 400 Roberta Maglione 401 Telecom Italia 402 Via Reiss Romoli 274 403 Torino 10148 404 Italy 406 Phone: 407 Email: roberta.maglione@telecomitalia.it 409 Alain Durand 410 Juniper Networks 411 1194 North Mathilda Avenue 412 Sunnyvale, CA 94089-1206 413 USA 415 Phone: 416 Fax: 417 Email: adurand@juniper.net 418 URI: