Wrangling IPv6 on AT&T and Mikrotik

Goal:  

Understanding how prefix delegation, Router Advertisements (RA), Neighbor Discovery (ND), and stateful firewalling interact is the difference between a rock-solid deployment and unrouteable breakdown.

This post walks through an IPv6 rollout using AT&T Business Internet (a non-SLA service behind an AT&T RG) routed through a MikroTik CCR2004-16G-2S+ running RouterOS v7.20.

Unlike a previous deployment on Spectrum—which handed out generous /56 prefixes. this AT&T setup initially delegated a single /64.

Consider, a /56 gives you 256 individual /64 subnets to route across your VLANs. A single /64 gives you exactly one conventional SLAAC-enabled LAN segment.

Solution:  

Here is how to set it up, how to secure it, and how to deal with an edge-case upstream routing freeze that caught us during testing.

1. Network Topology & Testing Goal

The goal was simple: establish isolated IPv6 connectivity for a single test Windows VM.

Hardware & Environment

• ISP: AT&T Business Internet (non-SLA)
• Upstream Edge: AT&T Residential Gateway (RG)
• Core Router: MikroTik CCR2004-16G-2S+ (RouterOS 7.20)
• WAN Interface: ether1_untrust
• Test LAN Bridge: bridge_ipv6
• Physical Port: ether16_ipv6
• Hypervisor: Microsoft Hyper-V host running a Windows VM

ether16_ipv6 is assigned to bridge_ipv6 and patches directly into a dedicated Hyper-V virtual switch isolated from hypervisor management.

       [ AT&T Internet ]
               |
      [ AT&T Gateway (RG) ]
               |
        ether1_untrust
               |
     [ MikroTik CCR2004 ]
               |
          bridge_ipv6
               |
         ether16_ipv6
               |
    [ Hyper-V Virtual Switch ]
               |
          [ Windows VM ]

Note: Even with IPv4 IP Passthrough enabled, the AT&T gateway handles IPv6 routing and prefix delegation state. You cannot bypass its IPv6 stack entirely.

2. Requesting the Prefix (DHCPv6 Client)

The first order of business is requesting an IPv6 prefix from the AT&T gateway over WAN.

/ipv6 dhcp-client
add interface=ether1_untrust \
    request=prefix \
    pool-name=att_pd \
    pool-prefix-length=64 \
    add-default-route=yes \
    accept-prefix-without-address=yes

Key Parameter Breakdown

• request=prefix: Requests DHCPv6 Prefix Delegation (IA_PD).
• pool-name=att_pd: Populates a dynamic IPv6 address pool in RouterOS named att_pd.
• pool-prefix-length=64: Controls the subnet block size RouterOS carves out of the pool for downstream interfaces (it does not control what size the ISP gives you).
• accept-prefix-without-address=yes: Accepts a delegated prefix even if AT&T doesn't hand out an IA_NA non-temporary address on WAN.
• add-default-route=yes: Installs an IPv6 default route via the DHCPv6 client mechanism.

Verifying the Binding

Run the print command to check client state:

/ipv6 dhcp-client print detail

Expected bound output:

interface=ether1_untrust status=bound dhcp-server-v6=fe80::3aa0:67ff:fe81:d662 
request=prefix pool-name=att_pd pool-prefix-length=64 
prefix=2600:1700:1335:452f::/64

Once status=bound, AT&T has handed off 2600:1700:1335:452f::/64. Because this prefix is dynamically delegated, hardcoding static IPs downstream is out of the question—we need to pull dynamically from the att_pd pool.

3. Assigning the Delegated Prefix to the LAN Bridge

Now we bind a /64 from our dynamic pool to bridge_ipv6:

/ipv6 address
add interface=bridge_ipv6 \
    from-pool=att_pd \
    advertise=yes

Using from-pool=att_pd ensures that if AT&T rebinds or changes our prefix on a WAN reconnect, RouterOS automatically updates the IP assigned to bridge_ipv6 without dropping LAN config.

Verify the binding:

/ipv6 address print

2600:1700:1335:452f::/64 FROM-POOL=att_pd INTERFACE=bridge_ipv6 ADVERTISE=yes

Caution: RouterOS displays the network address default (without an explicit EUI-64 or interface ID suffix) for pool assignments. If you want to ping the router's interface directly (e.g., ::1), make sure you explicitly define or bind that ID before using it as a source address.

4. Router Advertisements (RA) & SLAAC

Unlike IPv4, IPv6 clients can auto-configure using Stateless Address Autoconfiguration (SLAAC). The router advertises the prefix via Neighbor Discovery, and downstream endpoints build their own interface addresses.

