High-Performance XDP BNG · CGNAT · QoS · Low-Latency · Native IPv6 / Dual-Stack

Broadband Gateway · Native IPv6 & Dual-Stack

Full-Speed IPv6 in the Same XDP Fast Path — Plus DS-Lite and Real IPv4-Pool Relief

IPv6 on the BNGSOFT XDP BNG is not a slow-path afterthought. Every subscriber runs IPv4 and IPv6 simultaneously, and the entire feature set — forwarding, per-subscriber QoS, AQM/L4S low-latency queueing, firewall, BCP38 anti-spoof, flow logging — applies to v6 at line rate in XDP. For IPv6-only access networks, DS-Lite encap/decap runs in the same fast path. And as v6 traffic share grows, it directly relieves CGNAT load and public-IPv4 pool pressure — a concrete cost lever, not just future-proofing.

Most "IPv6 support" is a checkbox: the BNG forwards v6 but polices, shapes and protects only v4. On the BNGSOFT data plane, IPv6 is a first-class citizen in the same XDP program — and every v6 byte a subscriber sends is a byte that doesn't burn a CGNAT port-block.

2 stacks

every subscriber: IPv4 (CGNAT or static)
AND IPv6, simultaneously

1 path

v6 forwarding · QoS · L4S · firewall
· anti-spoof — all in XDP

DS-Lite

IPv4-as-a-service over a pure-IPv6
access network, encap/decap in XDP

Pool
RELIEF

native v6 traffic consumes no
CGNAT port-blocks or public IPs

A dual-stack subscriber on the BNGSOFT XDP BNG carries an IPv4 identity (a private CGNAT address or a static public one) and a full IPv6 identity at the same time. The v6 identity is two prefixes: a transport /64 on the WAN side and a delegated prefix (typically a /56 or /60) handed to the CPE via DHCPv6-PD and routed to the customer LAN. The XDP data plane holds both in a per-subscriber IPv6 map (customer_ipv6_map), so v6 forwarding and policy run at the same line rate as v4 — out of the same pinned maps the rest of the data plane uses.

1 · The "IPv6 checkbox" problem — and what first-class v6 means

THE CHECKBOX

"We support IPv6" — but only halfway.

Many BNGs forward v6 but police only v4: no per-subscriber v6 shaping, no v6 AQM, no v6 firewall, no v6 anti-spoof.
v6 packets fall to a slow path or a generic kernel route — different latency, different rules, different bugs.
The operator can't give the v6 half of a subscriber the same plan rate and protection as the v4 half.
Result: enabling IPv6 feels risky, so it stays off — and the v4 pool keeps bleeding.

FIRST-CLASS v6

The same data plane, both address families.

v6 forwarding, QoS/rate-shaping, AQM/L4S, firewall, BCP38 anti-spoof and flow logging all run in XDP.
Per-subscriber state for both prefixes lives in customer_ipv6_map — looked up at line rate.
A subscriber's v6 traffic gets the same plan rate, same low-latency queueing as their v4 traffic.
Turning IPv6 on becomes a confident default, not a gamble.

One subscriber, two address families, one fast path. The XDP program decodes IPv6 to L4, looks up the per-subscriber v6 state, and applies the same policy machinery it applies to IPv4 — at the same line rate. v6 is not bolted on beside the data plane; it is the data plane.

2 · Per-subscriber IPv6 addressing — transport + delegated prefix

Every dual-stack subscriber gets two IPv6 prefixes, and the data plane tracks both:

TRANSPORT PREFIX

The WAN-side /64

/64

the link prefix between BNG and CPE

Addresses the subscriber's WAN interface itself.
Source of the CPE's own on-link v6 traffic.
Part of the subscriber's v6 allow-set for anti-spoof.

DELEGATED PREFIX (DHCPv6-PD)

The customer LAN prefix

/56 – /60

routed to the CPE for the home/business LAN

Handed out via DHCPv6 Prefix Delegation.
Routed through the CPE to every device behind it.
The whole prefix is a valid source range for that subscriber.

Both prefixes are written into customer_ipv6_map keyed per subscriber, so when a v6 packet arrives the XDP program resolves it to the owning subscriber, applies that subscriber's policy, and forwards — without ever leaving the fast path. This is the same model the v4 side uses with customer_ip_map: one lookup, full per-subscriber context.

Why hold both prefixes: the transport /64 identifies the link; the delegated /56–/60 identifies everything behind the CPE. Anti-spoof, QoS classification and flow logging all need to know that a source inside either prefix belongs to this subscriber — and that a source outside both does not.

