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

From: Leaf yeh <[email-masked]>
Date: Tue, 06 Mar 2012 08:15:20 +0000

Dear WG,

A new draft named "Authorization Option for DHCPv6 Relay Agents on Broadband Access Server" has been posted yesterday. Questions and comments on it are more than welcome.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2012 5:26 PM
To: Leaf yeh
Subject: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt

A new version of I-D, draft-yeh-dhc-dhcpv6-authorization-opt-00.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository.

Filename:	 draft-yeh-dhc-dhcpv6-authorization-opt
Revision:	 00
Title:		 Authorization Option for DHCPv6 Relay Agents on Broadband Access Server
Creation date:	 2012-03-05
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   The DHCPv6 authorization 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 got from the
   centralized RADIUS server which is not located at the same place of
   DHCPv6 server in the case when the NAS works as DHCPv6 relay agent
   and RADIUS client simultaneously.

The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Mar 2012 10:48:57 +0000

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Mar 2012 07:28:23 -0400

Regard Ted's comment:

*** 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.

I fully agree. I had always thought it good if we had a v6 equivalent of RFC 4014. Jusy a container for comminicating a subset of the RADIUS attributes would work very well.

- Bernie

Sent from my iPad

On Mar 28, 2012, at 6:49 AM, "Ted Lemon" <[email-masked]> wrote:

> <draft-yeh-dhc-dhcpv6-authorization-opt-00.txt>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Mar 2012 12:02:07 +0000

> I fully agree. I had always thought it good if we had a v6 equivalent
> of RFC 4014. Jusy a container for comminicating a subset of the
> RADIUS attributes would work very well.

That's not actually what I was suggesting, but okay.

The main issue with this draft, though, is a simple one: is this the right architecture to solve the problem described in the introduction?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Mar 2012 08:15:05 -0400

I guess the core question is how is this different from 4014 (other than the obvious ones related to different DHCP versions)? The intro text is very different, but aren't they both trying to do the same thing? That of course begs the question as to what is wrong with the 4014 text (appropriately adjusted for v6). If this is trying to do something different, it certainly isn't clear to me.

Sent from my iPad

---

From: Leaf yeh <[email-masked]>
Date: Wed, 28 Mar 2012 14:03:08 +0000

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

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 [[email-masked]]
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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Mar 2012 14:23:04 +0000

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

> 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.

It seems that Bernie is arguing in favor of Design-2.   I don't have a strong opinion on this, other than that it seems as if you want to emphasize the specific options you mention in your draft, and so from that perspective it makes sense to simply send them as DHCP options.

However, I do not understand why you need to encapsulate these options.   Doesn't this just waste space in the DHCP packet for no purpose?

> quoted as '8-bit binary data'. UTF-8 is used in 'text' data type of RADIUS.

Okay, so if the RADIUS option is binary data, you should say "8-bit binary data" in the DHCP option definition.   If it's text, you should say "UTF-8 encoded text" in the DHCP option definition.   But you can't just say "text."

> 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).

Great, thanks!

> 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.

I may have expressed myself poorly.   I am not asking you to clarify how it works.   I am saying that I don't agree that it should work that way, and I would like the working group to consider the architecture you are proposing, and the two other architectures I proposed in my comments, and make a decision as to which architecture to use.   I understand that you are advocating the particular architecture you describe in the draft, and that's fine, but the working group should consider this question.