Dynamic Host Configuration E. Horley Internet-Draft HexaBuild Intended status: Informational 27 January 2026 Expires: 31 July 2026 Reserved Interface Identifier Sub-Range Delegation for IPv6 Endpoints draft-horley-dhc-pd2r-latest 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. 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 2. Conventions and Definitions 3. Terminology 4. Requirements and Constraints 5. Mechanism Overview 6. Protocol Overview 7. DHCPv6 OPTION_IID_SUBRANGE 7.1. Format 7.1.1. Field Requirements 8. Server Operation 8.1. Server Allocation Algorithm 8.1.1. Allocation Preconditions 8.1.2. Algorithm (Normative) 8.1.3. Rebinding 8.1.4. Collision Prevention 8.2. Example Server Policy 9. Client Operation 10. Examples 10.1. Example DHCPv6 Exchange 11. CLAT Use Cases 11.1. CLAT IID Reservation 11.1.1. Example CLAT Assignment 11.2. Server State Machine 11.2.1. Client State Machine 12. Validation Logic 13. Security Considerations 14. IANA Considerations 15. Normative References Acknowledgments Author's Address 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: * PD produces a routed prefix, not intended for assignment on the link. * PD requires router participation, not available on access links like Wi-Fi or residential broadband. * Hosts need the additional addresses locally, not as routed subnets. 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: * ParentPrefix (always a /64) * StartIID * EndIID * Lifetime The client treats addresses formed from this range as _additional IPv6 addresses_. These addresses: * belong to the on-link /64 * are not SLAAC addresses and do not follow IID rules (stable/ private) * MUST pass DAD * MAY be used by any local interface 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 * Predictable IID ranges may reveal host identity patterns; operators SHOULD allow randomized distribution. * DHCPv6 authentication SHOULD be used when available. * No new attacks on SLAAC or RAs are introduced. 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, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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 Email: ed@hexabuild.io