3 · The full feature set — in XDP, for IPv6 too

This is the core claim, and it is literal: the entire BNGSOFT feature set applies to IPv6 inside the XDP program, not as a kernel-slow-path afterthought.

FORWARDING

Line-rate v6 forwarding.

IPv6 decoded to L4 in the fast path
Per-subscriber lookup in customer_ipv6_map
Same path, both directions

QoS / SHAPING

Per-subscriber v6 rate.

The v6 half is shaped to the same plan rate as v4
No separate, weaker v6 treatment
One subscriber, one experience

AQM / L4S

Low-latency v6 queueing.

AQM and L4S ECN apply to v6 flows
Bufferbloat control for the v6 half
Same low-latency target as v4

FIREWALL

v6 firewall in the data plane.

Subscriber firewall policy applies to v6
Enforced in XDP, not a side path

BCP38 ANTI-SPOOF

v6 source validation.

Accept only sources inside the subscriber's v6 prefixes
Drop spoofed v6 sources at the edge

FLOW LOGGING

v6 flows logged too.

v6 flow records alongside v4
Same visibility, same export pipeline

The practical upshot: an operator does not have to choose between "fast v4, second-class v6." A subscriber's v6 traffic is shaped, queued, firewalled, anti-spoofed and logged with the same machinery and the same line-rate budget as their v4 traffic. There is no quality cliff when a device prefers IPv6 — which, on modern OSes, is most of the time.

4 · IPv6 anti-spoof (BCP38 for v6) — strict per-subscriber source validation

BCP38 source validation is independent per address family. The v6 anti-spoof builds an allow-set from each subscriber's transport and delegated prefixes: the BNG only accepts an IPv6 packet whose source falls inside that subscriber's own prefixes, and drops anything else as spoofed. This runs in XDP, at the edge, before the packet reaches the network — and it is entirely separate from the IPv4 anti-spoof, which has its own allow-set.

THE v6 ALLOW-SET

Built from the subscriber's own prefixes.

Transport /64 + delegated /56–/60 define the legitimate source range.
Synced from the same session state that drives forwarding.
A source inside either prefix is accepted; anything else is dropped.

INDEPENDENT OF v4

Two families, two allow-sets.

IPv6 anti-spoof has its own enforce/observe arming, separate from IPv4.
An operator can run v6 enforce while v4 is still observing, or vice-versa.
Spoofed v6 sources never reach the upstream network.

What a strict v6 anti-spoof decision looks like ILLUSTRATIVE FORMAT

root@NodeA:~# bngxdpctl antispoof show 2001:db8:5a30:1c00::/56
=== anti-spoof (IPv6) ===
  subscriber iface : ppp0    mode: enforce
  allow-set (this subscriber):
    transport  2001:db8:5a30:1cff::/64
    delegated  2001:db8:5a30:1c00::/56

  [ PASS ] src 2001:db8:5a30:1c0a::42  inside delegated /56
  [ PASS ] src 2001:db8:5a30:1cff::1   inside transport /64
  [ DROP ] src 2001:db8:9999::7     outside allow-set → spoofed

  v6 anti-spoof: strict per-subscriber, independent of IPv4

Illustrative format only — addresses are documentation prefixes (RFC 3849 2001:db8::/32) and the layout is representative, not a verbatim capture. The mechanism shown — accept sources inside the subscriber's transport/delegated prefixes, drop the rest — is the real per-subscriber v6 BCP38 model.

Honest caveat: IPv6 enforce is armed per-subscriber on load stability, the same discipline used for the v4 anti-spoof; an operator should validate observe mode before flipping enforce on a given deployment. The v6 allow-set is only as correct as the synced transport/delegated prefixes for that subscriber — which is why it is driven from the same session state as forwarding.

5 · DS-Lite — IPv4-as-a-service over a pure-IPv6 access network

Some access networks are IPv6-only by design: the subscriber gets IPv6 natively and has no native IPv4 on the access link at all. DS-Lite (Dual-Stack Lite, IPv4-over-IPv6) still gives those subscribers working IPv4 — by tunnelling their v4 traffic inside IPv6 from the CPE (the B4) to a carrier element (the AFTR), where NAT happens. BNGSOFT implements both the encap and decap halves of DS-Lite inside the XDP fast path, with a per-subscriber tunnel endpoint — so IPv4-as-a-service is delivered over a pure-IPv6 access network without burdening a separate slow v4 path.

B4 → AFTR

v4 tunnelled in v6.

