Internet-Draft DHCPv4 Routed Prefix August 2026
Drew Expires 13 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-drew-dhc-v4-routed-prefix-00
Published:
Intended Status:
Standards Track
Expires:
Author:
B. Drew

DHCPv4 Routed Prefix Option

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.

▲

Table of Contents

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.

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:

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.

4. Scope

This document defines only the communication of Routed Prefix information.

It does not define:

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:

       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.

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:

Table 1
Prefix Length Prefix Bytes
1-8 1
9-16 2
17-24 3
25-32 4

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:

Table 2
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

5.3. Multiple Prefixes

Multiple Routed Prefix descriptors are concatenated directly in the Prefix List.

For example, the following logical value:

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:

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:

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.

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:

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:

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.

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.

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.

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.

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.

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:

Table 3
Value Name Data Length Meaning
TBD1 Routed IPv4 Prefix N IPv4 prefixes routed toward the DHCP client

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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2131]
Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, , <https://www.rfc-editor.org/rfc/rfc2131>.
[RFC2132]
Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc6656>.
[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, , <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