Blackhole and Static Route Hygiene for a Free /48 You Originate

Disclosure up front: I run IPYE, a company that leases IP space. Most of this article is practical how-to; IPYE appears where a free /48, LOA, or ROA helps you try the work, with a short call to action at the end.

Blackhole routes and static routes are small, sharp tools. On an edge that originates a prefix, a correct blackhole keeps unused space from looping and protects you during attacks. A wrong one can withdraw your service, or announce routes you never meant to send. This article covers safe patterns for an edge announcing a free IPv6 /48 from IPYE, with 2001:db8:100::/48 and AS64496 as examples.

Three kinds of discard route on Linux

Linux has three route types that drop traffic:

ip -6 route add blackhole   2001:db8:100:99::/64   # drop silently
ip -6 route add unreachable 2001:db8:100:98::/64   # drop, send ICMPv6 unreachable
ip -6 route add prohibit    2001:db8:100:97::/64   # drop, send administratively prohibited

Use blackhole for attack traffic. The other two generate ICMPv6 errors for every dropped packet, which adds load during a flood. They are better for unused space inside your own network, where a quick error helps people debugging.

The aggregate anchor is a good blackhole

A blackhole for the whole /48 is the standard way to originate it:

ip -6 route add blackhole 2001:db8:100::/48

The BGP daemon needs a route to advertise, and the blackhole provides one. Any more-specific route, such as a connected /64 or a WireGuard peer's range, wins by longest match, so real traffic is delivered. Packets for unused parts of the /48 are dropped at your edge instead of being sent back to the upstream's default route and looping until their hop limit runs out.

The anchor is safe as long as your outbound policy allows only the /48 itself.

The dangerous one: redistributing statics

The most common blackhole accident is redistribute static on the BGP process. Every static route then becomes a candidate for export, including /64 blackholes you added during an attack and any test route someone left behind. Avoid redistribution and use network statements, or filter it explicitly:

ipv6 prefix-list OUT-V6 seq 10 permit 2001:db8:100::/48
!
route-map REDIST-STATIC permit 10
 match ipv6 address prefix-list OUT-V6
!
router bgp 64496
 address-family ipv6 unicast
  redistribute static route-map REDIST-STATIC
  neighbor 2001:db8:0:1::1 prefix-list OUT-V6 out

Two layers of filtering, at redistribution and at the neighbour, mean a single mistake does not leak.

Check what you actually send:

vtysh -c 'show bgp ipv6 unicast neighbors 2001:db8:0:1::1 advertised-routes'

It should list exactly one prefix.

Local discard versus remote blackholing

A local blackhole stops traffic at your router. During a volumetric attack that is too late, because the traffic has already filled the link from your upstream. Remote-triggered blackholing (RTBH) asks the upstream to drop it before it reaches you, usually by sending a /128 with the upstream's blackhole community. That sacrifices the attacked address to save everything else. Ask your upstream whether they support it and how, and test it once on an unused /128 outside an emergency.

Label every manual route

Plain ip route entries carry no description. Use FRR's static routes, which can carry a tag, and keep a comment in the configuration:

! ticket 4711, attack on 2001:db8:100:99::/64, remove after review
ipv6 route 2001:db8:100:99::/64 blackhole tag 4711

A route tag of the ticket number makes it easy to list all emergency routes with show ipv6 route tag 4711 and to find their reason later.

Make removal part of adding

Emergency blackholes tend to stay forever. A small timer helps:

systemd-run --on-active=6h --unit=bh-4711 \
  vtysh -c 'conf t' -c 'no ipv6 route 2001:db8:100:99::/64 blackhole tag 4711'

If the attack is still going after six hours, re-add it deliberately. That forces a human decision instead of a silent permanent outage for whatever later lives in that /64.

Watch out for uRPF interactions

If you use strict reverse-path filtering, a blackhole for a source range also drops traffic from that range, which is the basis of source-based RTBH. That is useful against an attack from a known source, and surprising when you did not intend it. Document whether your edge uses strict or loose mode.

Verify after every change

1. advertised-routes still shows only the /48.
2. A public route collector still shows the /48 with origin AS64496.
3. The blackholed range is silent, and everything else in the /48 still answers from an external host.

Paperwork

None of this changes your ROA or LOA. Keep the LOA from the IPYE portal and your upstream's RTBH instructions in the same runbook.

Do this next

Audit your static routes today with ip -6 route show type blackhole, and claim a free /48 from IPYE to practise these patterns on a lab edge. Questions: [e-mail].

About IPYE

IPYE (https://ipye.com) leases IPv4, IPv6 and ASN space with instant setup. Your first IPv6 /48 is free for the first year, a real allocation you can announce on your own ASN, with a LOA from the portal and the ROA created automatically. ASN and region changes apply automatically. IPv4 /24 to /22 leases include LOA, ROA and per-/24 rDNS; WHOIS is editable on IPv6 /44 and larger. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, Frankfurt. Claim your free /48: https://my.ipye.com/products/ipv6-rental. Questions: [e-mail].

Disclosure: I run IPYE