The CPE (B4) encapsulates the subscriber's IPv4 inside IPv6
Carried across the IPv6-only access network
Terminated at the carrier AFTR

XDP ENCAP / DECAP

Both halves in the fast path.

Dedicated encap and decap programs in XDP
Per-subscriber tunnel endpoint state
No separate slow-path v4 stack to burden

NAT AT THE AFTR

CGNAT where it belongs.

v4 NAT happens at the AFTR, after decap
Same CGNAT machinery, fed by the tunnel
IPv4-as-a-service over pure v6 access

Element	Role in DS-Lite	Where it runs on the BNGSOFT BNG
B4 (CPE)	Encapsulates the subscriber's IPv4 into IPv6 toward the AFTR.	On the customer CPE; the BNG presents the AFTR-side endpoint for it.
IPv6 access network	Carries the encapsulated v4 — no native v4 on the access link.	Native IPv6 forwarding in XDP (same data plane as Section 3).
AFTR (carrier)	Decapsulates and performs IPv4 NAT for the tunnelled traffic.	XDP encap/decap programs + CGNAT, per-subscriber tunnel endpoint.

Why DS-Lite in XDP matters: the whole point of an IPv6-only access network is to stop carrying native IPv4 everywhere. Doing the encap/decap in the fast path means the v4-over-v6 tunnel runs at the same line rate as everything else — the operator gets IPv4-as-a-service for legacy traffic without standing up a separate, slower v4 forwarding plane.

6 · IPv4-pool relief — the business case for turning v6 on

This is the part that shows up on the invoice. Modern operating systems and applications follow "happy eyeballs": given both, they prefer IPv6. So once a dual-stack subscriber has working v6, the bulk of their traffic flows natively over IPv6 — and native v6 traffic does not consume CGNAT port-blocks or public-IPv4 pool addresses, and does not generate CGNAT translation log volume. Enabling IPv6 is therefore a direct lever on three real costs.

CGNAT LOAD

Fewer port-blocks burned.

Native v6 flows never touch the NAT table
Port-block pressure drops as v6 share rises
Headroom on the same hardware

PUBLIC-IPv4 POOL

Less pool pressure.

Traffic over v6 doesn't claim public-v4 mappings
Defers buying more scarce, expensive IPv4 space
Stretches the pool you already own

CGNAT LOG VOLUME

Less to log, store, retain.

No v4 translation = no v4 translation log line
Lower IPFIX/flow-log storage and retention cost
Smaller compliance data footprint

The lever: every percentage point of subscriber traffic that shifts to native IPv6 is a percentage point that stops consuming CGNAT port-blocks, public-IPv4 mappings and translation-log volume. IPv6 isn't only future-proofing — it is a present-tense cost reduction that grows as v6 adoption grows.

Capacity counts IPv4 and IPv6 subscriber tables separately

Because the two families are tracked independently, the capacity tooling reports an IPv6 subscriber table with its own fill and headroom, alongside the IPv4 table — each with a maximum of 131,072 subscribers:

root@NodeA:~# bngxdpctl capacity
Capacity — NodeA  (headroom = how much is left before this resource limits the box)
  resource                    used        max   use%  headroom  status
  ------------------------------------------------------------------------------
  Subscribers (IPv4)     8538    131072    6%     94%  OK
  Subscribers (IPv6)     8318    131072    6%     94%  OK

  IPv4 and IPv6 subscriber tables are sized and tracked independently.

Headroom snapshot from a live ~8,700-subscriber production access node (QoS-only mode, i40e, native XDP). The IPv4/IPv6 subscriber counts and the 131,072 table maximum are real; the surrounding box layout is the standard capacity view.

7 · What it means for the business

Native IPv6 & Dual-Stack · operator value

True dual-stack, equal treatmentEvery subscriber runs IPv4 and IPv6 at once, and the v6 half gets the same line-rate forwarding, QoS, AQM/L4S, firewall and anti-spoof as the v4 half.

↓

Lower CGNAT & IPv4 costNative v6 traffic consumes no CGNAT port-blocks and no public-IPv4 mappings — relieving NAT load and pool pressure as v6 share grows.

DS-Lite for v6-only accessRun a pure-IPv6 access network and still deliver IPv4-as-a-service, with encap/decap in the XDP fast path — no separate slow v4 plane.

🛡

Per-subscriber v6 anti-spoofStrict BCP38 source validation against each subscriber's transport/delegated prefixes, independent of the IPv4 anti-spoof.

📉

Less log to storeTraffic that flows over v6 generates no v4 translation log — lowering flow-log storage, retention and compliance data footprint.

★

