RFC 3527

Link Selection sub-option for the Relay Agent Information Option for DHCPv4

📅 published April 2003, from ietf

okay bestie, this is RFC 3527 💅✨ It's a Standards Track doc from April 2003, written by K. Kinnear, M. Stapp, R. Johnson, and J. Kumarasamy at Cisco Systems, under the Network Working Group. It doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Status of this Memo 📜

okay so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, go check the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited, so share it with everyone 💖

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸

Abstract 🧚

so the giaddr is an IP address that determines two things at once: a subnet (and therefore a link) where a DHCP client lives, AND an IP address you can use to talk to the relay agent 🙈 The subnet-selection option lets those jobs get split up 🔥 When one entity is acting as a DHCP proxy, it can name the subnet/link where an IP address should come from, even if that's a different IP address from the one it wants to use to talk to the DHCP server. The same goes for a relay agent that needs to name the subnet/link where a DHCP client sits, which is different from an IP address it can use to talk to the relay agent 👑

1. Introduction ✨

so in RFC 2131, the giaddr is an IP address that picks out a subnet (and from there a link) where a DHCP client lives, AND an IP address that can be used to talk to the relay agent 🎀 The subnet-selection option [RFC 3011] lets those functions split apart, so a DHCP proxy can name the subnet/link where it wants an IP address allocated. That's different from the IP address it wants to use when talking to the DHCP server 💅

Relay agents have the same problem. They sometimes need to name the subnet/link where a DHCP client is, and that's not the same as an IP address they can use to talk to the relay agent. Here's the setup 🦋

      +--------+         +---------------+
      |  DHCP  |     IP x|               |IP y
      | Server |-.......-|  Relay Agent  |----+------------+
      +--------+         |               |    |            |
                         +---------------+    |         +------+
                                              |         |Modem |
                                              |         +------+
                                              |          |    |
                                           +-----+  +-----+ +-----+
                                           |Host1|  |Host2| |Host3|
                                           +-----+  +-----+ +-----+

in the usual approach, the relay agent puts IP address Y into the giaddr of every packet it forwards to the DHCP server. But if IP address Y isn't reachable from the DHCP server for some reason, that approach falls apart 😭 There are a couple of ways that could happen:

  • there could be some firewall capability in the network element where the relay agent lives, and it doesn't let the DHCP server reach the relay agent via IP y 🔥
  • there might not be an IP y at all. For example, there's only one host and it's a point-to-point link 💀

In any of these cases (or others), the relay agent still needs to tell the DHCP server which subnet/link to allocate an IP address from 🫶 And the IP address that carries that subnet/link info can't be used as the way the DHCP server and relay agent talk to each other 🙅‍♀️

Here's the kicker: a relay agent can only modify a client's DHCP DHCPREQUEST in two ways, the giaddr and the relay-agent-info option 😤 So the relay-agent-info option needs a new sub-option, the link-selection sub-option, so the subnet/link can be separated from the IP address used to talk to the relay agent 💖

2. Terminology 📖

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 BCP 14, RFC 2119 [RFC 2119] 🎀

this doc uses these terms:

  • "DHCP client"
    • a DHCP client is an Internet host that uses DHCP to get configuration parameters, like a network address 🌸
  • "DHCP relay agent"
    • a DHCP relay agent is a third-party agent that passes BOOTP and DHCP messages between clients and servers on different subnets, per [RFC 951] and [RFC 1542] 🧚
  • "DHCP server"
    • a DHCP server is an Internet host that sends configuration parameters back to DHCP clients ✨
  • "link"
    • a link is a communications facility or medium where nodes can talk at the link layer, which is the layer right below IPv4 🔥 Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks, and internet (or higher) layer "tunnels," like tunnels over IPv4 or IPv6 itself 🦋
  • "subnet"
    • for this document, a subnet is a routable address range 💜 It can be one of several that exist on a link at the same time 🌈

so the link-selection sub-option is used by any DHCP relay agent that wants to name a subnet/link for a DHCP client request it's relaying. The subnet/link it names has to be different from the IP address the DHCP server uses to talk to the relay agent 💅

the sub-option holds a single IP address, and that address is contained in a subnet. To get the subnet address, you take any IP address on the subnet and AND it with the subnet mask. That means the network and subnet bits stay the same, and the remaining (address) bits get set to zero 🧮 That gives you one subnet. When allocating an IP address, all the other related subnets on the same link also get considered, the same way the giaddr is processed in [RFC 2131, Section 4.3.1, first group of bullets, bullet 4] 🔥

when this sub-option is needed, the relay agent adds it every time it sets the giaddr value. That means it goes on all messages relayed to the DHCP server 🫶

when the DHCP server is allocating an address and this sub-option is there, the DHCP server MUST allocate the address on either:

  • the subnet named in the link-selection sub-option, or;
  • a subnet on the same link (also called a network segment) as the subnet named in the link-selection sub-option.

