Abstract

Wrangling IPv6 on AT&T. Deployment tips for Prefix Delegation, Router Advertisements, Neighbor Discovery, and stateful firewalling.

The Low-Down

This post walks through IPv6 for AT&T Internet (a non-SLA service behind an AT&T residential gateway). Unlike Spectrum, which hands out a generous /56, AT&T delegates a single /64. Yep. One measly /64. Needlessly stingy, but we can work with it.

Goal is isolated IPv6 connectivity for a single Windows test VM, with the MikroTik handling the prefix and the firewall keeping the rest of the world out.

Network Topology

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

This example works for any RouterOS hardware. ether16_ipv6 is assigned to bridge_ipv6 and patches directly into a dedicated Hyper-V virtual switch isolated from hypervisor management.

Note: IPv4 IP passthrough does not affect IPv6. The AT&T gateway handles IPv6 routing and prefix delegation independent of IPv4. You cannot bypass its IPv6 stack entirely.

Requesting the Prefix

Configure the IPv6 client to request a prefix on the WAN interface:

/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

Breakdown:

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

Verify the binding:

/ipv6 dhcp-client print detail

Expected 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

A /64 is the smallest routable subnet, so options are limited: DHCPv6 server, SLAAC, or Unique Local Addresses if you need to route beyond this single segment. ULAs are not used in this lab.

Assign the PD to the LAN Bridge

Bind the /64 to the bridge so it stays current if the ISP renumbers:

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

Verify:

/ipv6 address print

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

RouterOS shows the network address by default for pool assignments. If you want to ping the router itself (for example ::1), explicitly bind that ID:

/ipv6 address add interface=bridge_ipv6 from-pool=att_pd eui-64=::1

Dynamic and static in one.

Router Advertisements and SLAAC

Unlike IPv4, IPv6 clients can auto-configure with SLAAC. The router advertises the prefix via Neighbor Discovery and the clients build their own addresses.

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

Check existing ND settings first (/ipv6 nd print detail). RouterOS includes a default *all entry. Make sure you are not advertising back out ether1_untrust toward the AT&T gateway.

Windows natively supports DNS from RAs. Point RDNSS at your preferred resolvers:

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

Not every device supports RDNSS. Android and Xbox often need dual-stack and fall back to IPv4 DNS. Plan accordingly.

Neighbor Discovery Quick Refresher

IPv4 finds neighbors with broadcasts (ARP). IPv6 uses multicast and ICMPv6 Neighbor Discovery.

• Router Discovery (Types 133/134): Client multicasts a Router Solicitation to ff02::2. Router replies with a Router Advertisement containing default routes, MTU, lifetimes, and prefixes.
• Address Resolution (Types 135/136): Replaces ARP. Uses Neighbor Solicitations to a solicited-node multicast address derived from the target IP. Far less noise than broadcast ARP.

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

Hardening IPv6

Global addresses expose devices directly to the Internet. Stateful firewall rules on the WAN are required.

Input chain (protect the router):

/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 (protect the LAN):

/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"

Do not drop link-local traffic on the WAN. This rule looks tempting and breaks everything:

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

Legitimate control traffic (RAs, Neighbor Discovery, DHCPv6-PD) relies on fe80::/10 sources. Dropping it collapses the protocol between the WAN interface and the AT&T gateway.

Validate

From the Windows test VM:

ipconfig /all

Look for:

• Valid fe80:: link-local address
• Valid global address matching the AT&T /64
• Default gateway set to the MikroTik’s link-local address
• RDNSS DNS resolvers

Quick checks:

ping -6 2001:4860:4860::8888
nslookup google.com 2001:4860:4860::8888
tracert -6 2001:4860:4860::8888

Don’t panic if tracert shows asterisks. Many transit routers deprioritize or drop ICMPv6 Time Exceeded while still forwarding traffic at line rate.

Troubleshooting

During testing I hit an intermittent failure:

• The test VM could ping the local bridge and the AT&T RG’s internal interface.
• Outbound packets left ether1_untrust.
• Public IPv6 traffic died. Replies never came back.
• Opening the firewall completely did not fix it.

The fix was simple: renew the DHCPv6 client.

/ipv6 dhcp-client renew 0

RouterOS re-bound to the same prefix and the AT&T gateway immediately started forwarding again. Short-term workaround is to schedule that renew every few hours. Long-term is getting AT&T to look at the residential gateway.

This points to stale routing or NDP state inside the AT&T box. It kept the DHCPv6 lease but dropped the dynamic route or neighbor entry until a fresh exchange forced an update.

Two client tweaks worth testing:

• use-interface-duid=yes — Builds the DUID from the WAN interface MAC instead of the router-wide base DUID.
• allow-reconfigure=yes — Accepts server-initiated reconfigure requests so the upstream gateway can trigger a renewal.

Summary

IPv6 on RouterOS 7 behind AT&T works once the control plane is sorted:

• DHCPv6-PD brings the prefix from the ISP; SLAAC hands addresses to clients via RAs.
• Build explicit stateful filters on input and forward. Never drop fe80::/10 on the WAN.
• Dynamic GUAs from the pool keep the LAN current if the prefix changes.
• Watch the upstream gateway. A simple DHCPv6 renew clears the occasional stuck state.

That’s all folks.

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!

Problem:    

Solution:  

root@SRX# load replace terminal    
[Type ^D at a new line to end input]
interfaces 
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                    address 192.168.1.2/24;
            }
        }
    }
}
load complete
[edit]
root@SRX# commit

Problem:    

1. SRX 300 Series:
   
   {primary:node0}
    smj@SRX> request routing-engine login node 1
   
   
2. SRX 1500 Series:
   
   smj@SRX% rlogin -T node1

How To:  

Problem:  

• DH2-3DES-SHA1.   

Solution:  

• IKEv2 DH14-AES256-SHA256

Step 1:  Regedit:

Step 2:  Create new key:

Step 3:  Create new DWORDs (Table 1):

VPN Problem:  

Solution:

Key Management

Security Strength 

IPsec Cipher Assessment

• 89 security-bits are vulnerable to known attacks.
• 103 security-bits are not vulnerable to known attacks -for now.  Status forecast to depreciate in the near-future (may be months or years).
• 128 security-bits are not vulnerable to known attacks.  Status forecast remains secure for near-future.
• 192 security-bits are not vulnerable to known attacks.  Status forecast remains secure for long-term future (years).

Problem:  

Solution:  

Summary:

Problem:

• Older Kyocera Android phone.  
• Problem device only connects with 2.4GHz radios.

Topology:

Solution:

1. Identify client session:
   

   
   *WLC# sh sessions network verbose
   
   Name:               last-resort-Guest 2.4GHz-570
   
   SSID:               Guest 2.4GHz
   
   MAC:                6c:xx:xx:xx:xx:xx
   
   AP/Radio:           1/1
   
   State:              DEASSOCIATED
   
   Device type:        android-generic (AAA)
   
   Radio type:         802.11ng
   
   Last packet rate:   6.0 Mb/s
   
   Last packet RSSI:   -49 dBm
   
   Last packet SNR:    46
   

   Session interpretation:
   
   • Session state is deassociated.  
   • Excessive of roaming attempts.  
   • Good signal strength and SNR.  
   • Last packet rate is only 6.0 Mb/s. 
   Data indicates the phone probably uses legacy wireless standards -it's old!


2. Enable log tracing to debug connection attempts:
   *WLC#set log trace enable severity debug
