Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
<lionel.morand@orange-ftgroup.com> Mon, 08 August 2011 22:22 UTC
Return-Path: <lionel.morand@orange-ftgroup.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BFA21F8BCD for <aaa-doctors@ietfa.amsl.com>; Mon, 8 Aug 2011 15:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.248
X-Spam-Level:
X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i6nABfQBtTv for <aaa-doctors@ietfa.amsl.com>; Mon, 8 Aug 2011 15:21:57 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3C21F8581 for <aaa-doctors@ietf.org>; Mon, 8 Aug 2011 15:21:56 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D38878C0004; Tue, 9 Aug 2011 00:23:12 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id BE6AF8D0001; Tue, 9 Aug 2011 00:23:12 +0200 (CEST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 00:22:21 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC5619.A3A73DEA"
Date: Tue, 09 Aug 2011 00:22:19 +0200
Message-ID: <B11765B89737A7498AF63EA84EC9F577BB721E@ftrdmel1>
In-reply-to: <CAEZMJWs-E=6PZiPXsi0rsMeP9DGK0NisCC-egV-t361hFn3VQA@mail.gmail.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-topic: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
Thread-index: AcxV16ZtNKedrYlCTYahtVYh+eB/0AAQaABA
References: <EDC652A26FB23C4EB6384A4584434A04037753CB@307622ANEX5.global.avaya.com> <CAEZMJWs-E=6PZiPXsi0rsMeP9DGK0NisCC-egV-t361hFn3VQA@mail.gmail.com>
From: lionel.morand@orange-ftgroup.com
To: mark@azu.ca, dromasca@avaya.com
X-OriginalArrivalTime: 08 Aug 2011 22:22:21.0955 (UTC) FILETIME=[A46B0530:01CC5619]
Cc: aaa-doctors@ietf.org
Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 22:22:04 -0000
I reviewed this draft last year and I had the same comment. I even proposed an alternative based on RFC2868 but authors argued that their approach was better... that may be true! J Lionel De : aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] De la part de Mark Jones Envoyé : lundi 8 août 2011 16:29 À : Romascanu, Dan (Dan) Cc : aaa-doctors@ietf.org Objet : Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04 I took a quick read of the draft. I don't claim to be a softwire expert but it was not clear to me why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here. Mark On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote: Hi AAA Doctors, Did any of you review this document? Thanks and Regards, Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors
--- Begin Message ---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.--- End Message ---
- [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-e… Romascanu, Dan (Dan)
- Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radi… Mark Jones
- Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radi… Alan T DeKok
- Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radi… Bernard Aboba
- Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radi… Bernard Aboba
- Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radi… lionel.morand