RFC 6656
Description of Cisco Systems' Subnet Allocation Option for DHCPv4
Description of Cisco Systems' Subnet Allocation Option for DHCPv4 🎀
- RFC: 6656
- Authors: R. Johnson, K. Kinnear, and M. Stapp, all from Cisco Systems, Inc. 💅
- Category: Informational
- ISSN: 2070-1721
- Date: July 2012
- Obsoletes / Updates: none listed in the header, so this one doesn't replace or change anything else 🦋
Internet Engineering Task Force (IETF) R. Johnson
Request for Comments: 6656 K. Kinnear
Category: Informational M. Stapp
ISSN: 2070-1721 Cisco Systems, Inc.
July 2012Abstract ✨
Okay so this memo writes down a DHCPv4 option that already exists 🦋 It was privately defined before, and now it's getting documented as the Cisco Systems' Subnet Allocation Option for DHCPv4. The DHCPv4 Client and DHCPv4 Server pass it back and forth to request dynamic allocation of a subnet, describe the subnet(s) that got allocated, and report usage statistics. This memo documents the current usage in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented, and that the working group will try to officially assign those numbers to those options.
Status of This Memo 📜
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6656.
Copyright Notice 🔒
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 Block Format . . . . . . . . 8
3.3. Subnet-Name Suboption Format . . . . . . . . . . . . . . . 9
3.4. Suggested-Lease-Time Suboption Format . . . . . . . . . . 10
4. Requesting Allocation of a Subnet . . . . . . . . . . . . . . 10
4.1. Client DHCPDISCOVER Message . . . . . . . . . . . . . . . 11
4.2. Server DHCPOFFER Message . . . . . . . . . . . . . . . . . 11
4.3. Client DHCPREQUEST Message . . . . . . . . . . . . . . . . 12
4.4. Server DHCPACK Message . . . . . . . . . . . . . . . . . . 13
5. Client Renewal of Subnet Lease . . . . . . . . . . . . . . . . 13
5.1. Client RENEW DHCPREQUEST Message . . . . . . . . . . . . . 13
5.2. Server RENEW DHCPREQUEST Response . . . . . . . . . . . . 14
5.3. Client DHCPRELEASE Message . . . . . . . . . . . . . . . . 14
5.4. Server DHCPFORCERENEW Message . . . . . . . . . . . . . . 15
6. Client Requesting Previously Allocated Subnet Information . . 15
6.1. Initial Client DHCPDISCOVER Message . . . . . . . . . . . 15
6.2. Initial Server DHCPOFFER Response . . . . . . . . . . . . 16
6.3. Additional Client DHCPDISCOVER Messages . . . . . . . . . 16
6.4. Additional Server DHCPOFFER Responses . . . . . . . . . . 16
7. DHCP Server Subnet Allocation Method . . . . . . . . . . . . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Differences from DHCPv6 Prefix Delegation . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 231. Introduction 🧚
Okay so this memo is all about a DHCP option [RFC2132] called the Subnet Allocation option, which Cisco built 💖 It lets a DHCP Client allocate a subnet using information from a DHCP Server. It uses DHCP option number 220, which is one of the option numbers reclassified by [RFC3942]. That RFC says 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 is that documentation 🫶
The DHC WG had no input into any of the details of how this protocol operates, and it makes no statement about the correctness or any other aspect of the protocol 💀 The WG has also seen no interest in further implementation or deployment of this protocol other than privately, so they decided to publish this document solely for informational purposes.
The Subnet Allocation option gives you a straightforward way to allocate a subnet from DHCP. It's useful for a simple Dial-in Aggregation box, or for building a Hierarchical chain of DHCP Servers, where each one in turn leases one or more subnets to the next DHCP Server down the chain 🌸 This option is specified so that it uses one DHCP option number, while using suboption numbers for each function.
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 [RFC2119].
Also, here are a few terms you'll see around 🌈
- DHCP Client: DHCP Client (or just "Client") is an Internet host using DHCP to obtain configuration parameters such as a network address. 💜
- DHCP Server: A DHCP Server (or just "Server") is an Internet host that returns configuration parameters to DHCP Clients. ✨
3. Subnet Allocation Option Format 🍓
Here's the layout of the option. Look at those bits lining up, it's literally so pretty 😭
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-And here's what each field means:
Code = Subnet Allocation option code (1 octet): 220
Len = Length of the entire option including all suboptions
(1 octet)
Flags = Various flags: (None currently defined)One or more suboptions may be specified as described below. 🦋
Okay that's part 1 done 💅 More coming up, so keep scrolling bestie 🧚
3.1. Subnet-Request Suboption Format ✨
okay bestie, this is the request suboption 🎀 The client uses it to ask for subnets. Here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Lenis the length of the suboption. It's always 2 here. (1 octet) 🧚Flagsis the flags field. All unused bits must be zero. 💅his the Hierarchical flag. If it's 1, the client will be allocating addresses from this subnet. If it's 0, the client will be relaying DHCP requests to the Server from this subnet.iis the Information flag. If it's 1, the client is seeking info about subnets that were already allocated. If it's 0, the client is seeking a brand new subnet allocation.
Prefixis the network prefix length being requested. 0 means no suggested length is given. (1 octet) 🌸
The DHCP Server SHOULD NOT include the Subnet Request suboption in any replies to the DHCP Client. The Subnet-Information suboption already has enough info in it, so the Client doesn't need the Subnet Request suboption echoed back in replies. 🙈
The DHCP Server SHOULD allocate a subnet with a prefix length [RFC4632] less than or equal to the "Prefix" field length in the request. So it's a subnet with at least as many addresses as the requested prefix length suggests, and possibly more. ✨ The DHCP Server MAY allocate a subnet with a longer prefix length than requested (meaning fewer addresses than asked for), but that's not encouraged. 🫶
A DHCP Client MAY send a "Prefix" field size of 0. In that case, no suggested prefix length is given. 🍓
Multiple Subnet-Request suboptions in one DHCP packet mean that multiple subnets are being requested. Multiple occurrences of this suboption MUST NOT be concatenated in the sense of [RFC3396]. Literally don't mash them together, bestie. 🔥
Each Subnet-Request suboption MUST result in no more than one Subnet-Information suboption in the DHCPOFFER message from the Server. It may also result in no Subnet-Information suboptions at all. 🦋
The Client MAY also include the Subnet-Information suboption to request a particular subnet. In that case, the Client SHOULD only include one Subnet-Request suboption, because otherwise it would be unclear which Subnet-Information suboption matched which Subnet-Request suboption. 🧠 If you want multiple subnets, send multiple DHCPDISCOVER packets instead. 👑
Setting the 'h' flag to 1 means the Client will be allocating addresses from the allocated subnet(s) itself. You could call this "Hierarchical DHCP", because control over allocation for those subnets is handed over to the Client. 🌈
Setting the 'h' flag to 0 means the Client wants the DHCP Server to keep control over address allocation from the subnet(s). Any address allocation requests on that subnet get relayed back to the DHCP Server. 💜
Setting the 'i' flag to 1 means the Client is NOT seeking allocation of any subnets. It's just asking the Server what subnet(s) have been allocated (or reserved) for this Client. 🙃 If the 'i' flag is set to 1, the "Prefix" field SHOULD be set to 0 and MUST be ignored by the Server. In that case, the conversation only goes as far as the DHCPOFFER packet from the Server, which carries the information described in Section 6 below. 🎀
Any undefined flags (anything other than 'i' and 'h') should be ignored by the DHCP Server. 💅
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 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Len | Flags :c:s| SP1, SP2, ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Okay so this is the info suboption, and it's the one that carries the actual subnet details. 🍰
Lenis the length of the suboption. The minimum length is 8. (1 octet) 🧚Flagsare the various flags that apply to ALL Subnet Prefix Information fields in this suboption. Unused flags must be zero. 💅cis the Client flag. If it's 1, this info is in response to a Client request (or it was echoed back by the Client when asking for the next previously allocated subnet from the Server). If it's 0, it's something else.sis the Server flag. If it's 1, the Server has more subnet info for this Client. If it's 0, it doesn't.
SP1, SP2, ...are the Subnet Prefix Information blocks, described below. They're variable size. 🦋
Setting the 'c' flag to 1 means this Subnet-Information suboption is answering a Client's request for info about which subnet(s) have been allocated. It's used in response to a Subnet-Request suboption with the 'i' flag set, and it should be 0 in other Server responses. Also, the Client echoes this flag back to the Server when it asks for the "next previously allocated subnet". Another way to think about the 'c' bit: it tells you the subnet info here isn't a new allocation from the Server and isn't a new allocation request from the Client. It's just previously allocated subnet info. 🫧
Setting the 's' flag to 1 means the Server has additional subnet info for the Client. 💌
Any undefined flags (anything other than 'c' and 's') should be ignored by the DHCP Server. 🙈
The DHCP Server uses the Subnet-Information suboption to return info about which subnets are offered (in a DHCPOFFER packet) or allocated (in a DHCPACK packet). As mentioned above, one Subnet-Information suboption can return multiple subnets. 👑
The DHCP Client also uses the Subnet-Information suboption to request specific subnets in a DHCPREQUEST packet. In that case, the "Network", "Prefix", and "Flags" fields in the associated Subnet Prefix Information blocks MUST NOT be changed from what the Client received in the DHCPOFFER packet from the Server. No freelancing, bestie. 🚫 The Client MAY, however, use multiple Subnet-Information suboptions to request subnets that the Server originally put inside one Subnet-Information suboption. 🌈
3.2.1. Subnet Prefix Information Block 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Flags :h:d| Stat-len | Optional stats...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Networkis the IPv4 network number. (4 octets) 🌐Prefixis the prefix length. (1 octet) 🍓Flagsis the flags field. Undefined bits must be zero. (1 octet) 💅dis the Deprecate flag. If it's 1, deprecation of this subnet is requested. If it's 0, no deprecation is needed.his the Hierarchical flag. If it's 1, the Client will be allocating addresses from this subnet. If it's 0, the Client will be relaying DHCP requests to the Server from this subnet.
Stat-lenis the length of the optional statistics info field. It's zero if no statistics are included. (1 octet) 📊
The 'd' flag may only be returned by the Server to the Client (inside a DHCPACK packet, in response to a DHCP RENEW). Seeing it means the Client should get ready to give up the subnet. For example, if the Client is handing out addresses from this subnet to other Clients, it should stop right away and shouldn't renew any leases when those Clients ask for renewal. 🥺 Once every address in the subnet is unallocated, the Client should send a DHCPRELEASE message to the Server, including a Subnet Prefix Information block for the subnet so the subnet gets released. That message's format is described farther below. 🫶
The 'h' flag tells the Client how the Server wants the Client to use the allocated subnet. It's read the same way as the 'h' flag in the Subnet-Request suboption. When answering a Subnet-Request, the Server should normally set the 'h' flag the same way it was set in the Subnet-Request suboption from the Client. The Server MAY, however, change the 'h' flag from what the Subnet-Request suboption said, if it's been configured to override the Client's request. 🔮
Any undefined flags (anything other than 'd' and 'h') should be ignored by the DHCP Server. 💜
If any usage statistics info is included, the "Stat-len" field says how many bytes of statistics info come with it. More on that below. If no statistics info is included, this byte MUST be zero. The "Stat-len" field SHOULD always be zero when the DHCP Server sends this suboption. The usage statistics are only meant for reporting usage from the Client to the Server. 📈
3.2.1.1. Subnet Usage Statistics 📊
The Subnet-Information suboption may also include usage statistics. If it does, the "Stat-len" (Statistics length) field MUST be set to the number of bytes of statistics info being included. The statistics info 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| High water |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Currently in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unusable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- "High water" is the "high-water mark" of allocated addresses within the subnet. In other words, it's the largest number of addresses that were ever allocated at one time from the subnet. 🏔️
- "Currently in use" is the number of addresses currently allocated in the subnet. 🏠
- "Unusable" is the number of addresses that are currently unusable for any reason. For example, a Client sent a DHCPDECLINE, or found the address was already in use. 🙅♀️
More stats 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. To skip reporting a number for a particular field, use the all ones value (0xffff). 🙈 You can also include fewer fields than listed above. For example, if "Stat-len" is "4", the "Unusable" field hasn't been included. Any fields that are included MUST remain in the order specified here. 💖
3.3. Subnet-Name Suboption Format 🎀
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 suboption (min. length of 1) (1 octet)
okay so the Subnet-Name suboption lets you pass a subnet name over to the Server so it can use it during allocation ✨ The name can be used for any purpose, but it's meant to tell the Server something extra about the subnet you need. Think "sales department", "customer 1002", "address pool FOO", or some such 💖 The "name" should NOT be NULL terminated, because the "len" field already tells everyone how long it is. And the "Name" in this suboption MUST be given using UTF-8 [RFC3629]. No cap, UTF-8 is the only move here 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Len (4) | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Len = length of the suboption (always 4 for this suboption) (1 octet)
The Server MAY include the Suggested-Lease-Time suboption to suggest a lease time for the Client to use when it allocates addresses from the subnet it was given 🌸 The 4-octet value is in the same format as the "IP Address Lease Time" option (option 51), as described in [RFC2132].
If it's included, this suboption MUST appear only once! Multiple copies would be chaos, because nobody could tell which lease time belongs 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. That tells the Client to send another subnet request to collect the rest 🔥
The Client SHOULD use a lease time, when it allocates addresses from the subnet, that is the lesser of the remaining lease time of the subnet itself and the Suggested-Lease-Time suboption ✨
4. Requesting Allocation of a Subnet 🌸
4.1. Client DHCPDISCOVER Message 💅
So the DHCP Client builds a DHCPDISCOVER message that includes the Subnet Allocation option and its suboptions, and that's how it asks for a subnet 🫶 The Client should include the Subnet-Request suboption, with the prefix length of the subnet it wants. The 'h' bit should be set to 1 if the Client plans to control address allocation within the subnet itself, or 0 if the Server should keep control of addresses in that subnet. More than one Subnet Allocation option may show up in a DHCPDISCOVER message, but the Client SHOULD limit how many requests it makes, since the DHCP replies will need the Subnet-Information suboption, which takes up more room 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 length field of each Subnet-Request suboption MUST be either 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 say what lease time the Client wants for the subnet. If it isn't there, no suggested lease time is given 🦋
The DHCP "Client ID" option (code 61) MAY be included in the DHCPDISCOVER message, since the Server may use it when it does 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. That message includes the Subnet-Information suboption to list the subnet(s) it's willing to allocate to the Client to fulfil the request(s) 💖
The Server need not reserve the subnets it's offering, 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 🌈)
The Server MUST NOT include the Subnet-Request suboption in the DHCPOFFER. The same information is already in the Subnet Information suboption(s), which SHOULD be included in the DHCPOFFER 🙈
The Server SHOULD also include the IP address lease time option (option 51) in the DHCPOFFER message. This sets 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 to further control the Client's "T1" and "T2" lease timers. There MUST be exactly one IP address lease time (and optionally one Rebinding and/or one Renewal option) in the DHCPOFFER message. Very particular, very iconic 👑
The Server MAY set the "Server flag" ('s') to 1 to say it would like to allocate one or more additional subnet(s) to the Client. This tells the Client to send another DHCPDISCOVER message with a prefix length field, P, of zero, so it can request the information about the additional subnet allocation(s). This might be needed if the subnets are going to have different lease times, for example 🔥
The "Client flag" ('c') MUST be set to 0 to show that this is the Server answering a Client's request for a new subnet allocation, and not a reply to a request about subnets that are already allocated 💅
If the packet contains a Subnet Allocation option, the Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0), and the Client MUST ignore fields that have to do with address assignment. In other words, a DHCP packet exchange cannot provide subnet allocation and address assignment at the same time 😭
4.3. Client DHCPREQUEST Message 🫶
When sending a DHCPREQUEST, the Client MUST NOT modify any fields of any Subnet-Information suboptions it got from the Server. That said, the Client MAY choose not to include some Subnet-Information suboptions when it sends 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 🦋
When the DHCP Server gets the Client's DHCPREQUEST, it MAY refuse to allocate any subnets (for example, if they were given to someone else in the meantime). But here's the tea: the Server should have held the offered subnets for a short time, and the Client should have asked for them shortly after getting the offer(s). So a last-minute rejection should be rare 🌸 The DHCP Server MUST NOT change the network number(s) or prefix length(s). It MAY, however, remove some Subnet-Information suboptions from the list 💜
The Server SHOULD include the IP address lease time option in the DHCPACK, specifying the lease period for all subnet(s). 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 saying the Client should be allocated more subnets than were requested, the Server MAY set the 's' bit in the last Subnet-Information suboption. That tells the Client it needs to request more subnets (as described above) 🔥
The allocable unit is the tuple (network number, prefix length). Multiple subnets may be allocated in one DHCPACK, but since there can be only one Lease-time option, each subnet allocated gets the same lease time. Each subnet lease tuple (network number, prefix length) MAY be renewed or released individually 🧚
5. Client Renewal of Subnet Lease 🌈
5.1. Client RENEW DHCPREQUEST Message 👑
The Client MUST renew all subnets that were allocated with a lease time, in much the same way it renews an allocated IP address 💖 Renewal timers don't have to be set in exactly the same way, though. If Renewal and/or Rebinding options were included in the DHCPACK for the subnet allocation, then these "T1" and "T2" timers should be used just like they would be for address allocation timers ✨
The DHCPREQUEST message MUST include a Subnet-Information suboption for the lease the Client wants to renew. This Subnet-Information suboption may optionally include subnet usage statistics, as described above in Section 3.2 ("Subnet-Information Suboption Format") 🦋
The subnet network number field ("Network") and subnet prefix length field ("Prefix") MUST agree with the values the Server originally allocated to the Client. In any of the statistics fields (High water, Currently in use, Unusable), a value of all ones (0xffff) SHOULD be used if the Client has no information to report for that statistic 🙈
5.2. Server RENEW DHCPREQUEST Response 🍓
The Server MAY respond to a subnet RENEW with either a DHCPACK or a DHCPNAK. If it's a DHCPNAK, the Client MUST immediately stop using the subnet(s) specified. If it's possible, the Client should also 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 to get another subnet to 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 tells the DHCP Client to get ready 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 those 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), to release the subnet(s) back to the Server 🫶
5.3. Client DHCPRELEASE Message 🧚
When the Client is finished with its allocated subnet(s), it SHOULD send a DHCPRELEASE message to give them back to the Server ✨ This message MUST NOT include the Subnet-Request suboption, but MUST include one or more Subnet-Information suboptions, and may optionally include usage statistics 💜
The Client MUST release the same subnet(s) of the same prefix length ("Prefix") that were originally allocated. The Client MAY release only a subset of the subnets that were originally allocated. In other words, the allocable unit is the tuple (network number, prefix length). Multiple subnets may be allocated in one DHCPACK, but each subnet MAY be released individually 🌈
5.4. Server DHCPFORCERENEW Message 💌
okay bestie, so the DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message 📬 that carries the Subnet Allocation option and the Subnet-Information suboption. When the Client gets this, it MUST issue a DHCPREQUEST message to the Server so it can renew the lease on that subnet 🔄. Nothing else allocated to the Client gets touched, only the one subnet mentioned 🫶. Same as every DHCP RENEW message, the Client may include subnet usage info in the Subnet-Information suboption to report subnet usage statistics, or it can set the Stat-len field to 0 if there are no stats to share 📊.
If the Server answers this DHCPREQUEST with a DHCPNAK message 💀, 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 to acquire another subnet for use ✨.
6. Client Requesting Previously Allocated Subnet Information 🧚
A DHCP Client MAY request from the DHCP Server a list of what subnets are currently allocated to the Client 🗂️. This is super handy for recovering from a restart if the Client doesn't have local storage to hold the info itself 💾. (For an example of this, see Section 8.2 below 👀.)
6.1. Initial Client DHCPDISCOVER Message
When the DHCPDISCOVER message is being used to find already allocated subnet information, it SHOULD contain a Subnet-Request suboption with the Prefix field set to 0 and the 'i' flag set to 1 🚩. That tells the Server the Client is hunting for allocated subnet info. No Subnet-Information suboptions should be included in this message 🙅♀️. Why? Because the Client wouldn't know of any subnet to request at that point 🤷♀️.
This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, or broadcast in the normal fashion 📡.
6.2. Initial Server DHCPOFFER Response
Any DHCP Server that 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 🌸.
The Server SHOULD, internally, retain an ordered list of subnets that are allocated to each Client 📝. When an initial DHCPDISCOVER message asks for allocated subnet information (that's one with the 'i' flag set to 1 but no Subnet-Information suboption), the Server returns the subnet information for the first subnet(s) from this list in the DHCPOFFER message 🥇. 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 tell the Client more info is available ➡️. Since this info is answering a Client request for previously allocated subnet information, the 'c' bit MUST be set to 1 🫶.
6.3. Additional Client DHCPDISCOVER Messages
When the Client gets any Server DHCPOFFER messages with Subnet Information suboption info that has the 'c' ("Client") bit set, it SHOULD gather the network number ("Network") and prefix length ("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 that last Subnet-Information suboption from the Server's message 🔁. This message SHOULD then be sent back to the same DHCP Server that sent 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 🔒.
If the 's' bit in all of the Subnet-Information suboptions from the Server was 0, then it means the Server has no more info about subnets allocated to the Client 🏁.
6.4. Additional Server DHCPOFFER Responses
When the Server gets an additional DHCPDISCOVER message from a Client asking for allocated subnet info retrieval, with the 'i' flag set to 1 and containing one or more Subnet Information suboptions with the 'c' and the 's' bits set, the Server MUST use the network number ("Network") and prefix length ("Prefix") fields from the last such Subnet Information suboption 🕵️♀️. This is how it finds the spot in its internal table of allocated subnets for this Client 📍. Then the Server MUST return a DHCPOFFER message containing a Subnet-Information suboption with info about the next set of subnets allocated to this Client 🎁. If that finishes the list in the table for this Client, then the 's' bit MUST be set to 0 to say there's no more info 🛑. Any Subnet Information suboptions encountered without both the 'c' and 's' bits set should be ignored by the Server 🙃.
7. DHCP Server Subnet Allocation Method 🛠️
The actual method of allocating subnets on the DHCP Server is up to the implementation 🤓. So is the configuration of what networks may be subnetted and how 🌈.
8. Examples 🎀
Only the Subnet Allocation option and accompanying suboptions are shown in these examples 👀. All other fields in the DHCP messages are described in [RFC2131] 📖.
8.1. Example 1
Okay, here's the scenario 🦋: a DHCP Client requests a subnet with prefix length 24, and it'll allocate addresses to other Clients from that subnet. The Server responds with an allocation of exactly the size requested 💖.
The Client sends a DHCPDISCOVER message including a Subnet Allocation option with the Subnet-Request suboption 📨:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 🎁:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+The Client sends a DHCPREQUEST including a Subnet Allocation option with a Subnet-Information suboption 🙌:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+The Server responds with a DHCPACK message including a Subnet Allocation option with a Subnet-Information suboption 🥳:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+Later, the Client sends a DHCPRELEASE message including a Subnet Allocation option with a Subnet-Information suboption 👋:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+8.2. Example 2 💖
okay so this one is a client asking for two subnets, and both have prefix length 24 🎀 it's giving main character energy, fr fr
The Client sends a DHCPDISCOVER message with a Subnet Allocation option that carries a Subnet-Request suboption ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 9 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |0|0| 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Server replies with a DHCPOFFER that has a Subnet Allocation option with a Subnet-Information suboption 🦋 this offer gives one subnet of size 24 and one subnet of size 28.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 18 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 10 | 0 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 28 | |0|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Client sends a DHCPREQUEST with a Subnet Allocation option and a Subnet-Information suboption 🙈 the size 28 subnet is not enough for it, so it leaves that one out of the DHCPREQUEST message. bye bye size 28 💅
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Server responds with a DHCPACK that has a Subnet Allocation option with a Subnet-Information suboption 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+Later on, the Client sends a DHCPREQUEST to renew the lease on that one subnet, and it includes subnet usage info 📊 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. that's a lot of tea ☕
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 17 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 0 | 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Server responds with a DHCPACK, but it tells the Client that the subnet should be deprecated 🚫
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+Then the Client reloads 🔄 and once the reload is done, it sends a DHCPDISCOVER asking for info about every subnet that was allocated to it 🧚
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 5 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |1|0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Server responds with a DHCPOFFER giving the subnet info for the one subnet that is allocated to the Client. The Server also says that this one allocated subnet should be deprecated right away ⚡ Note that the 's' ("Server") bit is 0, which tells the Client that there is no more information available for this Client 🫶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |1|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+After deprecating the subnet, the Client responds with a DHCPRELEASE 👋
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 220 | 11 | 0 | SIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | |0|0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 24 | |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+9. Differences from DHCPv6 Prefix Delegation 🌈
okay bestie, this section is the "how is this different from DHCPv6 prefix delegation" tea ☕ the spec lists these differences, which you might spot while comparing the two [RFC3633]:
- This option does not use anything like an "IA_PD" as is used in DHCPv6.
- If the Server cannot allocate a subnet, it remains silent, instead of returning a special response saying nothing is available.
- DHCPv6 Prefix Delegation has no mechanism for returning subnet/prefix usage statistics.
- DHCPv6 has no equivalent to the "subnet deprecation" flag as described here.
- DHCPv6 Prefix Delegation makes no mention of what Client actions should result from receiving a DHCPNAK during a RENEW of a delegation.
- 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.
- DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet Allocation" (setting the 'h' flag in the Prefix Information block). There is no v6 equivalent of clearing the 'h' flag, in which the Server retains authority over allocation of addresses from the subnet.
- DHCPv6 Prefix Delegation has nothing to correspond to the Suggested-Lease-Time suboption.
10. Security Considerations 🔐
okay this part is serious, so read it carefully 🙈 potential exposures to attack are discussed in Section 7 of the DHCP protocol specification [RFC2131]. and the Subnet Allocation option can be used to hoard ALL the allocable subnets on a network. yikes, that's a whole-network power move 💀
Implementations should consider using the DHCP Authentication option [RFC3118] in order to provide a higher level of security if it is deemed necessary in their environment. so if your setup needs extra protection, add that auth option 🛡️
11. IANA Considerations 📚
IANA has assigned DHCP option number 220 for this option, in accordance with [RFC3942]. that's the number everyone uses 🎀
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 [RFC5226]. basically, this means they're defined by RFCs approved by the IESG ✨
12. References 🧾
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
Appendix A. Acknowledgments 🙌
The authors gratefully acknowledge the contributions of Jay Kumarasamy. thank you Jay 🫶
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
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📦 where this page comes from
- ietf: rfc6656 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms