DHCPv4 Routed Prefix Option
draft-drew-dhc-v4-routed-prefix-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Brendon Drew | ||
| Last updated | 2026-08-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-drew-dhc-v4-routed-prefix-00
Network Working Group B. Drew
Internet-Draft 12 August 2026
Intended status: Standards Track
Expires: 13 February 2027
DHCPv4 Routed Prefix Option
draft-drew-dhc-v4-routed-prefix-00
Abstract
This document defines a DHCPv4 option that conveys one or more IPv4
prefixes that are routed toward a DHCP client independently of the
client's on-link DHCP-assigned IPv4 address and default-router
configuration.
The option is intended for requesting routers whose upstream
attachment address is distinct from IPv4 prefix space routed toward
them. Examples include access networks in which a customer router
receives a private-use address [RFC1918] or Shared Address Space
[RFC6598] attachment address while one or more additional public or
private IPv4 prefixes are routed toward that router.
This document does not define how the upstream network establishes
the route, does not require Network Address Translation (NAT), and
does not specify how a client uses, assigns, translates, or delegates
an advertised prefix after receipt.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 February 2027.
Drew Expires 13 February 2027 [Page 1]
Internet-Draft DHCPv4 Routed Prefix August 2026
Copyright Notice
Copyright (c) 2026 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Routed IPv4 Prefix Option . . . . . . . . . . . . . . . . . . 5
5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Routed Prefix Descriptor . . . . . . . . . . . . . . . . 6
5.3. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7
5.4. Long Option Encoding . . . . . . . . . . . . . . . . . . 8
6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . 8
7. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9
8. Lease Lifetime, Renewal, and Withdrawal . . . . . . . . . . . 9
8.1. Absence of the Option . . . . . . . . . . . . . . . . . . 10
9. Relationship to Existing DHCP Routing Options . . . . . . . . 10
10. Relationship to RFC 6656 Subnet Allocation . . . . . . . . . 11
11. Relationship to DHCPv6 Prefix Delegation . . . . . . . . . . 12
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Shared Attachment Address with a Routed Public /32 . . . 12
12.2. Routed Public Subnet . . . . . . . . . . . . . . . . . . 13
12.3. Multiple Routed Prefixes . . . . . . . . . . . . . . . . 13
12.4. Prefix Withdrawal on Renewal . . . . . . . . . . . . . . 13
13. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
14. Operational Considerations . . . . . . . . . . . . . . . . . 14
14.1. Routing State . . . . . . . . . . . . . . . . . . . . . 14
14.2. Address Conservation . . . . . . . . . . . . . . . . . . 14
14.3. Client Use of Routed Prefixes . . . . . . . . . . . . . 15
15. Security Considerations . . . . . . . . . . . . . . . . . . . 15
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . 17
Drew Expires 13 February 2027 [Page 2]
Internet-Draft DHCPv4 Routed Prefix August 2026
Appendix A. Design Notes for Revision -00 . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
DHCPv4 [RFC2131] provides a mechanism for assigning an IPv4 address
and other configuration information to a client. In many access
networks, however, the address used by a router to attach to the
upstream network is not necessarily the same address space that the
provider routes toward that router.
For example, a requesting router might receive:
On-link DHCP address: 100.64.20.17/24
Default router: 100.64.20.1
Additional routed prefix: 203.0.113.42/32
In this example, 203.0.113.42/32 is not on-link on the upstream
interface. The upstream network has independently arranged for
traffic destined to 203.0.113.42/32 to be forwarded toward the
requesting router.
This separation can be useful where globally unique IPv4 address
space is scarce. A provider can use shared, private, or otherwise
suitable addressing for subscriber attachment while assigning
globally routable IPv4 space only to subscribers that require it. It
also permits the routed resource to be a subnet, rather than
requiring the customer's globally routable address space to form part
of the access-link addressing plan.
DHCPv4 presently has mechanisms for telling a client _where to send_
traffic. For example, the Classless Static Route Option [RFC3442]
communicates destination prefixes and next hops that a client should
install. The mechanism defined here communicates the inverse
relationship: it tells a requesting router that specified prefixes
are routed _toward that router_ by the upstream network.
Cisco's Subnet Allocation Option, documented in [RFC6656], also
describes allocation of IPv4 subnets using DHCPv4. That protocol
contains request, allocation, renewal, release, deprecation,
hierarchy, and usage-reporting semantics. The option defined by this
document is deliberately narrower. It does not allocate a subnet and
does not define an independent subnet lease. It only conveys routing
information associated with the client's existing DHCPv4 lease.
Drew Expires 13 February 2027 [Page 3]
Internet-Draft DHCPv4 Routed Prefix August 2026
DHCPv6 Prefix Delegation, now specified by [RFC9915], demonstrates a
related architectural property in IPv6: a requesting router can use
one form of upstream attachment while prefixes used beyond that
attachment are separately communicated. The option defined here is
not an IPv4 port of DHCPv6 Prefix Delegation. It has no IA_PD-style
state machine, independent prefix lifetimes, prefix hints, or
delegation negotiation.
The purpose of this document is therefore limited to a missing DHCPv4
configuration primitive:
Inform a requesting router of one or more IPv4 prefixes that the
upstream network currently routes toward it, independently of the
client's on-link IPv4 address.
2. Requirements Language
The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
*SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *NOT RECOMMENDED*, *MAY*, and
*OPTIONAL* in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
This document uses the following terms:
*Client* A DHCPv4 client implementing this option. In the context
of this document, the client is normally a router.
*Requesting Router* A DHCPv4 client that receives routed-prefix
information and is capable of receiving traffic for those prefixes
from its upstream network.
*Attachment Address* The IPv4 address assigned to the client by
ordinary DHCPv4 mechanisms for use on the upstream link.
*Routed Prefix* An IPv4 network prefix that the upstream network
represents as being routed toward the requesting router. A Routed
Prefix is not, solely by virtue of this option, an on-link prefix
on the upstream interface.
*Upstream Network* The network providing the DHCPv4 service and
routing the advertised Routed Prefixes toward the requesting
router.
Drew Expires 13 February 2027 [Page 4]
Internet-Draft DHCPv4 Routed Prefix August 2026
4. Scope
This document defines only the communication of Routed Prefix
information.
It does not define:
* how the upstream network creates or distributes the route;
* how a server selects which prefixes are associated with a client;
* how the client assigns a prefix to an interface or downstream
link;
* how the client performs NAT, port translation, proxying, or
service binding;
* how the client further delegates a prefix;
* firewall policy;
* source-address authorization; or
* provider accounting, subscriber management, or routing policy.
A client MAY use a received Routed Prefix for NAT, local address
assignment, downstream routing, service binding, or another purpose,
subject to local policy. No such behavior is implied by receipt of
the option.
5. Routed IPv4 Prefix Option
5.1. Option Format
The DHCPv4 Routed IPv4 Prefix Option is encoded according to the DHCP
option format defined in [RFC2132] and has the following format:
Drew Expires 13 February 2027 [Page 5]
Internet-Draft DHCPv4 Routed Prefix August 2026
0 1 2 3
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 | Len | Prefix List Fragment ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code: TBD1
Len: Length, in octets, of this option instance's Prefix List
Fragment.
Prefix List Fragment:
A fragment of the concatenated Prefix List.
The option contains no next-hop field. The next-hop relationship is
already established by the client's ordinary DHCPv4 configuration and
the upstream network's routing state.
The Prefix List in an individual option instance can be a fragment of
the complete Prefix List. When multiple instances of this option
occur in a DHCP message, they MUST be concatenated before the Prefix
List is validated or parsed, as specified in [RFC3396].
The option contains no independent lifetime field. The validity of
the information is bound to the DHCPv4 lease as described in
Section 8.
5.2. Routed Prefix Descriptor
Each Routed Prefix is encoded using a compact prefix representation
similar to the destination-descriptor encoding in [RFC3442]:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
| |
. Prefix Bytes .
. .
+-+-+-+-+-+-+-+-+
Prefix Length is an unsigned integer from 1 through 32 specifying the
number of significant bits in the IPv4 prefix. A value of 0 is
invalid and MUST NOT be sent or accepted. A default-route prefix is
not suitable for this option because it would normally create a
routing loop between the upstream network and the requesting router.
Drew Expires 13 February 2027 [Page 6]
Internet-Draft DHCPv4 Routed Prefix August 2026
Prefix Bytes contains ceil(Prefix Length / 8) octets. Only the
significant octets of the IPv4 prefix are carried.
The number of prefix octets is therefore:
+===============+==============+
| Prefix Length | Prefix Bytes |
+===============+==============+
| 1-8 | 1 |
+---------------+--------------+
| 9-16 | 2 |
+---------------+--------------+
| 17-24 | 3 |
+---------------+--------------+
| 25-32 | 4 |
+---------------+--------------+
Table 1
When the prefix length is not an integer multiple of eight, any bits
in the final octet that lie outside the prefix length MUST be zero
when sent. A receiver MUST mask any such bits before constructing
the prefix.
For example:
+==================+====================+
| Routed Prefix | Encoded Descriptor |
+==================+====================+
| 10.0.0.0/8 | 08 0a |
+------------------+--------------------+
| 192.0.2.0/24 | 18 c0 00 02 |
+------------------+--------------------+
| 198.51.100.64/27 | 1b c6 33 64 40 |
+------------------+--------------------+
| 203.0.113.42/32 | 20 cb 00 71 2a |
+------------------+--------------------+
Table 2
5.3. Multiple Prefixes
Multiple Routed Prefix descriptors are concatenated directly in the
Prefix List.
For example, the following logical value:
Drew Expires 13 February 2027 [Page 7]
Internet-Draft DHCPv4 Routed Prefix August 2026
203.0.113.42/32
198.51.100.64/29
10.40.0.0/16
is encoded as three consecutive descriptors.
A client MUST process each descriptor after validating the complete
concatenated Prefix List.
A server MUST NOT include the same prefix more than once in the
effective option value.
5.4. Long Option Encoding
The Routed IPv4 Prefix Option is a concatenation-requiring option in
the sense of [RFC3396].
Clients implementing this option and servers sending this option
*MUST* implement DHCPv4 option splitting and concatenation as
specified by [RFC3396].
After concatenation, the resulting octet sequence is parsed as one
Prefix List.
6. DHCP Client Behavior
A client supporting the Routed IPv4 Prefix Option MUST include the
option code in the Parameter Request List option in every DHCPREQUEST
message. It SHOULD also include the code in any other DHCP message
that carries a Parameter Request List option.
A client receiving this option in a DHCPACK MUST interpret each
advertised prefix as a statement from the DHCP server that the
upstream network intends traffic for that prefix to be routed toward
the client for the validity period described in Section 8.
A client:
* *MUST NOT* infer that an advertised Routed Prefix is on-link on
its upstream interface solely because it appears in this option;
* *MUST NOT* alter its DHCP-assigned Attachment Address, subnet
mask, or Router option solely because this option is present;
* *MUST NOT* treat receipt of the option as proof of authorization
to originate packets using an address from an advertised prefix;
and
Drew Expires 13 February 2027 [Page 8]
Internet-Draft DHCPv4 Routed Prefix August 2026
* *MAY* make the prefix available to local routing, address
assignment, NAT, service-binding, or downstream configuration
mechanisms according to local policy.
A client that does not implement this option ignores it in accordance
with normal DHCPv4 option processing.
A malformed option MUST be ignored in its entirety. An option is
malformed if, after RFC 3396 concatenation, its Prefix List is empty,
any prefix descriptor is truncated, a Prefix Length is 0 or greater
than 32, or the option otherwise cannot be unambiguously parsed.
7. DHCP Server Behavior
A server MUST send this option only when the client requested it in
the Parameter Request List option of the corresponding client
message. A server MAY include it in a DHCPOFFER when the client
requested it, to indicate prefixes that the server intends to
associate with a lease.
The definitive Routed Prefix set is the set contained in the DHCPACK
that establishes or renews the lease.
A server sending this option:
* *MUST* include only prefixes that its provisioning and routing
system intends to route toward the client;
* *MUST* establish the corresponding routing state before sending
the DHCPACK containing the option;
* *MUST* include the complete current Routed Prefix set associated
with the lease in each DHCPACK in which the option is sent; and
* *MUST* encode prefixes in canonical form as described in this
document.
The mechanism by which the DHCP server learns the applicable Routed
Prefix set is outside the scope of this document. It may derive the
set from static configuration, subscriber provisioning, RADIUS, an
IPAM system, a routing controller, or another source.
8. Lease Lifetime, Renewal, and Withdrawal
A Routed Prefix conveyed by this option is valid only in association
with the DHCPv4 lease for which it was acknowledged.
Drew Expires 13 February 2027 [Page 9]
Internet-Draft DHCPv4 Routed Prefix August 2026
Unless another standards-track specification explicitly defines
different semantics for a future extension, a Routed Prefix has no
lifetime independent of the DHCPv4 lease.
When a client receives a DHCPACK containing this option, the option
value represents the server's current Routed Prefix set for that
lease.
If a prefix that was present in the previously acknowledged set is
absent from a subsequent DHCPACK that contains this option, the
client MUST cease treating that prefix as currently routed toward it.
If the DHCPv4 lease expires or is invalidated, the client MUST cease
treating all Routed Prefixes learned through that lease as currently
routed toward it.
A DHCP server that needs a client to renew before the normal T1/T2
timers MAY use existing DHCPv4 mechanisms such as DHCPFORCERENEW
[RFC3203], where operationally appropriate.
8.1. Absence of the Option
If a client requested this option in the DHCPREQUEST and the
acknowledging server had previously supplied the option for the same
lease, omission of the option from the subsequent DHCPACK MUST be
treated as withdrawal of all previously learned Routed Prefixes.
Thus, an empty response to a request for this option means that the
server no longer represents any additional prefixes as routed toward
the client.
A client MUST also withdraw the prefixes when the associated lease is
lost, expires, or is replaced by a lease from another server.
9. Relationship to Existing DHCP Routing Options
The Router option and the Classless Static Route Option [RFC3442]
describe routes the DHCP client should use to reach destinations.
This option describes prefixes for which the direction of
reachability is reversed:
Drew Expires 13 February 2027 [Page 10]
Internet-Draft DHCPv4 Routed Prefix August 2026
Classless Static Route Option:
DHCP client -----> destination prefix
via specified next hop
Routed IPv4 Prefix Option:
upstream network -----> advertised prefix
routed toward DHCP client
The two options therefore carry different information and MAY appear
in the same lease.
Receipt of the Routed IPv4 Prefix Option MUST NOT change the
processing rules for the Router or Classless Static Route options.
10. Relationship to RFC 6656 Subnet Allocation
[RFC6656] documents Cisco Systems' Subnet Allocation Option (option
220). That option can request and allocate IPv4 subnets and has
specific mechanisms for subnet lease lifetimes, renewals, releases,
deprecation, hierarchical allocation, and usage statistics.
The option specified by this document intentionally does not
reproduce that protocol.
In particular:
* the client does not request a particular prefix or prefix length
using this option;
* the server does not allocate a prefix as a separately leased
resource through this option;
* there are no per-prefix renewal or release transactions;
* there are no usage statistics;
* there is no hierarchical-allocation flag; and
* the advertised set is simply information associated with the
client's ordinary DHCPv4 lease.
This narrower model is intended for deployments in which the routing
or subscriber provisioning system already determines which prefixes
are routed toward a client and DHCPv4 is used to communicate that
existing state to the requesting router.
Drew Expires 13 February 2027 [Page 11]
Internet-Draft DHCPv4 Routed Prefix August 2026
11. Relationship to DHCPv6 Prefix Delegation
DHCPv6 includes Prefix Delegation as specified by [RFC9915]. Prefix
Delegation allows a DHCPv6 server to delegate IPv6 prefixes to a
client using dedicated identity associations and prefix lifetimes.
The mechanism specified here shares one useful architectural property
with DHCPv6 Prefix Delegation: the prefix used beyond a requesting
router can be distinct from the address used by that router for its
upstream attachment.
However, this specification does not reproduce DHCPv6-PD semantics
for IPv4.
There is no separate allocation transaction, no prefix-length hint,
no IA_PD equivalent, and no preferred/valid lifetime carried per
prefix. This option only communicates prefixes that the server's
upstream provisioning system already considers routed toward the
requesting router.
This specification is not intended as an alternative to IPv6
deployment.
12. Examples
The addresses used in these examples are documentation addresses and
are not intended for deployment.
12.1. Shared Attachment Address with a Routed Public /32
A provider uses Shared Address Space for subscriber attachment:
DHCP address: 100.64.20.17/24
Default router: 100.64.20.1
Routed Prefix: 203.0.113.42/32
The provider's routing system has arranged:
203.0.113.42/32 -> subscriber attachment
The DHCP server includes:
Routed IPv4 Prefix Option:
203.0.113.42/32
The requesting router continues to use 100.64.20.1 as its upstream
default router.
Drew Expires 13 February 2027 [Page 12]
Internet-Draft DHCPv4 Routed Prefix August 2026
The option does not specify whether the requesting router assigns
203.0.113.42 locally, uses it as a NAT address, routes it to another
device, or binds a service to it.
12.2. Routed Public Subnet
A business subscriber has:
DHCP attachment: 10.200.5.37/24
Default router: 10.200.5.1
Routed Prefix: 198.51.100.64/29
The requesting router receives the /29 through the Routed IPv4 Prefix
Option. The /29 is not considered on-link on the upstream interface
solely as a result of receiving the option.
The customer may route the /29 internally according to local policy.
12.3. Multiple Routed Prefixes
A requesting router receives:
203.0.113.42/32
198.51.100.64/29
10.40.0.0/16
The first two prefixes might be globally routable resources and the
third might be private routed space. The option itself makes no
distinction between public and private IPv4 prefixes.
12.4. Prefix Withdrawal on Renewal
Initial DHCPACK:
Routed Prefixes:
203.0.113.42/32
198.51.100.64/29
Later DHCPACK:
Routed Prefixes:
203.0.113.42/32
The client MUST cease treating 198.51.100.64/29 as routed toward it.
Drew Expires 13 February 2027 [Page 13]
Internet-Draft DHCPv4 Routed Prefix August 2026
The upstream network remains responsible for ensuring that revoked or
unassigned source addresses cannot be used contrary to network
policy.
13. Backwards Compatibility
DHCPv4 clients that do not recognize the option ignore it under
normal DHCP option processing.
The option does not change the semantics of the client's assigned
IPv4 address, subnet mask, Router option, Classless Static Route
Option, or other existing DHCPv4 options.
A server can therefore deploy this option for supporting requesting
routers without changing ordinary DHCPv4 behavior for clients that do
not implement it.
14. Operational Considerations
14.1. Routing State
The DHCP server's advertisement of a Routed Prefix does not create
the upstream route.
Operators MUST ensure that the corresponding routing state exists
before the DHCP server sends the DHCPACK containing the Routed
Prefix.
Likewise, when a prefix is withdrawn, operators SHOULD coordinate
withdrawal of routing state and subscriber authorization in a manner
that avoids unintended reassignment or traffic delivery.
14.2. Address Conservation
One motivation for the option is to allow access-link addressing to
be decoupled from routed customer IPv4 resources.
For example, a provider may maintain a large subscriber attachment
network using shared or private address space while allocating
individual globally routable /32 addresses or larger prefixes only
where required.
This document does not prescribe such an architecture and does not
require Carrier-Grade NAT.
Drew Expires 13 February 2027 [Page 14]
Internet-Draft DHCPv4 Routed Prefix August 2026
14.3. Client Use of Routed Prefixes
Implementations are expected to expose received Routed Prefixes to
appropriate local subsystems, but this document deliberately does not
mandate one use model.
Possible uses include:
* source NAT using an advertised /32;
* routing a larger prefix to a downstream interface;
* assigning an address from the prefix to a loopback or service
interface; or
* making the prefix available to another local network-management
component.
These are examples only.
15. Security Considerations
This option conveys routing information. It is not an authorization
credential.
A client *MUST NOT* treat possession or receipt of a Routed Prefix as
cryptographic or administrative proof that the client is authorized
to originate packets using addresses from that prefix.
The upstream network remains responsible for source-address
validation and subscriber policy. Techniques such as ingress
filtering described by BCP 38 [RFC2827], access-layer source
validation, or equivalent provider controls can be used as
appropriate.
The security considerations of DHCPv4 [RFC2131] apply. A forged or
malicious DHCP response containing this option could cause a client
to believe that prefixes are routed toward it when they are not.
This may cause denial of service, accidental address conflicts,
incorrect NAT behavior, or exposure of services.
Where DHCP authentication is deployed, [RFC3118] provides mechanisms
for authenticating DHCP messages. Deployments may also rely on
lower-layer controls, DHCP snooping, trusted access links, or other
mechanisms appropriate to their environment.
Drew Expires 13 February 2027 [Page 15]
Internet-Draft DHCPv4 Routed Prefix August 2026
A server MUST NOT advertise a prefix to a client merely because the
client claims or requests use of that prefix through some unrelated
mechanism. The advertised set must originate from trusted
provisioning or routing policy.
A client SHOULD remove withdrawn prefix state promptly. However,
upstream enforcement MUST NOT assume that every client will behave
correctly after withdrawal.
16. IANA Considerations
IANA is requested to assign one DHCPv4 option code from the "BOOTP
Vendor Extensions and DHCP Options" registry for:
+=======+====================+=============+========================+
| Value | Name | Data Length | Meaning |
+=======+====================+=============+========================+
| TBD1 | Routed IPv4 | N | IPv4 prefixes routed |
| | Prefix | | toward the DHCP client |
+-------+--------------------+-------------+------------------------+
Table 3
The registration should reference this document.
The option is a concatenation-requiring option as specified by
[RFC3396].
17. Acknowledgements
The author would like to thank the DHCP and operational networking
communities for prior work on DHCPv4 routing options, IPv4 subnet
allocation, and DHCPv6 Prefix Delegation that informed this proposal.
18. References
18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>.
Drew Expires 13 February 2027 [Page 16]
Internet-Draft DHCPv4 Routed Prefix August 2026
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/rfc/rfc2132>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
DOI 10.17487/RFC3396, November 2002,
<https://www.rfc-editor.org/rfc/rfc3396>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
18.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<https://www.rfc-editor.org/rfc/rfc3118>.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, DOI 10.17487/RFC3203,
December 2001, <https://www.rfc-editor.org/rfc/rfc3203>.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442,
DOI 10.17487/RFC3442, December 2002,
<https://www.rfc-editor.org/rfc/rfc3442>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <https://www.rfc-editor.org/rfc/rfc6598>.
[RFC6656] Johnson, R., Kinnear, K., and M. Stapp, "Description of
Cisco Systems' Subnet Allocation Option for DHCPv4",
RFC 6656, DOI 10.17487/RFC6656, July 2012,
<https://www.rfc-editor.org/rfc/rfc6656>.
Drew Expires 13 February 2027 [Page 17]
Internet-Draft DHCPv4 Routed Prefix August 2026
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/rfc/rfc9915>.
Appendix A. Design Notes for Revision -00
This appendix is non-normative and is expected to be removed or
revised before publication.
Items for early working-group discussion include:
1. Whether the Parameter Request List requirement is sufficient
client capability signaling.
2. Whether the compact RFC 3442-style prefix encoding is preferable
to fixed-width {IPv4 address, prefix length} tuples.
3. Whether additional text is required to distinguish this mechanism
from the Cisco Subnet Allocation Option in RFC 6656.
4. Whether the DHC working group prefers another name, such as
"DHCPv4 Routed Prefix Information Option".
Author's Address
Brendon Drew
Email: brendon@drewnet.com.au
Drew Expires 13 February 2027 [Page 18]