RFC 7969

Customizing DHCP Configuration on the Basis of Network Topology

📅 published October 2016, from ietf

Customizing DHCP Configuration on the Basis of Network Topology 🎀

okay so this is RFC 7969 🦋, and it's giving Informational vibes, not a Standards Track spec. The authors are T. Lemon (Nominum, Inc.) and T. Mrugalski (ISC), it's dated October 2016, and it lives in ISSN 2070-1721. The header has no Obsoletes or Updates line, so this doc doesn't replace or change any other RFC 🙈

Abstract 📖

DHCP servers have level-upped way past what the base specs describe 💅 One of the glow-ups is support for context-specific configuration information, meaning the settings a server hands out can depend on where the client is. This memo walks through some of those features and explains how they work ✨

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes only 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🧐

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7969 🔗

Copyright (c) 2016 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled from this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says 🫶

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Identifying Client's Location by DHCP Servers . . . . . . . .   3
  3.1.  DHCPv4-Specific Behavior  . . . . . . . . . . . . . . . .   7
  3.2.  DHCPv6-Specific Behavior  . . . . . . . . . . . . . . . .   7
4.  Simple Subnetted Network  . . . . . . . . . . . . . . . . . .  10
5.  Relay Agent Running on a Host . . . . . . . . . . . . . . . .  12
6.  Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . .  12
7.  Regional Configuration Example  . . . . . . . . . . . . . . .  13
8.  Multiple Subnets on the Same Link . . . . . . . . . . . . . .  15
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
  10.2.  Informative References . . . . . . . . . . . . . . . . .  18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

bestie, so the DHCPv4 [RFC2131] and DHCPv6 [RFC3315] specs explain how addresses can be handed out to clients based on network topology info that the DHCP relay infrastructure provides 🗺️ Picking the right address is a huge part of how addresses and prefixes get allocated in DHCP, so this matters a lot 💖

DHCP also has ways to hand devices extra configuration, like DNS [RFC1034] server addresses, default DNS search domains, and other stuff like that 🌈

The authors of these specs totally meant for DHCP servers to give each device config that fits where it sits on the network 👑 But that practice was never written down, let alone explained in detail 😭

Real DHCP servers already do this, though, and this doc is here to describe those capabilities. It's for operators and for protocol designers who might want to use DHCP to configure their own services but don't know what modern DHCP servers can do 🧚

2. Terminology 💅

  • CPE device: Customer Premise Equipment device. Usually a router that belongs to the customer and plugs directly into the provider link 🏠
  • DHCP, DHCPv4, and DHCPv6: DHCP is the Dynamic Host Configuration Protocol in general, and it covers both DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 only come up when things would be confusing otherwise or when the differences matter 🫶
  • PE router: Provider Edge router. The provider router closest to the customer 🛰️
  • Routable IP address: An IP address whose scope of use is wider than the local link 🌍
  • Shared subnet: A case where two or more subnets of the same protocol family are on the same link. The term "Shared subnet" is usually used in Unix environments. It's usually called "multinet" in Windows environments, and the admin config inside a Microsoft DHCP server is called "DHCP Superscope" 🪟
  • Link or local link: A layer 2 network link, as defined in Section 1.2 of [RFC3297] 🔌
  • Link subset: A chunk of a link that holds a subset of all the connection points on that link. You can use it to pin down the physical location of a group of clients, or to describe topology at a finer level than the full set of places where that link is available 🔍 The smallest link subset is a single link attachment point, like one port on a layer 2 switch 💜

3. Identifying Client's Location by DHCP Servers ✨

