Re: [radext] [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt

Maglione Roberta <roberta.maglione@telecomitalia.it> Wed, 01 August 2012 06:21 UTC

Return-Path: <roberta.maglione@telecomitalia.it>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6A21F86D4; Tue, 31 Jul 2012 23:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.425
X-Spam-Level: *
X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
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 5fH7iZ2vytFP; Tue, 31 Jul 2012 23:21:39 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78321F86CB; Tue, 31 Jul 2012 23:21:38 -0700 (PDT)
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 1 Aug 2012 08:21:32 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 1 Aug 2012 08:21:32 +0200
From: Maglione Roberta <roberta.maglione@telecomitalia.it>
To: 'Leaf yeh' <leaf.y.yeh@huawei.com>, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Date: Wed, 01 Aug 2012 08:21:31 +0200
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kIAAiG2AgAEgNbCAAECDsA==
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F127@GRFMBX704BA020.griffon.local>
References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C44FBC5@SZXEML510-MBS.china.huawei.com> <5016DF55.9040401@forthnetgroup.gr> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C45052B@SZXEML510-MBS.china.huawei.com> <5018131B.4090605@forthnetgroup.gr> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C450A83@SZXEML510-MBS.china.huawei.com>
In-Reply-To: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C450A83@SZXEML510-MBS.china.huawei.com>
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, it-IT
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 06:21:40 -0000

Hello,

> I could delete Framed-Pool (88) from the list if you all believe it is
> only for IPv4 address pool.

> Maglione, your opinion?

In my opinion you should remove Framed-Pool because this attribute is used for IPv4 only pool, so it does not apply here.

I'm cc-ing also radext mailing list.

Best Regards,
Roberta


-----Original Message-----
From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: mercoledì 1 agosto 2012 4.41
To: Tassos Chatzithomaoglou; Maglione Roberta
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt

Tassos - Maybe you could separate the attributes, to the ones clearly defined for
dhcp usage (replies) and to others which are defined for passing to the
dhcp server as a guidance or hint or whatever.

I prefer OPTION_RADIUS only carried those attributes that sounds useful to DHCPv6 server, whether it is hint or not.


Tassos - Regarding the pool options, i would give light a preference to
Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool.

I could delete Framed-Pool (88) from the list if you all believe it is only for IPv4 address pool.

Maglione, your opinion?


Best Regards,
Leaf


-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]
Sent: Wednesday, August 01, 2012 1:17 AM
To: Leaf yeh
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt

Thank you for the detailed answer Leaf,

I was under the impression that this draft covered also attributes that
could be passed to the DHCPv6 server as a hint.
So it wasn't necessarily a strict path for the DHCPv6 server to use
these attributes to the replies it sends back.

Maybe you could separate the attributes, to the ones clearly defined for
dhcp usage (replies) and to others which are defined for passing to the
dhcp server as a guidance or hint or whatever.

Regarding the pool options, i would give light a preference to
Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool.

Tassos

