IPv6-only deployments are becoming increasingly common in cloud, carrier and private networks. When building a secure remote-access or site-to-site solution over IPv6-only transport, IKEv2 offers a modern, robust IPsec control plane with mobility and multihoming support (MOBIKE), streamlined negotiation, and wide client support. This article walks through practical design choices, security considerations, and concrete configuration examples for deploying IKEv2 in IPv6-only environments. It is aimed at site owners, system architects, and developers who need a concise but technically substantive setup guide.

Why IKEv2 for IPv6-only?

IKEv2 was designed to address many limitations of IKEv1. For IPv6-only networks specifically, it brings several advantages:

  • Native IPv6 transport: IKEv2 messages and ESP packets can be carried directly over IPv6 addresses without IPv4 mappings.
  • MOBIKE support: endpoint IP changes (mobile clients, prefix changes) are handled without rekeying the entire session.
  • Simpler SA negotiation: modern cipher suites, PRFs and D-H groups are standardized making policy management easier.
  • Interoperability: Broad client support across Linux (strongSwan/Libreswan), Windows (native IKEv2 client), macOS/iOS and Android.

High-level design considerations

Before any configuration, decide on the service model and how IPv4 reachability is handled for your users:

  • IPv6-only network with IPv6-only services: simplest—no IPv4 needed if all destinations support IPv6.
  • IPv6-only clients needing IPv4 access: deploy NAT64/DNS64 or 464XLAT on the server or network. Alternatively, provide IPv4-in-IPv6 tunnelling inside the VPN (adds complexity).
  • Client addressing: assign ULA/global IPv6 prefixes to clients via static routes or DHCPv6/PD (prefix delegation) depending on your scale.

Security posture decisions:

  • Prefer certificate-based authentication or EAP-TLS for enterprises. PSK is acceptable for small deployments but harder to scale securely.
  • Use strong ciphers: AES-GCM (AES-256-GCM) or ChaCha20-Poly1305, with ECDH groups (e.g. X25519 or P-384/X448 as supported).
  • Enable MOBIKE to allow seamless roaming and IPv6 prefix or address changes.

Network and MTU considerations

IPv6 requires a minimum MTU of 1280 bytes for the path. IPsec (ESP + optional UDP encapsulation for NAT-T) adds overhead which can push packets above path MTU. Recommended practices:

  • Set the interface MTU on the VPN virtual interface lower to account for ESP overhead. A safe default: MTU = 1280 – 100 ≈ 1180, but test with your exact encryption/authentication overhead.
  • Enable MSS clamping for TCP flows (e.g., clamp to 1200) to avoid fragmentation.
  • Prefer AES-GCM/ChaCha20-Poly1305 (authenticated encryption) to reduce header overhead vs separate AH/ESP approaches.
  • On Linux hosts, adjust sysctl if needed: net.ipv6.conf.all.disable_ipv6=0 and tune fragmentation parameters if the environment introduces PMTU black holes.

IKEv2 & IPsec policy parameters

Use modern defaults for key exchange, encryption, and lifetimes. Example strong recommendations:

  • Encryption: AES-256-GCM or ChaCha20-Poly1305
  • Integrity/PRF: SHA2-256 (prf=hmac-sha2-256)
  • DH groups: X25519 (RFC 7748) or NIST P-384 if X25519 unsupported
  • SA lifetimes: IKE SA 24h (86400s), Child SA 1–8h depending on rekey policy (3600–28800s)
  • MOBIKE: enabled to support mobile endpoints

Practical strongSwan server example (IPv6-only)

Below are minimal yet practical snippets for a strongSwan server running on an IPv6-only host. This assumes cert-based authentication for the server and EAP or certs for clients.

Certificate bootstrapping

Generate CA and server certificate (strongSwan’s pki utility):

Commands:

ipsec pki --gen --type rsa --size 3072 --outform pem > caKey.pem

ipsec pki --self --ca --lifetime 3650 --in caKey.pem --type rsa --dn "CN=MyVPN CA" --outform pem > caCert.pem

ipsec pki --gen --type rsa --size 3072 --outform pem > serverKey.pem

ipsec pki --pub --in serverKey.pem | ipsec pki --issue --lifetime 1825 --cacert caCert.pem --cakey caKey.pem --dn "CN=vpn.example.com" --san "vpn.example.com" --san "2001:db8:..." --outform pem > serverCert.pem

strongSwan ipsec.conf (core parts)

Place these under /etc/strongswan/ipsec.conf (IPv6 addresses used):

config setup
charondebug="ike 2, knl 2, cfg 2"
uniqueids=yes