Okay bestie, let's look at Figure 1 🗺️ It's a small hierarchy of network links, and Link D is the backbone that the DHCP server is plugged into.

              Link A                   Link B
           |===+===========|    |===========+======|
               |                            |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   A   |                    |   B   |
           +---+---+                    +---+---+
               |                            |
               |       Link C               |
           |===+==========+=================+======|
                          |
                          |
                     +----+---+        +--------+
                     | router |        |  DHCP  |
                     |    A   |        | Server |
                     +----+---+        +----+---+
                          |                 |
                          |                 |
                          |   Link D        |
           |==============+=================+======|
                          |
                          |
                     +----+---+
                     | router |
                     |    B   |
                     +----+---+
                          |
                          |
           |===+==========+=================+======|
               |       Link E               |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   C   |                    |   D   |
           +---+---+                    +---+---+
               |                            |
               |                            |
           |===+===========|    |===========+======|
              Link F                   Link G

        Figure 1: A Simple Network with a Small Hierarchy of Links

Figure 2 is the glow-up version 💅 It's more complex. Some of it probably won't show up in real production networks, but it's super useful for understanding the finer details of the DHCP protocols. Quick heads-up: some nodes are routers (they forward all IP traffic), and some are relay agents (they run DHCP-specific software and only forward DHCP traffic). Iconic distinction 🙌

              Link A                   Link B            Link H
           |===+==========|    |=========+======|  |======+======|
               |                         |                |
               |                         |                |
           +---+---+                 +---+---+        +---+---+
           | relay |                 | relay |        | relay |
           |   A   |                 |   B   |        |   G   |
           +---+---+                 +---+---+        +---+---+
               |                         |                |
               |       Link C            |                | Link J
           |===+==========+==============+======|  |======+======|
                          |                               |
                          |                               |
                     +----+---+        +--------+     +---+---+
                     | router |        |  DHCP  |     | relay |
                     |    A   |        | Server |     |   F   |
                     +----+---+        +----+---+     +---+---+
                          |                 |             |
                          |                 |             |
                          |   Link D        |             |
           |==============+=========+=======+=============+======|
                          |         |
                          |         |
                     +----+---+ +---+---+
                     | router | | relay |
                     |    B   | |   E   |
                     +----+---+ +---+---+
                          |         |
                          |         |
           |===+==========+=========+=======+======|
               |       Link E               |
               |                            |
           +---+---+                    +---+---+
           | relay |                    | relay |
           |   C   |                    |   D   |
           +---+---+                    +---+---+
               |                            |
               |                            |
           |===+===========|    |===========+======|
              Link F                   Link G

                         Figure 2: Complex Network

These diagrams are how we show off a bunch of different network setups, and how an existing DHCP server can hand out config info that's tailored to exactly where the client is asking from. Main character energy 🎀

Now the background, because it matters for reading those pictures 🧠 We assume DHCP clients might not have routable IP addresses yet while they're trying to grab their config.

Why? Because one of DHCP's jobs is bootstrapping the client's IP configuration. If the client doesn't have an IP configured yet, it can't route packets to a server that's off-link. So some kind of relay mechanism is required. Makes sense, right? 🦋

DHCPv4 and DHCPv6 deliver packets in slightly different ways, but the core idea is the same ✨ Whether or not the client has an IP config, it usually sends its requests to a DHCP relay agent on the local link. That relay has a routable IP address, so it forwards the requests to the DHCP server, either directly or through other relays. Later on, once the client has an address and certain conditions are met, it's allowed to send packets straight to the server and skip the relays 🏃‍♀️ Those conditions are different for DHCPv4 and DHCPv6, and we'll cover them in Sections 3.1 and 3.2.

To figure out where the client is plugged in and which link-specific config it needs, the server typically looks at the client-facing IP address of the relay agent 👀 In some cases, the server can use the client's routable IP address instead, but only if the client has that routable IP assigned to its interface and it's sent in the DHCP message. Either way, the server can work out the client's point of attachment and pick the right subnet- or link-specific config. Slay 💖

Sometimes relay agents also share extra info about the topology 🗺️ There are a bunch of extensions defined for this. The details are different, but the big idea is always the same: the relay agent knows exactly where the original request came from, so it adds an identifier that helps the server pick the right address pool and config parameters. We'll look at examples of these in the following sections 🌸

Last one: clients can also be on the same link as the server, so no relay agents are needed 🙈 In that case, a DHCPv4 server usually uses the IPv4 address on the network interface where the message came in to pick the subnet. DHCPv6 is trickier, because a DHCPv6 server isn't required to have any globally unique addresses, so extra config info may need to be required. Some servers let you say that a given subnet is directly reachable over a specific local network interface, which is a lowkey lifesaver 🧚

