Summary

  • RFC 6666 assigns 100::/64 as a dedicated IPv6 Discard-Only Address Block. An operator may carry it inside an autonomous system and resolve it to null interfaces, but it should not be exchanged with third-party ASes.
  • The prefix is not the victim route, the BLACKHOLE community or a packet receipt. A trigger becomes evidence only when the intended prefix is authorised, accepted, resolved into the FIB, observed discarding at the intended edges and kept inside its scope.
  • Nick Hilliard and David Freedman coauthored the Informational RFC. Their useful contribution was collaborative operational clarity: a globally unique name for a strictly bounded action, not a global service and not a mandate to deploy it.

The route that was accepted too early

Imagine an IPv6 service under volumetric attack. An authorised operator injects a /128 for the targeted address into iBGP, gives it a next hop inside 100::/64, and sees the route accepted on every border router. The automation closes the incident as “blackhole active.”

That conclusion is one receipt too early. On three edges, recursion reaches a static route to a null interface and the victim traffic stops. On a fourth, the static discard route is absent, so the BGP route never becomes a usable forwarding entry. On a fifth, an export policy leaks the discard prefix to a neighbour. The controller saw a coherent control-plane object; the packets met three different outcomes.

No real incident is being described here. The example isolates the contract that RFC 6666 makes possible and the evidence it does not supply by itself.

A globally unique address for a local act

Destination-based remote-triggered blackholing changes the route for the attacked host or network so traffic is discarded before it consumes deeper links and systems. Earlier IPv4 deployments often pointed the victim route at private address space that every edge already sent to a null interface. That worked operationally, but it borrowed a namespace meant for another purpose. Reusing documentation space was worse: example addresses are supposed to remain examples, not become a production control dependency.

RFC 6666 therefore asked for a dedicated IPv6 block. IANA records 100::/64—the normalized form of 0100::/64—as the Discard-Only Address Block. No end party owns an assignment from it. The current registry marks it usable as source and destination and forwardable, while also marking it not globally reachable.

Those columns are not in conflict. “Forwardable” allows routers inside a controlled domain to carry the address through ordinary forwarding and recursive-lookup machinery. “Not globally reachable” states the intended external boundary. The address has to look sufficiently like unicast for routing machinery to use it, while remaining unsuitable as an inter-domain destination.

This is a useful example of a registry doing narrow work. IANA gives operators one unambiguous codepoint. It does not install a static route, select an ingress edge, approve a victim prefix, discard a packet or accept liability for collateral loss. The record coordinates meaning; the operator controls execution.

Three controls that must not be collapsed

The first distinction is between destination and source RTBH. Destination blackholing sacrifices reachability to the attacked address so that attack traffic is stopped near ingress. Source RTBH combines routing state with unicast reverse-path forwarding to reject packets whose claimed source should resolve through a discard path. The goals and failure modes differ. A receipt for one does not certify the other.

The second distinction is between discard and sinkhole. A null interface destroys the packet. A sinkhole diverts traffic to an analysis system and may, depending on design, reinsert selected traffic into normal forwarding. Calling both “blackhole” erases whether evidence was retained and whether legitimate traffic had any path onward.

The third distinction is between 100::/64 and the RFC 7999 BLACKHOLE community. The address block provides a consistent recursive next hop inside a routing domain. The community is an advisory label attached to the victim prefix. A neighbour may honour it only under an agreed policy and after verifying that the announcing network is authorised for the prefix. Equipment should not discard merely because the bit pattern appears; explicit operator configuration remains necessary.

A community receipt can therefore prove that a signal arrived. It cannot prove that the recipient accepted the route, installed a discard action or stopped propagation. Conversely, a router can use 100::/64 internally without asking an external neighbour to honour the BLACKHOLE community. One object carries policy intent across a relationship; the other makes local recursive forwarding deterministic.

The prefix must be present and absent at the same time

Inside an AS, some or all of 100::/64 may be announced by an IGP or another dynamic protocol and resolved to a null interface on some or all routers. That “some” matters. A design may intend discard only at ingress edges, while another may want a consistent internal fallback. The topology, hardware and incident objective decide.

At the inter-domain boundary, the result reverses. RFC 6666 says the prefix or its subnets should not be announced to or accepted from third-party ASes, and traffic addressed to it should not cross those boundaries. A leak can attract traffic toward the very network already handling an attack. The mechanism designed to remove load can become a new path for load.

The healthy state is therefore asymmetric: internally resolvable where the policy needs it, externally filtered everywhere. A single global “route present” light cannot represent that state. The same route is required on one side of the boundary and prohibited on the other.

A six-receipt evidence chain

The first receipt is authority. It names who approved the blackhole, the exact victim prefix, the permitted scope, the reason, the start time and the expiry. A customer should not be able to discard an unrelated network; an internal system should not turn a stale alert into an indefinite route.

The second is control-plane acceptance. It records the trigger route, community, next hop, receiving routers and policy decision. This is where malformed attributes, prefix-length filters, RPKI policy and origin checks can prevent intended activation. Acceptance is necessary, but it is still only a RIB event.

The third is recursive resolution and FIB installation. Each intended ingress must show that the victim prefix resolves through the selected address in 100::/64 to the expected discard interface. A route visible in a controller, route reflector or RIB can lose in selection, fail recursion or be rejected by the forwarding plane.

The fourth is packet outcome. Interface, forwarding or platform counters should show attack traffic being discarded at the named edge. Clean canary tests should show the expected loss for the victim address without claiming that one probe represents every source. A zero counter may mean no traffic arrived, the wrong edge was selected, telemetry is broken or the FIB action was never installed.

The fifth is containment. eBGP Adj-RIB-Out, route collectors where appropriate, neighbour policy and prefix filters should demonstrate that neither 100::/64 nor an unintended trigger escaped the authorised domain. Silence in one public collector is not proof of universal absence, so the operator must keep local export evidence.

The sixth is recovery. Withdrawal of the trigger, removal from the FIB, restoration of ordinary reachability and expiry of the authority record need their own timestamps. A historical discard counter proves that packets once died; it does not prove the blackhole remains active or that service recovered cleanly.

Collateral damage is part of the decision

Destination blackholing protects a wider system by making the targeted address unreachable to attackers and legitimate users alike. That is not a hidden side effect. It is the trade. The narrowest defensible prefix reduces collateral loss, but the route still needs to be accepted by the internal policies and hardware that carry it. RFC 7999 notes why blackhole routes are often more specific than prefixes ordinarily accepted on the public Internet; policy must recognise the exceptional purpose without creating an unrestricted bypass.

The operator should therefore record what continued to work after activation. Did shared access links recover? Did neighbouring services in the same aggregate remain reachable? Did the attack move to another address? Did the trigger suppress only destination traffic, or did an unexpected source-based rule broaden the loss? “Traffic fell” is not enough when the mechanism itself destroys traffic by design.

Hilliard's contribution is precision, not ownership

Nick Hilliard's IETF profile records RFC 6666 among six RFCs. The document was coauthored with David Freedman, reviewed through the IETF and published as Informational. It should not be recast as a personal standard or a universal command.

The durable idea is smaller and more useful. Operational controls deserve their own namespace rather than borrowing documentation or private-purpose addresses. The name should also expose the boundary of the action. 100::/64 is valuable because everyone can know what it means and because nobody should treat it as a globally reachable service.

That is close to the larger discipline of keeping a ledger separate from the network. A registry row can make a control legible. Running systems, explicit authority and packet evidence determine whether it worked.

Sources