DHCP Option 121 Calculator

DHCP Option 121 is the Classless Static Route option defined by RFC 3442. A DHCP server can give a client a list of destination networks and next-hop routers without relying on classful network masks.

Each route identifies a CIDR prefix, the significant destination-network octets, and a four-byte IPv4 next hop. This calculator generates the option data locally; it does not connect to a DHCP server or apply a configuration.

A classless static route uses an explicit prefix length, such as 10.20.0.0/16, instead of inferring a network mask from the address range. That lets a DHCP administrator advertise routes for subnet sizes from /0 through /32.

For example, 10.20.0.0/16 via 192.168.1.1 directs matching traffic to that next hop. The client still decides how to install and select routes according to its operating system and routing table.

A client that supports RFC 3442 can request the Classless Static Route option in its DHCP parameter request list. The server returns route entries for that client's scope, and the operating system installs or applies them according to its own routing behavior.

When Option 121 and Router Option 3 are both returned, an RFC 3442 client must ignore Option 3. Put the default route in the Option 121 route list if clients using classless routes need one.

For each route, the option value contains one prefix-length byte, the significant bytes of the normalized destination network, and all four bytes of the gateway address. Route entries are concatenated in the order entered.

The prefix length is a decimal number from 0 to 32, encoded as one byte. The number of destination bytes is the prefix length divided by eight and rounded up. The full DHCP option's code and length fields are supplied by the server interface; the calculator shows the Option 121 value bytes.

A /8 route carries one destination byte, a /16 carries two, a /24 carries three, and prefixes from /25 through /32 carry all four. For 10.20.0.0/16, the destination portion is 0A 14; the trailing zero octets are omitted.

For a non-octet prefix such as 10.20.255.255/17, host bits are masked to the network 10.20.128.0 before encoding. The route contains three destination bytes, 0A 14 80. The calculator shows the normalized network and flags the edit.

The default route is 0.0.0.0/0. Its prefix byte is 00 and it contains zero destination-network bytes, followed immediately by the gateway's four IPv4 bytes. Via 192.168.1.1, its Option 121 value is 00 C0 A8 01 01.

RFC 3442 says clients that use Option 121 must ignore the Router option (Option 3) when both are present. Include the intended default route in Option 121 itself; administrators may also set Option 3 for older clients that do not support classless routes.

The value is the byte-for-byte concatenation of each route entry. Add the entries in the order you want represented in the server configuration. Longest-prefix route selection happens in the client's routing system, not by this calculator reordering the input.

Duplicate normalized destinations are retained and flagged rather than silently deleted. A destination repeated with different next hops may have implementation-specific behavior, so confirm that any duplicate is intentional before deploying it.

Option 3 (Router) advertises default router addresses; Option 121 advertises classless destination-and-next-hop routes, including an optional /0 default. They are distinct DHCP options and do not encode the same data.

A client implementing RFC 3442 must ignore Option 3 when it receives Option 121. RFC 3442 recommends that administrators include the default route in both options when supporting older clients, but clients using Option 121 use its route list.

Microsoft's protocol specification documents a separate Microsoft Classless Static Route option with code 249 and the same route encoding examples as RFC 3442, except for the option code. This calculator generates standard Option 121 and does not relabel its output as Option 249.

Windows Server DHCP interfaces, PowerShell syntax, and client behavior can vary by version and configuration. Use a verified scope-option definition for the exact server version; do not assume a standard Option 121 byte value is a complete Windows Server command.

Kea's published DHCPv4 example uses the classless-static-route option name and route/prefix-to-router data. The dnsmasq example configuration shows Option 121 as CIDR destination and gateway pairs. Use the source links next to those snippets and adapt the example to the exact subnet scope.

ISC's standard-option list marks Option 121 as supported by ISC DHCP and Kea, but ISC DHCP is end-of-life. The snippets shown by this tool are limited to syntax directly verified in the respective project examples; the RFC byte sequence remains the portable reference.

Check the prefix byte first, then count the destination bytes: /0 adds none, /1–/8 adds one, /9–/16 adds two, /17–/24 adds three, and /25–/32 adds four. Every route then ends with exactly four gateway bytes.

If a route looks wrong, verify the normalized network, gateway, DHCP scope, client support, and whether the server expects route pairs or raw option bytes. When Option 121 is present, a client following RFC 3442 ignores Option 3, so make sure the /0 route is included when needed.

10.20.0.0/16 via 192.168.1.1 becomes 10 0A 14 C0 A8 01 01: prefix 16, two destination bytes, then four gateway bytes. 172.16.50.0/24 via 192.168.1.254 becomes 18 AC 10 32 C0 A8 01 FE.

A default route via 192.168.1.1 is 00 C0 A8 01 01. Multiple examples are concatenated without separators in the actual option data; the grouped spaces shown here only make byte boundaries readable.