3.1. DHCPv4-Specific Behavior 💜

Okay, DHCPv4 specifics. In some cases, when a DHCPv4 client has a routable IPv4 address, the message gets unicast straight to the DHCPv4 server instead of going through a relay agent 📬 Examples are renewal (DHCPREQUEST) and address release (DHCPRELEASE).

The relay agent that gets the client's message sets the giaddr field to the address of the interface the message was received on 🎀 The relay agent may also insert a relay agent option [RFC3046].

There are several options defined that help with subnet selection in DHCPv4, and they're giving very useful 🔥 [RFC3527] defines the Link Selection sub-option, which a relay agent inserts. It's especially handy when the relay needs to name the subnet or link where the DHCPv4 client actually lives, which can be different from the IP address used to talk to the relay itself 🦋

The Virtual Subnet Selection (VSS) sub-option, specified in [RFC6607], can also be added by a relay agent to specify info in a VPN environment 🔐 And sometimes the client itself should specify the Virtual Subnet Selection option. For example, that happens when there are no relay agents involved during the VPN setup process 🫶

Another option that can influence subnet selection is the IPv4 Subnet Selection option, defined in [RFC3011]. It lets the client explicitly request an allocation from a given subnet, which is a very direct "this is the one I want" move 💅✨

3.2. DHCPv6-Specific Behavior ✨

okay so DHCPv6 has its own vibe 💅 Unicast is possible when the server has a Server Unicast option (see Section 22.12 in [RFC3315]) and clients can actually use it. Once a client has a (presumably global) address, it can talk straight to the server and skip the relays entirely 🦋 It's also totally up to the admins whether this happens, bestie. They can just not configure the Server Unicast option, and then clients always send their messages through relay agents 🫶

The DHCPv6 protocol [RFC3315] gives us two core mechanisms that let a server figure out which link the relay agent is plugged into 🔍 The first one is the link-address field in Relay-forward and Relay-reply messages. This field uniquely identifies the link and should not be mistaken for a link-local address. Honestly, this is the easiest one to keep up, because you can reuse existing address assignments and you don't need extra admin stuff like giving each relay agent its own identifier, making sure those are unique, and keeping a list of them 🙌 The catch is that the relay agent needs an address with a scope larger than link-local configured on its client-facing interface.

The second mechanism uses an Interface-ID option (see Section 22.18 of [RFC3315]) that the relay agent inserts to identify the link the client is connected to 💜 This one is useful when the relay agent doesn't have a globally unique address or Unique Local Address (ULA) [RFC4193] on its client-facing interface, which means the first mechanism isn't feasible. If the interface-id is unique within an administrative domain, the interface-id value can be used to pick the right subnet. But there's no guarantee of uniqueness, since [RFC3315] only mandates the interface-id to be unique within a single relay agent context 😭 So it's up to the administrator to check whether the relay agents they've deployed use unique interface-id values. If they aren't unique, the Interface-ID option can't be used to determine the client's point of attachment.

It should be noted that Relay-forward and Relay-reply messages are exchanged between relays and servers only. Clients are never exposed to those messages 🙈 Also, servers never receive Relay-reply messages. Relay agents have to be able to process both kinds of messages: Relay-forward (passing an already relayed message further toward the server when there's more than one relay agent in a chain) and Relay-reply (sending the response back toward the client when there's more than one relay agent in a chain) 🔁

For completeness, there's an uncommon but valid case where relay agents use a link-local address in the link-address field of relayed Relay-forward messages 🌸 This can happen if the relay agent doesn't have any address with a larger scope on the interface connected to that link. Even though link-local addresses can't be automatically used to associate the relay agent with a given link, the server may still be able to pick the right link if it gets some additional configuration info ✨

This requires that the DHCP server has a way of associating a particular link-local address with a particular link. The network administrator can then explicitly configure the DHCP server to recognize that the particular link-address field in a relay message refers to that link 🎀

