Steven M. Jordan

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.

Goal

Configure a MikroTik router as an IKEv2 VPN server for mobile and remote clients, including Windows, Android, and Apple iOS/iPadOS.

Clients authenticate using X.509 certificates and receive an address from a dedicated VPN address pool.

Why IKEv2?

IKEv2 provides a standards-based IPsec VPN that is well suited to mobile clients. It is supported natively by Windows and Apple operating systems and is widely supported by Android VPN clients.

Compared with older VPN protocols, IKEv2 provides strong cryptography, certificate-based authentication, NAT traversal, and reliable reconnection when a mobile device changes networks.

Configuration Overview

The configuration consists of four basic components:

• Certificates: Create a Certificate Authority, server certificate, and client certificates.
• Client addressing: Create an IP pool and configure DNS and routing information supplied through IKEv2 Mode Config.
• IPsec: Configure the IKEv2 profile, proposal, peer, identity, and policy template.
• Firewall and NAT: Permit IKEv2/IPsec negotiation and control what authenticated VPN clients may access.

---

Step 1: Certificates

IKEv2 certificate authentication requires three certificate types:

• Certificate Authority (CA)
• IKEv2 server certificate
• IKEv2 client certificate

The CA signs both the server and client certificates, establishing the chain of trust used during IKEv2 authentication.

Create the Certificate Authority

Create the CA certificate that will sign the server and client certificates.

Configure the Certificate Revocation List

Specify the public address from which the Certificate Revocation List can be retrieved.

Use the router's public IP address or a DNS name reachable by VPN clients.

The CRL location is published through the CA certificate. It does not need to be configured separately on the server or client certificates.

Sign the Certificate Authority

Create the IKEv2 Server Certificate

Create a certificate identifying the VPN server and sign it with Domain_CA.

The server certificate should contain the VPN server's DNS name in both the Common Name and Subject Alternative Name.

The certificate should include the tls-server key usage. After creating it, sign it with Domain_CA and mark the CA and server certificates as trusted.

Create Client Certificates

Create an individual certificate for each VPN client or user.

For maximum client compatibility, use the same identity in the Common Name and Subject Alternative Name.

The certificate should include the tls-client key usage.

Sign the certificate with Domain_CA, mark it as trusted, and export the certificate and private key as PKCS#12 (.p12) for installation on the client.

Using individual certificates allows a single client to be revoked without affecting every other VPN user.

---

Step 2: VPN Client Address Pool

Dedicate a subnet or address range to remote VPN clients.

This address space should not overlap existing LAN or remote networks.

The pool may be shared with other remote-access VPN services when appropriate, although separate pools can simplify firewall policy and troubleshooting.

---

Step 3: Configure IPsec

Mode Config

Mode Config supplies network configuration to connecting VPN clients.

The client receives an address from ikev2-pool, a /32 client address, and 192.168.88.10 as its DNS server.

For a split-tunnel VPN, internal networks may also be advertised using split-include.

Mode Config determines what routes the client is asked to install. Firewall policy still determines what the client is actually permitted to access.

Phase 1 Profile

The IPsec profile defines the cryptographic parameters used during IKE negotiation.

Phase 2 Proposal

Create a dedicated proposal for IKEv2 traffic.

A dedicated proposal is preferable to modifying the RouterOS default because unrelated IPsec tunnels will not inherit the remote-access VPN configuration.

Policy Group and Template

Create a policy group for dynamically generated IKEv2 client policies.

Create the corresponding policy template.

RouterOS uses this template to generate IPsec policies dynamically as clients connect.

IKEv2 Peer

Create a passive IKEv2 peer that listens for incoming client connections.

Because the MikroTik is acting as the VPN server, remote clients initiate the connection.

IKEv2 Identity

Associate certificate authentication, Mode Config, and dynamic policy generation with the IKEv2 peer.

The router verifies that each connecting client presents a certificate signed by a trusted CA.

A specific remote-certificate is deliberately not configured. Specifying one would bind the identity to a particular client certificate. Leaving certificate matching generic allows multiple clients signed by the trusted CA to authenticate.

---

Step 4: Firewall and NAT

The firewall performs two separate functions: permitting establishment of the IKEv2/IPsec tunnel and controlling what authenticated VPN clients may access after the tunnel is established.

