RFC 3011

RFC 3011: The IPv4 Subnet Selection Option for DHCP 🦋

Okay bestie, this is RFC 3011, The IPv4 Subnet Selection Option for DHCP 🎀. It was written by Glenn Waters of Nortel Networks, it's a Standards Track document, and it's dated November 2000. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of this Memo 📜

This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Copyright Notice ©️

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🍓

Okay so this memo introduces a brand new DHCP option 💅. Its whole job is picking which subnet an address gets allocated from. It overrides the DHCP server's usual way of choosing that subnet for a client, so it's kind of a big deal 👑.

Table of Contents 🧚

   1. Introduction..................................................1
   1.1. Motivational Example........................................2
   2. Subnet Selection Option Definition............................3
   3. Intellectual Property.........................................4
   4. IANA Considerations...........................................4
   5. Acknowledgements..............................................5
   6. Security Considerations.......................................5
   7. References....................................................5
   8. Editor's Addresses............................................6
   9. Full Copyright Statement......................................7

1. Introduction 🌸

Bestie, DHCP [RFC2131] is the thing that hands configuration info out to hosts on a TCP/IP network 🖥️. RFC 2132 [RFC2132] is where the DHCP option configuration info lives, the stuff that gets carried in DHCP packets going to and from the server and the client 📦. This document adds one new DHCP option, and that's the main event 🦋.

So here's how the server normally picks a subnet. It works out which subnet the request came from, and then it picks an address on that originating subnet, or on a subnet that sits on the same network segment as it ✨. The originating subnet can be figured out in two ways:

• Using the subnet address of the giaddr field in the DHCP packet header, or if the giaddr field is zero;
• Using the subnet address of the local interface on which the DHCP server received the packet.

This memo defines the subnet selection option 🎀. It lets the DHCP client name the subnet it wants an address from, and it beats the server's own methods for choosing the subnet 👑. Iconic behavior, honestly 💅.

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

1.1. Motivational Example 🦋

Let me give you a real example of when this option slaps 🔥. Picture a device, like a RAS device, that hands out addresses for its clients 💻. It gets those addresses through DHCP and then manages them among its clients 🫶.

Here's the setup. The device is plugged into a private "internal" network where the DHCP server lives 🏠. It's also plugged into one or more service providing "external" networks, which are the networks its clients are on 🌐. The internal network is not IP connected to the external networks. There's still connectivity inside the device, though, like through the backplane 🔌.

Now the tricky part 😭. The device is handing out addresses on the external networks, and there's no IP connectivity between internal and external. So DHCP requests can't come from the external networks, because packets can't route between them. That means the DHCP requests have to start on the internal network. The problem is the server will allocate addresses on the internal subnet, when what's actually needed is addresses on the external subnets 💀. This option is the fix for exactly that problem 🧚.

So the device sends its DHCP request on the internal subnet, but it also includes the subnet selection option. That option has the address of the external subnet where it needs the address ✨. The option tells the DHCP server to allocate from that requested subnet, instead of doing the normal thing and allocating from the subnet the request came from 🙌.

2. Subnet Selection Option Definition 🎀

The subnet selection option is a DHCP option 🍓. It carries a single IPv4 address, and that address is the address of a subnet 🌸. To get that value, you take any IPv4 address on the subnet and AND it with the subnet mask. The network and subnet bits stay as they are, and the remaining address bits get set to zero 🧮.

When the DHCP server is set up to respond to this option, it's allocating an address, and this option is present, the server MUST allocate the address on either:

• the subnet specified in the subnet selection option, or;
• a subnet on the same network segment as the subnet specified in the subnet selection option.

Here's the format of the option 👀:

        Code   Len        IPv4 Address
       +-----+-----+-----+-----+-----+-----+
       | 118 |  4  | A1  | A2  | A3  | A4  |
       +-----+-----+-----+-----+-----+-----+

Servers that are set up to support this option MUST return an identical copy of the option to any client that sends it 🔁. That's true whether or not the client asked for the option in a parameter request list 💖. On the client side, clients using this option MUST discard any DHCPOFFER or DHCPACK packets that don't contain this option 🗑️. Bestie, that's a hard rule 😤.

This option doesn't require the server to change anything about its operations or features, apart from picking the subnet to allocate from 🧠. For example, the way the server handles a DHCPDISCOVER for an unknown subnet should keep working exactly the same 🦋.

When this option is present and the server is set up to support it, the server MUST NOT offer an address that isn't on the requested subnet or network segment 🚫. Servers that don't understand this option will allocate an address using their normal algorithms, and they won't put this option in the DHCPOFFER or DHCPACK. In that case the client will discard the DHCPOFFER or DHCPACK 😭.

Then there are servers that understand the option but have been administratively configured to ignore it. These servers MUST ignore the option, use their normal algorithms to allocate an address, and MUST NOT return this option in the DHCPOFFER or DHCPACK 🙈. And yep, once again, the client will discard the DHCPOFFER or DHCPACK 💅.

Heads up, bestie 🚨: during an address renew, the DHCP server may send a DHCPACK directly to the allocated address. But packets from the DHCP server may not be routable to that address. So, in every packet that the DHCP client sends that contains the subnet selection option, the giaddr field in the BOOTP header MUST be set to an IPv4 address where the DHCP client will accept DHCP packets. An example is the address on the subnet connected to the internal network 🫶.

Last thing for this part 🌈. The IPv4 address that a DHCP server sends its reply to MUST be the same one it would choose when this option isn't present 🎯. Everything else works the way it normally does 🦋.

9. Full Copyright Statement ✨

Copyright (C) The Internet Society (2000). All Rights Reserved. 💅

okay so the copyright stuff is kinda boring but it matters, so bear with me 🫶 You're allowed to copy this document and hand it out to people, and you can make derivative works that comment on or explain it or help with implementing it. You can prepare, copy, publish, and distribute those, whole or in part, with no restriction of any kind, as long as the above copyright notice and this paragraph are included on all those copies and derivative works. 🎀

BUT the document itself may not be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then you have to follow the procedures for copyrights in the Internet Standards process) or when you're translating it into a language other than English. 🙈

The limited permissions above are perpetual, so they're forever 💜 and they won't be revoked by the Internet Society or its successors or assigns. Iconic, honestly. 👑

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💀

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