There are two ways this can work. One is that the DHCP server provides a mechanism that explicitly associates the link-local address with a link. In this case, the network administrator figures out the link-local address of the relay agent on a particular link, which we're presuming is stable, and sets up an association between that address and the link 💅

If the DHCP server doesn't explicitly provide such a mechanism, it may still provide a "shared subnet" mechanism (see Section 8). If it does, the shared subnet mechanism can be used to explicitly associate a link-local address with a link. To do this, the network administrator creates a shared subnet association for the link, if one doesn't already exist. Then they configure a /128 subnet that contains just the link-local address of the relay agent, and add this new /128 to the shared subnet. Now, when a DHCP message comes in with that link-layer address in the link-address field, the correct shared network gets selected 🧚

DHCPv6 also supports more finely grained link identification using Lightweight DHCPv6 Relay Agents (LDRAs) [RFC6221] 👑 In this case, the link-address field is set to the unspecified address ::, but the DHCPv6 server also receives an Interface-ID option from the relay agent, which can be used to pinpoint the client's location on the network even more precisely. It's possible to mix LDRAs and regular relay agents in the same network. See Sections 7.2 and 7.3 in [RFC6221] for detailed examples 🌈

What this means in practice is that the DHCP server has enough info in all cases to pinpoint the link the client is connected to. In some cases, it may also be possible to pinpoint the particular link subset the client is on ⭐

In all cases, then, the DHCPv6 server will have a link-identifying IP address, and in some cases it may also have a link-specific identifier (e.g., the Interface-ID option or the Link Address option defined in Section 5 of [RFC6977]) 💖 It should be noted that the link-specific identifier is unique only within the scope of the link-identifying IP address. For example, the link-specific identifier "eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is distinct from an "eth0" identifier used by a different relay agent with address 2001:db8::2 🦋

It's also possible for link-specific identifiers to be nested, so the actual identifier for the specific link subset is an aggregate of two or more identifiers sent by a set of LDRAs in a chain 🧶 In general this works exactly as if a single identifier were received from a single LDRA, so we don't treat it specially in the discussion below. But sites that use chained LDRA configurations will need to be aware of this when configuring their DHCPv6 servers 🙈

The Virtual Subnet Selection options, which are present in DHCPv4, are also defined for DHCPv6 💜 The use case is the same as in DHCPv4: the relay agent inserts VSS options that help the server select the right subnet, with its address pool and associated configuration options. See [RFC6607] for details 🍓

4. Simple Subnetted Network

Consider Figure 1 in the context of a simple subnetted network. In this network there are four leaf subnets where DHCP clients get configured: Links A, B, F, and G. Relays A, B, C, and D are shown in the diagram as IP routers with an embedded relay function, because that's a very typical setup. But the relay function can also live in a separate node on each link 🌸

In a simple network like this, there may be no need for link-specific configuration in DHCPv6, since local routing information is delivered through router advertisements. However, in IPv4 it's super typical to configure the default route using DHCP. In that case the default route is different on each link, so the DHCP server will need link-specific configuration for the default route 💅

To illustrate, we'll use an example from a hypothetical DHCP server that uses a simple JSON notation [RFC7159] for configuration. We don't know of any DHCP server that uses this exact syntax, but most modern DHCP servers give you similar functionality ✨

{
    "prefixes": {
        "192.0.2.0/26": {
            "options": {
                "routers": ["192.0.2.1"]
            },
            "on-link": ["A"]
        },
        "192.0.2.64/26": {
            "options": {
                "routers": ["192.0.2.65"]
            },
            "on-link": ["B"]
        },
        "192.0.2.128/26": {
            "options": {
                "routers": ["192.0.2.129"]
            },
            "on-link": ["F"]
        },
        "192.0.2.192/26": {
            "options": {
                "routers": ["192.0.2.193"]
            },
            "on-link": ["G"]
        }
    }
}

Figure 3: Configuration Example

