Network Working Group R. Johnson
Internet-Draft J. Jumarasamy
Expires: April 25, 2007 K. Kinnear
M. Stapp
Cisco Systems, Inc.
October 22, 2006
Subnet Allocation Option
draft-ietf-dhc-subnet-alloc-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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[7], which declares that any pre-existing
usages of option numbers in the range 128 - 223 should be documented
Johnson, et al. Expires April 25, 2007 [Page 1]
Internet-Draft Subnet Allocation Option October 2006
and the working group will try to officially assign those numbers to
those options.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Subnet Allocation Option format . . . . . . . . . . . . . . . 5
3.1 Subnet-Request Suboption format . . . . . . . . . . . . . 5
3.2 Subnet-Information Suboption format . . . . . . . . . . . 7
3.2.1 Subnet Prefix Information section format . . . . . . . 7
3.3 Subnet-Name Suboption format . . . . . . . . . . . . . . . 9
3.4 Suggested-Lease-Time Suboption format . . . . . . . . . . 10
4. Requesting allocation of a subnet . . . . . . . . . . . . . . 11
4.1 Client DHCPDISCOVER message . . . . . . . . . . . . . . . 11
4.2 Server DHCPOFFER message . . . . . . . . . . . . . . . . . 11
4.3 Client DHCPREQUEST message . . . . . . . . . . . . . . . . 12
4.4 Server DHCPACK message . . . . . . . . . . . . . . . . . . 12
5. Client renewal of subnet lease . . . . . . . . . . . . . . . . 14
5.1 Client RENEW DHCPREQUEST message . . . . . . . . . . . . . 14
5.2 Server RENEW DHCPREQUEST response . . . . . . . . . . . . 14
5.3 Client DHCPRELEASE message . . . . . . . . . . . . . . . . 15
5.4 Server DHCPFORCE message . . . . . . . . . . . . . . . . . 15
6. Client requesting subnet allocation information . . . . . . . 16
6.1 Client DHCPDISCOVER message . . . . . . . . . . . . . . . 16
6.2 Server DHCPOFFER response . . . . . . . . . . . . . . . . 16
6.3 Client additional DHCPDISCOVER messages . . . . . . . . . 16
6.4 Server additional DHCPOFFER messages . . . . . . . . . . . 17
7. DHCP Server Subnet Allocation method . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1 Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Differences with DHCPv6 Prefix Delegation . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
12. Intellectual Property Rights . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
Johnson, et al. Expires April 25, 2007 [Page 2]
Internet-Draft Subnet Allocation Option October 2006
1. Introduction
There is a need for a DHCP Client to be able to allocate a subnet
from a DHCP Server. Alternate methods of allocation, such as AAA are
not appropriate for various reasons and the most straight-forward way
to accomplish this allocation is via DHCP. A DHCP option to support
this may be utilized by a simple Dialin Aggregation box, or even to
implement a Hierarchical chain of DHCP Servers, each one in turn
leasing one or more subnets to the next DHCP Server down the chain.
This new DHCP option [3], the Subnet Allocation option is specified
in such a way as to use one DHCP Option number, while using suboption
numbers for each function. The Subnet-Request suboption tells what
types of subnets are needed and how many. The Subnet-Information
suboption gives the actual subnet number(s) and allows for extra
flags to convey additional information about each subnet. The
"Subnet-Name" suboption allows a method of passing additional
information about the requested subnet(s), such as department name,
user name, customer number, etc. The "Suggested-Lease-Time"
suboption provides a method for the DHCP Server to suggest a lease
time for addresses allocated from the offered subnet. The DHCP
Server has the option of not supplying all subnets requested or even
returning different sized subnets than were requested. Additionally,
usage statistics may be included in RENEW messages from the DHCP
Client back to the DHCP Server.
Johnson, et al. Expires April 25, 2007 [Page 3]
Internet-Draft Subnet Allocation Option October 2006
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document also uses the following terms:
DHCP Client: DHCP Client or "Client" is an Internet host using DHCP
to obtain configuration parameters such as a network address.
DHCP Server: A DHCP Server or "Server" is an Internet host that
returns configuration parameters to DHCP Clients.
Johnson, et al. Expires April 25, 2007 [Page 4]
Internet-Draft Subnet Allocation Option October 2006
3. Subnet Allocation Option format
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len | Flags | Suboptions ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code = Subnet Allocation option code (1 octet) 220
Len = Length of the entire option including all sub-options and
excluding the "Code" and "Len" fields above (1 octet)
Flags = Various flags: (None currently defined)
One or more sub-options may be specified as described below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = Length of the suboption excluding the subcode and Len fields (1
octet)
Flags = Flags field. (all unused bits MBZ)
'h'
'1' = Client will be allocating addresses from this subnet.
'0' = Client will be relaying DHCP requests to the Server from
this subnet.
'i'
'1' = Client is seeking information about previously allocated
subnets.
'0' = Client is seeking a new subnet allocation.
Johnson, et al. Expires April 25, 2007 [Page 5]
Internet-Draft Subnet Allocation Option October 2006
Prefix = Size of the subnet needed [6] (number of bits in subnet
prefix) (zero (0) means no suggested size is given) (1 octet)
The DHCP Server SHOULD NOT include the Subnet Request suboption in
any replies to the DHCP Client. Enough information will be present
in the Subnet-Information suboption, such that the Subnet Request
suboption is not needed in replies to the Client.
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. The DHCP
Server MAY allocate a subnet with a prefix size greater than that
specified in the request (subnet of a size smaller than requested),
but this is not encouraged.
A size P of zero (0) MAY be specified by the DHCP Client. In this
case, no suggested size is given.
Multiple Subnet-Request suboptions in a DHCP packet indicate that
multiple subnets are being requested.
Each Subnet-Request suboption MUST result in no more than one (1)
Subnet-Information suboption in the DHCPOFFER message from the
Server, and may result in zero (0) Subnet-Information suboptions.
The Client MAY also include the Subnet-Information suboption in order
to request a particular subnet. In this case, the Client SHOULD only
include one (1) Subnet-Request suboption, since it would otherwise be
unclear which Subnet-Information suboption refered to which Subnet-
Request suboption. Multiple subnet requests can be made by sending
multiple DHCPDISCOVER packets.
Setting the "h" flag to "1" indicates the Client will be allocating
addresses from the allocated subnet(s) itself. This can be thought
of as a "Hierarchial DHCP" design in that control of allocation for
the subnet(s) will be passed to the Client.
Setting the "h" flag to "0" indicates the Client wants the DHCP
Server to retain control over allocation of addresses from the
subnet(s). Any address allocation requests on the subnet will be
relayed back to the DHCP Server.
Setting the "i" flag to "1" indicates the Client is NOT seeking
allocation of any subnets, but is simply seeking information from the
Server as to what subnet(s) have been allocated (or reserved) for
this Client. If the "i" flag is set to "1", then the "P" field
SHOULD be set to "0" and MUST be ignored by the Server.
Johnson, et al. Expires April 25, 2007 [Page 6]
Internet-Draft Subnet Allocation Option October 2006
3.2 Subnet-Information Suboption format
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Len | Flags |c|s| SP1, SP2, ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = Length of the sub-option excluding the Subcode and Len fields
(1 octet)
Flags = Various flags which apply to ALL Subnet Prefix Information
fields specified in this suboption
'c' = Client flag (explained below)
's' = Server flag (explained below)
SP1,SP2 = Subnet Prefix information as specified below (variable
sized)
The "Client flag" ("c") is set to "1" if this Subnet-Information
suboption is in response to a Client request for information from the
Server as to what subnet(s) have been allocated. This flag is only
used in response to a Subnet-Request suboption with the "i" flag set
and should be zero (0) otherwise.
The "Server flag" ("s") is set to "1" if the Server has additional
subnet information for the Client.
The Subnet-Information suboption is used by the DHCP Server in order
to return information as to what subnets are offered (in the case of
a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet).
As is indicated above, multiple subnets may be returned in one
Subnet-Information suboption.
The Subnet-Information suboption is also used by the DHCP Client in
order to request allocation of specific subnets in a DHCPREQUEST
packet. In this case, the Address, Prefix, and Flags fields MUST NOT
be changed from the information which was received in the DHCPOFFER
packet from the server. The Client MAY, however, use multiple
Subnet-Information suboptions in order to request subnets which were
originally specified by the Server inside one Subnet-Information
suboption.
3.2.1 Subnet Prefix Information section format
Johnson, et al. Expires April 25, 2007 [Page 7]
Internet-Draft Subnet Allocation Option October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Flags |h|d| Stat-len | Optional stats...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr = IPv4 address (4 octets)
Prefix = Specifying number of prefix bits in the subnet (1 octet)
Flags = Flags field (Undefined bits must be zero) (1 octet)
'd' Flag
'1' = Deprecate this subnet.
'h' Flag
'1' = Client will be allocating addresses from this subnet.
'0' = Client will be relaying DHCP requests to the Server from
this subnet.
Stat-len = Length of the optional statistics information field
The "d" flag may only be returned by the Server to the Client (inside
a DHCPACK packet, in response to a DHCP RENEW). It's presence means
that the Client should prepare to give up the subnet. For example,
if the Client is assigning addresses from this subnet to other
clients, it should cease doing so immediately and should not renew
any leases when client's ask for renewal. As soon as all addresses
in the subnet are unallocated, the Client should send a DHCPRELEASE
message to the Server, including a Subnet Prefix Information
suboption for the subnet in order to release the subnet. The format
of this message is described farther below.
The "h" flag tells the Client how the Server intends for the Client
to use the allocated subnet. It is interpreted in the same manner as
that in the Subnet-Request suboption. In response to a Subnet-
Request, the Server should normally specify the "h" flag in the same
mannor was it was in the Subnet-Request suboption from the Client.
The Server MAY, however, change the "h" flag from that specified in
the Subnet-Request suboption if it has been configured to override
the Client's request.
If any usage statistics information is to be included, then the
Johnson, et al. Expires April 25, 2007 [Page 8]
Internet-Draft Subnet Allocation Option October 2006
"Stat-len" field specifies the number of bytes of statistics
information which is included. See below for more information. If
no statistics information is included, then this byte MUST be zero.
The "Stat-len" field SHOULD always be zero when this suboption is
sent by the DHCP Server. The usage statistics information is
intended for use only to report usage statistics from the Client to
the Server.
3.2.1.1 Subnet Usage Statistics
The Subnet-Information suboption may also include usage statistics
information. If this information is included, then the "Stat-len"
(Statistics length) field MUST be set to the number of bytes of
statistics information which is being included. The statistics
information MUST be in the following form and order:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| High water |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Currently in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unusable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"High water" refers the to "high water mark" of allocated addresses
within the subnet. I.e., the largest number of addresses which were
ever allocated at one time from the subnet.
"Currently in use" refers to the number of addresses currently
allocated in the subnet.
"Unusable" refers to the number of addresses which are currently
unusable for any reason (such as a client returning a DHCPDECLINE, or
finding the address already in use).
Additional statistics may be added to this option in the future. If
so, they MUST be appended to the end of the option. All statistics
fields MUST remain in the same order. Use the all ones value
(0xFFFF) in order to skip reporting a number for a particular field.
Fewer fields may be included than what is specified in any current
RFC, but all fields which are included MUST remain in order specifed
here.
3.3 Subnet-Name Suboption format
Johnson, et al. Expires April 25, 2007 [Page 9]
Internet-Draft Subnet Allocation Option October 2006
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Len | Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = length of the sub-option excluding the Subcode and Len fields
(1 octet)
The Subnet-Name suboption may be used in order to pass a subnet name
to the server for use during allocation. This name may be used for
any purpose but is intended to tell the server something extra about
the needed subnet; for example, "sales department", "customer 1002",
"address pool FOO", or some such. The "name" should NOT be NULL
terminated since the "len" field already specifies the length of the
name. The "Name" in this suboption is simply a number of octets and
need not be ASCII text.
3.4 Suggested-Lease-Time 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Len (4) | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = length of the sub-option excluding the Subcode and Len fields
(always 4 for this suboption) (1 octet)
The Suggested-Lease-Time suboption MAY be included by the Server in
order to suggest the lease time to be used by the Client when
allocating addresses from the subnet allocated. The four (4) octet
value of the lease time is in the same format as that of the "IP
Address Lease Time" option (option 51), as described in [3].
If included, this suboption MUST appear only once. (Inclusion of
multiple such suboptions would result in ambiguity as to which
applied to which subnet.) If different suggested lease times are
needed, the Server SHOULD, instead, reply with only one offered
subnet and should set the "Server flag" in the Subnet-Information
suboption to indicate to the Client that it should send another
subnet request to gather the others.
The Client SHOULD use a lease time, when allocating addresses from
the subnet, which is the lesser of the remaining lease time of the
subnet itself and the Suggested-Lease-Time suboption.
Johnson, et al. Expires April 25, 2007 [Page 10]
Internet-Draft Subnet Allocation Option October 2006
4. Requesting allocation of a subnet
4.1 Client DHCPDISCOVER message
The DHCP Client creates a DHCPDISCOVER message including the Subnet
Allocation option, and its set of suboptions, to request allocation
of a subnet. The DHCP Client should include the Subnet-Request
suboption, specifying the prefix size of the subnet requested. The
"h" bit should be set to "1" if the Client intends to control
allocation of addresses within the subnet itself, or "0" if the
Server should retain control of addresses within the subnet. More
than one Subnet Allocation option may appear in a DHCPDISCOVER
message, however the client SHOULD limit the number of requests,
noting that the DHCP replies will need to include the Subnet-
Information suboption, which takes up more space than the Subnet-
Request suboption.
If more than one subnet is being requested, multiple Subnet-Request
suboptions MAY be included or multiple DHCPDISCOVER messages MAY be
sent instead. The prefix size field of each Subnet-Request suboption
MUST be either zero (0), or in the range of 1 to 30 inclusive.
The DHCP "IP address lease time" option (code 51) MAY be included in
the DHCPDISCOVER message to specify the lease time the Client is
requesting for the subnet. If not present, no suggested lease time
is given.
The DHCP "Client ID" option (code 61) MAY be included in the
DHCPDISCOVER message as it may be used by the Server in performing
the subnet allocation.
4.2 Server DHCPOFFER message
Upon receiving a DHCPDISCOVER containing the Subnet Allocation
option, the DHCP Server should respond with a DHCPOFFER message
including the Subnet-Information suboption in order to specify the
subnet(s) which it is willing to allocate to the Client in order to
fill the request(s).
The Server need not reserve the subnets which are being offered, but
SHOULD strive to not offer the same subnets to another DHCP Client
until a reasonable time period (implementation dependent) has passed.
(This is similar to normal DHCP address allocation.)
The Server MUST NOT include the Subnet-Request suboption in the
DHCPOFFER. The same information is already present in the Subnet
Information suboption(s) which SHOULD be included in the DHCPOFFER.
Johnson, et al. Expires April 25, 2007 [Page 11]
Internet-Draft Subnet Allocation Option October 2006
The Server SHOULD also include the IP address lease time option
(option 51) in the DHCPOFFER message. This gives the lease time for
all subnets given in all Subnet-Request suboptions contained in the
DHCPOFFER message. The Server MAY also include the Renewal and/or
Rebinding options in order to further control the "T1" and "T2" lease
timers of the client. There MUST be only one IP address lease time,
rebind, and/or renew option in the DHCPOFFER message.
The Server MAY set the "Server flag" ("s") to "1" to indicate that it
would like to allocate one or more additional subnet(s) to the
Client. This indicates that the Client should send another
DHCPDISCOVER message specifying a zero prefix size field, P, in order
to request the additional subnet allocation(s) information. This may
be necessary if the subnets are to be allocated with different lease
times, for example.
The "Client flag" ("c") MUST be set to zero (0) to indicate this is a
Server response to a client request for a new subnet allocation and
not a response to a request for information about already allocated
subnets.
The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0)
and the Client MUST ignore fields having to do with address
assignment if the packet contains a Subnet Allocation option. In
other words, a DHCP packet exchange can not provide subnet allocation
and address assignment simultaneously.
4.3 Client DHCPREQUEST message
When sending a DHCPREQUEST, the Client MUST NOT modify any fields of
all Subnet-Information suboptions received from the Server. However,
the Client MAY choose not to include some Subnet-Information
suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions
MUST NOT be included in the DHCPREQUEST message, only the Subnet-
Information suboption(s) should be included.
4.4 Server DHCPACK message
The DHCP Server, upon receipt of the Client's DHCPREQUEST message,
MAY refuse allocation of any subnets (for example, if they have been
allocated elsewhere in the meantime), however since the Server should
have set aside the subnets offered for a short period of time, and
since the Client should have requested the subnets within a short
period of time after receiving the offer(s) from the server(s), this
last minute rejection should be rare. The DHCP Server MUST NOT
change the subnet address(es) or prefix size(s), however it MAY
remove some Subnet-Information suboptions from the list.
Johnson, et al. Expires April 25, 2007 [Page 12]
Internet-Draft Subnet Allocation Option October 2006
The Server SHOULD include the IP address lease time option specifying
the lease period for all subnet(s) in the DHCPACK. All subnets
allocated in one DHCP message will have the same lease time and only
one IP address lease time option must appear in the DHCP message.
If the Server has internal information which states that the Client
should be allocated more subnets than were requested, the Server MAY
set the "s" bit in the last Subnet-Information suboption to indicate
that the Client needs to request more subnets (as described above).
The allocable unit is the tuple (subnet-address, prefix-size).
Multiple subnets may be allocated in one DHCPACK, however since there
can be only one Lease-time option, each subnet allocated is assigned
the same lease time. Each subnet lease tuple (subnet-address,
prefix-size) MAY be renewed or released individually.
Johnson, et al. Expires April 25, 2007 [Page 13]
Internet-Draft Subnet Allocation Option October 2006
5. Client renewal of subnet lease
5.1 Client RENEW DHCPREQUEST message
The Client MUST renew all subnets allocated with a lease time in much
the same manner as renewing an allocated IP address. Renewal timers
need not be set in exactly the same manner, however. If Renewal
and/or Rebinding options were included in the DHCPACK of the subnet
allocation, then these "T1" and "T2" timers should be used just as
they would be in the case of address allocation timers.
The DHCPREQUEST message MUST include a Subnet-Information suboption
for which the Client is seeking renewal of the lease. This Subnet-
Information suboption may optionally include subnet usage statistics,
as described above w.r.t. the Subnet-Information suboption format.
The subnet IP address field (Address) and subnet prefix field
(Prefix) MUST agree with the values as they were originally allocated
to the Client by the Server. In any of the statistics fields (High,
Current, Ususable), a value of all ones (0xffff) SHOULD be used if
the Client has no information to report for a statistic.
5.2 Server RENEW DHCPREQUEST response
The Server MAY respond to a subnet RENEW with either a DHCPACK or
DHCPNAK response. If a DHCPNAK response is given the Client MUST
immediately stop using the subnet(s) specified and, if possible,
notify all Clients with addresses allocated from this subnet that
their addresses are no longer valid. The Client MAY, of course, send
a DHCPDISCOVER message containing the Subnet Allocation option and
the Subnet-Request suboption in order to acquire another subnet for
use. In general, the Server should ask the Client to deprecate
subnets by using the "d" bit of the Subnet-Information suboption in a
DHCPACK message (see below).
If a DHCPACK response is given, the "Deprecate" ("d") bit of the
flags field in the Subnet-Information suboption may also be set.
This indicates the DHCP Client should "prepare to stop using this
subnet". If the Client is allocating IP addresses for other clients
from this subnet (e.g. via DHCP), the Client SHOULD immediately stop
allocating such addresses. Once all allocated addresses in the
subnet have been released, the Client SHOULD send a DHCPRELEASE
message, including the Subnet-Information suboption (with optional
usage statistics) in order to release the subnet(s) back to the
Server.
Johnson, et al. Expires April 25, 2007 [Page 14]
Internet-Draft Subnet Allocation Option October 2006
5.3 Client DHCPRELEASE message
The DHCP Client should send a DHCPRELEASE message in order to release
allocated subnet(s) back to the Server when it is finished using
them. This message MUST NOT include the Subnet-Request suboption,
but MUST include one or more Subnet-Information suboptions, and
optionally including usage statistics.
The Client MUST release the same subnet(s) of the same prefix size
(Prefix), as was originally allocated. The Client MAY release a
subset of the subnets which were allocated originally. In other
words, the allocable unit is the tuple (subnet address, prefix size).
Multiple subnets may be allocated in one DHCPACK, however each subnet
MAY be released individually.
5.4 Server DHCPFORCE message
The DHCP Server may issue a DHCPFORCE [8] message containing the
Subnet Allocation option and the Subnet-Information suboption. This
message effectively immediately times out the Client's lease(s) for
the allocated subnet(s). Upon receiving this message, the DHCP
Client MUST issue a DHCPREQUEST message to the DHCP Server in order
to renew the lease on the subnet mentioned. No other subnets
allocated to the Client are effected. As is the case with all DHCP
RENEW messages, the Client may include subnet usage information in
the Subnet-Information suboption in order to report subnet usage
statistics, or set the "Stat-len" field to zero (0) if no statistics
are to be reported.
If the Server responds to this DHCPREQUEST with a DHCPNAK message,
then the Client MUST immediately stop using the subnet(s) and, if
possible, notify all Clients with addresses allocated from this/these
subnet(s) that their addresses are no longer valid. The Client MAY,
of course, send a DHCPDISCOVER message containing the Subnet
Allocation option and the Subnet-Request suboption in order to
acquire another subnet for use.
Johnson, et al. Expires April 25, 2007 [Page 15]
Internet-Draft Subnet Allocation Option October 2006
6. Client requesting subnet allocation information
The DHCP Client may request from the DHCP Server a list of what
subnets are currently allocated to Client. This may be used to
recover from a restart if the Client does not have local storage in
order to retain the information itself.
6.1 Client DHCPDISCOVER message
The DHCP Client DHCPDISCOVER message, in order to discover already
allocated subnet information, should contain a Subnet-Request
suboption, with the "Prefix" field set to zero (0) and with the "i"
flag set to "1" to indicate that the Client is seeking already
allocated subnet information from the Server. No Subnet-Information
suboptions should be included in this message.
This DHCPDISCOVER message MAY be unicast to a particular DHCP Server,
or broadcast in the normal fashion.
6.2 Server DHCPOFFER response
Any DHCP Server which has allocated subnets to the Client should
respond to the DHCPDISCOVER message with a DHCPOFFER message The
DHCPOFFER message should contain one or more Subnet-Information
suboption(s) telling the subnet address(es) and prefix(es) of the
subnet(s) allocated to the Client.
The Server SHOULD, internally, retain an ordered list of subnets
which are allocated to each Client. The subnet(s) information
returned in the DHCPOFFER message are the first subnet(s) from this
list. If the end of the list has been reached, then the "s" bit of
the last Subnet-Information suboption included in the message hould
be set to "0". If there are more subnets in the list, the "s" bit
should be set to "1". to indicate to the Client that more information
is available. If this is the initial DHCPOFFER to the client, the
"c" flag should be set to "1".
6.3 Client additional DHCPDISCOVER messages
The Client, upon receiving any Server DHCPOFFER messages containing
Subnet Information suboption information with the "c" ("Client") bit
set, should gather the subnet address and prefix information from the
message.
If the "s" bit is set in the last of the Subnet-Information
suboptions included in the message, then the client SHOULD construct
a new DHCPDISCOVER message containing the Subnet Allocation option
and the last Subnet-Information suboption from the Server's message,
Johnson, et al. Expires April 25, 2007 [Page 16]
Internet-Draft Subnet Allocation Option October 2006
and send this message back to the same DHCP Server originating the
DHCPOFFER message. The "c" and "s" bits MUST retain the same
settings they had from the Server's DHCPOFFER message and the subnet
address ("A") and prefix size ("P") fields MUST be unaltered as well.
If the "s" bit in all of the Subnet-Information suboptions from the
Server was "0", then it indicates the Server has no more information
about subnets allocated to the Client.
6.4 Server additional DHCPOFFER messages
The Server, upon receiving a DHCPDISCOVER message from a Client
containing a Subnet Information suboption with the "c" and the "s"
bits set, MUST use the subnet address ("A") and prefix size ("P")
fields in order to locate the position in the internal table of
allocated subnets for this Client, and then return an DHCPOFFER
message containing a Subnet-Information suboption giving information
about the next set of subnets allocated to this Client. If this
finishes the list in the table for this Client, then the "s" bit MUST
be set to "0" to indicate there is no more information.
Johnson, et al. Expires April 25, 2007 [Page 17]
Internet-Draft Subnet Allocation Option October 2006
7. DHCP Server Subnet Allocation method
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.
Johnson, et al. Expires April 25, 2007 [Page 18]
Internet-Draft Subnet Allocation Option October 2006
8. Examples
Only the Subnet Allocation option and accompanying suboptions are
displayed in these examples. All other fields in the DHCP messages
are described in [2].
8.1 Example 1:
DHCP Client requesting a subnet with prefix size 24 from which the
Client will allocate addresses to other clients. The Server responds
with allocation of exactly the size requested:
Client sends DHCPDISCOVER including the Subnet Allocation option with
the Subnet-Request suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server responds with DHCPOFFER including Subnet Allocation option
with a Subnet-Information suboption, offering the subnet 10.0.1.0/24.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Client sends DHCPREQUEST including Subnet Allocation option with
Subnet-Information suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Server responds with DHCPACK including Subnet Allocation option with
Johnson, et al. Expires April 25, 2007 [Page 19]
Internet-Draft Subnet Allocation Option October 2006
Subnet-Information suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Later Client sends DHCPRELEASE including Subnet Allocation option
with Subnet-Information suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
8.2 Example 2:
DHCP Client requesting two subnets, each with prefix size 24:
Client sends DHCPDISCOVER including the Subnet Allocation option with
the Subnet-Request suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 9 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server responds with DHCPOFFER including Subnet Allocation option
with Subnet-Information suboption:
DHCPOFFER includes 1 subnet of size 24 and 1 subnet of size 28.
Johnson, et al. Expires April 25, 2007 [Page 20]
Internet-Draft Subnet Allocation Option October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 18 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 10 | 0 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 28 | |0|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client sends DHCPREQUEST including Subnet Allocation option with
Subnet-Information suboption:
Client decides that the subnet of size 28 is not sufficient so
doesn't include it into the DHCPREQUEST message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Server responds with DHCPACK including Subnet Allocation option with
Subnet-Information suboption:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Later Client sends DHCPREQUEST message in order to renew the lease on
the one subnet, including subnet usage information. It reports that
a maximum of 10 addresses were allocated from the subnet since the
last report, 7 addresses are currently allocated, and 2 addresses
were found to be unusable.
Johnson, et al. Expires April 25, 2007 [Page 21]
Internet-Draft Subnet Allocation Option October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 17 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 0 | 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server responds with DHCPACK, however signals Client that the subnet
should be deprecated.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Client reloads at this point and upon completion of the reload sends
a DHCPDISCOVER asking for information about all subnets which were
allocated to it.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |1|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server responds with a DHCPOFFER, giving the subnet information of
the one subnet which is allocated to the Client. Also the Server
specifies that the one allocated subnet should be immediately
deprecated. Note that the "s" ("Server") bit is zero (0) thus
indicating that there is no more information available for this
Client.
Johnson, et al. Expires April 25, 2007 [Page 22]
Internet-Draft Subnet Allocation Option October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |1|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Client responds with DHCPRELEASE message after having deprecated the
subnet:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | SIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Johnson, et al. Expires April 25, 2007 [Page 23]
Internet-Draft Subnet Allocation Option October 2006
9. Differences with DHCPv6 Prefix Delegation
The following differences may be noticed between Subnet Allocation as
described in this document and DHCPv6 Prefix Delegation as described
in [5]:
o This option does not use anything like an "IA_PD" as is used in
DHCPv6.
o If the Server can not allocate a subnet, it remains silent,
instead of returning a special response saying nothing is
available.
o DHCPv6 Prefix Delegation has no mechanism for returning subnet/
prefix usage statistics.
o DHCPv6 has no equivalent to the "subnet deprecation" flag as
described here.
o DHCPv6 Prefix Delegation makes no mention of what Client actions
should result from receiving a DHCPNAK during a RENEW of a
delegation.
o DHCPv6 has no equivalent of the subnet allocation "Network name"
suboption, which may be used by the Server for various purposes,
such as to specify a pool to use when allocating a subnet.
o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet
Allocation" (setting the "h" flag in the Prefix Information
suboption). There is no V6 equivalent of clearing the "h" flag,
in which the Server retains authority over allocation of addresses
from the subnet.
o DHCPv6 Prefix Delegation has nothing to correspond to the
Suggested-Lease-Time suboption.
Johnson, et al. Expires April 25, 2007 [Page 24]
Internet-Draft Subnet Allocation Option October 2006
10. Security Considerations
Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification [2]. The Subnet Allocation option can be used
to hoard all allocable subnets on a network.
It is suggested that DHCP Authentication be used with this option.
Message authentication in DHCP for intradomain use where the out-of-
band exchange of a shared secret is feasible is defined in RFC 3118
[4]. Potential exposures to attack are discussed in section 7 of the
DHCP protocol specification in RFC 2131 [2].
Johnson, et al. Expires April 25, 2007 [Page 25]
Internet-Draft Subnet Allocation Option October 2006
11. IANA Considerations
This option is in current usage with the number 220. As per RFC-
3942, this already existing number assignment should simply be made
"official" by IANA, unless there is a conflict with some other usage.
No assignment of values for the suboption codes need be made at this
time. New values may only be defined by IETF Consensus, as described
in [5]. Basically, this means that they are defined by RFCs approved
by the IESG.
Johnson, et al. Expires April 25, 2007 [Page 26]
Internet-Draft Subnet Allocation Option October 2006
12. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
13. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] Droms, R., "Authentication for DHCP Messages", RFC 3118,
June 2001.
[5] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
RFC 3633, February 2003.
[6] Pummill, T. and B. Manning, "Variable Length Subnet Table For
IPv4", RFC 1878, December 1995.
[7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options", RFC 3942, November 2004.
[8] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure
extension", RFC 3203, December 2001.
Authors' Addresses
Richard A. Johnson
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Phone: +1 408 526 4000
Email: raj@cisco.com
Johnson, et al. Expires April 25, 2007 [Page 27]
Internet-Draft Subnet Allocation Option October 2006
Jay Kumarasamy
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Phone: +1 408 526 4000
Email: jayk@cisco.com
Kim Kinnear
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Phone: +1 408 526 4000
Email: kkinnear@cisco.com
Mark Stapp
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
US
Phone: +1 408 526 4000
Email: mjs@cisco.com
Johnson, et al. Expires April 25, 2007 [Page 28]
Internet-Draft Subnet Allocation Option October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Johnson, et al. Expires April 25, 2007 [Page 29]