Future-proof, todayIndependent IPv6 subscriber tables (max 131,072) with their own headroom mean you can scale v6 adoption on the same hardware and see it in capacity planning.

Enable dual-stack so subscribers get IPv4 (CGNAT or static) plus a transport /64 and a DHCPv6-PD delegated /56–/60 routed to the CPE.

Let the data plane do the rest — v6 forwarding, QoS, AQM/L4S, firewall, anti-spoof and flow logging all run in the same XDP program as v4.

Arm v6 anti-spoof in observe, validate the allow-sets, then flip enforce per the same load-stability discipline as the v4 anti-spoof.

For IPv6-only access, deploy DS-Lite — XDP encap/decap with a per-subscriber tunnel endpoint and NAT at the AFTR.

Watch the relief — as native v6 traffic share rises, CGNAT port-block pressure, public-IPv4 pool usage and translation-log volume fall.

The bottom line

IPv6 on the BNGSOFT XDP BNG is first-class, not a checkbox: every subscriber runs v4 and v6 together, and the v6 half gets the same line-rate forwarding, shaping, low-latency queueing, firewall and anti-spoof — all in the same XDP fast path. For IPv6-only access, DS-Lite delivers IPv4-as-a-service with encap/decap in that same fast path.

And it pays for itself: as native v6 traffic share grows, it directly relieves CGNAT load, public-IPv4 pool pressure and translation-log volume. Dual-stack here is future-proofing and a present-tense cost lever — on the hardware you already run.

Methodology and honest framing: This document describes the IPv6 / dual-stack capabilities of the BNGSOFT XDP BNG. The following are grounded product facts. Each dual-stack subscriber runs IPv4 (a private CGNAT address or a static public one) and IPv6 simultaneously. IPv6 addressing per subscriber consists of a transport prefix (the WAN-side /64) plus a delegated prefix obtained via DHCPv6 Prefix Delegation (typically a /56 or /60 routed to the CPE); the XDP data plane holds both in a per-subscriber IPv6 map (customer_ipv6_map) so that v6 forwarding and policy run at line rate. The complete feature set applies to IPv6 in XDP: forwarding, per-subscriber QoS/rate-shaping, AQM/L4S low-latency queueing, firewall, BCP38 anti-spoof, and flow logging — not as a slow-path afterthought. The IPv6 anti-spoof performs strict per-subscriber source validation, accepting only IPv6 source addresses inside that subscriber's delegated/transport prefixes (a v6 allow-set) and dropping spoofed sources; it is independent of the IPv4 anti-spoof. DS-Lite (IPv4-over-IPv6) is implemented for IPv6-only access networks: the subscriber's IPv4 is tunnelled from the B4 (CPE) to the AFTR (carrier), where NAT happens, with dedicated encap and decap programs in the XDP fast path and a per-subscriber tunnel endpoint. The capacity tooling tracks IPv4 and IPv6 subscriber tables separately and reports "Subscribers (IPv6)" with its own headroom; each table's maximum is 131,072 subscribers.

Illustrative material: The block in Section 4 labelled ILLUSTRATIVE FORMAT (the bngxdpctl antispoof show IPv6 allow-set / pass-drop example) is a representative illustration of the per-subscriber v6 BCP38 mechanism, not a verbatim capture; all IPv6 addresses shown use the RFC 3849 documentation prefix 2001:db8::/32 and are not real subscriber addresses. The exact CLI flags, field labels and output layout shown are representative and may differ from a given release. The bngxdpctl capacity headroom snapshot in Section 6 reflects the real, separately-tracked IPv4/IPv6 subscriber counts and the 131,072 table maximum on a live production access node; the surrounding capacity view is the standard tool output. Node names in this document are generic (e.g. NodeA) and do not identify a specific operator's network.

Honest caveats: IPv6 L4 handling matured across releases; the current QoS-only and full-CGNAT operating modes both forward and police IPv6. DS-Lite applies specifically to IPv6-only access deployments. The IPv4-pool-relief benefit is real but deployment-dependent: the magnitude of CGNAT, public-IPv4-pool and translation-log relief depends on how much of each subscriber's traffic actually flows over IPv6 (driven by "happy eyeballs" client behaviour and content availability), and is therefore a function of v6 traffic share rather than a fixed guarantee. IPv6 anti-spoof enforce should be validated in observe mode before being armed on a given deployment, using the same load-stability discipline as the IPv4 anti-spoof. Prepared as a management and technical overview for large-scale operators. Native IPv6 & Dual-Stack is a capability of the BNGSOFT XDP BNG product.