Visual RFC.
ALL RFCs / RFC 6164
Read the RFC ↗
RFC 6164 / IPv6 ROUTER LINKS

Plan around reserved values and the verified boundary

05

Many router links can be numbered from one /64. The address-planning advice concerns the rightmost 64 bits, which is different from the single varying bit of a /127.

RFC 6164 · § 6EXAMPLE
4 / 4
Plan around reserved values and the verified boundaryChosen::2/::3avoid the listed warnings; the anycast-disable MUST still applies.Parent context: 2001:db8:1::/64Examples below show only the rightmost 64 bits0000:0000:0000:00020000:0000:0000:0003Chosen ordinary pair; not all possible checksMUST disable Subnet-Router anycast for the /127Zero final bit on ::2 does not mean 64 zero bitsListed §6 planning advice is not a complete reserved-address validator
04
Assign an ordinary pair with the mandatory configuration

The illustrative lower64 values ::2 and ::3 avoid both listed planning concerns. Assign one to each router and disable Subnet-Router anycast for this /127; support is mandatory, universal deployment is not.

Source for this drawing: RFC 6164 · Read RFC section 6 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC 6164 §6(b), printed ff7fVerified erratum 3422: ff80

The highest 128 values start at ffff:ffff:ffff:ff80, not ff7f. The SHOULD NOT recommendation and its address-planning context remain unchanged.

Read the updated RFC section ↗
KEY POINT

Assuming multiple point-to-point links are numbered from one /64, addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned as unicast, to avoid the Subnet-Router anycast collision.

  • Assuming multiple point-to-point links are numbered from one /64, addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned as unicast, to avoid the Subnet-Router anycast collision.
  • Under the same planning context, the highest 128 rightmost-64-bit values SHOULD NOT be used as unicast. Verified erratum 3422 corrects the start to ffff:ffff:ffff:ff80, through ffff:ffff:ffff:ffff inclusive.
  • These are SHOULD NOT recommendations, distinct from MUST support /127 and MUST disable Subnet-Router anycast for its prefix. The listed checks are not a complete reserved-address, allocation, or routing validator.
  • The chosen lower64 values ::2 and ::3 avoid both listed ranges. A zero last bit on ::2 is not the same as all 64 low bits being zero. Other reserved anycast formats, policies and address-management checks still matter.
DETAILS

Fictional documentation addresses within 2001:db8::/32. Bounded operator-chosen address examples, not a complete router, Neighbor Discovery, ICMPv6 or address-validation implementation.

Read the RFC section ↗

All chapters in RFC 6164

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