Skip to main content

IPv6 / Dual-Stack

Native dual-stack subscriber service: every subscriber gets an IPv4 address plus a routable IPv6 WAN address and a delegated IPv6 prefix for their LAN, driven entirely by RADIUS.

Overview​

AthenaBNG delivers IPv6 alongside IPv4 on the same subscriber session. A dual-stack subscriber receives:

  • an IPv4 address, exactly as before (see PPPoE Termination / DHCP/IPoE); and
  • an IPv6 WAN address on the access link (a /64 advertised via Router Advertisements / SLAAC), from the RADIUS Framed-IPv6-Prefix; and
  • a delegated IPv6 prefix (the PD, e.g. a /56) for the customer's own LANs, handed out via DHCPv6 IA_PD, from the RADIUS Delegated-IPv6-Prefix.

Unlike IPv4, IPv6 is native and globally routable — CGNAT does not apply. The delegated prefix becomes a routed prefix pointing at the subscriber's link.

Access typeWAN addressLAN delegationMechanism
PPPoElink-local + /64 (Framed-IPv6-Prefix) via RA/SLAAC/56 (Delegated-IPv6-Prefix) via DHCPv6 IA_PDIPv6CP → RA + DHCPv6-PD
IPoE/64 via RA (SLAAC)/56 (Delegated-IPv6-Prefix) via DHCPv6 IA_PDRS/RA + DHCPv6 IA_PD

RADIUS is authoritative — no local pool, fail-closed​

IPv6 addressing follows one firm rule: RADIUS is the single source of truth, and the BNG never invents a prefix.

  • Every subscriber's Delegated-IPv6-Prefix (the PD) and Framed-IPv6-Prefix (the WAN /64) come only from the RADIUS reply.
  • There is no local IPv6 pool anywhere — no accel-ppp ipv6-pool, no pool in the DHCPv6 path.
  • A session whose RADIUS reply carries no IPv6 attributes simply comes up IPv4-only — the dual-stack degrades cleanly rather than the BNG assigning a made-up prefix.
Fail-closed by design

No RADIUS IPv6 attribute means no IPv6. In the DHCPv6 path this is explicit: an IA_PD request with no delegated prefix from RADIUS is answered NoPrefixAvail (and NoBinding on Renew/Rebind), never a locally chosen prefix.

This also gives stable per-subscriber prefixes (they are keyed to the RADIUS identity, not to a lease from a rotating pool) and keeps a single central address authority.

PD length is RADIUS's choice, per-subscriber — not a BNG default. Typical assignments are /56 for residential and /48 for business; the BNG simply routes whatever prefix RADIUS delegates.

PPPoE dual-stack​

Status: shipping. PPPoE dual-stack is fully implemented via accel-ppp.

Enable it with the pppoe.ipv6 knob (default deny):

abng# set pppoe ipv6 allow
abng# commit

pppoe.ipv6 accepts the accel-ppp IPv6CP negotiation modes:

ValueMeaning
denyIPv6CP disabled — IPv4-only (default)
allowNegotiate IPv6 if the client asks
preferOffer IPv6, fall back to IPv4-only if the client declines
requireRequire IPv6CP — reject sessions that won't negotiate it

When pppoe.ipv6 is anything other than deny, abngd renders accel-ppp with the ipv6_nd and ipv6_dhcp modules loaded:

  • ipv6_nd sends Router Advertisements for the WAN /64 (from Framed-IPv6-Prefix), and advertises the configured resolvers via RA RDNSS.
  • ipv6_dhcp is the DHCPv6 server that delegates the customer prefix (from Delegated-IPv6-Prefix) via IA_PD. accel-ppp installs the delegated-prefix route itself (via the PPP peer, route-via-gw), which FRR then redistributes.

There is no ipv6pool module and no [ipv6-pool] section — assignment is RADIUS-only, fail-closed, exactly as described above.

IPv6 DNS resolvers​

pppoe.ipv6_dns is a list of IPv6 resolver addresses advertised to subscribers (via RA RDNSS and DHCPv6). It is only used when pppoe.ipv6 is not deny.

