draft-ietf-softwire-dslite-radius-ext-05.txt   draft-ietf-softwire-dslite-radius-ext-06.txt 
softwire R. Maglione softwire R. Maglione
Internet-Draft Telecom Italia Internet-Draft Telecom Italia
Intended status: Standards Track A. Durand Intended status: Standards Track A. Durand
Expires: February 11, 2012 Juniper Networks Expires: March 2, 2012 Juniper Networks
August 10, 2011 August 30, 2011
RADIUS Extensions for Dual-Stack Lite RADIUS Extensions for Dual-Stack Lite
draft-ietf-softwire-dslite-radius-ext-05 draft-ietf-softwire-dslite-radius-ext-06
Abstract Abstract
Dual-Stack Lite is a solution to offer both IPv4 and IPv6 Dual-Stack Lite is a solution to offer both IPv4 and IPv6
connectivity to customers which are addressed only with an IPv6 connectivity to customers which are addressed only with an IPv6
prefix. Dual-Stack Lite requires to pre-configure the Dual-Stack prefix. Dual-Stack Lite requires to pre-configure the Dual-Stack
Lite Address Family Transition Router (AFTR) tunnel information on Lite Address Family Transition Router (AFTR) tunnel information on
the Basic Bridging BroadBand (B4) element. In many networks, the the Basic Bridging BroadBand (B4) element. In many networks, the
customer profile information may be stored in Authentication customer profile information may be stored in Authentication
Authorization and Accounting (AAA) servers while client Authorization and Accounting (AAA) servers while client
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 11, 2012. This Internet-Draft will expire on March 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DS-Lite Configuration with RADIUS and DHCPv6 . . . . . . . . . 5 3. DS-Lite Configuration with RADIUS and DHCPv6 . . . . . . . . . 5
4. RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . . 7 4. RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. DS-Lite-Tunnel-Name . . . . . . . . . . . . . . . . . . . 8 4.1. DS-Lite-Tunnel-Name . . . . . . . . . . . . . . . . . . . 8
5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 9 5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6 Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6
skipping to change at page 5, line 23 skipping to change at page 5, line 23
together to accomplish DS-Lite configuration on the B4 element when a together to accomplish DS-Lite configuration on the B4 element when a
PPP Session is used to provide connectivity to the user. PPP Session is used to provide connectivity to the user.
The Network Access Server (NAS) operates as a client of RADIUS and as The Network Access Server (NAS) operates as a client of RADIUS and as
DHCP Server for DHC protocol. The NAS initially sends a RADIUS DHCP Server for DHC protocol. The NAS initially sends a RADIUS
Access Request message to the RADIUS server, requesting Access Request message to the RADIUS server, requesting
authentication. Once the RADIUS server receives the request, it authentication. Once the RADIUS server receives the request, it
validates the sending client and if the request is approved, the AAA validates the sending client and if the request is approved, the AAA
server replies with an Access Accept message including a list of server replies with an Access Accept message including a list of
attribute-value pairs that describe the parameters to be used for attribute-value pairs that describe the parameters to be used for
this session. This list may also contain the AFTR Tunnel Name. When this session. This list MAY also contain the AFTR Tunnel Name. When
the NAS receives a DHCPv6 client request containing the DS-Lite the NAS receives a DHCPv6 client request containing the DS-Lite
tunnel Option, the NAS shall use the name returned in the RADIUS DS- tunnel Option, the NAS SHALL use the name returned in the RADIUS DS-
Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME
option in the DHCPv6 reply message. option in the DHCPv6 reply message.
B4 NAS AAA B4 NAS AAA
| | Server | | Server
| | | | | |
|----PPP LCP Config Request------> | | |----PPP LCP Config Request------> | |
| | | | | |
| |----Access-Request ---->| | |----Access-Request ---->|
| | | | | |
| |<---- Access-Accept-----| | |<---- Access-Accept-----|
| | (DS-Lite-Tunnel-Name) | | | (DS-Lite-Tunnel-Name) |
|<-----PPP LCP Config ACK ----- | | |<-----PPP LCP Config ACK ------- | |
| | | | | |
| | | | | |
|------ PPP IPv6CP Config Req ---->| | |------ PPP IPv6CP Config Req ---->| |
| | | | | |
|<----- PPP IPv6CP Config ACK -----| | |<----- PPP IPv6CP Config ACK -----| |
| | | | | |
|------- DHCPv6 Solicit -------->| | |------- DHCPv6 Solicit -------->| |
| | | | | |
|<-------DHCPv6 Advertisement -----| | |<-------DHCPv6 Advertisement -----| |
| (DHCPv6 OPTION_AFTR_NAME) | | | (DHCPv6 OPTION_AFTR_NAME) | |
| | | | | |
|------- DHCPv6 Request -------->| | |------- DHCPv6 Request -------->| |
| | | | | |
|<-------- DHCPv6 Reply --------- | | |<-------- DHCPv6 Reply ---------- | |
| (DHCPv6 OPTION_AFTR_NAME) | | | (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS DHCPv6 RADIUS
Figure 1: RADIUS and DHCPv6 Message Flow for a PPP Session Figure 1: RADIUS and DHCPv6 Message Flow for a PPP Session
The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work
together to accomplish DS-Lite configuration on the B4 element when together to accomplish DS-Lite configuration on the B4 element when
an IP Session is used to provide connectivity to the user. an IP Session is used to provide connectivity to the user.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
from the B4 acting as DHCPv6 client, while in case of a PPP Session from the B4 acting as DHCPv6 client, while in case of a PPP Session
the trigger is the PPP LCP Config Request message received by the the trigger is the PPP LCP Config Request message received by the
NAS. NAS.
B4 NAS AAA B4 NAS AAA
| | Server | | Server
|------ DHCPv6 Solicit ---------> | | |------ DHCPv6 Solicit ---------> | |
| | | | | |
| |----Access-Request ---->| | |----Access-Request ---->|
| | | | | |
| |<-Access-Accept---------| | |<---Access-Accept-------|
| | (DS-Lite-Tunnel-Name) | | | (DS-Lite-Tunnel-Name) |
| | | | | |
|<-------DHCPv6 Advertisement------| | |<-------DHCPv6 Advertisement------| |
| (DHCPv6 OPTION_AFTR_NAME) | | | (DHCPv6 OPTION_AFTR_NAME) | |
| | | | | |
|------- DHCPv6 Request -------->| | |------- DHCPv6 Request -------->| |
| | | | | |
| | | | | |
| <---- DHCPv6 Reply ---- | | |<----- DHCPv6 Reply ------------- | |
| (DHCPv6 OPTION_AFTR_NAME) | | | (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS DHCPv6 RADIUS
Figure 2: RADIUS and DHCPv6 Message Flow for an IP Session Figure 2: RADIUS and DHCPv6 Message Flow for an IP Session
In the scenario depicted in Figure 2 the Access-Request packet
contains a Service-Type attribute with the value Authorize Only (17),
thus according to [RFC5080] the Access-Request packet MUST contain a
State attribute.
After receiving the DS-Lite-Tunnel-Name in the initial Access-Accept After receiving the DS-Lite-Tunnel-Name in the initial Access-Accept
the NAS MUST store the received AFTR Tunnel Name locally. When the the NAS MUST store the received AFTR Tunnel Name locally. When the
B4 sends a DHCPv6 Renew message to request an extension of the B4 sends a DHCPv6 Renew message to request an extension of the
lifetimes for the assigned address or prefix, the NAS does not have lifetimes for the assigned address or prefix, the NAS does not have
to initiate a new Access-Request towards the AAA server to request to initiate a new Access-Request towards the AAA server to request
the AFTR tunnel name. The NAS retrieves the previously stored AFTR the AFTR tunnel name. The NAS retrieves the previously stored AFTR
tunnel name and uses it in its reply. tunnel name and uses it in its reply.
According to [RFC3315] if the DHCPv6 server to which the DHCPv6 Renew According to [RFC3315] if the DHCPv6 server to which the DHCPv6 Renew
message was sent at time T1 has not responded, the DHCPv6 client message was sent at time T1 has not responded, the DHCPv6 client
initiates a Rebind/Reply message exchange with any available server. initiates a Rebind/Reply message exchange with any available server.
In this scenario the NAS receiving the DHCPv6 rebind message MUST In this scenario the NAS receiving the DHCPv6 rebind message MUST
initiate a new Access-Request towards the AAA server. The NAS MAY initiate a new Access-Request towards the AAA server. The NAS MAY
include the DS-Lite-Tunnel-Name attribute in its Access-Request. include the DS-Lite-Tunnel-Name attribute in its Access-Request.
If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the
Access-Accept it MAY fallback to a pre-configured default tunnel Access-Accept it MAY fallback to a pre-configured default tunnel
name, if any. If the NAS does not have any pre-configured default name, if any. If the NAS does not have any pre-configured default
tunnel name or if the NAS receives an Access-Reject, the tunnel tunnel name or if the NAS receives an Access-Reject, the IPv4 over
cannot be established and NAS MUST terminate the session towards the IPv6 tunnel cannot be established, thus the B4 element has only IPv6
B4. connectivity.
4. RADIUS Attribute 4. RADIUS Attribute
This section specifies the format of the new RADIUS attribute. This section specifies the format of the new RADIUS attribute.
4.1. DS-Lite-Tunnel-Name 4.1. DS-Lite-Tunnel-Name
Description Description
The DS-Lite-Tunnel-Name RADIUS attribute contains a Fully Qualified The DS-Lite-Tunnel-Name RADIUS attribute contains a Fully Qualified
skipping to change at page 8, line 36 skipping to change at page 8, line 40
Access-Accept it MAY fallback to a pre-configured default tunnel Access-Accept it MAY fallback to a pre-configured default tunnel
name, if any. If the NAS does not have any pre-configured default name, if any. If the NAS does not have any pre-configured default
tunnel name, the tunnel can not be established. tunnel name, the tunnel can not be established.
If the NAS is pre-provisioned with a default AFTR tunnel name and the If the NAS is pre-provisioned with a default AFTR tunnel name and the
AFTR tunnel name received in Access-Accept is different from the AFTR tunnel name received in Access-Accept is different from the
configured default, then the AFTR tunnel name received in the Access- configured default, then the AFTR tunnel name received in the Access-
Accept message MUST be used for the session. Accept message MUST be used for the session.
If the NAS cannot support the received AFTR tunnel name for any If the NAS cannot support the received AFTR tunnel name for any
reason, the tunnel should not be established. reason, the tunnel SHOULD NOT be established.
When the Access-Request is triggered by a DHCPv6 Rebind message if When the Access-Request is triggered by a DHCPv6 Rebind message if
the AFTR tunnel name received in the Access-Accept is different from the AFTR tunnel name received in the Access-Accept is different from
the currently used one for that session, the NAS MUST force the B4 to the currently used one for that session, the NAS MUST force the B4 to
re-establish the tunnel using the new AFTR name received in the re-establish the tunnel using the new AFTR name received in the
Access-Accept message. Access-Accept message.
If an implementation includes the Change-of-Authorization (CoA) If an implementation includes the Change-of-Authorization (CoA)
messages [RFC5176], they could be used to modify the current messages [RFC5176], they could be used to modify the current
established DS-Lite tunnel. When the NAS receives a CoA Request established DS-Lite tunnel. When the NAS receives a CoA Request
skipping to change at page 9, line 45 skipping to change at page 9, line 48
As the DS-Lite-Tunnel-Name attribute is used to populate the DHCPv6 As the DS-Lite-Tunnel-Name attribute is used to populate the DHCPv6
OPTION_AFTR_NAME option, the DS-Lite-Tunnel-Name field is formatted OPTION_AFTR_NAME option, the DS-Lite-Tunnel-Name field is formatted
as required in DHCPv6 (Section 8 of [RFC3315] "Representation and Use as required in DHCPv6 (Section 8 of [RFC3315] "Representation and Use
of Domain Names"). Briefly, the format described is using a single of Domain Names"). Briefly, the format described is using a single
octet noting the length of one DNS label (limited to at most 63 octet noting the length of one DNS label (limited to at most 63
octets), followed by the label contents. This repeats until all octets), followed by the label contents. This repeats until all
labels in the FQDN are exhausted, including a terminating zero-length labels in the FQDN are exhausted, including a terminating zero-length
label. Any updates to Section 8 of [RFC3315] also apply to encoding label. Any updates to Section 8 of [RFC3315] also apply to encoding
of this field. of this field.
The data type of DS-Lite-Tunnel-Name RADIUS attribute is a string
with opaque encapsulation, according to section 5 of [RFC2865]
5. Table of attributes 5. Table of attributes
The following tables provide a guide to which attributes may be found The following tables provide a guide to which attributes may be found
in which kinds of packets, and in what quantity. in which kinds of packets, and in what quantity.
Access- Access- Access- Challenge Accounting # Attribute Access- Access- Access- Challenge Accounting # Attribute
Request Accept Reject Request Request Accept Reject Request
0-1 0-1 0 0 0-1 TBA1 DS-Lite-Tunnel-Name 0-1 0-1 0 0 0-1 TBA1 DS-Lite-Tunnel-Name
CoA-Request CoA-ACK CoA-NACK # Attribute CoA-Request CoA-ACK CoA-NACK # Attribute
skipping to change at page 10, line 49 skipping to change at page 11, line 9
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011. RFC 6334, August 2011.
8.2. Informative References 8.2. Informative References
 End of changes. 16 change blocks. 
16 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/