One document matched: draft-ietf-dhc-subnet-alloc-13.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-ietf-dhc-subnet-alloc-13.txt"
ipr='pre5378Trust200902'>
<front>
<title abbrev="Cisco Systems' DHCP Subnet Alloc Option">Description of
Cisco Systems' Subnet Allocation Option for DHCPv4</title>
<author fullname="Richard A. Johnson" initials="R.A." surname="Johnson">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone>+1 408 526 4000</phone>
<email>raj@cisco.com</email>
</address>
</author>
<author fullname="Jay Kumarasamy" initials="J." surname="Kumarasamy">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone>+1 408 526 4000</phone>
<email>jayk@cisco.com</email>
</address>
</author>
<author fullname="Kim Kinnear" initials="K." surname="Kinnear">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone>+1 408 526 4000</phone>
<email>kkinnear@cisco.com</email>
</address>
</author>
<author fullname="Mark Stapp" initials="M." surname="Stapp">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<phone>+1 408 526 4000</phone>
<email>mjs@cisco.com</email>
</address>
</author>
<date month="April" year="2012" />
<area>Internet</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo documents a currently existing and previously privately
defined DHCPv4 option, documenting the operation and usage of the Cisco
Systems Subnet Allocation Option for DHCPv4. The option is passed
between the DHCPv4 Client and the DHCPv4 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 <xref target="RFC3942"></xref>, 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This memo documents a DHCP option <xref target="RFC2132"></xref>, the
Subnet Allocation option, that was developed by Cisco and allows a DHCP
Client to allocate a subnet given information from a DHCP Server. This
protocol makes use of DHCP option number 220, one of the option numbers
reclassified by [RFC3942]. That RFC specifies in section 4, procedure 2,
"Vendors that currently use one or more of the reclassified options have
6 months following this RFC's publication date to notify the DHC WG and
IANA that they are using particular options numbers and agree to
document that usage in an RFC." This memo serves as that documentation.
The DHC WG has had no input into any of the details of the protocol
operation and makes no statement about the correctness or any other
aspect of the protocol. The WG also has seen no interest in further
implementation or deployment of this protocol other than privately, and
therefore has decided to publish this document solely for informational
purposes.</t>
<t>The Subnet Allocation option provides a straightforward way to
allocate a subnet from DHCP, useful for a simple Dialin Aggregation box,
or 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
option is specified in such a way as to use one DHCP Option number,
while using suboption numbers for each function.</t>
</section>
<section title="Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>This document also uses the following terms:</t>
<t><list style="hanging">
<t hangText="DHCP Client:">DHCP Client or "Client" is an Internet
host using DHCP to obtain configuration parameters such as a network
address.</t>
<t hangText="DHCP Server:">A DHCP Server or "Server" is an Internet
host that returns configuration parameters to DHCP Clients.</t>
</list></t>
</section>
<section title="Subnet Allocation Option format">
<figure>
<artwork><![CDATA[
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
(1 octet)
Flags = Various flags: (None currently defined)]]></artwork>
</figure>
<t>One or more sub-options may be specified as described below.</t>
<section title="Subnet-Request Suboption format">
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Len | Flags :i:h| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = Length of the suboption (always 2 for this suboption)
(1 octet)
Flags = Flags field. (all unused bits must be zero)
'h' = Hierarchical flag
1 : Client will be allocating addresses from this subnet.
0 : Client will be relaying DHCP requests to the Server
from this subnet.
'i' = Information flag
1 : Client is seeking information about previously
allocated subnets.
0 : Client is seeking a new subnet allocation.
Prefix = Network prefix length requested
(0 means no suggested length is given) (1 octet)]]></artwork>
</figure>
<t></t>
<t>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.</t>
<t>The DHCP Server SHOULD allocate a subnet with prefix length <xref
target="RFC4632"> </xref> less than or equal to the "Prefix" field
length specified in the request. In other words, a subnet containing a
number of addresses at least the size indicated by the prefix length
requested and possibly more. The DHCP Server MAY allocate a subnet
with a prefix length greater than that specified in the request
(subnet with a number of addresses less than requested), but this is
not encouraged.</t>
<t>A "Prefix" field size of 0 MAY be specified by the DHCP Client. In
this case, no suggested prefix length is given.</t>
<t>Multiple Subnet-Request suboptions in a DHCP packet indicate that
multiple subnets are being requested. Note that multiple occurrances
of this suboption MUST NOT be concatenated in the sense of <xref
target="RFC3396"></xref>.</t>
<t>Each Subnet-Request suboption MUST result in no more than one
Subnet-Information suboption in the DHCPOFFER message from the Server,
and may result in no Subnet-Information suboptions.</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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 "Prefix" field SHOULD be
set to 0 and MUST be ignored by the Server. In this case, the
conversation between the Client and the Server will only progress to
the DHCPOFFER packet from the Server, giving the information, as
described in section 6 below.</t>
<t>Any undefined flags (those other than 'i' and 'h', mentioned above)
should be ignored by the DHCP Server.</t>
</section>
<section title="Subnet-Information Suboption format">
<figure>
<artwork><![CDATA[
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 (min. length of 8) (1 octet)
Flags = Various flags which apply to ALL Subnet Prefix
Information fields specified in this suboption.
Unused flags must be zero.
'c' : Client flag (explained below)
1 : This information is in response to a client request
(or has been echoed back by the client, when asking
for the next previously allocated subnet from the
server)
0 : Otherwise
's' : Server flag (explained below)
1 : Server has additional subnet information for this
client
0 : Otherwise
SP1, SP2, ... Subnet Prefix information blocks as specified below
(variable sized)]]></artwork>
</figure>
<t>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 used in
response to a Subnet-Request suboption with the 'i' flag set and
should be 0 in other Server responses. Note, the flag is echoed back
from the Client to the Server when requesting the "next previously
allocated subnet". Another way to think of the 'c' bit would be that
it indicates that the subnet information contained in this suboption
does not represent a new allocation by the Server or a new request for
allocation by the Client, but instead represents previously allocated
subnet information.</t>
<t>The "Server flag" ('s') is set to 1 if the Server has additional
subnet information for the Client.</t>
<t>Any undefined flags (those other than 'c' and 's', mentioned above)
should be ignored by the DHCP Server.</t>
<t>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.</t>
<t>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 "Network", "Prefix", and "Flags" fields
contained in the associated Subnet Prefix Information blocks 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.</t>
<section title="Subnet Prefix Information block format">
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Flags |h|d| Stat-len | Optional stats...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network = IPv4 network number (4 octets)
Prefix = Prefix length (1 octet)
Flags = Flags field (Undefined bits must be zero) (1 octet)
'd' = Deprecate flag (explained below)
1 : Deprecation of this subnet is requested
0 : No deprecation is needed
'h' = Hierarchical flag (explained below)
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
(zero if no statistics are included)]]></artwork>
</figure>
<t>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 clients 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.</t>
<t>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 manner as 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.</t>
<t>Any undefined flags (those other than 'd' and 'h', mentioned
above) should be ignored by the DHCP Server.</t>
<t>If any usage statistics information is to be included, then the
"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.</t>
<section title="Subnet Usage Statistics">
<t>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:</t>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| High water |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Currently in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unusable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>"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.</t>
<t>"Currently in use" refers to the number of addresses currently
allocated in the subnet.</t>
<t>"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).</t>
<t>Additional statistics may be added to this option in the
future. If so, they MUST be appended immediately after the already
defined statistics fields. 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 above, for example the if
"Stat-len" is "4", then the "Unusable" field has not been
included. All fields which are included MUST remain in order
specifed here.</t>
</section>
</section>
</section>
<section title="Subnet-Name Suboption format">
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 3 | Len | Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Len">= length of the sub-option (min. length of 1) (1
octet)</t>
</list></t>
<t>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 MUST be given using UTF-8 <xref
target="RFC3629"></xref>.</t>
</section>
<section title="Suggested-Lease-Time Suboption format">
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Len (4) | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Len">= length of the sub-option (always 4 for this
suboption) (1 octet)</t>
</list></t>
<t>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 <xref
target="RFC2132"></xref>.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Requesting allocation of a subnet">
<section title="Client DHCPDISCOVER message">
<t>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 length 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.</t>
<t>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 length field of each Subnet-Request suboption
MUST be either 0, or in the range of 1 to 30 inclusive.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Server DHCPOFFER message">
<t>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
fulfill the request(s).</t>
<t>The Server need not reserve the subnets which are being offered,
but SHOULD 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.)</t>
<t>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.</t>
<t>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 each in the DHCPOFFER message.</t>
<t>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 length 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.</t>
<t>The "Client flag" ('c') MUST be set to 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.</t>
<t>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.</t>
</section>
<section title="Client DHCPREQUEST message">
<t>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.</t>
</section>
<section title="Server DHCPACK message">
<t>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 network number(s) or prefix length(s), however it MAY remove some
Subnet-Information suboptions from the list.</t>
<t>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.</t>
<t>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).</t>
<t>The allocable unit is the tuple (network number, prefix length).
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 (network number, prefix
length) MAY be renewed or released individually.</t>
</section>
</section>
<section title="Client renewal of subnet lease">
<section title="Client RENEW DHCPREQUEST message">
<t>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.</t>
<t>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 in the Subnet-Information suboption
format section (3.2).</t>
<t>The subnet network number field ("Network") and subnet prefix
length 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, Unusable), a value of all ones
(0xffff) SHOULD be used if the Client has no information to report for
a statistic.</t>
</section>
<section title="Server RENEW DHCPREQUEST response">
<t>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).</t>
<t>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.</t>
</section>
<section title="Client DHCPRELEASE message">
<t>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.</t>
<t>The Client MUST release the same subnet(s) of the same prefix
length ("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 (network number, prefix
length). Multiple subnets may be allocated in one DHCPACK, however
each subnet MAY be released individually.</t>
</section>
<section title="Server DHCPFORCERENEW message">
<t>The DHCP Server MAY issue a DHCPFORCERENEW <xref
target="RFC3203"></xref> message containing the Subnet Allocation
option and the Subnet-Information suboption. 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 0 if no statistics are to
be reported.</t>
<t>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.</t>
</section>
</section>
<section title="Client requesting previously allocated subnet information">
<t>A DHCP Client MAY request from the DHCP Server a list of what subnets
are currently allocated to the 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. (For example of this, see the section 8.2
below.)</t>
<section title="Client Initial DHCPDISCOVER Message">
<t>The DHCP Client DHCPDISCOVER message, when used to discover already
allocated subnet information, SHOULD contain a Subnet-Request
suboption with the "Prefix" field set to 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. Note, no Subnet-Information suboption is
included in this message, since the client would not know of any
subnet to request at this point.</t>
<t>This DHCPDISCOVER message MAY be unicast to a particular DHCP
Server, or broadcast in the normal fashion.</t>
</section>
<section title="Server Initial DHCPOFFER Response">
<t>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 prefix of the subnet(s) allocated to the
Client.</t>
<t>The Server SHOULD, internally, retain an ordered list of subnets
which are allocated to each Client. In response to an initial
DHCPDISCOVER message requesting allocated subnet information (i.e.,
one with the 'i' flag set to 1, but not carrying a Subnet-Information
suboption), the server returns in the DHCPOFFER message the subnet(s)
information for 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 MUST be set to 0. If there are more
subnets in the list, the 's' bit MUST be set to 1 to indicate to the
Client that more information is available. Since this information is
in response to a client request for previously allocated subnet
information, the 'c' bit MUST be set to 1.</t>
</section>
<section title="Client Additional DHCPDISCOVER Messages">
<t>The Client, upon receiving any Server DHCPOFFER messages containing
Subnet Information suboption information with the 'c' ("Client") bit
set, SHOULD gather the network number ("Network") and prefix length
("Prefix") information from the message.</t>
<t>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. This
message SHOULD then be sent 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 network
number ("Network") and prefix length ("Prefix") fields MUST be
unaltered as well.</t>
<t>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.</t>
</section>
<section title="Server Additional DHCPOFFER Responses">
<t>The Server, upon receiving from a Client an additional DHCPDISCOVER
message for allocated subnet information retrieval, with the 'i' flag
set to 1 and containing one or more Subnet Information suboptions with
the 'c' and the 's' bits set, MUST use the network number ("Network")
and prefix length ("Prefix") fields contained in the last such Subnet
Information suboption 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. Any Subnet
Information suboptions encountered without both the 'c' and 's' bits
set should be ignored by the Server.</t>
</section>
</section>
<section title="DHCP Server Subnet Allocation method">
<t>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.</t>
</section>
<section title="Examples">
<t>Only the Subnet Allocation option and accompanying suboptions are
displayed in these examples. All other fields in the DHCP messages are
described in <xref target="RFC2131"></xref>.</t>
<section title="Example 1:">
<t>A DHCP Client requesting a subnet with prefix length 24 from which
the Client will allocate addresses to other clients. The Server
responds with an allocation of exactly the size requested:</t>
<t>The Client sends a DHCPDISCOVER message including a Subnet
Allocation option with the Subnet-Request suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Server responds with a DHCPOFFER message including a Subnet
Allocation option with a Subnet-Information suboption, offering the
subnet 10.0.1.0/24.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Client sends a DHCPREQUEST including a Subnet Allocation option
with a Subnet-Information suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Server responds with a DHCPACK message including a Subnet
Allocation option with a Subnet-Information suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Later the Client sends a DHCPRELEASE message including a Subnet
Allocation option with a Subnet-Information suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Example 2:">
<t>A DHCP Client requesting two subnets, each with prefix length
24:</t>
<t>The Client sends a DHCPDISCOVER message including a Subnet
Allocation option with a Subnet-Request suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 9 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Server responds with a DHCPOFFER message including a Subnet
Allocation option with a Subnet-Information suboption:</t>
<t>The DHCPOFFER specifies 1 subnet of size 24 and 1 subnet of size
28.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 18 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 10 | 0 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 28 | |0|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Client sends a DHCPREQUEST message including a Subnet
Allocation option with a Subnet-Information suboption:</t>
<t>The Client decides that the subnet of size 28 is not sufficient so
it doesn't include that subnet into the DHCPREQUEST message.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Server responds with a DHCPACK message including a Subnet
Allocation option with a Subnet-Information suboption:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Later the Client sends a DHCPREQUEST message in order to renew the
lease on the one subnet and includes 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.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 17 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 0 | 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Server responds with a DHCPACK message, however it signals to
the Client that the subnet should be deprecated.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The 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.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |1|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The 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 0 thus indicating that
there is no more information available for this Client.</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |1|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Client responds with a DHCPRELEASE message after having
deprecated the subnet:</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | SIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
<section title="Differences from DHCPv6 Prefix Delegation">
<t>The following differences may be noticed between Subnet Allocation as
described in this document and DHCPv6 Prefix Delegation as described in
<xref target="RFC3633"></xref>:</t>
<t><list style="symbols">
<t>This option does not use anything like an "IA_PD" as is used in
DHCPv6.</t>
<t>If the Server can not allocate a subnet, it remains silent,
instead of returning a special response saying nothing is
available.</t>
<t>DHCPv6 Prefix Delegation has no mechanism for returning
subnet/prefix usage statistics.</t>
<t>DHCPv6 has no equivalent to the "subnet deprecation" flag as
described here.</t>
<t>DHCPv6 Prefix Delegation makes no mention of what Client actions
should result from receiving a DHCPNAK during a RENEW of a
delegation.</t>
<t>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.</t>
<t>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.</t>
<t>DHCPv6 Prefix Delegation has nothing to correspond to the
Suggested-Lease-Time suboption.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification <xref target="RFC2131"></xref>. The Subnet
Allocation option can be used to hoard all allocable subnets on a
network.</t>
<t>Implementations should consider using the DHCP Authentication option
<xref target="RFC3118"></xref> in order to provide a higher level of
security if it is deemed necessary in their environment. Potential
exposures to attack are discussed in section 7 of the DHCP protocol
specification in <xref target="RFC2131"></xref>.</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign DHCP option number 220 for this option,
in accordance with <xref target="RFC3942"></xref>.</t>
<t>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
<xref target="RFC5226"></xref>. Basically, this means that they are
defined by RFCs approved by the IESG.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4632.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:49:37 |