Re: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt

[Leaf yeh <[e-mail]>]

Hi, Ted

Thanks for your comments of the quick review and text revisions after '/s'. I will update these revision in the '-01'.

Ted  - *** There is no reason to use either suboptions or RADIUS options.   The
right thing to do is simply define a DHCP option to carry each RADIUS attribute
that you think the DHCP server might need.   Sub-options are common in DHCPv4
because there are only 256 option codes possible, but in DHCPv6 this is not a
problem, and the additional complexity introduced by suboptions is undesirable.

Section 4 of this draft raised the discussion on the option design. Design-1 employs the sub-option; Design-2 employs the same method of RFC4014. Hope we could figure out the best design in the WG. The code space of DHCPv6 option is 2-octect, so we don't need to worry about the exhaustion of DHCPv6 option codes. The draft could request the option code for Option_Pool_Name, Option_Address_Prefix_Auth from the same space for Option_Authorization, such as OPTION_IAPREFIX(26) in OPTION_IA_PD(25), or OPTION_IAADDR(5) in OPTION_IA_NA(3). That means the concept of sub-option is not necessary in this draft, the 'contained option' might be the substitute for the text.


Ted - *** So, the following should all just be DHCPv6 options, and there should be
no Option_Authorization option.

The following (Option_Pool_Name, Option_Address_Prefix_Auth ) could be DHCPv6 options, and also could be the 'contained option' in the 'container option', Option_Authorization.


Ted - *** You need to say how the string is encoded; I'd suggest UTF8 or
NVT-ASCII, whichever makes more sense to you.   UTF8 is better if
it's possible, but I don't know what the RADIUS spec says.

The defintion of RADIUS attribute 'Framed-Pool' in the setion 5.18 of RFC2869 is quoted as 'The string field contains the name of an assigned address pool configured on the NAS.'. The defintion of RADIUS attribute 'Framed-IPv6-Pool' in the setion 2.6 of RFC3316  is quoted as 'The string field contains the name of an assigned IPv6 prefix pool configured on the NAS. The field is not NUL (hex 00) terminated.'. The definetion of 'string'data type in RADIUS attribute can be found in section 5 of RFC2865 and section 2.1 of RFC6158, quoted as '8-bit binary data'. UTF-8 is used in 'text' data type of RADIUS.

Ted - *** Why not have two options here, one an address and the other a prefix?
Is there a reason why it makes sense to overload this (e.g., does RADIUS
do it this way?)

No special reason here, just supposed the address and the prefix could be presented in the unified format. I am ok with re-define 2 options here. RADIUS employs one data type for 'IPv6 address' and the other data type for 'IPv6 prefix' per the section 2.1 of RFC6158 (or the section 2.1, 2.3 of RFC3162).

Ted - *** Okay, so RADIUS does it the same way I'd suggest doing it for DHCP.

Ted - *** This really isn't kosher.   DHCP servers do address allocation,
not relay agents.   If the RADIUS server actually controls address
allocation, there is no need for a DHCP server.



As mentioned in section 6 of this draft, the relay includes Option_Authorization per the RADIUS attrbutes in the message of 'Access-Accept'. The server will respond (or do address allocation) per the indication in Option_Authorization, as the same behavior when the server locates on the NAS (BRAS). In fact, the idea in this draft expects the sever only do the address/prefix allocation. Hope it is clarified.





Best Regards,
Leaf



From: Ted Lemon [[e-mail]]
Sent: Wednesday, March 28, 2012 18:48
To: Leaf yeh; dhc WG
Subject: RE: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt


I had a chance to give the draft a thorough read yesterday; I've attached comments and proposed edits.