RFC 5010

RFC 5010: DHCPv4 Relay Agent Flags Suboption 🎀

Okay bestie, this one is RFC 5010, and it's giving standards track 💅 It's titled "The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption," and it came out in September 2007. It was written by Kinnear, Normoyle, and Stapp (K. Kinnear, M. Normoyle, and M. Stapp), all from Cisco Systems, Inc., and it's part of the Network Working Group 🌸 Nothing in the header says it obsoletes or updates any other RFC, so it's a fresh little addition to the DHCPv4 family ✨

Status of This Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the official 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 🦋

Abstract ✨

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option. It lets the DHCP relay specify flags for the forwarded packet 🫶 One flag is defined, and it tells the server whether the DHCP relay received the packet as a unicast or a broadcast packet. The DHCP server can use this information to better serve clients, depending on whether their request was originally broadcast or unicast 🔥

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Requirements Terminology  . . . . . . . . . . . . . . . . . . . 2
3.  The Flags Suboption . . . . . . . . . . . . . . . . . . . . . . 3
4.  DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 3
5.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . . 4
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  9.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

1. Introduction 🎀

Okay so whenever a client's DHCP packet gets broadcast, a local DHCP relay processes the request and forwards it on to the DHCP server 👀 When it does this, the relay can be configured to use the DHCP relay agent information option to pass extra info along to the server, which the server may then use to tweak how it processes things. Once a lease has been granted though, future DHCP DHCPREQUEST/RENEWAL messages are unicast directly to the DHCP Server [RFC2131] [RFC2132] [RFC3046]. Main character energy 💅

Servers can also make subtle (and sometimes not so subtle) changes to their processing depending on how they got the message. Did it come as a unicast packet straight from the DHCP client? A broadcast packet from a client on a locally connected network? Or a unicast packet from a DHCP Relay Agent that forwarded a broadcast from a client on a network local to that relay? Each one can get a different response 🧚

Here's the tricky bit 😭 Sometimes DHCP Clients unicast their DHCPREQUEST/RENEW packets to the DHCP Relay Agent, and the relay forwards them on to the server. In those cases the DHCP server can't tell whether the client's packet was broadcast or unicast, so it might not be able to process the packet the way it would if it knew. For example, a server might be willing to NAK a client in the REBINDING state because the client's address doesn't match its location in the network, but it might not be willing to do that if the client is in the RENEWING state 💀

That's where this suboption comes in 🦋 It lets the DHCP relay specify flags for the forwarded packet. These flags describe DHCP client attributes that matter to the DHCP server but that only the local DHCP relay can detect. The server can then use what the relay tells it to improve its processing algorithms ✨

One flag is defined, and it indicates whether the DHCP relay received the packet via a unicast or broadcast packet. This lets the DHCP server know if a packet forwarded by a DHCP Relay Agent was broadcast or unicast to that relay 🫶

2. Requirements Terminology 🌈

Quick vocab check 🤓 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].

3. The Flags Suboption 🍓

The Flags suboption is an extensible suboption definition for several possible flags. The first flag defined is the unicast flag 🦋

Here's what the suboption looks like on the wire:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |    Length     |    Flags      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field means 💖

• Code: the suboption code, which is 10.
• Length: the suboption length, which is 1 octet.
• Flags: the Relay Agent flags for this forwarded packet.

The Flags field is laid out like this:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |U|    MBZ      |
                +-+-+-+-+-+-+-+-+

• U: the UNICAST flag. unicast = 1, broadcast = 0.
• MBZ: MUST BE ZERO (reserved for future use) 🔒

4. DHCP Relay Agent Behavior 🧚‍♀️

A DHCP relay agent that claims to conform to this specification MUST include this suboption in every Relay Agent Information Option [RFC3046] it adds to a forwarded DHCP request 🫶 This is how the DHCP server can tell apart a request forwarded by a relay that doesn't support the relay-agent-flags suboption from one forwarded by a relay that does support it and got the request in a broadcast packet ✨

Put another way: a DHCP relay agent that supports the relay-agent-flags suboption MUST always include it in every relay-agent-information-option it inserts into packets it forwards to the DHCP server, whether the packet it's forwarding came in as a broadcast or as a unicast. The reason is that the DHCP server will be dealing with relay agents that support the relay-agent-flags suboption and relay agents that don't, so it needs the flag every single time 💅

5. DHCP Server Behavior 👑

This option gives the DHCP server additional information. The DHCP server MAY use this information to make processing decisions about the DHCP Client's packet it's handling 🌸 For example, knowing whether a relay agent received a packet as a broadcast or unicast could be used when making the processing decisions needed to implement Load Balancing [RFC3074]. A load-balancing server may be willing to respond to a REBINDING client, but it can't figure out the client's state without this extra indication 🙈

The option length is one octet. If the DHCP server receives a relay-agent-flags suboption that is longer than one octet, it MUST evaluate the first octet 🔥

Note to implementors: when you specify the behavior of new flags bits in the future, you have to be super careful about compatibility with earlier implementations. If additional flags values get defined later, it won't always be possible to tell apart a relay agent that understands the new value and sets it to 'zero' from a relay agent that's just setting a bunch of unassigned bits to 'zero'. It would be a mistake to specify significant behavior changes based on 'zero' values of flags specified in the future 😭

That's the first half, babe 🦋 The rest of the doc (Security Considerations, IANA Considerations, Acknowledgements, References, and the authors and copyright bits) is coming up next 💜

Intellectual Property ✨

okay so this part is all about who owns what 💅 the IETF is like "we're not picking a side on whether any patents or rights apply to the tech in this doc, and we haven't gone hunting for them either" 🙈 like, not our problem bestie 💁‍♀️ if you want the rules on rights in RFC docs, they live in BCP 78 and BCP 79 📚

if you're an implementer or user who wants to know about IPR disclosures that were sent to the IETF Secretariat, or any promises to license stuff, or what happened when someone tried to get a general license or permission to use proprietary rights for this spec, check the IETF online IPR repository at http://www.ietf.org/ipr 🔍 that's the place for the receipts 🧾✨

and if you spot any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to build this standard, the IETF literally wants you to tell them 🫶 send it to ietf-ipr@ietf.org and they'll take it from there 💌 that's the whole vibe, no cap 🌸