Ask and you shall receive.  They delegate a /56 prefix through DHCPv6-PD -as long as you ask nicely!

For illistration, Spectrum assigns:

2001:db8:1234:5600::/56

Note: 2001:db8::/32 is reserved for documentation. This is not the actual Spectrum prefix.

A /56 contains 256 individual /64 networks.  For example:

This provides considerably more flexibility than a single /64.

Each /64 can be assigned to a separate routed LAN, VLAN, wireless network, or other Layer 3 segment.  A /64 is also SLAAC friendly.

How many networks can we delegate?

A /56 contains:

• 256 × /64 networks
• 64 × /58 networks
• 16 × /60 networks

Our design delegates one /58 to the AP.

That /58 contains 64 separate /64 networks.  🤯

The remaining address space can support other internal segments or downstream routers, provided the allocations do not overlap.  That's exactly what we want -options.    

Configure prefix delegation on the primary firewall

The edge firewall runs a DHCPv6 client on its Spectrum-facing WAN interface.

The client requests a prefix and places the delegation into a RouterOS IPv6 pool:

/ipv6 dhcp-client
add interface=<spectrum-wan> \
    request=prefix \
    pool-name=spectrum_ipv6 \
    pool-prefix-length=56 \
    add-default-route=no

Replace with the actual interface name.

The important settings are:

The actual Spectrum configuration uses Router Advertisements for default-route discovery.

Verify the prefix

/ipv6 dhcp-client print detail
/ipv6 pool print detail

We expect the DHCPv6 client to report status=bound and a delegated prefix of length /56.

The pool should contain the dynamically delegated address space.

Why not hardcode the prefix?

Spectrum's delegation is dynamic.

Although an ISP may consistently assign the same prefix, there is no guarantee it will remain unchanged.

Hardcoding the global prefix into downstream interfaces would create additional maintenance work if Spectrum renumbers the connection.

Using a dynamic pool allows RouterOS to update the assigned global prefixes when the upstream delegation changes.

IPv6 default routes: Router Advertisements versus DHCPv6

An important architectural distinction is that DHCPv6 Prefix Delegation does not inherently supply a default gateway.

In IPv6, Router Advertisements are the standard mechanism for discovering default routers.

On the Spectrum WAN, the edge firewall receives an RA from the upstream router.

The RA identifies the default router through its link-local address.

The resulting route conceptually resembles:

::/0
    gateway=fe80::xxxx%<spectrum-wan>

The %interface notation identifies the interface associated with the link-local next hop.

This is necessary because link-local IPv6 addresses are scoped to a particular link.

Why link-local next hops?

IPv6 routers do not need globally routable addresses to communicate with directly connected neighbors.

A link-local address is sufficient for forwarding traffic to the next router. This is normal behavior.

The edge firewall receives a global /56 through PD.  It independently learns its default route through an RA.

These are separate control-plane functions.

RouterOS consideration

RouterOS must be configured to accept Router Advertisements to learn its IPv6 default route.  

For example:

/ipv6 settings
set accept-router-advertisements=yes

Enabling RA acceptance does not replace DHCPv6-PD. 

6. Delegating a /58 to the AP

This is where the architecture becomes interesting.

The AP is simultaneously:

• A DHCPv6-PD client toward Spectrum.
• A DHCPv6-PD server toward the AP.

The AP requests a prefix from the edge firewall.

The AP allocates a /58 from Spectrum's delegated /56.

Using our documentation prefix, one possible allocation is:

Spectrum delegates:
2001:db8:1234:5600::/56

Edge firewall delegates to AP:
2001:db8:1234:5640::/58

That /58 contains the /64 networks beginning at 5640 through 567f.

The exact allocation is determined by the pool and client configuration.

Configure a delegation pool

The Spectrum-facing DHCPv6 client creates the upstream dynamic pool spectrum_ipv6.

To delegate /58s, the AP must have a suitable nonoverlapping allocation mechanism that makes /58 prefixes available to its downstream DHCPv6 server.

A RouterOS dynamic pool created with pool-prefix-length=64 is intended to allocate /64s, not /58s. The pool arrangement must therefore support the /58 request.

For example, the upstream client could be configured to create /58 allocations:

/ipv6 dhcp-client
set [find where pool-name=spectrum_ipv6] \
    pool-prefix-length=58

Changing the pool prefix length on a running network can affect existing assignments.

Configure the DHCPv6 server

The DHCPv6 server on the edge firewall serves the link towards the AP:

/ipv6 dhcp-server
add name=dhcpv6_to_ap \
    interface=<ap-facing-interface> \
    address-pool=<pd-pool>

The selected pool must provide the /58 delegations.

The server receives a prefix request from the AP, allocates the prefix, and associates that delegation with the downstream router.

