You cannot automatically assign a Unique Local Address (ULA) via Stateless Address Autoconfiguration (SLAAC) on macOS because the operating system strictly adheres to RFC 4862, which reserves SLAAC for generating Global Unicast Addresses (GUA) from Router Advertisements. macOS does not support using RA prefixes for ULA generation natively. To achieve this behavior, you must manually configure IPv6 addresses or use a local DHCPv6 server that provides ULA options, as the built-in network settings only handle GUA assignment through standard router advertisements.
Understanding SLAAC and IPv6 Address Types
Stateless Address Autoconfiguration (SLAAC) is a protocol defined in RFC 4862 that allows devices to self-assign IPv6 addresses without a central server like DHCP. When a device connects to an IPv6 network, it listens for Router Advertisements (RA) sent by routers on the local link. These RAs contain prefix information that tells the device which range of Global Unicast Addresses (GUA) it can use. The device combines this prefix with its Interface Identifier (usually derived from its MAC address using EUI-64 or generated randomly for privacy) to create its own IP address.
Unique Local Addresses (ULA), defined in RFC 4193, are intended for local communication within an organization or site, similar to private IPv4 addresses (like 192.168.x.x). They start with the prefix fd00::/8. While some enterprise networks might want to distribute ULAs automatically, the SLAAC mechanism is designed specifically for global routing prefixes. Consequently, most consumer and standard business routers do not advertise ULA prefixes in their RAs, and client operating systems like macOS do not interpret RA prefixes as instructions to generate ULA addresses. This architectural distinction means that expecting macOS to auto-configure a ULA via SLAAC is based on a misunderstanding of how IPv6 addressing works in modern networking stacks.
Why macOS Does Not Support ULA via SLAAC
The macOS network stack is highly compliant with IETF standards. When you configure IPv6 settings in System Settings under Network, you have limited options: Automatic, Using DHCPv6, and Manually. The "Automatic" setting triggers SLAAC. If your router advertises a GUA prefix (such as 2001:db8::/64), macOS will generate a GUA. It ignores any other prefix types that might theoretically be advertised if they do not conform to the expected GUA structure for auto-configuration.
There is no hidden toggle or advanced preference in macOS that enables ULA generation via SLAAC. This is not a bug but a design choice to ensure interoperability with the broader internet infrastructure. Attempting to force this behavior through standard network configuration interfaces will fail because the underlying kernel networking code filters out non-GUA prefixes for auto-configuration purposes. For users encountering issues with IPv6 connectivity, such as those described in
Unable to connect using ipv6 with macOS: ping6: UDP connect: No route to host, the problem is often related to incorrect RA filtering or firewall rules, not a lack of ULA support.
Manual Configuration of ULA on macOS
Since automatic assignment is not supported, you must manually assign the ULA if you need one for local services. This involves navigating to System Settings > Network, selecting your active interface (Wi-Fi or Ethernet), and clicking Details or Network Settings. Under the TCP/IP section, change the Configure IPv6 setting to Manually. In the IPv6 Address field, enter a valid ULA from the fd00::/8 range, such as fd12:3456:789a::1. You must also specify the Subnet Prefix Length, typically /64, and the Router Gateway if required for routing beyond the local link.
This manual approach ensures that your Mac has a consistent local address for internal services like file sharing or local DNS resolution. However, it requires administrative intervention every time the network topology changes or if you move between different local networks. For dynamic environments where multiple devices need ULAs, manual configuration becomes impractical. In such cases, relying on a local DHCPv6 server is a more scalable alternative, although macOS's native DHCPv6 client still primarily targets GUA assignment and may require specific vendor extensions to accept ULA assignments via DHCPv6 Option 31 or similar mechanisms, which are rarely implemented in standard home routers.
Alternative Solutions for Local IPv6 Management
If your goal is to manage local IPv6 addresses efficiently, consider using a dedicated DHCPv6 server like
dnsmasq or
radvd configured to send specific options. While SLAAC handles the GUA, DHCPv6 can provide additional information. However, note that macOS's DHCPv6 implementation is conservative. For many users, the best practice is to rely on GUA for external connectivity and use mDNS (Multicast DNS) for local service discovery rather than depending on static or dynamically assigned ULAs. This aligns with modern zero-conf networking principles.
Another consideration is NAT64/DNS64 translation, which allows IPv6-only clients to communicate with IPv4 servers. If you are experiencing connectivity issues in mixed environments, refer to
Unable to Access Internet with NAT64 Network Sharing on MacBook Pro running macOS High Sierra for troubleshooting steps related to translation layers. Understanding the distinction between GUA, ULA, and link-local addresses (fe80::/10) is crucial for diagnosing these issues. Link-local addresses are always auto-assigned and work for local neighbor discovery, but they are not routable beyond the single link segment.
Frequently Asked Questions
Can I enable ULA auto-assignment via a terminal command?
No, there is no terminal command or sysctl parameter that enables ULA generation via SLAAC on macOS. The kernel networking stack strictly follows RFC 4862 for SLAAC, which mandates the use of globally routable prefixes. Any attempt to manipulate this via launchd agents or network configurations will be overridden by the system's default IPv6 stack behavior.
What is the difference between ULA and Link-Local addresses?
Link-Local addresses (starting with fe80::) are automatically assigned to every IPv6 interface and are only usable for communication on the immediate local network segment. Unique Local Addresses (starting with fd00::) are meant for routing within an organization or site but are not routable on the public internet. Unlike Link-Local, ULAs can be routed across subnets within your local network if properly configured.
Why does my Mac show both GUA and ULA after manual setup?
When you manually configure a ULA while keeping SLAAC enabled for GUA, macOS assigns both addresses. The GUA comes from the router's advertisement, allowing internet access, while the manually entered ULA serves local purposes. This dual-stack approach is common in enterprise environments where internal services rely on stable local addresses independent of the changing global prefix.
Is it safe to use ULA for internet-facing services?
No, ULAs are non-routable on the public internet. Using them for services that need to be accessed from outside your local network will result in connection failures unless you implement complex NAT64 or proxy solutions. Always use Global Unicast Addresses for any service that requires external accessibility.
How do I troubleshoot IPv6 connectivity if SLAAC fails?
Check if your router is sending Router Advertisements by using the command line tool
ping6 to the all-nodes multicast address ff02::1. If you receive replies, SLAAC is likely working. If not, verify your router's IPv6 settings and ensure that macOS is not blocking ICMPv6 traffic, which is essential for SLAAC operation.