conn ikev2-v6
left=%any
leftcert=serverCert.pem
leftid="CN=vpn.example.com"
leftsubnet=::/0
right=%any
rightauth=pubkey
rightsourceip=fd00:100::/64
ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16!
keyexchange=ikev2
mobike=yes
rekey=no
dpdaction=clear
auto=add

Notes:

  • leftsubnet=::/0 or specific routes you want to provide through the VPN.
  • rightsourceip supplies IPv6 addresses from a ULA prefix (fd00:100::/64). For scaled setups use RADIUS/DHCPv6 for assignments.

ipsec.secrets

Reference the server private key:

: private serverKey.pem

Firewall and kernel rules for IPv6

On an IPv6 host using nftables or ip6tables, allow IKE and ESP:

  • Allow UDP/500 and UDP/4500 for IKE and NAT-T: ip6tables -A INPUT -p udp –dport 500 -j ACCEPT and similar for 4500.
  • Allow ESP (protocol 50) if your network path does not require NAT-T: ip6tables -A INPUT -p 50 -j ACCEPT.
  • Allow forwarding between the client’s virtual subnet and external interfaces; enable IPv6 forwarding: sysctl -w net.ipv6.conf.all.forwarding=1.

IPv4 reachability from IPv6-only clients

If clients on IPv6-only networks must access IPv4 hosts, choose one of:

  • NAT64/DNS64: The server or network provides DNS64 and NAT64. IPv6-only clients resolve IPv4-only hostnames to synthesized IPv6 addresses and traffic is translated at NAT64 gateway.
  • 464XLAT: Useful for mobile/managed devices—client-side translation combined with a network CLAT and stateful PLAT.
  • IPv4-over-IPv6 transport inside the VPN: Set up a v4-in-v6 tunnel or run a v4-enabled NAT on the VPN server. This is more complex but gives full IPv4 connectivity.

For corporate setups, NAT64/DNS64 centralization usually scales better and avoids per-client IPv4 address exhaustion.

Client configuration guidelines

Windows/macOS/iOS/Android all have native IKEv2 support. Important client considerations:

  • Use certificate validation—install CA and client cert or configure EAP credentials.
  • Ensure the client requests an IPv6 address or receives an assigned address via the server’s rightsourceip pool or DHCPv6.
  • Enable MOBIKE or equivalent in client settings to avoid session resets when switching networks.
  • Lower MTU on the client-side virtual adapter if persistent fragmentation occurs; clamp TCP MSS to account for ESP overhead.

Rekeying, lifetimes and security hardening

Proper lifetimes and rekey strategies reduce impact of compromised keys and maintain availability:

  • Set IKE SA lifetimes to several hours to a day (e.g., 24h) and child SAs shorter (1–8h). Use rekeying so SAs are refreshed without user disruption.
  • Enable perfect forward secrecy via ECDH groups (X25519 or 256/384-bit curves).
  • Regularly rotate CA/server certificates and enforce short validity for client certs if possible.
  • Monitor logs and configure alerting on frequent reauths or failed IKE negotiations (possible attack indicator).

Troubleshooting checklist

  • Verify UDP 500/4500 reachability (ICMPv6 port unreachable indicates blocked path).
  • Confirm ESP (protocol 50) is permitted if NAT-T is not used.
  • Check assigned IPv6 addresses and routing (ip -6 addr, ip -6 route).
  • Inspect strongSwan logs (charon) with increased verbosity and look for AUTH/CHILD_SA errors.
  • Test IPv4 reachability strategy (NAT64/DNS64): confirm DNS64 is synthesizing AAAA records and NAT64 translating TCP/UDP correctly.
  • Examine MTU and fragmentation with ping6 -s tests and tune MSS/MTU accordingly.

Operational best practices

For production-grade deployments:

  • Use automated certificate management (ACME for server certs; enterprise PKI for clients).
  • Integrate authentication with RADIUS or LDAP for EAP-based user auth and centralized accounting.
  • Implement logging/monitoring and collect IKE events centrally (SIEM) for incident detection.
  • Perform periodic cipher-suite reviews to retire weak algorithms and keep DH groups current.

IKEv2 delivers a secure, resilient control plane for IPv6-only networks when configured with modern crypto, correct MTU handling, and an appropriate IPv4 interworking strategy (if needed). By favoring certificate-based auth, enabling MOBIKE, and tuning SA lifetimes and MTU/MSS, site owners and operators can build scalable VPN services fit for both corporate and cloud-native environments.

For more practical tips, example configs and service options tailored to dedicated IPv6 VPN deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.