This is not the same as assigning an IPv6 address to the AP's WAN interface.

A delegated prefix represents address space.  It is not the same an IPv6 address. 

Configure the AP as a DHCPv6-PD client

The AP runs a DHCPv6 client toward the edge firewall.

The client requests a prefix and places it into a local pool:

/ipv6 dhcp-client
add interface=<edge-uplink> \
    request=prefix \
    pool-name=spectrum_pool \
    pool-prefix-length=64 \
    add-default-route=no

The /64 allocation size is intentional.  The AP receives a /58 but subdivides that prefix into /64s for its internal networks.

The hierarchy is:

Spectrum
     |
Edge Firewall /56
     |
Access Point  /58
     |
Wireless Clients /64

This is routing.  It's not address translation.

Every global IPv6 address and subnet belongs to the original Spectrum /56.

Assign /64 networks to internal interfaces

The AP can assign /64 networks from its delegated pool to internal interfaces:

/ipv6 address
add interface=bridge_wifi \
    from-pool=spectrum_pool \
    advertise=yes

RouterOS selects an available /64 from the delegated pool and assigns it to bridge_wifi.

The interface then advertises that prefix to wireless clients.

What about bridge_lan?

The existing topology distinguishes between two networks:

bridge_lan
Receives a global /64 advertised by the edge firewall through SLAAC.

bridge_wifi
Receives a global /64 from the AP's delegated /58.

This is a useful distinction.

On the bridge_lan, the AP participates as a host on the upstream link, receiving a global address through SLAAC.

On the bridge_wifi, the AP acts as the router advertising a delegated /64 to downstream clients.

The two interfaces therefore have different addressing and routing.

Router Advertisements and SLAAC

The AP provides Router Advertisements on the wireless bridge.

/ipv6 nd
add interface=bridge_wifi \
    advertise-dns=yes \
    managed-address-configuration=no \
    other-configuration=no

ND advertises its /64 to clients.  Clients receiving these advertisements can automatically configure global IPv6 addresses using SLAAC.

RAs can provide:

• Default-route
• Prefix information
• MTU
• Router lifetime
• DNS resolvers through RDNSS

DHCPv6 IA_NA and SLAAC

The design also incorporates DHCPv6 IA_NA service on bridge_wifi.

Note the distinction between PD, DHCPv6, and SLAAC.

• DHCPv6-PD: Delegates prefixes to routers.
• DHCPv6 IA_NA: Assigns individual IPv6 addresses to clients.
• SLAAC: Allows clients to generate their own addresses using advertised prefixes.

Why incorporate both SLAAC and DHCPv6 service?  It's all about the clients.  Some only support SLAAC, some only DHCPv6, some only support SLAAC but do not accept RDNSS 🤣.  If you want to support Windows, and Mac IOS, and Android, and Xbox...  It's best to support SLAAC and provide DHCPv6.

To advertise that stateful DHCPv6 addressing is available, the RA Managed flag can be enabled:

/ipv6 nd
set [find where interface=bridge_wifi] \
    managed-address-configuration=yes

The DHCPv6 server and address pool must also be configured.  The Managed flag alone does not create a DHCPv6 server.

Return routing

The major advantage for this design is that the edge firewall does require a static route for every delegated /64.

When It delegates a /58 to the AP, the DHCPv6-PD server can install a route for that delegated prefix through its DHCPv6 client.

Conceptually:

Destination:
2001:db8:1234:5640::/58

Next hop:
AP

The actual next hop may use the AP's link-local address. This is a critical feature of routed prefix delegation.

IPv6 firewall considerations

Globally routable IPv6 addresses, without controls, provide unrestricted two-way Internet access.

A stateful firewall policy is the primary tool that makes IPv6 functionally secure.  It should block all unsolicited traffic on both the inbound and forward chains. It should permit defined control traffic on the inbound chain and permit outbound traffic on the forward chain.  It should drop everything else. 

It's conceptually similar to a solid IPv4 firewall filter.  Review an example of IPv6 firewall configuration here.

The AP should apply equivalent principles to traffic entering its own routed networks.

17. Conclusion

My Spectrum IPv6 deployment demonstrates a clean approach to routing using RouterOS.

Spectrum delegates a /56 to my edge firewall.

My edge firewall allocates a /58 to my AP.

My AP subdivides that /58 into /64 networks for its internal interfaces.

Router Advertisements provide default-router discovery and host configuration, while DHCPv6-PD manages the delegation hierarchy and associated routes.

The resulting architecture supports globally routable IPv6 addresses throughout the network without NAT66.

More importantly, it establishes a foundation for expansion.

Additional VLANs, wireless networks, downstream routers, and branch segments can be incorporated without changing the architecture.

The underlying principle is simple: delegate prefixes to routers, advertise prefixes to hosts, and route between networks.

That's it!