the format of the sub-option looks like this 🧚

             SubOpt   Len     subnet IP address
            +------+------+------+------+------+------+
            |  5   |   4  |  a1  |  a2  |  a3  |  a4  |
            +------+------+------+------+------+------+

a relay agent that uses this sub-option MUST assume the server receiving it supports the sub-option and uses the info in it to allocate an IP address correctly. A relay agent that uses this sub-option MUST NOT take different actions based on whether the sub-option appears or doesn't appear in the response packet from the server 💀

it's important to make sure, using administrative techniques, that any relay agent using this sub-option only sends packets to a server that supports it 🔐

supporting this sub-option doesn't require changes to the DHCP server's operations or features, except selecting the subnet (and link) to allocate an address from. For example, handling a DHCPDISCOVER for an unknown subnet should keep working unchanged 🌸

if a DHCP server gets a packet with BOTH a subnet-selection option [RFC 3011] AND a link-selection sub-option, the info in the link-selection sub-option MUST be used to control the IP address allocation, in preference to the info in the subnet-selection option 👑

when this sub-option is present and the server supports it, the server MUST NOT offer an address that isn't on the requested subnet, or on the link (network segment) that subnet is associated with 🙅‍♀️

the IP address a DHCP server sends its reply to MUST be the same as the one it would choose if this sub-option weren't present 💖

4. Security Considerations 🔐

okay this part is SERIOUS, bestie 😭 Potential attacks on DHCP are discussed in section 7 of the DHCP protocol specification [RFC 2131], and also in the DHCP authentication specification [RFC 3118] 📚

the link-selection sub-option lets a relay agent name the subnet/link where an address gets allocated for a DHCP client. Since the subnet-selection option already exists [RFC 3011], no fundamental new security issues come from the link-selection sub-option in this document, beyond the ones already implied by the subnet-selection option [RFC 3011] ✨

BUT here's the tea ☕ Either the subnet-selection option or the link-selection sub-option documented here would let a malicious DHCP client do a more complete address-pool exhaustion attack than it could without these options. Why? Because the client wouldn't be limited to attacking address pools on just its local subnet 😈

⚠️ the tiny bit of protection: this sub-option has some minor protection against this kind of attack that the subnet-selection option doesn't have. A trusted relay agent that supports the relay-agent-info option MUST discard a packet it receives with a zero giaddr and a relay-agent-info option, when that packet arrives on an "untrusted" circuit [RFC 3046, section 2.1] 🛡️

5. IANA Considerations 🗂️

IANA has assigned a value of 5 from the DHCP Relay Agent sub-options space [RFC 3046] for the link-selection sub-option defined in Section 3 🎀

6. Acknowledgments 🫶

Eric Rosen helped the authors understand why this sub-option was needed 💜 A lot of this document was borrowed, with only minimal changes, from the document describing the subnet-selection option [RFC 3011] 🌈

7. References 📚

7.1. Normative References

  • [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [RFC 3011] Waters, G. "The IPv4 Subnet Selection Option for DHCP", RFC 3011, November 2000.
  • [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.

7.2. Informative References 📚

okay so these two are the "background reading" ones, not the must-read ones 🤓

[RFC 951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
           September 1985.

[RFC 1542] Wimer, W., "Clarifications and Extensions for the
           Bootstrap Protocol", RFC 1542, October 1993.

8. Intellectual Property Statement ⚖️

bestie, the IETF is not claiming it knows whether any IP rights apply to the tech in this doc, or whether anyone can license it. It also hasn't done a search to find any. 🙈 If you want the IETF's rules on rights for standards-track docs, go read BCP-11. Copies of any rights claims filed for publication, any licensing assurances, or the outcome of anyone trying to get a general license for implementers or users can be requested from the IETF Secretariat.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF Executive Director. 💌

9. Authors' Addresses 🧑‍💻

the squad behind this one 🫶

Kim Kinnear
Cisco Systems
1414 Massachusetts Ave
Boxborough, Ma. 01719

Phone: (978) 936-0000
EMail: kkinnear@cisco.com


Mark Stapp
Cisco Systems
1414 Massachusetts Ave
Boxborough, Ma. 01719

Phone: (978) 936-0000
EMail: mjs@cisco.com


Jay Kumarasamy
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134

Phone: (408) 526-4000
EMail: jayk@cisco.com


Richard Johnson
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134

Phone: (408) 526-4000
EMail: raj@cisco.com

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

okay the legal part, but I'll keep every bit of it 💅 Anyone can copy and share this document, and translations of it too. You can also make derivative works that comment on or explain it, or that help people implement it, and you can copy, publish, and distribute those, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy. 🦋

Here's the catch: you can't modify this document itself in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when it's needed for developing Internet standards, and then the copyright procedures in the Internet Standards process must be followed. You're also allowed to translate it into languages other than English.

These permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them. 🌈

Now the disclaimer, which I'm leaving in caps because it's serious 😭

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 🎀

the RFC Editor function is currently funded by the Internet Society, so a big thank-you to them 🌸

📦 where this page comes from