AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 64 Bitcoin

addrmgr: fix IsRoutable for IPv6 addresses starting with 0

Public commit record

What the developer wrote

Authored by Eric Grill

91/100 · Strong
addrmgr: fix IsRoutable for IPv6 addresses starting with 0

In this commit, we fix `IsRoutable` to correctly reject IPv6 addresses
whose first 16-bit group is zero (i.e., in the `0000::/16` reserved
block per RFC 4291). Differential fuzzing between btcd and Bitcoin Core
revealed that addresses like `0:9881:8181:8181:fe00:a:9e:9801` were
slipping through as routable when they shouldn't be.

We add a new `zero6Net` (`0000::/16`) definition alongside the existing
`zero4Net`, and introduce an `IsZero` helper that checks both. The /16
prefix width is intentional: the broader /8 reservation would
incorrectly catch allocated sub-ranges like `0064:ff9b::/96` (RFC 6052,
NAT64). We also carve out an exception for RFC 6145 translated IPv4
addresses (`::ffff:0:0:0/96`), which live within `0000::/16` but are
valid for routing.

Test coverage includes the original bug report address, various
zero-prefix IPv6 addresses, the RFC 6145 exclusion, and corresponding
`GroupKey` entries to confirm they land in the "unroutable" bucket.

Fixes #2431
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in btcd's address manager where certain invalid IPv6 addresses starting with '0:' were incorrectly treated as valid internet-routable addresses. These addresses belong to a reserved block that should never be routed. The fix adds a check to reject them, with a special exception for a specific translated-IPv4 range. Because Bitcoin nodes share peer addresses with each other, accepting such addresses could let an attacker pollute the peer database with unusable or specially crafted entries, potentially degrading network connectivity.

Recommended action

Review whether any cached addrman entries from prior versions contain now-rejected zero-prefix IPv6 addresses and consider whether addrman eviction or bootstrap from trusted seeds is warranted. Ensure the fix is included in the next release and monitor for similar discrepancies in other address classification functions.

Security signals we found

01

Incorrect routability classification of reserved IPv6 range

02

Peer address database pollution vector

03

Differential fuzzing discovery against Bitcoin Core

04

RFC 4291 reserved address handling

05

Special-case carve-out for RFC 6145 translated IPv4

Risk score

Why this scored 64/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.