pppoe:
  enabled: true
  ipv6: allow
  ipv6_dns:
    - "2606:4700:4700::1111"
    - "2001:4860:4860::8888"

Example: dual-stack PPPoE​

pppoe:
  enabled: true
  ac_name: "AthenaBNG"
  ipv6: prefer
  ipv6_dns:
    - "2606:4700:4700::1111"
    - "2001:4860:4860::8888"

radius:
  servers:
    - host: "10.255.0.10"
      secret: "your-secret"
  nas_identifier: "AthenaBNG"
  nas_ip_address: "10.255.0.1"

With this config and a RADIUS profile that returns the v6 attributes, a PPPoE client negotiates IPv6CP, gets a /64 on its WAN link via RA, and receives its RADIUS-assigned prefix via DHCPv6-PD. A client whose RADIUS profile returns no v6 attributes comes up IPv4-only on the same config.

MTU

PPPoE IPv6 uses the same 1492-byte MTU as IPv4. Ensure ICMPv6 "Packet Too Big" messages are permitted through any subscriber/management firewalls so PMTUD works.

IPoE dual-stack (DHCPv6)​

Preview / in development

IPoE DHCPv6 is not yet shipping. The DHCPv6 wire protocol and the IA_PD response logic are implemented and unit-tested, but the async socket listener, the Router Advertisement sender for IPoE, and the demux DHCPv6-Solicit detection are still in development. Treat this as a preview of the intended behaviour.

The DHCPv6 core in abng-dhcpd already implements the same RADIUS-authoritative, fail-closed model as PPPoE:

  • IA_PD is delegated from the RADIUS Delegated-IPv6-Prefix. If RADIUS returns no delegated prefix, the client is answered NoPrefixAvail (NoBinding on Renew/Rebind) — no prefix is ever locally invented.
  • IA_NA is answered NoAddrsAvail. The IPoE WAN address comes via SLAAC (Router Advertisements carrying the Framed-IPv6-Prefix), not stateful DHCPv6, so the server never hands out a /128.
  • Solicit → Advertise (or Reply on Rapid-Commit); Request / Renew / Rebind / Confirm → Reply; Information-Request → DNS-only.

What remains for IPoE to ship: the [::]:547 UDP listener (joining ff02::1:2 on each subscriber interface), the RA sender that accel-ppp's ipv6_nd provides for PPPoE, DHCPv6-Solicit detection in the demux, and the route installation for the delegated prefix. Until then, use PPPoE for dual-stack service.

RADIUS attributes​

Two standard RADIUS attributes drive IPv6, both returned in the Access-Accept:

#AttributeRFCMeaning
97Framed-IPv6-PrefixRFC 3162The on-link WAN prefix (typically a /64) advertised to the CE via RA/SLAAC
123Delegated-IPv6-PrefixRFC 4818The prefix delegated to the CE's LANs (e.g. a /56), handed out via DHCPv6 IA_PD

Both are encoded as reserved(1) | prefix-length(1) | prefix octets (the prefix octets left-aligned and zero-padded). Returning neither attribute yields an IPv4-only session. See the RADIUS Attributes Reference for the full list.

Example Access-Accept (dual-stack)​

Access-Accept
    User-Name = "user1"
    Framed-IP-Address = 203.0.113.10
    Framed-IPv6-Prefix = 2001:df4:2040:1234::/64
    Delegated-IPv6-Prefix = 2001:df4:2040:1200::/56
    Athena-Rate-Down = "100mbit"
    Athena-Rate-Up = "40mbit"

How IPv6 prefixes are announced (aggregate only)​

Upstream, IPv6 differs from the IPv4 plane. Rather than announcing a host route per subscriber, BGP announces the subscriber aggregate only — a single prefix (a /52 in the reference deployment, 2001:df4:2040:1000::/52) via aggregate-address … summary-only. The per-customer /56 (or /48) delegated prefixes forward locally as connected/kernel routes but are suppressed from BGP advertisement, so the routing table upstream stays clean.

For the BGP/IS-IS configuration, IPv6 address-family, and aggregate announcement detail, see IPv6 routing & upstream peering and the Routing configuration page.

Next Steps​