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
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt
Precedence: list

Tassos - Is there any particular reason for including Framed-Pool instead o=
f Framed-IPv6-Pool?=20

Good question.=20

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 as=
signed pool that SHOULD be used to assign an IPv6 prefix for the user.</quo=
te>  RFC3162 was published in 2001, at that time, we don't have DHCPv6 (RFC=
3315) 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 attrib=
utes are the name of pool in string. I suppose it will be fine for the usag=
e 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://datatr=
acker.ietf.org/doc/draft-ietf-radext-ipv6-access/?include_text=3D1 ), <quot=
e>To avoid ambiguity in this scenario, use of the Delegated-IPv6-Prefix-Poo=
l 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 SLA=
AC. </quote>. So it is also not recommended to use Framed-IPv6-Pool (100) f=
or DHCPv6.

d. The alternative options for DHCPv6 address/ prefix pool might be : 1. Fr=
amed-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 y=
our 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. ref=
er to section 2.2 of draft-ietf-radext-ipv6-access , <quote>To avoid ambigu=
ity, the Framed-IPv6-Address attribute is only used for authorization and a=
ccounting of DHCPv6-assigned addresses and the Framed-IPv6-Prefix and Frame=
d-Interface-Id attributes are used for authorization and accounting of addr=
esses assigned via SLAAC. </quote>

Tassos - Generally, what's the criteria for choosing which attributes to in=
clude?

The original though was to design OPTION_RADIUS to convey the AAA-authorize=
d pool/address/prefix for the right selection of the configuration paramete=
r at DHCPv6 server, but  I suppose each of the attributes, which is associa=
ted with IPv6 and might be used by DHCPv6 server, could be the candidate. B=
ut I guess we will not reuse the analysis in RFC3580 here, which is only de=
signed for IEEE 802.1x. The scenarios mentioned in this draft are focused o=
n the broadband access, including IPoE and PPPoE. Agree?


Best Regards,
Leaf



From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]=20
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 draf=
t 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 =EC=EC, Leaf yeh wrote:
Dear DHC folks,

The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IE=
TF84 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 i=
nternet-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 director=
ies.
 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 Acces=
s 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=3Ddraft-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