Towards the Age of IPv6-Only#

Speakers not listed on the program item; the LACNIC 45 tutorial overview identifies José Cotúa and Alejandro Acosta (LACNIC tutorial team)

• Why: IPv6-mostly (RFC 8925) is quietly becoming the pragmatic end-state for campus, enterprise, and access networks — the PM may not be tracking it, and this tutorial carries real configurations and an OS-support matrix that de-risk a decision they will likely face.
• What: A hands-on tutorial on IPv6-only and IPv6-mostly operation: NAT64/DNS64 mechanics and header translation; 464XLAT for IPv4 literals, legacy IPv4-socket software, and broken dual-stack servers; and the IPv6-mostly model (RFC 8925 §1.2) where one segment simultaneously serves IPv6-only, dual-stack, and IPv4-only hosts — hosts that request DHCPv4 option 108 simply do not get an IPv4 address. Claimed benefits: >⅔ savings in IPv4 addresses, less NAT, and a simpler network than dual stack. Companion decks cover an IPv6-only recursive DNS resolver behind NAT64, RFC 8950 (extended-nexthop encoding for routing IPv4 packets over IPv6-only links), and DHCPv6 prefix delegation.
• How: DHCP option 108 signaling (client requests it; a configured server offers an IPv4 lease of "none for 30 minutes"; the client aborts and retries later), with host-side CLAT — native on Android 12+, iOS 15+, and macOS 12.0.1+ (CLAT activates on seeing the PREF64 router-advertisement option); Windows 11 support in recent releases; Linux via the clatd script or NetworkManager 1.52+.
• Where applicable: Enterprise/campus/access networks with NAT64 in place and IPv4 pool pressure; DC relevance is narrower but real (RFC 8950 for IPv6-only fabrics). The OS-support matrix is the gating constraint — older client fleets simply keep dual stack on the same segment, which is precisely what the model is designed to allow.