The tldp Linux+IPv6-HOWTO (or from tldp-howtos-txt) article is older, and less maintained. Yet it attempts to cover many topics that are mentioned in this article, starts from the basics, and advances in a slower pace. It also has many command line examples. Beginners might want to read or skim it before reading this wiki article.
Pinging the multicast address results in all hosts in link-local scope responding. An interface has to be specified:
After that, you can get a list of all the neighbors in the local network with:
With a ping to the multicast address only routers will respond.
If you add an option , link-local hosts will respond with their link-global scope addresses. The interface can be omitted in this case:
To ping everyone on all interfaces, and announce your address to everyone, use a script.
The easiest way to acquire an IPv6 address as long as your network is configured is through Stateless address autoconfiguration (SLAAC for short). The address is automatically inferred from the prefix that your router advertises and requires neither further configuration nor specialized software such as a DHCP client.
If you are using netctl you just need to add the following line to your Ethernet or wireless configuration.
If you are using NetworkManager then it automatically enables IPv6 addresses if there are advertisements for them in the network.
Please note that stateless autoconfiguration works on the condition that IPv6 icmp packets are allowed throughout the network. So for the client side the packets must be accepted. If you are using the Simple stateful firewall/iptables you only need to add:
If you are using an other firewall frontend (ufw, shorewall, etc) consult their documentation on how to enable the packets.
The above configuration will tell clients to autoconfigure themselves using addresses from the advertised /64 block. Please note that the above configuration advertises all available prefixes assigned to the LAN facing interface. If you want to limit the advertised prefixes instead of use the desired prefix, e.g. . The block can be repeated many times for more prefixes.
To advertise DNS servers to your LAN clients you can use RDNSS feature. For example, add the following lines to to advertise Google's DNS v6 servers:
When a client acquires an address through SLAAC its IPv6 address is derived from the advertised prefix and the MAC address of the network interface of the client. This may raise privacy concerns as the MAC address of the computer can be easily derived by the IPv6 address. In order to tackle this problem the IPv6 Privacy Extensions standard (RFC 4941) has been developed. With privacy extensions the kernel generates a temporary address that is mangled from the original autoconfigured address. Private addresses are preferred when connecting to a remote server so the original address is hidden. To enable Privacy Extensions reproduce the following steps:
After a reboot, at the latest, Privacy Extensions should be enabled.
dhcpcd's default configuration includes the option , which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing RFC 7217. Therefore, it is not necessary to change anything, except if it is desired to change of IPv6 address more often than each time the system is connected to a new network. Set it to for a stable address.
The use of IPv6 Privacy Extensions in NetworkManager can be controlled with the setting in NetworkManager.conf(5) or in the connection's profile. If it is not set globally nor per-connection, NetworkManager will fall back to reading .
To explicitly enable IPv6 Privacy Extensions by default, add these lines to NetworkManager.conf(5):
Apply the configuration and reconnect to all active connections.
To control the use of IPv6 Privacy Extensions for individual NetworkManager-managed connections, edit the desired connection keyfile in and append to its section the key-value pair :
Reload the connection and reconnect to it afterwards.
Other options for the IPv6 Privacy Extensions like:
Another option is a stable private IP address (RFC 7217). This allows for IPs that are stable within a network without exposing the MAC address of the interface.
In order to have the kernel generate a key (for , for example) we can set:
Bring the interface down and up and you should see next to each IPv6 address after running . The kernel has generated a 128-bit secret for generating ip addresses for this interface, to see it run . We are going to persist this value so add the following lines to :
The above settings are not honored by NetworkManager, but NetworkManager uses stable private addresses by default.[2][3]
The above settings are not honored by systemd-networkd. To ensure stable private addresses are always used, you can set:
The above tells systemd-networkd to use a secret derived from the machine ID. You can also specify a secret yourself or even apply the setting to only specific prefixes appearing in Router Advertisement messages. See systemd.network(5) for details.
You can also generate stable private link-local addresses if desired:
Sometimes, using a static address can improve security. For example, if your local router uses Neighbor Discovery or radvd (RFC 2461), your interface will automatically be assigned an address based on its MAC address (using IPv6's Stateless Autoconfiguration). This may be less than ideal for security since it allows a system to be tracked even if the network portion of the IP address changes.
To assign a static IP address using netctl, look at the example profile in . The following lines are important:
The standard tool for PPPoE, pppd(8), provides support for IPv6 on PPPoE as long as your ISP and your modem support it. Just add the following to
If you are using netctl for PPPoE then just add the following to your netctl configuration instead:
Prefix delegation is a common IPv6 deployment technique used by many ISPs. It is a method of assigning a network prefix to a user site (i.e. local network). A router can be configured to assign different network prefixes to various subnetworks. The ISP hands out a network prefix using DHCPv6 (usually a or ) and a dhcp client assigns the prefixes to the local network. For a simple two interface gateway it practically assigns an IPv6 prefix to the interface connected to the local network from an address acquired through the interface connected to WAN (or a pseudo-interface such as ppp).
DHCPv6 requires the client to receive incoming connections on port 546 UDP. For an nftables-based firewall, that can be configured with one line in the input chain in :
dhcpcd apart from IPv4 dhcp support also provides a fairly complete implementation of the DHCPv6 client standard which includes DHCPv6-PD. If you are using edit . You might already be using dhcpcd for IPv4 so just update your existing configuration.
This configuration will ask for a prefix from WAN interface () and delegate it to the internal interface (). In the event that a range is issued, you will need to use the 2nd that is commented out instead. It will also disable router solicitations on all interfaces except for the WAN interface ().
Configure both your upstream (wan) and downstream (lan) interface. This will enable DHCPv6-PD on the interface where the DHCPv6 client is running. The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network.
dhclient can also request a prefix, but assigning that prefix, or parts of that prefix to interfaces must be done using a dhclient exit script. For example: https://github.com/jaymzh/v6-gw-scripts/blob/master/dhclient-ipv6.
Wikipedia:NAT64 is the IPv6 transition mechanism where IPv6 only hosts are able to communicate with IPv4 hosts using NAT.
Linux kernel does not support NAT64 natively but there are several packages to add support for NAT64.
There are very few reasons to disable either IPv4 or the IPv6 address stack on Linux, dual-stacked Linux has worked just fine since 1999. But as global IPv6 adoption grows, IPv6-only networks have become increasingly common. NAT64 and DNS64 are commonly used transition mechanisms for IPv6-only networks to communicate with legacy IPv4-only networks.
For some ISPs[4][5], the IPv6 traffic is slower than the IPv4 one: if you can confirm with certainty you are affected by such issues, disabling IPv6 may speed up your network speeds.
This should not be done blindly: for most users, IPv4-only networking will degrade performance behind Carrier-grade NAT and hamper their usage of P2P or WebRTC applications (e.g. some games). Instead, configuring IPv4 to be preferred over IPv6 is the best of both worlds.
Adding to the kernel line disables the whole IPv6 stack, which is likely what you want if you are experiencing issues. See Kernel parameters for more information.
Alternatively, adding instead will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices.
If one wants to disable the IPv6 stack for all network interfaces on boot, with the ability to easily enable IPv6 later, a systemd unit which runs after the network manager is necessary.
To adjust this unit for other network manager one needs to replace all occurrences of with the configuration unit of their network manager.
Disabling IPv6 functionality in the kernel does not prevent other programs from trying to use IPv6. In most cases, this is completely harmless, but if you find yourself having issues with that program, you should consult the program's manual pages for a way to disable that functionality.
This will create a drop-in snippet that will be run instead of the default . The flag prevents IPv6 from being used by the ntp daemon. Put the following into the drop-in snippet:
On occasion systemd-timesyncd will attempt to query an IPv6 timeserver even when IPv6 has been disabled. This can result in the system clock not being updated and the journal showing an error similar to:
Note however that even when using the above option, networkd will still be expecting to receive router advertisements if IPv6 is not disabled globally. If IPv6 traffic is not being received by the interface (e.g. due to sysctl or ip6tables settings), it will remain in the configuring state and potentially cause timeouts for services waiting for the network to be fully configured. To avoid this, the option should also be set in the section.