Build or audit classless-route and vendor-specific payloads without sending configuration anywhere. Every result shows its wire bytes, offsets, length envelope, and copyable server syntax.
RFC 3442 + Microsoft compatibility code
Classless static routes — Options 121 and 249
5–255 payload bytes
A route is a prefix width, only the significant destination octets, then a four-byte gateway. Option 249 uses the same payload layout as 121.
Preparing the example…
Current result
Payload
Framing shown
Decoded routes
#
Destination
Gateway
Payload offsets
Route bytes
Payload hex
Full option hex
Payload decimal
Byte layout
Byte offset
Field
Meaning
Hex
Raw configuration snippets
These inject the exact payload. Put them in the correct subnet, pool, class, or scope and verify syntax against your installed release before deployment.
Kea option-data
ISC-style custom option
RouterOS
Review notes
RFC 2132 opaque vendor information
Vendor-specific TLVs — Option 43
Generic TLV view
Build code/length/value suboptions or audit an existing payload. Because each vendor defines its own codes, values are displayed as bytes with optional text and IPv4 views—not asserted meanings.
Preparing the example…
Current result
Payload
Framing shown
Vendor suboptions
#
Code
Length
Printable ASCII
IPv4 view
Value hex
Payload hex
Full option hex
Payload decimal
Byte layout
Byte offset
Field
Meaning
Hex
Raw configuration snippets
The payload stays byte-for-byte identical. Option 60/vendor-class matching is separate and vendor-specific.
Kea option-data
ISC-style custom option
RouterOS
Review notes
All input stays in this browser. No DHCP server is contacted and no configuration is applied. The shared site analytics tag may count the page visit, but this workbench does not send option bytes.
How classless-route bytes are built
RFC 3442 §3 defines Option 121 as one or more routes. Each begins with a prefix-width byte from 0 through 32. It then carries only ceil(prefix ÷ 8) destination octets, followed by all four gateway octets. Missing destination octets are zero. Bits after the prefix in the final carried octet must also be zero.
A default route is especially compact: width 00, no destination octets, then its four-byte gateway. For example, 0.0.0.0/0 via 10.0.0.1 is 00 0A 00 00 01. The two outer bytes shown by “full option” are the DHCP option code and one-byte payload length; they are not part of the route payload.
Option 121 versus Option 249
Microsoft documents Option 249 with the same destination-descriptor and router layout as RFC 3442. The only wire difference in this tool is the outer code. Microsoft’s interoperability guidance says that when a client requests both 121 and 249, a server should return 121. Client support and request lists vary, so inspect an actual DHCP exchange before removing a compatibility option.
RFC 3442 also requires a client that receives Option 121 to ignore the older Router option (3). A route list that omits 0.0.0.0/0 can therefore intentionally—or accidentally—leave those clients without a default gateway.
What Option 43 does and does not say
RFC 2132 §8.4 calls Option 43 an opaque vendor-defined object. When it contains several items, the recommended encapsulated form is code, length, value: code 0 is padding, code 255 is END, and other code meanings belong to the vendor. No DHCP magic cookie appears inside Option 43. END is optional because the enclosing option length can terminate the sequence.
The text and IPv4 columns are deliberately only alternate views. Four bytes can look like an address while representing an integer or identifier; printable bytes can be binary data. Verify the vendor class (Option 60), suboption registry, byte order, repetition rules, and client firmware before deployment.
Using the generated server snippets
The Kea form uses csv-format: false, which Kea documents as hexadecimal option data. The ISC-style declaration treats the payload as a raw string, while RouterOS uses its hexadecimal value form. These are portable payload representations, not complete policies: scope placement, vendor matching, precedence, quoting, existing option definitions, and release-specific syntax still belong to the server configuration.
Test in an isolated scope, validate the server configuration with its own tooling, capture the resulting offer or acknowledgement, and decode the bytes again here. This tool checks structure and exact lengths; it cannot prove that a particular client recognizes, requests, trusts, or installs the option.
Frequently asked questions
Can I paste Wireshark hex?
Yes, if it contains only the selected option’s bytes. Hex input accepts spaces, colons, commas, hyphens, and 0x prefixes. Do not include packet offsets or ASCII columns.
Why was my route rejected for host bits?
The destination descriptor is a network prefix, not a host address. The encoder refuses to silently change it so the difference is visible—for example, enter 192.0.2.128/25, not 192.0.2.200/25.
Does Option 249 use a different payload?
No. Microsoft’s specification gives it the RFC 3442 format. It exists for compatibility; code 121 is the standardized option.
Can this identify my Option 43 vendor?
No. The payload has no universal dictionary. Interpret it with the device vendor’s Option 43 and vendor-class documentation.
Audit an OBS scene collection locally: media paths, browser-source URLs, plugins, fonts and devices, broken items, leaked tokens and stream keys, a migration checklist, and a redacted copy.
Audit Final Cut Pro XML locally: media paths, missing or duplicate references, proxy-only assets, frame rates, roles, third-party titles and effects, and a portability checklist.