In Figure 3 we see a configuration example for this scenario: a set of prefixes, each with a set of options and a list of links it's on-link for 🎀 We've defined one option for each prefix: a routers option. This option holds a list of values, and each list only has one value, which is the IP address of the router specific to that prefix 🧚

When the DHCP server gets a request, it searches the list of prefixes for one that encloses the link-identifying IP address provided by the client or relay agent. Then it looks at the options list associated with that prefix and returns those options to the client 👑

So, for example, a client connected to Link A would have a link-identifying IP address within the 192.0.2.0/26 prefix, so the DHCP server would match it to that prefix. Based on the configuration, the DHCP server would then return a routers option containing a single IP address: 192.0.2.1. A client on Link F would have a link-identifying address in the 192.0.2.128/26 prefix and would get a routers option containing the IP address 192.0.2.129 🌈

5. Relay Agent Running on a Host 🖥️

A relay agent is DHCP software that can run on any IP node. Although it's typically run on a router, that's by no means required by the DHCP protocol 🙌 The relay agent is simply a service that operates on a link, receiving link-local multicasts (IPv6) or broadcasts (IPv4) and relaying them, using IP routing, to a DHCP server. As long as the relay has an IP address on the link and a default route or a more specific route through which it can reach a DHCP server, it doesn't need to be a router or even have multiple interfaces 💖

A relay agent can be run on a host connected to two links. That case is presented in Figure 2. There's router B connected to Links D and E. At the same time, there's also a host connected to the same links, and the relay agent software is running on that host. That's uncommon, but it's a valid configuration 🦋

6. Cascaded Relays 🎀

okay so bestie, let's look at another case, shown in Figure 2 ✨ In this setup, the clients on Link G send their requests to relay D, and relay D forwards its packets straight to the DHCP server 💖 That's the usual way to do it, but it's not the only option 🦋 Relay agent D can be set up to forward client messages to relay E instead, and then relay E sends them on to the DHCP server 🌸 People call this "cascaded relay agents," and it's giving very multi-hop vibes 🔥

Okay, here's where DHCPv4 and DHCPv6 are totally different, so pay attention 👑 In DHCPv4, only the first relay is able to set the giaddr field in the DHCPv4 packet 💅 Any relays after that which receive the packet will not change it, because the server needs the giaddr info from the first relay (the one closest to the client) 🧚 The server then sends the response back to the giaddr address, which is the address of the first relay agent that saw the client's message 🍓 So the client's messages and the server's replies take different paths, and that's lowkey wild 😭 A message from a client on Link G goes through relay D, then relay E, and finally reaches the server 💜 The response goes from the server to relay D through router B, and then relay D sends it to the client on Link G 🌈

DHCPv6 is way more structured, though 🫶 Each relay agent encapsulates a packet that's destined for the server and sends it along toward the server ⭐ Depending on how it's configured, that can be a server's unicast address, a multicast address, or the address of the next relay agent 🦋 The next relay then does the encapsulation process again 💖 The resulting packet is more complex (it may have up to 32 levels of encapsulation if the packet traveled through 32 relays) 😭 But every relay can insert its own options, and it's always clear which relay agent inserted which option 🎀 Iconic, honestly 💅

7. Regional Configuration Example 🌸

In the Figure 2 example, Link C is a regional backbone for an ISP 🌈 Link E is also a regional backbone for that same ISP ✨ Relays A, B, C, and D are PE routers 🔥 Links A, B, F, and G are actually link aggregators with individual layer 2 circuits to each customer 💅 For example, the relays might be Digital Subscriber Line Access Multiplexers (DSLAMs) or cable head-end systems 🧚 At each customer site, we assume there's a single CPE device attached to the link 🍓

We also assume that Links A, B, F, and G are each addressed by a single prefix 💜 It would be equally valid, though, for each CPE device to be numbered on a separate prefix 🦋

In a real-world deployment, there would likely be many more than two PE routers connected to each regional backbone 🫶 We kept the number small here just for simplicity 💖

In the example presented in Figure 4, the goal is to configure all the devices within a region with server addresses local to that region 🔥 That way, service traffic doesn't have to be routed between regions unnecessarily 👑

