[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comment on draft-maglione-softwire-dslite-radius-ext
Hi Lionel,
Thanks for putting together an alternative way to address this scenario. The difference I see comparing the two methods is that in your proposal you just have one single attribute, the Tunnel-Server-Endpoint that can contain either the tunnel name or the tunnel address, while
in our draft we wanted to keep a 1 to 1 mapping between the RADIUS attributes and the already specified DHCPv6 options (OPTION_DS_LITE_ADDR and OPTION_DS_LITE_NAME). For this reason we prefer having two separate attributes one for the DSLite tunnel name (DS-Lite-Tunnel-Name) and the other for the DSLite tunnel address (DS-Lite-Tunnel-Addr).
Best regards,
Roberta
-----Original Message-----
From: lionel.morand@orange-ftgroup.com [mailto:lionel.morand@orange-ftgroup.com]
Sent: giovedì 29 luglio 2010 16.57
To: radiusext@ops.ietf.org
Cc: bernard_aboba@hotmail.com; Maglione Roberta; adurand@juniper.net; stefan.winter@restena.lu
Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext
Here is an example of what could be the content of tyhe draft describing the use of the Tunnel attributes for DS-Lite Tunneling.
This is based on the draft published by Alain and Roberta as well as the RFC 2868.
This kind of approach would avoid having to define a new set of attributes.
Please comment the idea based on the following draft attempt!
BR,
Lionel
***********************
Title: Use of RADIUS Tunnel Attributes for Dual-Stack Lite
Abstract
This document describes the use of the set of RADIUS attributes defined in the RFC 2868 to support
establishment of Dual-Stack Lite tunnel.
1. Motivation
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is a solution to
offer both IPv4 and IPv6 connectivity to customers which are
addressed only with an IPv6 prefix (no IPv4 address is assigned to
the attachment device). One of its key components is an IPv4-over-
IPv6 tunnel, but a DS-Lite Basic Bridging BroadBand (B4) will not
know if the network it is attached to offers Dual-Stack Lite support,
and if it did, would not know the remote end of the tunnel to
establish a connection.
To inform the B4 of the AFTR's location, either an IPv6 address or
Fully Qualified Domain Name (FQDN) may be used. Once this
information is conveyed, the presence of the configuration indicating
the AFTR's location also informs a host to initiate Dual-Stack Lite
(DS-Lite) service and become a Softwire Initiator.
The draft draft-ietf-softwire-ds-lite-tunnel-option
[I-D.ietf-softwire-ds-lite-tunnel-option] specifies two DHCPv6
options which are meant to be used by a Dual-Stack Lite client (Basic
Bridging BroadBand element, B4) to discover its Address Family
Transition Router (AFTR) address. In order to be able to populate
such options the DHCPv6 Server must be pre-provisioned with the
Address Family Transition Router (AFTR) address or name.
In Broadband environments, customer profile may be managed by AAA
servers, together with user Authentication, Authorization, and
Accounting (AAA). RADIUS protocol [RFC2865] is usually used by AAA
Servers to communicate with network elements.
[I-D.ietf-radext-ipv6-access] describes a typical broadband network
scenario in which the Network Access Server (NAS) acts as the access
gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6
Server function that allows it to locally handle any DHCPv6 requests
issued by the clients.
Since the DS-Lite AFTR information can be stored as tunneling information
in AAA servers and the client configuration is mainly provided through
DHC protocol running between the NAS and the requesting clients, this
document aims at describing the use of the RADIUS tunnel attributes
defined in RFC 2868 for carrying the DS-Lite tunnel information (DS-Lite
Tunnel Name and DS-Lite Tunnel Address), this information being populated in
in DHCPv6 options already specified in [I-D.ietf-softwire-ds-lite-tunnel-option].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-
Lite Address Family Transition Router element (AFTR) are defined in
[I-D.ietf-softwire-dual-stack-lite].
3. DS-Lite Configuration with RADIUS and DHCPv6
The Figure 1 illustrates how the RADIUS protocol and DHCPv6 work
together to accomplish DS-Lite configuration on the B4 element.
B4 NAS AAA
| | Server
| | |
| | |
| |-----Access Request -------->|
| | |
| |<----Access Accept |
| | (Tunnel-Type, |
| | Tunnel-Medium-Type , |
| | Tunnel-Server-Endpoint) |
| | |
|------DHCPv6 Request----->| |
| (DS-Lite tunnel Option) | |
| | |
|<-----DHCPv6 Reply--------| |
| (DS-Lite tunnel option) | |
DHCPv6 RADIUS
Figure 1: RADIUS and DHCPv6 Message Flow
The Network Access Server (NAS) operates as a client of RADIUS and as
DHCP Server for DHC protocol. The NAS initially sends a RADIUS
Access Request message to the RADIUS server, requesting
authentication. Once the RADIUS server receives the request, it
validates the sending client and if the request is approved, the AAA
server replies with an Access Accept message including a list of
attributes that describe the parameters to be used for
this session. This list may also contain the RADIUS Tunnel attributes
Tunnel-Type, Tunnel-Medium-Type and Tunnel-Server-Endpoint (and
Tunnel-Preference if multiple tunnels information are provided).
These attirbutes are used to provide the NAS with AFTR Tunnel IPv6
Address and/or the AFTR Tunnel Name. When the NAS receives a
DHCPv6 client request containing the DS-Lite tunnel Options, the NAS
shall use the address and/or name returned in the RADIUS
Tunnel-Server-Endpoint attribute to populate the
DHCPv6 OPTION_DS_LITE_ADDR option in the DHCPv6 reply message.
3. Use of the RADIUS Tunnel Attributes
This section describes the RADIUS attributes defined in RFC 2868 and
used to provide a NAS with DS-Lite tunnel information. The use of these
attributes shall follow the recommendations given in the RFC 2868.
Any other attirbutes defined in RFC 2868 SHOULD NOT be used.
3.1. Tunnel-Type
The Tunnel-Type Attribute (64) [RFC 2868] SHALL be used to indicate the type
of tunnel to be used. This document defines a new value of tunnel type
to be populated in the Value field of the Tunnel-Type attribute for DS-Lite
Tunneling information.
Value Name
TBD1 DS-Lite Tunneling
3.2. Tunnel-Medium-Type
The Tunnel-Medium-Type Attribute (65) SHALL be used to indicate IPv6
(value 2) as transport medium for DS-Lite Tunnel.
3.4. Tunnel-Server-Endpoint
The Tunnel-Server-Endpoint attribute ((67) SHALL be used to provide
either the FQDN of the AFTR Tunnel or a text representation of the
IPv6 address in either the preferred or alternate form [17].
If the The Tunnel-Type Attribute (64) indicates the tunnet type "DS-Lite
Tunneling" (value TBD1), at least one Tunnel-Server-Endpoint attribute
MUST be provided by the RADIUS server and at least two if the IPv6 address
and the FQDN of the AFTR Tunnel are both provided.
3.8. Tunnel-Preference
If more than one set of DS-Lite tunneling attributes is returned by the
RADIUS server to the NAS, this Attribute MAY be included in each
set to indicate the relative preference assigned to each tunnel.
4. Table of Attributes
The following table provides a guide to which of the above attributes
may be found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Acct-Request # Attribute
0+ 0+ 0 0 0-1 64 Tunnel-Type
0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type
0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
0+ 0+ 0 0 0 83 Tunnel-Preference
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
5. Security Considerations
TBD.
6. IANA Considerations
This document defines a new value of tunnel type to be assigned by the IANA.
Value Name
TBD1 DS-Lite Tunneling
7. References
________________________________
De : MORAND Lionel RD-CORE-ISS
Envoyé : mercredi 28 juillet 2010 10:31
À : 'radext mailing list'
Objet : Comment on draft-maglione-softwire-dslite-radius-ext
Following my comment during the meeting, about (re-)using an existing attribute to convey tunnel info for DS-Lite, what about re-using attributes defined in RFC 2868 ???
It should be straightforward to create a new type for DS-Lite.
BR,
Lionel
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>