*WLC#set trace dot1x level 10 mac
*WLC#set trace sm level 10 mac
*WLC#sh log trace
SM Apr 14 13:45:08.197931 DEBUG SM-EVENT: Cannot set ipaddr for 6c:76:60:59:9e:6a
SM Apr 14 13:45:08.743477 DEBUG sm_do_flood_announce: 6c:76:60:59:9e:6a flood announce
SM Apr 14 13:45:16.176513 DEBUG SM-EVENT: (4601) rssi -69, rate code 0x0018, idle 48 secs
SM Apr 14 13:45:16.176661 DEBUG SM-EVENT: (4601) idle timer 132755 left, reset to 132000 ms
SM Apr 14 13:45:16.177599 DEBUG SM-EVENT: (4556) rssi -56, rate code 0x0018, idle 9 secs
SM Apr 14 13:45:16.177756 DEBUG SM-EVENT: (4556) idle timer 150259 left, reset to 171000 ms
SM Apr 14 13:45:16.179532 DEBUG SM-EVENT: (5415) rssi -76, rate code 0x0018, idle 20 secs
SM Apr 14 13:45:16.179653 DEBUG SM-EVENT: (5415) idle timer is tracking (160258 to go)
SM Apr 14 13:45:16.180066 DEBUG SM-EVENT: (4551) rssi -63, rate code 0x0018, idle 6 secs
SM Apr 14 11:12:44.674414 DEBUG SM-DOT11: sm_dot11_handle_deassociate: ev type 5 (good), token 0, mac 6c:76:60:59:9e:6a
SM Apr 14 11:12:44.674576 DEBUG SM-STATE: (2462) mac 6c:76:60:59:9e:6a, flags 1801800028834dh, to change state ACTIVE -> DEASSOCIATED, by sm_dot11_handle_deassociate
Log Interpretation:
   
   • SM=Session Management.
   • SM-DOT11=World Mode Multi-Domain Operation.  The DOT11D option makes access points advertise local settings, such as frequencies and power levels.
   • Rate code 0x0018 = 11Mb per Multi-band Atheros Wi-Fi (MADwifi) 5212.
   The deassociation was based on DOT11D.  In other words, due to AP frequency or power level restrictions.


3. Check the configuration for frequency or power restrictions:
   set service-profile Guest_2.4 transmit-rate 11g mandatory 12,24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,18.0 beacon-rate 24.0 multicast-rate AUTO
Snap!  The service profile indicates that devices must connect at a minimum, 12Mbps -normally good policy.  However, we have a single client that can only connect at 6Mbps.

Available Options:

1. Remove 6Mbps from the list of disabled data rates.  N.B., Legacy devices on the BSSID has a negative impact for the entire wi-fi network. Is one person worth the trouble?  It certainly is if that person is your boss!
   
2. Create a dedicated legacy SSID -diplomatic solution.
3. Ask the employee to get rid of the stone-age device!   Suggest or provide a modern device that handles 802.11na!

Executive Summary:

Problem:

Topology:

Symptoms:

Cause:

Influencing Factors: 

1.  Power save handler. iPhones enter standby/ sleep mode based on application activity. iPhones generally disconnect Wi-Fi in standby mode. End-users should understand this behavior is by design (à la Apple). It is not a limitation of their corporate Guest network.
2. Roaming. Clients may disconnect if the roaming process takes too long.
3. Spectrum preference. iPhones prefer the 2.4GHz spectrum over the 5Ghz spectrum. Wireless clients work best on the 5GHz spectrum. Consider disabling 2.4GHz radios from the APs.
4. Data Rates. Legacy 2.4GHz data rates (e.g., 802.11b and 802.11g) harm 802.11n wireless networks. Disable 802.11b and consider disabling 802.11g (i.e., adjust roaming cell size). Wireless networks realize 30% to 50% increases in throughput after disabling 1,2,5.5, and 11 Mbps data rates.
5. Encryption and Ciphers. WPA and TKIP caps/limits Wi-Fi networks to 54Mbps. Juniper recommends only implementing WPA2 with CCMP cipher for 802.11n transmissions. Pre-shared key is acceptable. 802.1X (i.e., WPA2-Enterprise) is better.
6. Range. Signal strength affects client roaming decisions. 802.11b (2.4GHz) has nearly twice the range of 802.11a (5GHz). Adjust radio power levels (i.e., transmit power) so that 5GHz RSSI is great than the 2.4GHz RSSI. For example, set 2.4GHz to 4 dBm; and set 5GHz to 12dBm. 

Power Save:

Roaming Rates

Spectrum Preference:

Spectrum Throughput

RSSI, SNR, and Throughput:

iPhone Roaming Process:

1. iPhone compares current BSSID (based on radio Mac) and other available AP BSSID signal levels.
2. The roaming decision based on client activity: (a) idle session (phone in pocket) or (b) active session (e.g., web surfing). iPhone searches for a better signal level in both 2.4GHz and 5GHz bands.

• iPhone roams when it locates another AP with a signal at least +12dB better.
• iPhone scans in 90 second intervals until its current signal strength improves (e.g., -69 dB) or it locates a different BSSID with 12dB stronger signal strength. 

• iPhone chooses new BSSID if it has +8dB or greater RSSI.
• iPhone continues to scan in 90 second intervals until current signal improves or locates a different BSSID at least 8 dB or better. 

Encryption and Ciphers

References: