Stable IPv6 Addressing 🌐

Use Case: Stable IPv6 Addressing in Consumer Networks with Dynamic ISP Delegation

radvd‑container provides a minimal, containerized solution for advertising IPv6 Unique Local Address (ULA) prefixes on local networks.
It is designed for environments where ISPs delegate unstable IPv6 prefixes and Linux no longer supports stable interface tokens, making it impossible to rely on predictable global IPv6 addresses.

By running radvd inside a lightweight container, this project enables stable internal IPv6 addressing using ULAs (fc00::/7) while remaining independent of ISP prefix churn. Internal services can bind to static IPv6 addresses, and clients automatically discover those addresses via Router Advertisements—without advertising a default route or interfering with upstream routing.

Why This Exists

Consumer ISPs frequently change delegated IPv6 prefixes, breaking internal services that depend on stable addressing. Linux previously mitigated this with the token keyword, but that mechanism has been removed.

This project exists to solve that gap.

By advertising a locally scoped IPv6 ULA prefix using radvd, internal devices gain stable, predictable IPv6 addresses that do not depend on ISP behavior. Running radvd as a container keeps the solution portable, auditable, and independent of router firmware limitations.

This approach restores IPv6 usability for internal services without relying on NAT, DHCPv6, or ISP cooperation.

Impact

• Internal servers cannot be addressed consistently.
• DNS records pointing to internal services break when the prefix changes.
• Automation, firewall rules, and access controls become brittle.
• Running IPv6-only internal services is impractical.

Solution Overview

The recommended approach is to introduce Unique Local Addresses (ULA) from the fc00::/7 block, which is reserved for private IPv6 networking. ULAs provide:

• Stable, non-routable IPv6 addressing.
• Independence from ISP prefix changes.
• Predictable addressing for internal services.

Servers and infrastructure components are assigned static IPv6 addresses from the chosen ULA prefix. These addresses remain constant regardless of external network changes.

Advertising the ULA Prefix

Clients still need to learn that the ULA prefix is valid and on-link. This is achieved using Router Advertisements (RA).

radvd (Router Advertisement Daemon) is used to advertise the ULA prefix to the local network. In this scenario:

• No default router is advertised.
• Only the ULA prefix is announced as on-link.
• Clients automatically configure addresses within the ULA range.

This keeps routing simple while ensuring all devices recognize the ULA space as local.

Network Architecture Diagram

The following diagram illustrates how the components interact in this setup. The ISP provides a dynamic prefix which changes over time, affecting the Global Unicast Address (GUA). However, the containerized radvd instance independently advertises the Unique Local Address (ULA) prefix (e.g., fc00:abcd::/64) to the LAN. Internal servers (Server A, Server B) bind to static IP addresses within this ULA range, ensuring they remain reachable at the same address regardless of ISP changes.

Implementation with Containers

A minimal, production-ready setup can be deployed using a containerized radvd instance.

• Container image: udp1024/radvd-alpine
• Available on Docker Hub and GitHub Container Registry
• Example pull command: docker pull udp1024/radvd-alpine:edge

The container includes:

• A lightweight Alpine-based radvd
• A near-ready default configuration
• A helper script to generate radvd.conf

Full source of the container is available on GitHub: https://github.com/udp1024/radvd-container

Configuration options:

• Review and customize radvd.conf in the documentation:
• Or generate a baseline configuration using setup-config.sh

Outcome

By combining ULAs with targeted router advertisements:

• Internal IPv6 services gain stable, predictable addresses.
• ISP prefix churn no longer impacts internal networking.
• IPv6 can be used confidently for self-hosted and infrastructure services.
• The solution remains simple, standards-compliant, and future-proof.

This approach restores operational sanity to consumer IPv6 environments while respecting modern Linux networking constraints.