[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comment on draft-maglione-softwire-dslite-radius-ext
It seems that the first mail, sent yesterday, was not delivered.
> 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
> -----Message d'origine-----
> De : owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] De la part de
> lionel.morand@orange-ftgroup.com
> Envoyé : jeudi 29 juillet 2010 16:57
> À : radiusext@ops.ietf.org
> Cc : bernard_aboba@hotmail.com;
> roberta.maglione@telecomitalia.it; adurand@juniper.net;
> stefan.winter@restena.lu
> Objet : 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
>
>
> --
> 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/>
>
--
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/>