Allow IKEv2 and IPsec

At minimum, the router must accept IKE and NAT Traversal from the Internet.

If native ESP must be accepted separately:

These rules must appear before the router's general WAN input-drop rule.

Allow VPN Clients to Reach the LAN

Access from authenticated VPN clients into internal networks should be explicitly permitted according to policy.

Traffic not specifically authorized should remain blocked by the normal firewall policy.

NAT Considerations

Existing masquerade rules should not accidentally NAT traffic between VPN clients and internal networks.

Where necessary, place an IPsec NAT-bypass rule before the Internet masquerade rule.

The exact firewall and NAT configuration depends on whether the VPN is LAN-only split tunnel, includes multiple internal networks, or provides full-tunnel Internet access through the MikroTik.

Mode Config provides addressing and routing information. The firewall determines authorization.

That's It!

NPS Azure AD Extension Certificate Renewal

The NPS Azure AD Extension creates a self-signed certificate that’s only valid for two years. If you forget to renew it, authentication will eventually start failing when that certificate expires.

Renewal

Renewing the certificate is simple. Just rerun the Azure MFA NPS Extension configuration script:

C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1

This will generate a new certificate and update the extension to use it.

PowerShell Error

When you run the script, you might see an error like:

The package source https://www.powershellgallery.com/api/v2 is not reachable or resolved.

This usually means PowerShell isn’t using a modern TLS version when it tries to connect to the PowerShell Gallery.

Fix

Windows Server 2016, 2019, and newer support TLS 1.2, but PowerShell may still default to older protocols, depending on .NET and cryptography settings.

The quickest fix is to force TLS 1.2 in your PowerShell session and then rerun the script:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Once TLS 1.2 is enabled, the script can reach the PowerShell Gallery and the NPS Azure AD Extension certificate is renewed without further issues.

Problem

You need to move the FSMO roles, and you would rather do it in PowerShell than click through the old MMC snap-ins.

Solution

Use the Active Directory PowerShell module. If it is not already loaded, import it first.

Import-Module ActiveDirectory

See who has the forest roles

Get-ADForest contoso.com | ft DomainNamingMaster, SchemaMaster

See who has the domain roles

Get-ADDomain contoso.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

Move one role

This hands the PDC Emulator role to the domain controller named DCX.

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

PowerShell also accepts the role as a number:

• 0 = PDCEmulator
• 1 = RIDMaster
• 2 = InfrastructureMaster
• 3 = SchemaMaster
• 4 = DomainNamingMaster

Move several roles

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" -OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Move all of them by number

Move-ADDirectoryServerOperationMasterRole "DCX" -OperationMasterRole 0,1,2,3,4

That's it. Same command either way. Name the destination domain controller, then list the roles you want it to take.

References

Move-ADDirectoryServerOperationMasterRole

Migrating FSMO roles from Windows Server 2012 R2 to 2016

GPOs don't work on the VPN?

Problem:  

Branch office or managed laptops are missing group policies.

Definition:  Group Policy Slow Link Detection

Slow-link detection identifies slow connections:  Slow transfer rates or high latency.  This process can trigger applications to scale back feature and function.  For example, slow link detection may interfere with distributed file systems (DFS).   In other situations, slow link detection can prevent remote workstations from receiving GPO updates.

Background:  

Wide-spread high-speed Internet connections (e.g., 100 Mbps) were uncommon before c. 2009.  Older network protocols were less efficient (e.g., SMB2 vs SMB3).  Slow-link detection was designed to compensate for poor connections.  This legacy process continues to impact modern network services (e.g., Windows 2019). 

Group Policy Slow Link Detection:

Connection rates are measured between the domain controllers and the client.  Group policy changes are not distributed when this transfer rate is less than 500 kbps. 

500 kbps may seem reasonable -but it's not. 

Solution:

Disable slow link detection:

   GPO:  Policies\Administrative Templates\System\Group Policy\Slow Link Detection

Options:  Enable this policy.

• Enter 0 to disable slow-link detection.
• Alternately, set high connection speed rate (e.g., 10000 Kbps is ~10 Mbps).

That's it!

References:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978717(v=technet.10)