Internet-Draft DHCPv6-PD Sub-Range Delegation January 2026
Horley Expires 31 July 2026 [Page]
Workgroup:
Dynamic Host Configuration
Internet-Draft:
draft-horley-dhc-pd2r-latest
Published:
Intended Status:
Informational
Expires:
Author:
E. Horley
HexaBuild

Reserved Interface Identifier Sub-Range Delegation for IPv6 Endpoints

Abstract

This document specifies a mechanism allowing DHCPv6 servers to allocate small Interface Identifier (IID) sub-ranges (e.g., /96 or /120 blocks) from within the lower 64 bits of an IPv6 on-link /64. These sub-ranges provide hosts with deterministic, host-specific address pools while preserving normal Neighbor Discovery (ND) and Router Advertisement (RA) behavior. Clients continue to treat the prefix as a /64 for all purposes, including ND, and may freely assign addresses from the reserved sub-range to any local interface (including a CLAT internal interface). This specification maintains architectural requirements for IPv6 subnetting, avoids introducing new routing semantics, and enables hosts to perform richer internal addressing without disrupting the network.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://github.com/hexabuild/draft-horley-dhc-pd2r. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-horley-dhc-pd2r/.

Discussion of this document takes place on the Dynamic Host Configuration Working Group mailing list (mailto:dhcwg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dhcwg/. Subscribe at https://www.ietf.org/mailman/listinfo/dhcwg/.

Source for this draft and an issue tracker can be found at https://github.com/hexabuild/draft-horley-dhc-pd2r.

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 31 July 2026.

▲

Table of Contents

1. Introduction

IPv6 addressing architecture defines a /64 prefix boundary between the network prefix and Interface Identifier (IID). Hosts typically obtain IPv6 addresses through SLAAC, DHCPv6 IA_NA, DHCPv6 IA_PD, or combinations thereof. However, emerging endpoint architectures—multi-interface nodes, CLAT translators (RFC 6877), virtual machine hosting, and container networks—require access to *multiple deterministic IPv6 addresses belonging to the same on-link /64.

Prefix Delegation (PD) is not appropriate in these situations because:

This document introduces IID Sub-Range Reservation, allowing a DHCPv6 server to reserve a block of IIDs in the lower 64 bits of an on-link /64 and deliver it to the client—*without altering router advertisements or ND behavior. Hosts continue to perceive the network prefix as a normal /64. The reserved block is not a delegated prefix, not routed, and not advertised externally.

This mechanism extends conceptual models from RFC 9663 by specifying concrete DHCPv6 behavior, algorithms, interoperability rules, and examples.

2. Conventions and Definitions

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

Parent Prefix: The /64 prefix advertised via RA.

IID Sub-Range: A reserved block of the lower 64 bits, commonly /96 or /120.

Reserved IID Range: The usable IPv6 addresses created by concatenating ParentPrefix[0:64] with the IID sub-range.

CLAT Host: A Customer-side translator using IPv6 addresses for NAT64/CLAT internal mappings.

4. Requirements and Constraints

This specification MUST meet the following:

  1. Do not alter SLAAC. SLAAC MUST operate normally. Host MUST consider the on-link prefix to be /64.

  2. No changes to Router Advertisements. RAs MUST NOT be extended with additional options related to reserved sub-ranges.

  3. Server-managed uniqueness. DHCPv6 server MUST ensure IID ranges do not overlap between clients.

  4. Clients are not required to advertise these prefixes. The reserved range is local-only and MUST NOT be treated as a routed prefix.

  5. Host-local multi-interface use allowed. Clients MAY assign sub-range addresses to any local interface.

  6. If DHCPv6 and SLAAC are run on the same on-link via the RA, then simple duplicate address detection will be used for the rare cases where a SLAAC address is dynamically generated in one of the IID Sub-Ranges that is in use. The host that is allocated the IID Sub-Range MUST do the DAD response on behalf of the entire range.

5. Mechanism Overview

The mechanism operates in the following phases:

``` +---------+ DHCPv6 IA_NA + OPTION_IID_SUBRANGE +---------+ | Client | <----------------------------------------------------> | Server | +---------+ +---------+

  1. Client sends SOLICIT.

  2. Server allocates and returns IID sub-range via OPTION_IID_SUBRANGE.

  3. Client configures any number of addresses from that range.

  4. Client still processes RA and SLAAC normally. ```

The DHCPv6 server never advertises a prefix and never signals a non-/64 boundary.

6. Protocol Overview

A new DHCPv6 option, OPTION_IID_SUBRANGE, provides:

The client treats addresses formed from this range as additional IPv6 addresses. These addresses:

7. DHCPv6 OPTION_IID_SUBRANGE

7.1. 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IID_SUBRANGE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ParentPrefix (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RangeStartIID (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RangeEndIID (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (16 bits) | Lifetime (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.1.1. Field Requirements

  • ParentPrefix MUST be a /64 (low 64 bits = 0).

  • RangeStartIID and RangeEndIID MUST satisfy Start ≤ End.

  • Lifetime MUST be treated similar to IA_NA lifetimes.

8. Server Operation

This section defines normative algorithms.

8.1. Server Allocation Algorithm

8.1.1. Allocation Preconditions

Server MUST know:

  • The RA-advertised /64 for the link.

  • The administrative IID allocation pool (e.g., 0x0000:0000:0000:0000–0x0000:0000:00FF:FFFF).

8.1.2. Algorithm (Normative)

Python example:

``` function allocate_iid_subrange(client_duid): pool = get_available_iid_ranges() if pool is empty: return ERROR_NoAvailableRange

range = select_smallest_available_block(pool)  # SHOULD pick /120
mark_range_as_reserved(range, client_duid)
return range ```

8.1.3. Rebinding

If a client repeats SOLICIT with the same DUID:

if existing_assignment_for(client_duid): return existing_assignment else: return allocate_iid_subrange(client_duid)

8.1.4. Collision Prevention

Server MUST guarantee:

ReservedRange(clientA) ∩ ReservedRange(clientB) = ∅.

8.2. Example Server Policy

A server MAY divide the lower IID /80–/120 into blocks:

2001:db8:1000:200::0000/120 → Client 1 2001:db8:1000:200::0100/120 → Client 2 2001:db8:1000:200::0200/120 → Client 3 ...

9. Client Operation

Client MUST follow these rules:

  1. Continue processing RAs and SLAAC as usual.

  2. Treat ParentPrefix as /64.

  3. Validate ParentPrefix against local RAs.

  4. Create addresses: example:

IPv6Address = ParentPrefix/[0:64] || IID_value

  1. Perform DAD normally.

  2. MAY assign any sub-range address to: - primary interface - CLAT internal interface - loopback - virtual NICs - containers

10. Examples

10.1. Example DHCPv6 Exchange

``` Client → SOLICIT

Server → ADVERTISE IA_NA: 2001:db8:1000:200::a8f1 OPTION_IID_SUBRANGE: ParentPrefix: 2001:db8:1000:200::/64 StartIID: 0x0000000000000100 EndIID: 0x00000000000001FF Lifetime: 7200

Client → REQUEST

Server → REPLY (same contents) ```

Client may now assign:

2001:db8:1000:200::100 2001:db8:1000:200::101 ... 2001:db8:1000:200::1FF

11. CLAT Use Cases

11.1. CLAT IID Reservation

A CLAT host MUST use a deterministic IPv6 address for its NAT64-binding IPv6 endpoint.

Today, implementations typically:

  • derive the CLAT IPv6 address from EUI-64 or stable IID

  • rely on RFC 7217 private addresses

  • limit the host to one CLAT address

With IID sub-ranges, the host MAY allocate:

  • one address for CLAT internal translation

  • other addresses for per-flow, per-container, or per-service mapping

11.1.1. Example CLAT Assignment

``` Reserved range: 2001:db8:1000:200::200–::2FF

CLAT internal interface: 2001:db8:1000:200::200

Container A (CLAT-enhanced): 2001:db8:1000:200::210

Container B: 2001:db8:1000:200::220

Host loopback: 2001:db8:1000:200::2FF ```

CLAT behavior is unchanged; the host simply has more stable options.

State Machines

11.2. Server State Machine

+----------------+ | INIT | +--------+-------+ | v +--------+-------+ | WAIT_SOLICIT | +--------+-------+ | SOLICIT v +--------+-------+ | ALLOCATE_RANGE | +--------+-------+ | v +--------+-------+ | SEND_ADVERTISE | +--------+-------+ | REQUEST v +--------+-------+ | SEND_REPLY | +----------------+

11.2.1. Client State Machine

+-------------+ | INIT | +------+------+ | v +------+------+ RA arrives | LISTEN_RA |------------------------------+ +------+------+ | | | v | +------+------+ | | SOLICIT | | +------+------+ | | DHCPv6 ADVERTISE | v | +------+-------+ | | PROCESS_OPT | ← Validate ParentPrefix ←----+ +------+-------+ | v +------+-------+ | CONFIG_IIDS | +------+-------+ | v +------+-------+ | OPERATE | +--------------+

12. Validation Logic

Client MUST:

  1. Confirm ParentPrefix matches a prefix advertised via RA.

  2. Reject options referencing unknown or non-/64 prefixes.

  3. Ensure RangeEndIID ≥ RangeStartIID.

  4. Ensure generated addresses succeed in DAD.

  5. Ignore invalid or overlapping sub-ranges.

Server MUST:

  1. Guarantee exclusivity of IID ranges.

  2. Validate ParentPrefix is an on-link /64.

  3. Reject attempts to allocate ranges outside administrative pools.

13. Security Considerations

14. IANA Considerations

IANA is requested to assign a DHCPv6 option code for:

OPTION_IID_SUBRANGE

15. 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>.
[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>.

Acknowledgments

The author(s) would like to acknowledge the valuable input and contributions from Tim Winters, Nick Buraglio, and Tommy Jensen.

Author's Address

Ed Horley
HexaBuild