Reservation of f000::/4 for Structured Internal-Use IPv6 Addressing

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 6 November 2025.¶

Copyright Notice

Copyright (c) 2025 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

IPv6 was designed with the intention of end-to-end global addressing, eliminating the need for NAT and simplifying global routing. However, practical deployment experience has shown that not all devices, networks, or use cases benefit from global addressability. Internal networks, isolated infrastructures, and large-scale private deployments continue to need structured, non-routable address space for segmentation, privacy, hierarchy, and operational simplicity.¶

RFC 4193 introduced the fc00::/7 block for Unique Local Addresses (ULAs), but it is relatively constrained in size, and the distinction between "fc" and "fd" prefixes can be ambiguous in practice. Meanwhile, many real-world networks have adopted other portions of the unallocated high-bit IPv6 space (e.g., f000::/4) for internal use.¶

This document proposes formally reserving f000::/4 for structured internal addressing, preventing its future use as public address space and aligning official policy with existing practice.¶

2. Motivation

Despite the expansive address space provided by IPv6, there remains a fundamental need for private, non-globally routable address blocks. Several practical realities drive this requirement:¶

• Not every device is suited for global connectivity. Many devices, such as embedded controllers, IoT sensors, and legacy systems, are best kept off the public internet.¶

• Some ISPs offer only limited IPv6 connectivity (e.g., a single /64 or one usable global address, sometimes with port restrictions).¶

• Organisations frequently operate geographically distributed internal networks connected by VPNs or other overlays that should remain isolated from the public internet.¶

• Address planning and hierarchical segmentation benefit from a larger and more structured internal-use space than fc00::/7 currently allows.¶

3. Structured Addressing Use Case

Consider an organisation that operates multiple locations and entities. Their addressing may follow a hierarchy such as:¶

f1:33:3:1a::7:1a - Company 1, France, Strasbourg, Building A, VM segment, NIC A¶

f2:33:3:1a::7:1a - Company 2, same site and structure, but logically separated at the top level¶

In this model:

• The first hexadecimal (f1, f2, etc.) denotes logical separation (e.g., company, person, function)¶

• Subsequent fields denote country codes, regions, buildings, and network segments¶

• The final octets define purposes (e.g., VM, NIC, sensors)¶

Such structured internal addressing supports ease of management, deterministic routing, and strong auditability - attributes that are especially valuable in private sector, defence, industrial, and inter-organisational settings.¶

4. Real-World Adoption

In practice, many network administrators already use f000::/4 or its subranges for internal networks. Examples include:¶

- Enterprises avoiding `fc00::/7` due to Matter protocol conflicts
- Data centres using f8::/8 as a structured overlay
- Multi-site VPNs mapping `f000::/4` internally with consistent schemes

Despite no official allocation, the range is already widely treated as non-routable and internal-only. However, if IANA were to assign f000::/4 for global use in future, it would create significant conflicts for these deployments.¶

5. Proposal

This document proposes:¶

• IANA formally reserves `f000::/4` for internal-use structured IPv6 addressing.¶

• This range MUST NOT be advertised on the public internet.¶

• Implementations SHOULD treat packets from this range as unroutable across public interfaces.¶

• Operators MAY use this block for internal routing, NAT66, NPTv6, overlay networks, and segmented infrastructures.¶

6. IANA Considerations

IANA is requested to update the IPv6 Special-Purpose Address Registry with the following entry:¶

  Address Block:      f000::/4
  Name:               Structured Internal-Use IPv6 Space
  RFC:                [This Document]
  Allocation Date:    [To Be Filled by IANA]
  Termination Date:   N/A
  Source:             False
  Destination:        False
  Forwardable:        False
  Global:             False
  Reserved-by-Protocol: False

7. Security Considerations

Reserving f000::/4 for structured internal use introduces no new security vulnerabilities. On the contrary, it enhances operational clarity by preventing potential leakage of internal addresses into the global space. Operators must still apply appropriate internal firewalls, access controls, and traffic isolation.¶

Author's Address