Mechanisms for Transition from IPv4 to IPv6
Discover the concept of "IPv6 Mostly" and its role in transitioning from dual-stack networks to IPv6-dominant environments. Learn about relevant RFCs, DHCPv4 configuration, NAT64 translators, and the significance of PREF64 in Router Advertisements. Implementing IPv6 Mostly allows networks to gracefully sunset IPv4, providing a cost-effective strategy for managing client connectivity while draining the remaining pool of IPv4-dependent devices.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
"IPv6 Mostly" at the edge Brian Candler NetUK1
Recap: 464XLAT (RFC 6877) 203.0.113.1 8.8.8.8 192.168.1.1 8.8.8.8 2001:db8::c0a8:101 64:ff9b::808:808 CLAT PLAT NAT46 NAT64 Browser Designed to carry IPv4 (from a dual-stack edge) over an IPv6-only core
Client with embedded CLAT 203.0.113.1 8.8.8.8 2001:db8:a:b:c:d:e:f 64:ff9b::808:808 PLAT NAT64 192.0.0.2 8.8.8.8 CLAT Browser NAT46 Client can be connected to an IPv6-only network and still reach the IPv4 Internet
What is "IPv6 Mostly"? Relatively new set of mechanisms for the graceful sunset of IPv4 in dual-stack networks RFC 8925: DHCPv4 "IPv6-Only Preferred" (option 108) RFC 8781: PREF64 in Router Advertisements The client declines an IPv4 address and enables an embedded CLAT (NAT46 464XLAT) IPv4 Internet still accessible, via a NAT64 device, even though client has only IPv6 address In effect, using IPv6 as a sort of "super RFC1918"
What's the purpose? Huge networks (Google) running out of RFC1918 addresses For everyone else: dual stack is an expensive "forever" proposition with no exit strategy IPv6-mostly lets you drain down and observe the pool of clients that still require IPv4 connectivity When there's nothing important left, you can turn off IPv4 at the edge and be confident nothing will break
You will need: DHCPv4 server configured to respond with option 108 to clients who request it in their Parameter Request List A NAT64 translator (PLAT) somewhere at your network edge Router configured to include PREF64 in Router Advertisements, announcing the PLAT's prefix Clients which can work with this (see later)
% ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=34.383 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=33.917 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.316 ms 09:00:48.499160 IP6 2001:df9:0:3:c88:a341:b8c:8ade > fd64::808:808: ICMP6, echo request, id 12084, seq 0, length 64 09:00:48.533271 IP6 fd64::808:808 > 2001:df9:0:3:c88:a341:b8c:8ade: ICMP6, echo reply, id 12084, seq 0, length 64
Client view (macOS) % ifconfig en0 en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500 options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> ether 60:3e:5f:81:98:c4 inet6 fe80::14a5:e833:7d65:c178%en0 prefixlen 64 secured scopeid 0xe inet6 2001:df9:0:3:1424:5189:5756:bcaa prefixlen 64 autoconf secured inet6 2001:df9:0:3:7407:fd14:7b93:124b prefixlen 64 autoconf temporary inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2 inet6 2001:df9:0:3:c88:a341:b8c:8ade prefixlen 64 clat46 nat64 prefix fd64:: prefixlen 96 nd6 options=201<PERFORMNUD,DAD> This IPv4 address is entirely internal and does not leave the machine or so I thought!
Notes on DHCP option 108 Server response value tells client how long (in seconds) it can run single-stack before checking again In IPv6-only networks without any DHCPv4, more recent clients will enable the CLAT anyway (e.g. macOS 13) However, option 108 prevents the client from repeatedly broadcasting DISCOVER and configuring link-local (169.254) There was an older RFC for that too (option 116, disable stateless AutoConfigure: RFC 2563) but as far as I can see, no client implements it
Notes on PREF64 in RAs Many router vendors only have it in very new firmware e.g. Mikrotik added in RouterOS 7.8 (but they have no NAT64 anyway) Linux radvd does it, but not in last release (v2.19) You need to compile from source Changing eventually: there is a v2.20_rc1 (Nov 2023) You can't use radvd to send PREF64 on behalf of a different router PREF64 avoids the need for DNS64 completely In the absence of PREF64, clients typically can also use the old ipv4only.arpa mechanism for detecting NAT64 prefix (RFC 7050) But these days many clients bypass the local DNS resolver (DoH etc)
State of client support (CLAT, PREF64) macOS, iOS, Android: all good Windows: in progress currently only mobile broadband cards Linux: poor to non-existent install and configure clatd by hand?! depends on either a userland translator (tayga) or an out-of-tree kernel module (nat46) does not support PREF64 detection
Issues You'll only start finding the problems in your IPv6 connectivity when you start running IPv6-only! e.g. IPv6 drops after 30 minutes, nobody notices because Happy Eyeballs Minor client-side niggles. For macOS 14.3-14.5: traceroute to IPv4 destination shows "*" for all hops "ssh -4 hostname" fails (but v4 literal is fine, and homebrew ssh is fine) 192.0.0.2 leaking as source address on multicast packets Some wireless controllers see this as "IP Theft" and kick off the client. Disable it. Caveats with the Well-Known Prefix 64:ff9b::/96 Can't be used with private IPv4 destination addresses (RFC 6052 3.1)
You need a NAT64 Something you need to configure or build (or rent) It needs IPv4 address(es) on the outside, just like your NAT44 So it's not going to reduce your public IPv4 requirement The benefit is that you can replace your IPv4 edge networks with IPv6, instead of running IPv6+IPv4 dual stack forever
Test: APRICOT IPv6-only SSID (Feb 2024) Used coredhcp to return DHCP option 108 whilst offering no IPv4 addresses at all (i.e. pure single-stack IPv6, not IPv6-mostly) 142 unique MAC addresses seen in total 115 (81%) of these requested option 108 Of the remaining 27, none of them offered option 116 These 27 requested DHCPv4 repeatedly Median 53 times One device tried 49,482 times over 2 days
More information https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6- mostly-access-networks/ -- Ond ej Caletka https://ripe87.ripe.net/archives/video/1160/ -- Jen Linkova Monitor your own network to see how many devices include option 108 in their Parameter Request List DHCP-Message (53), length 1: Discover Parameter-Request (55), length 12: Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway (3), Domain-Name (15), Unknown (108), URL (114), Unknown (119) Unknown (252), LDAP (95), Netbios-Name-Server (44), Netbios-Node (46)