{ "prefixes": { "2001:db8::/40": { "on-link": ["A"] }, "2001:db8:100::/40": { "on-link": ["B"] }, "2001:db8:200::/40": { "on-link": ["F"] }, "2001:db8:300::/40": { "on-link": ["G"] } }, "links": { "A": {"region": "omashu"}, "B": {"region": "omashu"}, "F": {"region": "gaoling"}, "G": {"region": "gaoling"} }, "regions": { "omashu": { "options": { "SIP Server": ["sip.omashu.example.org"], "DNS Recursive Name Server": ["dns1.omashu.example.org", "dns2.omashu.example.org"] } }, "gaoling": { "options": { "SIP Server": ["sip.gaoling.example.org"], "DNS Recursive Name Server": ["dns1.gaoling.example.org", "dns2.gaoling.example.org"] } } } }

Figure 4: Regional Configuration Example

In this example, when a request comes in to the DHCPv6 server with a link-identifying IP address in the 2001:db8::/40 prefix, it gets identified as being on Link A 💖 The DHCPv6 server then checks its list of links to see what region the client is in 🌸 Link A is identified as being in omashu 🎀 The DHCPv6 server then looks up omashu in the set of regions and finds a list of region-specific options 🦋

The DHCPv6 server then resolves the domain names listed in those options 🫶 It sends a SIP Server option containing the IP addresses the resolver returned for sip.omashu.example.org, and a DNS Recursive Name Server option containing the IP addresses returned by the resolver for dns1.omashu.example.org and dns2.omashu.example.org 💅 Depending on the server's capability and configuration, it may cache resolved responses for a specific period of time, repeat the queries every time, or even keep the response until reconfiguration or shutdown 🧚 For more detailed discussion, see Section 7 of [RFC7227] 📚✨

Similarly, if the DHCPv6 server gets a request from a DHCPv6 client where the link-identifying IP address is contained by the prefix 2001:db8:300::/40, then the server identifies the client as being connected to Link G 🍓 It then identifies Link G as being in the gaoling region and returns the SIP Server and DNS Recursive Name Server options specific to that region 💜

As with the previous example, the exact configuration syntax and structure shown above doesn't precisely match what existing DHCPv6 servers do 🌈 But the behavior illustrated in this example can be accomplished with most existing modern DHCPv6 servers ⭐

There are scenarios where there's more than one subnet from the same protocol family (like two or more IPv4 subnets, or two or more IPv6 subnets) configured on the same link 🔥 This is often called 'shared subnets' in Unix environments, or 'multinet' in Microsoft terminology 💅

The most frequently mentioned use case is network renumbering, where some services have been migrated to the new addressing scheme but some haven't yet 🫶

A second example is expanding the allocation space 💖 In DHCPv4 and for DHCPv6 Prefix Delegation, there could be cases where multiple subnets are needed, because a single subnet may be too small to accommodate the client population 🌸

The third use case covers allocating addresses (or delegation prefixes) that aren't the same as the topological information 🎀 For example, the link-address is on prefix X, but the addresses to be assigned are on prefix Y 🧚 This could be based on differentiating information (like whether the device is a CPE or a cable modem in the Data Over Cable Service Interface Specification (DOCSIS)), or it could just be because the link-address/giaddr is different from the actual allocation space 🍓

The fourth use case is a cable network, where cable modems and the devices connected behind them are on the same layer 2 link 😭 However, operators want the cable modems and user devices to get addresses from distinct address spaces, so users couldn't easily access their modems' management interfaces 💀

To support such a configuration, additional differentiating information is required 💜 Many DHCP server implementations offer a feature that's typically called "client classification" 🌈 The server segregates incoming packets into one or more classes based on certain packet characteristics, e.g., the presence or value of certain options, or even a match between existing options ⭐ Servers need that extra information to handle this setup, because they can't use the topographical property of the relay addresses alone to properly choose a subnet 🦋 The exact details of such an operation aren't part of the DHCPv4 or DHCPv6 protocols, and they're implementation dependent 🔥

9. Security Considerations 🔐