Configure ipv6 nd for the test bridge:

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

Check your existing ND settings first (/ipv6 nd print detail). RouterOS includes a default *all entry. Always verify your effective ND configuration so you don't accidentally spit Router Advertisements back out ether1_untrust toward the AT&T RG.

DNS Advertisements (RDNSS)

To push DNS servers directly inside the RAs using RDNSS options (supported natively in modern Windows builds), assign your preferred resolvers:

/ipv6 nd
set [find where interface=bridge_ipv6] \
    dns=2001:4860:4860::8888,2001:4860:4860::8844 \
    advertise-dns=yes

5. Adding Unique Local Addresses (ULA) for Local Stability

Because ISP-assigned global prefixes (GUAs) can change on a whim, relying on them for local infrastructure management or internal DNS causes unnecessary friction.

Unique Local Addresses (ULAs)—the IPv6 equivalent of RFC 1918 private space—solve this.

We assigned a ULA /64 block (fdfd:231:0:10::/64) to bridge_ipv6:

/ipv6 address
add address=fdfd:231:0:10::1/64 \
    interface=bridge_ipv6 \
    advertise=yes

bridge_ipv6 now advertises two concurrent prefixes:

1. Global (GUA): 2600:1700:1335:452f::/64 (Internet bound)
2. Local (ULA): fdfd:231:0:10::/64 (Internal service reachability)

Windows endpoints dual-stack these seamlessly: GUA routes out the default gateway to the public Internet, while ULA traffic handles internal LAN communications without requiring NAT66.

RFC 4193 Note: fdfd:231::/48 was used here for lab clarity. Production ULA assignments should use a randomly generated 40-bit Global ID to prevent subnet overlapping during site-to-site VPN expansion.

6. Neighbor Discovery Mechanics: A Quick Refresher

IPv6 discards IPv4 broadcast mechanisms like ARP in favor of ICMPv6-based Neighbor Discovery Protocol (NDP).

   +-----------------------------------------------------------------------+
   |                        ROUTER DISCOVERY                               |
   |                                                                       |
   |   [ Windows VM ] --- (Type 133: Router Solicitation) ---> [ ff02::2 ] |
   |   [ Windows VM ] <--- (Type 134: Router Advertisement) -- [ MikroTik ] |
   +-----------------------------------------------------------------------+
   |                        ADDRESS RESOLUTION                             |
   |                                                                       |
   |   [ Windows VM ] --- (Type 135: Neighbor Solicitation) -> [ Sol-Node ]|
   |   [ Windows VM ] <--- (Type 136: Neighbor Advertisement) -- [ Target ]|
   +-----------------------------------------------------------------------+

• Router Discovery (Types 133 / 134): Endpoints multicast a Router Solicitation (RS) to ff02::2 (all-routers). The router replies with a Router Advertisement (RA) to ff02::1 (all-nodes) containing default routes, MTU, lifetimes, and prefixes.
• Address Resolution (Types 135 / 136): Replaces ARP. Uses Neighbor Solicitations (NS) directed to a Solicited-Node Multicast Address (ff02::1:ffXX:XXXX) derived from the target IP, drastically cutting broadcast noise across the switch fabric.

The CCR handles WAN-side NDP to the AT&T gateway automatically over link-local addresses (fe80::/10). You do not need manual static neighbor entries on WAN.

7. Hardening the IPv6 Firewall

Because IPv6 exposes devices directly without NAT, stateful firewall policies on both input and forward chains are non-negotiable.

Input Chain (Protecting RouterOS)

/ipv6 firewall filter
add chain=input action=accept connection-state=established,related comment="Accept established/related"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmpv6 comment="Accept essential ICMPv6"
add chain=input action=accept in-interface=ether1_untrust protocol=udp src-port=547 dst-port=546 comment="Allow DHCPv6 reply from RG"
add chain=input action=accept in-interface-list=trust comment="Allow trusted management"
add chain=input action=drop in-interface=ether1_untrust comment="Drop all other unsolicited WAN input"

Forward Chain (Protecting LAN Endpoints)

/ipv6 firewall filter
add chain=forward action=accept connection-state=established,related comment="Accept established/related"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept protocol=icmpv6 comment="Allow ICMPv6 pass-through"
add chain=forward action=accept in-interface=bridge_ipv6 out-interface=ether1_untrust comment="Allow test LAN outbound"
add chain=forward action=drop in-interface=ether1_untrust out-interface=bridge_ipv6 comment="Block unsolicited WAN to LAN"

