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

Leaf yeh <leaf.y.yeh@huawei.com> Tue, 31 July 2012 03:46 UTC

Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91A211E80E5 for <dhcwg@ietfa.amsl.com>; Mon, 30 Jul 2012 20:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.376
X-Spam-Level:
X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 GqoFNelf0iIZ for <dhcwg@ietfa.amsl.com>; Mon, 30 Jul 2012 20:46:12 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9608811E80E2 for <dhcwg@ietf.org>; Mon, 30 Jul 2012 20:46:12 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM32358; Mon, 30 Jul 2012 23:46:12 -0400 (EDT)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 20:42:59 -0700
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 20:43:01 -0700
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 11:42:57 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kA==
Date: Tue, 31 Jul 2012 03:42:56 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C45052B@SZXEML510-MBS.china.huawei.com>
References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C44FBC5@SZXEML510-MBS.china.huawei.com> <5016DF55.9040401@forthnetgroup.gr>
In-Reply-To: <5016DF55.9040401@forthnetgroup.gr>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2012 03:46:13 -0000

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-IPv6-Pool (88), the format of it is exactly the same as Framed-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-IPv6-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