This document explains existing practice with respect to the use of Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host Configuration Protocol Version 6 [RFC3315] 💅 The security considerations for these protocols are described in their specifications and in related documents that extend them 🫶

The mechanisms described in this document could possibly be exploited by an attacker to misrepresent its point of attachment in the network 😱 This would cause the server to assign addresses, prefixes, and other configuration options, which can be considered a leak of information 💀 In particular, this could be used as a preliminary stage of an attack when the DHCP server leaks information about available services in parts of the network the attacker doesn't have access to 🚨

There are several ways that such an attack can be prevented 🛡️ First, it's a common practice to filter DHCP traffic passing to clients within a particular administrative domain from outside of that domain, and also to filter DHCP traffic to clients outside of a particular administrative domain from within that domain 💖 Second, the DHCP servers can be configured to not respond to traffic that's coming from unknown subnets (i.e., those subnets the server isn't configured to serve) 🌸 Third, some relays provide the ability to reject messages that don't fit expected characteristics 🎀 For example, the Cable Modem Termination System (CMTS) acting as a DHCP relay detects if the Media Access Control (MAC) address specified in chaddr in incoming DHCP messages matches the MAC address of the cable modem it came from, and it can alter its behavior accordingly 🧚 Also, relay agents and servers that are connected to clients directly can reject traffic that looks as if it has passed a relay (this could indicate the client is trying to spoof a relay, possibly to inject forged relay options) 🍓

There are a number of general DHCP recommendations that should be considered in all DHCP deployments 💜 While they're not strictly related to the mechanisms described in this document, they may be useful in certain deployment scenarios 🌈 [RFC7819] and [RFC7824] provide an analysis of privacy problems in DHCPv4 and DHCPv6, respectively ⭐ If those are of concern, [RFC7844] offers mitigation steps 🦋

Current DHCPv4 and DHCPv6 standards lack strong cryptographic protection 😭 There's an ongoing effort in the DHC working group to address this 🔥 [SECURE-DHCPv6] attempts to provide a mechanism for strong authentication and encryption between DHCPv6 clients and servers 💅 [SECURITY-MESSAGES] attempts to improve security of exchanges between DHCP relay agents and servers 🫶

Another possible attack vector is setting up a rogue DHCP server and providing clients with false information, either as a denial of service or to execute a man-in-the-middle type of attack 🚨 This can be mitigated by deploying DHCPv6-Shield [RFC7610] 🛡️

Finally, there's an ongoing effort to update the DHCPv6 specification, which is currently 13 years old 😭 Sections 21 ("Security Considerations") and 22 ("Privacy Considerations") of [DHCPv6bis] contain more recent analysis of the security and privacy considerations 💖

10. References 📚

10.1. Normative References

[RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
           RFC 2131, DOI 10.17487/RFC2131, March 1997,
           <http://www.rfc-editor.org/info/rfc2131>.

[RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
           C., and M. Carney, "Dynamic Host Configuration Protocol
           for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
           2003, <http://www.rfc-editor.org/info/rfc3315>.

10.2. Informative References ✨

okay so these are the "good to know" references, the ones that give you extra context without being required reading. bestie, read them if you're curious 🧚

Acknowledgements 🙏💖

big thank-you hugs to Dave Thaler 🫶 he suggested that even though "everybody knows" how DHCP servers get deployed in the real world, it's worth having an IETF doc that actually explains what everybody knows, because not everyone is a DHCP expert. iconic idea tbh 👑

thanks also to Andre Kostur, Carsten Strotmann, Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-Francois Tremblay, Marcin Siodelski, Bernie Volz, and Yaron Sheffer for their reviews, comments, and feedback. you all are literally the reason this doc slaps 💅🌈

Authors' Addresses 🎀

these are the lovely people who wrote it 🦋

Ted Lemon
Nominum, Inc.
800 Bridge Parkway, Suite 100
Redwood City, CA  94065
United States of America

Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com


Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA  94063
United States of America

Phone: +1-650-423-1345
Email: tomasz.mrugalski@gmail.com
📦 where this page comes from