⚠️ A Critical Firewall Footgun: Dropping Link-Local Traffic

During initial hardening, we tested an explicit RAW prerouting rule aimed at blocking incoming link-local traffic on WAN:

# DO NOT USE THIS RULE
/ipv6 firewall raw
add chain=prerouting action=drop in-interface=ether1_untrust src-address=fe80::/10

Result: Immediate protocol collapse.

Legitimate IPv6 control traffic (RAs, Neighbor Discovery, DHCPv6-PD acknowledgments, and next-hop gateway resolution) relies entirely on fe80::/10 source addresses between the MikroTik WAN interface and the upstream AT&T gateway. Dropping link-local traffic on a directly connected WAN interface severs critical control plane communication. Keep link-local traffic open on local segments.

8. Verification & Operational Checks

From the Windows test VM, confirm full auto-configuration:

ipconfig /all

Check for:

1. Valid fe80:: link-local address.
2. Valid global IPv6 address matching the AT&T delegated /64.
3. Default gateway set to the MikroTik’s link-local WAN/Bridge IPv6 address.
4. RDNSS-assigned DNS resolvers.

Run diagnostics:

:: Test ICMP Reachability
ping -6 2001:4860:4860::8888

:: Test DNS Resolution
nslookup google.com 2001:4860:4860::8888

:: Trace Route
tracert -6 2001:4860:4860::8888

Note: If tracert -6 drops off or shows * on intermediate hops, don't immediately panic. Core transit routers frequently deprioritize or drop ICMPv6 Time Exceeded generation while continuing to pass payload traffic at line rate.

9. Troubleshooting Upstream Frozen Route State

During testing, we ran into an intermittent routing freeze:

• The test VM could ping the MikroTik bridge and the internal interface of the AT&T RG.
• Outbound packets were captured exiting ether1_untrust.
• Public IPv6 traffic completely died. Replies never returned from the upstream AT&T network.
• Temporarily setting the IPv6 firewall to action=accept across all chains did not resolve the issue.

The Fix

Manually renewing the DHCPv6 client in RouterOS (/ipv6 dhcp-client renew 0) immediately restored outbound connectivity. RouterOS re-bound to the exact same prefix, but the AT&T RG instantly resumed forwarding outbound/inbound traffic across its backplane.

Root Cause Analysis & Diagnostic Steps

This issue points to a stale routing table or NDP state inside the AT&T gateway. The gateway maintained the DHCPv6 lease, but dropped the underlying dynamic route or neighbor entry pointing to our CCR until a fresh DHCPv6 exchange forced its forwarding plane to update.

If you encounter this behavior on AT&T gear, collect this data on the MikroTik before issuing a renewal:

/ipv6 dhcp-client print detail
/ipv6 route print detail
/ipv6 address print detail
/ipv6 neighbor print detail
/ipv6 pool print detail
/ipv6 firewall filter print stats

Additionally, run /tool torch interface=ether1_untrust or spin up a packet capture on UDP ports 546 and 547 to confirm whether outbound requests are leaving and whether return traffic is being dropped upstream by the RG's internal state machine.

Advanced DHCPv6 Client Tweaks

We tested two specific client parameters under /ipv6 dhcp-client:

1. use-interface-duid=yes: Forces RouterOS to generate its DUID from the WAN interface's MAC address (ether1_untrust) rather than the global router-wide base DUID. This ensures identity stability if system configuration alters internal interface numbering.
2. allow-reconfigure=yes: Allows the DHCPv6 client to accept server-initiated Reconfigure requests (RFC 3315) to trigger out-of-band renewal cycles if the upstream gateway requests it.

10. Summary

Setting up IPv6 on RouterOS v7 behind AT&T Business Internet works smoothly once the core control mechanisms are dialed in:

• Prefix Delegation vs. SLAAC: DHCPv6-PD handles the macro prefix handoff from the ISP to the CCR; SLAAC handles downstream address assignment to clients via RAs.
• Firewall Order: Always build explicit stateful filtering on forward and input chains. Never drop fe80::/10 link-local traffic on WAN.
• Dual Addressing: Combine dynamic GUAs (from-pool) with static ULAs (fdfd::/48) to maintain internal address stability across ISP rebinds.
• Watch Upstream State: AT&T residential-style gateways can occasionally freeze or drop dynamic prefix routes. A targeted DHCPv6 client renewal clears the pipe.

Next steps for this lab deployment: Working with AT&T to confirm if larger /56 delegations are available for this connection class to allow proper multi-VLAN routing without resorting to extra NAT66 or prefix slicing tricks.