Summary

  • RFC 9637 reserves 3fff::/20 for realistic IPv6 documentation and says it must not carry actual traffic or be globally advertised.
  • IANA's special-purpose row defines the block's intended semantics; it does not prove that every routing and packet boundary has loaded or enforced them.
  • A useful isolation receipt joins the current registry row, example provenance, environment purpose, policy version, installation scope, route observations, packet evidence, exceptions and application outcome.

The network diagram was excellent. It had regions, aggregation layers, customer segments and enough address space to look like a serious deployment. Someone copied its configuration into a connected lab.

The addresses were still reserved for documentation. That fact had not changed. What changed was the authority of the artifact: a diagram had become running configuration. If the lab could originate routes, exchange packets or reach production, the word documentation no longer described the operational boundary.

RFC 9637 was written to make large IPv6 examples safer and more realistic. It adds 3fff::/20 to the documentation space established by RFC 3849. The larger block lets authors model allocation patterns that would not fit comfortably under 2001:db8::/32 without borrowing space assigned to someone else or space that might later be allocated.

That is a valuable symbolic guarantee. It is not a packet receipt.

Five false properties, not five deployed controls

The IANA IPv6 Special-Purpose Address Registry records 3fff::/20 as Documentation. Its Source, Destination, Forwardable, Globally Reachable and Reserved-by-Protocol properties are false.

Those fields answer questions about the registered purpose of the block. They do not testify that every router has an ACL, every peer rejects an announcement, every host rejects a destination, every source-validation rule is current or every tunnel exposes the inner address to the same policy.

This distinction is easy to lose because a registry row is crisp and global while enforcement is fragmented. IANA can name the block. The IETF can say it MUST NOT be used for actual traffic and MUST NOT be globally advertised. Each operator still controls its own route policy, packet policy, software release, exception process and monitoring.

RFC 6890 gives the registry fields a common model. A model reduces ambiguity across implementations; it does not collapse configuration, installed state and observed behavior into one layer.

A route rejection is not a packet drop

There are at least four different claims hidden inside “we block documentation space.”

First, the network may reject a route whose NLRI falls under 3fff::/20. Second, it may prevent its own systems from originating such a route. Third, it may drop packets whose source belongs to the prefix. Fourth, it may drop packets whose destination belongs to the prefix.

These controls overlap, but none proves all the others. A route filter can stop one BGP path while an internal static route, tunnel or private interconnect remains. A source filter can reject some spoofed packets without saying anything about destination forwarding. A destination drop observed at one edge does not establish behavior at every ingress. RFC 3704 shows why even source validation has several feasible-path choices in multihomed networks.

The receipt therefore needs direction and attachment point. “Bogon filter installed” is too vague. Record the policy version, the exact prefix set, route import and export placement, source and destination packet placement, device or service scope, installation result, counters, exceptions and observation interval.

Silence at one collector has a boundary

A route absent from one routing table or collector is useful evidence. It supports the statement that this observation surface did not see the route during a stated interval. It does not prove that no autonomous system originated it, that no private peer accepted it, that no short-lived leak occurred between samples or that no internal route carried it.

The same rule applies to probes. A packet dropped from one vantage point establishes that path, time and packet construction. It does not establish universal unreachability. Conversely, a reply would establish a serious observation about that path, not automatically identify the responsible configuration or prove global reachability.

The strongest public report keeps negative evidence scoped. It names collectors or vantage classes, timestamps, sampling intervals, address and protocol coverage, and blind spots. “Not observed” becomes credible when it says where observation ended.

Realistic examples need a visible stage edge

The reason for 3fff::/20 is realism. RFC 9637 cites August 2023 RIR statistics to show that many IPv6 allocations were larger than /32 and that /29 was common. The figures are historical design rationale, not a live census, but the architectural point remains: a large example can now represent hierarchy, aggregation and multiple sites without using another party's addresses.

Realism improves teaching and review. It also makes an example easier to mistake for deployable configuration. A repository should mark which files are prose, simulator input, disconnected lab data or production templates. CI can reject documentation prefixes from production manifests while allowing them in fixtures. Environment promotion should rebind addresses explicitly rather than carrying example values forward by accident.

The prefix alone cannot infer that context. A parser sees an IPv6 address; a policy engine needs the artifact class and destination environment. “Reserved for documentation” is a constraint on use, not a self-enforcing type system.

The isolation receipt

A defensible receipt begins with a dated registry snapshot and the governing RFC. It links that classification to the exact diagram, example or configuration containing the prefix. It states the intended environment and who authorized any connected test.

Next come controls: route-origin prevention, import and export policy, source and destination filters, attachment points, software or list versions, successful installation and exceptions. Observation follows: route tables and collectors over a defined interval, packet counters, scoped probes and application logs. The final field is outcome—whether the example remained a document, a disconnected simulation, an approved lab exercise or an unintended production dependency.

The chain preserves separate authority. IANA classifies. Authors create examples. Operators configure boundaries. Routers and hosts enforce. Observers see limited surfaces. Applications reveal consequences. None should borrow the certainty of another.

Sources