On 30/7/2012 8:42 μμ, Leaf yeh wrote:
> Tassos - Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool?
>
> Good question.
>
> a. Framed-IPv6-Pool is defined in section 2.6 of RFC3162 (http://tools.ietf.org/html/rfc3162 ) , and  <quote>This Attribute contains the name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user.</quote>  RFC3162 was published in 2001, at that time, we don't have DHCPv6 (RFC3315) published in 2003. So I guess Framed-IPv6-Pool is designed for SLAAC (Stateless Address Autoconfiguration). But we need something for DHCPv6.
>
> b. When we look into the definition of Framed-Pool (88), the format of it is exactly the same as Framed-IPv6-Pool (100). The content of these 2 attributes are the name of pool in string. I suppose it will be fine for the usage whether it is IPv4 pool or IPv6 pool, or whether it is address pool name or prefix pool name. Agree?
>
> c. When we read section 2.4 of draft-ietf-radext-ipv6-access (http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/?include_text=1 ), <quote>To avoid ambiguity in this scenario, use of the Delegated-IPv6-Prefix-Pool attribute should be restricted to authorization and  accounting of prefix pools used in DHCPv6 Prefix Delegation and the Framed-IPv6-Pool attribute should be used for authorization and accounting of prefix pools used in SLAAC. </quote>. So it is also not recommended to use Framed-IPv6-Pool (100) for DHCPv6.
>
> d. The alternative options for DHCPv6 address/ prefix pool might be : 1. Framed-Pool (88); 2. Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool defined in draft-ietf-radext-ipv6-access. Which one do you prefer in your implementation or suggestion? Or would you like both of them?
>
> Tassos - What about Framed-IPv6-Prefix?
>
> Again. Framed-IPv6-Prefix(97) is design for SLAAC, not for DHCPv6. Pls. refer to section 2.2 of draft-ietf-radext-ipv6-access , <quote>To avoid ambiguity, the Framed-IPv6-Address attribute is only used for authorization and accounting of DHCPv6-assigned addresses and the Framed-IPv6-Prefix and Framed-Interface-Id attributes are used for authorization and accounting of addresses assigned via SLAAC. </quote>
>
> Tassos - Generally, what's the criteria for choosing which attributes to include?
>
> The original though was to design OPTION_RADIUS to convey the AAA-authorized pool/address/prefix for the right selection of the configuration parameter at DHCPv6 server, but  I suppose each of the attributes, which is associated with IPv6 and might be used by DHCPv6 server, could be the candidate. But I guess we will not reuse the analysis in RFC3580 here, which is only designed for IEEE 802.1x. The scenarios mentioned in this draft are focused on the broadband access, including IPoE and PPPoE. Agree?
>
>
> Best Regards,
> Leaf
>
>
>
> From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]
> Sent: Tuesday, July 31, 2012 3:24 AM
> To: Leaf yeh
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
>
> Just two questions after a quick reading...
>
> Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool?
> What about Framed-IPv6-Prefix?
> Generally, what's the criteria for choosing which attributes to include?
>
> Your draft states:
>
>
>     The option-data of OPTION_RADIUS is one or a list of RADIUS
>     attributes received in the Access-Accept message from the RADIUS
>     server.  As the same method in [RFC4014], only the attributes listed
>     in the table below may be included in the OPTION_RADIUS.
>
> RFC 4014 states:
>
>
>     To avoid dependencies between the address allocation and other state
>     information between the RADIUS server and the DHCP server, the DHCP
>     relay agent SHOULD include only the attributes in the table below in
>     an instance of the RADIUS Attributes suboption.  The table, based on
>     the analysis in RFC 3580 [8], lists attributes that MAY be included:
>
>
> I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your draft refers to DHCPv6 only, and if yes, why a DHCPv4 server should know about an IPv6 attribute and vice versa.
>
>
> --
> Tassos
> On 29/7/2012 8:02 μμ, Leaf yeh wrote:
> Dear DHC folks,
>
> The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IETF84 DHC session, is waiting for your review and comments.
>
>
> Best Regards,
> Leaf
>
> PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ )
>
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Monday, July 30, 2012 9:58 AM
> To: i-d-announce@ietf.org
> Cc: dhcwg@ietf.org
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
>
>       Title           : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server
>       Author(s)       : Leaf Y. Yeh
>                            Mohamed Boucadair
>                            Ted Lemon
>       Filename        : draft-ietf-dhc-dhcpv6-radius-opt-01.txt
>       Pages           : 9
>       Date            : 2012-07-29
>
> Abstract:
>     The DHCPv6 RADIUS option provides a communication mechanism between
>     relay agent and the server.  This mechanism can help the centralized
>     DHCPv6 server to select the right configuration for the client based
>     on the authorization information received from a separate RADIUS
>     server which is not located at the same place of DHCPv6 server in the
>     cases where the NAS acts as DHCPv6 relay agent and RADIUS client
>     simultaneously.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>


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.