IPv6 over PON is mostly a Layer 2 story: the OLT and ONU treat IPv6 packets as ordinary data frames and pass them upstream to the BRAS/BNG, while the actual address assignment (SLAAC, DHCPv6, and prefix delegation) is done by the carrier router, not by the OLT.
In almost every PON deployment the OLT and ONU are transparent bridges for IPv6 — they forward frames, they do not hand out addresses.
The home gateway decides bridge mode (terminal gets a global address straight from the BRAS) or route mode (gateway pulls a prefix via DHCPv6 PD and sub-delegates it).
Real-world IPv6 uses SLAAC for zero-config addressing plus DHCPv6 for DNS and other parameters; PD solves the "router behind the gateway" prefix problem.
IPv6 multicast rides MLD, and the OLT runs MLD Snooping exactly the way it runs IGMP Snooping for IPv4.
The failure points are operational, not the OLT: dual-stack pass-through, RA Guard, a 1280-byte MTU floor, and not blocking RA/DHCPv6/MLD control packets.
Most PON equipment treats IPv6 exactly like any other Ethernet frame. The ONU receives the user's IPv6 packet and ships it upstream to the OLT; the OLT forwards it toward the BRAS/BNG on the uplink. The whole path is "IP-unaware" — as long as Layer 2 forwarding and VLAN tagging are correct, IPv6 just flows. The OLT never has to understand an IPv6 address to move the traffic.
This ipv6 transparent pass-through model is why IPv6 "just works" on a PON that was originally built for IPv4: you are not re-architecting the access network, you are letting another protocol ride the same frames.
The home gateway (HG, often built into the ONU) has two modes, and the mode decides who owns the IPv6 address:
Bridge mode: the HG does not take an IP role. The IPv6 packet passes straight through to the carrier, and the PC or phone receives its global unicast address directly from the BRAS. Simplest, clearest address ownership.
Route mode: the HG becomes an IPv6 router. It requests a prefix from the carrier through DHCPv6 PD (prefix delegation) and then splits that prefix across the devices behind it. This is what you want when there is a second-level router downstream.
In the vast majority of residential PON deployments the user-side ONU runs bridge mode, so the IPv6 configuration pressure sits entirely on the upper layer.
| Method | State | What it does | Typical use |
|---|---|---|---|
| SLAAC | Stateless | The terminal builds its own address from the Router Advertisement prefix | Zero-config client addressing |
| DHCPv6 | Stateful | The server assigns addresses and pushes DNS and other options | Managed addressing, parameter delivery |
| PD (prefix delegation) | Delegates a prefix | The gateway gets a prefix and hands sub-prefixes to downstream networks | Router-behind-gateway topologies |
Real deployments usually run SLAAC + DHCPv6 together: SLAAC gives the terminal an address with no configuration, while DHCPv6 delivers the DNS server and other parameters. slaac alone cannot hand out DNS, which is why pure SLAAC is hard to live with. PD is the piece that solves "there is another router hanging off the home gateway" — the gateway gets a prefix and re-divides it.
IPv4 multicast is controlled by IGMP; the IPv6 equivalent is MLD (Multicast Listener Discovery). If the PON carries IPTV or any multicast service, the OLT runs mld snooping on the IPv6 side using exactly the same logic as IGMP Snooping: it replicates the stream only to the ONUs that actually have members, instead of flooding every downstream port. The only difference between the two is the control protocol — IGMP for IPv4, MLD for IPv6.
Note: Keep the IPv6 control plane allowed through the access side. RA, DHCPv6, and MLD are the packets that let terminals get addresses and join groups; an over-broad ACL that "cleans up" unknown traffic can silently break IPv6 while IPv4 keeps working.
Dual stack first. IPv4 and IPv6 coexist for years. The OLT pass-through must permit both; do not enable IPv6 and accidentally filter IPv4.
RA Guard. SLAAC trusts Router Advertisements, so a user who forges an RA can hijack addressing. Turn on RA Guard on the access side.
MTU floor. IPv6 requires a path MTU of at least 1280 bytes and does not allow fragmentation in the middle. Leave enough headroom on the PON link or large packets get dropped. (This is the same boundary covered in the MTU and jumbo-frames article.)
Do not block the control packets. As noted above, ACLs that kill RA, DHCPv6, or MLD break address assignment and group membership.
Does the OLT need to support IPv6 routing? Usually no. The OLT and ONU do Layer 2 transparent pass-through; IPv6 routing and address assignment are the job of the BRAS/BNG upstream. Only a routing-type ONU or an edge-computing scenario pulls the terminal into IPv6 routing.
SLAAC or DHCPv6 — which should I use? Normally both. SLAAC gives the terminal a zero-config address; DHCPv6 adds the DNS server and other options. Pure SLAAC leaves the device without DNS and is painful in practice.
What if there is a second router behind the home gateway? Put the home gateway in route mode and let it pull an IPv6 prefix through DHCPv6 PD, then delegate sub-prefixes to the second router's devices. Each layer gets its own address space.
Why do some web pages fail to open under IPv6? The usual causes are an MTU mismatch that drops large packets, or RA/DHCPv6 control packets being filtered by a mid-link ACL. Check the path MTU and confirm the access side permits IPv6 control packets.
Does Rayin equipment handle IPv6? Yes. Rayin PON and ONU solutions fully support transparent IPv4/IPv6 dual-stack pass-through on the access side, so IPv6 rides the same PON as IPv4 without special provisioning.
The hard part of IPv6 over PON is not the OLT — it is the layering. The devices do Layer 2 transparent pass-through, the upper-layer BRAS/BNG owns addressing, and SLAAC, DHCPv6, and PD each cover one slice of the job. Hold the dual-stack, RA Guard, MTU, and control-packet boundaries and IPv6 stays as stable as IPv4 on the same fiber.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
