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

[Tassos Chatzithomaoglou <[e-mail]>]

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-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:[e-mail]]
> Sent: Tuesday, July 31, 2012 3:24 AM
> To: Leaf yeh
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Monday, July 30, 2012 9:58 AM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>