Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-06.txt

From: [email-masked]
Date: Fri, 16 Nov 2007 12:15:02 -0500

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		: Subnet Allocation Option
	Author(s)	: R. Johnson, et al.
	Filename	: draft-ietf-dhc-subnet-alloc-06.txt
	Pages		: 32
	Date		: 2007-11-16
	
This document defines a new DHCP option which is passed between the
   DHCP Client and the DHCP Server to request dynamic allocation of a
   subnet, give specifications of subnet(s) allocated, and report usage
   statistics.  This memo documents the current usage of the option in
   agreement with RFC-3942[4], which declares that any pre-existing
   usages of option numbers in the range 128 - 223 should be documented
   and the working group will try to officially assign those numbers to
   those options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dhc-subnet-alloc-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 15:27:25 +0100

Hi, I've read this draft and I have some comments.  I may have missed 
prior discussion around it, sorry if I sound uninformed on this.

Was there a Last Call for this draft?  What are the reasons behind its 
intended status being Informational? Was there any mention about 
prototyping or intent of it or of an Ethereal/WireShark packet analyzer 
dissector?

[email-masked] wrote:
> directories. This draft is a work item of the Dynamic Host 
> Configuration Working Group of the IETF.
> 
> Title		: Subnet Allocation Option Author(s)	: R. Johnson, et al. 
> Filename	: draft-ietf-dhc-subnet-alloc-06.txt Pages		: 32 Date		: 
> 2007-11-16  This document defines a new DHCP option which is passed 
> between the DHCP Client and the DHCP Server to request dynamic 
> allocation of a subnet, give specifications of subnet(s) allocated, 
> and report usage statistics.  This memo documents the current usage 
> of the option in agreement with RFC-3942[4], which declares that any 
> pre-existing usages of option numbers in the range 128 - 223 should 
> be documented and the working group will try to officially assign 
> those numbers to those options.
> 

Comments on this draft:

> 3.1.  Subnet-Request Suboption format
 >
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       1       |     Len       |     Flags |i|h|    Prefix     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since the Prefix field will only encode a maximum of 32 values (the 
prefix length of an IPv4 address, or the subnet mask) 5 bits would 
suffice (and not 8 as above).  This would allow Flags field to expand 
more flags in the future.  Thoughts?

Nit:
>  The DHCP Server SHOULD allocate a subnet with prefix size less than 
> or equal to the size P specified in the request.  In other words, a 
> subnet at least the size requested and possibly bigger.
                                          ^^
I think you meant 'possibly smaller' (if we characterize the size 
parameter as the number of addresses within it then a bigger subnet 
accommodates more hosts).

>    The actual method of allocating subnets on the DHCP Server, as well
>    as the configuration of what networks may be subnetted and how, is
>    left up to the implementation.

I think this is reasonable.

However, I see more simple issues around it that don't necessarily need 
to be left to implementations and moreover have a direct relationship to 
DHCP.

-Could we have a picture somewhere at the beginning of the document
  describing an example with topology how you see this prototyped?  Is
  that like Client--Server or more like Client--Relay--Server?
-If the latter then we may have some new restrictions to specify: the
  Server should allocate a subnet _within_ the subnet on which the Relay
  already allocates addresses for Clients.  This has a strong impact on
  implementations' ways to specify their configuration files.
-and also about routing: if working through a Relay then the routing
  must be updated for the subnet allocation to work.  Maybe how to update
  it it's left to other specs, but the routing must be updated (Server's
  routing table must point to Client's address for the subnet it
  allocated).  This is something that could be mentioned I hinkl.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Ralph Droms <[email-masked]>
Date: Tue, 20 Nov 2007 10:27:17 -0500

Quick top-level response. This draft describes Cisco's current use of  
option code 220, and follows the process outlined in RFC 3942 to  
document the use of option codes the were previously identified as  
"site-specific options" in RFC 2132.  According to the RFC 3942  
process, the document will be published as "Informational"; because  
it documents current use rather than future deployment, there likely  
won't be changes to the syntax or semantics of the option at this point.

- Ralph

On Nov 20, 2007, at Nov 20, 2007,9:27 AM, Alexandru Petrescu wrote:

> Hi, I've read this draft and I have some comments.  I may have  
> missed prior discussion around it, sorry if I sound uninformed on  
> this.
>
> Was there a Last Call for this draft?  What are the reasons behind  
> its intended status being Informational? Was there any mention  
> about prototyping or intent of it or of an Ethereal/WireShark  
> packet analyzer dissector?
>
>> 2007-11-16  This document defines a new DHCP option which is  
>> passed between the DHCP Client and the DHCP Server to request  
>> dynamic allocation of a subnet, give specifications of subnet(s)  
>> allocated, and report usage statistics.  This memo documents the  
>> current usage of the option in agreement with RFC-3942[4], which  
>> declares that any pre-existing usages of option numbers in the  
>> range 128 - 223 should be documented and the working group will  
>> try to officially assign those numbers to those options.
>> A URL for this Internet-Draft is: http://www.ietf.org/internet- 
>> drafts/draft-ietf-dhc-subnet-alloc-06.txt
>
> Comments on this draft:
>
> suffice (and not 8 as above).  This would allow Flags field to  
> expand more flags in the future.  Thoughts?
>
> Nit:
>>  The DHCP Server SHOULD allocate a subnet with prefix size less  
>> than or equal to the size P specified in the request.  In other  
>> words, a subnet at least the size requested and possibly bigger.
>                                          ^^
> However, I see more simple issues around it that don't necessarily  
> need to be left to implementations and moreover have a direct  
> relationship to DHCP.
>