or “IPv6 put simply”

This FAQ is released under the WTFPL version 2. Please share it as much as possible, correct it (and it would be nice to feed back corrections), translate it, share it again, compress it, share it again.

This FAQ is meant as a quick-starter for people wondering about adding IPv6 support to their network. It is not meant as a documentation, just as a FAQ, so please keep the contributed answers small and simple. They can however contain links to documentations. Also, sometimes simplifications are made on purpose because as a first approach they are OK, so please techies bear with them :)

If you are wondering about adding IPv6 support and see one of your questions not answered here, please add the question, and lurkers will add the answer :)

If you do not have an ffdn wiki account, you can ask for one (see http://www.ffdn.org/wiki/doku.php), or just send questions or patches to samuel.thibault@ens-lyon.org

That being said, the goal is to answer practical beginner questions, not trolls :) In particular, it won't detail at lengths why you want to use IPv6, although a brief non-detailed list is given.

The structure of the FAQ is:

• Why IPv6, briefly
• Basic features of IPv6
• Cheatsheet, for quick-beginner-reference
• Some quick examples
• Some introduction to advanced features of IPv6

• Because there are no IPv4 addresses any more.
• Because this permits to give a public IP address to all equipments (computer, phone, tablet, video game consoles, recorder, etc.) without having to use NAT any more, because there are a lot of IPv6 addresses (almost a million of billions of billions of IPv6 adresses per earth square meter, or dozens of thousands of IPv6 /64 networks per earth square meter), compared to IPv4 addresses, which are now nowhere to be found.
• Because there are no IPv4 addresses any more.
• Because you have the opportunity to rethink your addressing scheme.
• Because there are no IPv4 addresses any more.
• Because IPv4 will be yet more and more painful to make working at all. We have kept piling up tricks to continue using IPv4, but that has already cost more than just migrating to IPv6, and continue costing again even more than just migrating to IPv6.
• Because there are no IPv4 addresses any more.
• https://labs.ripe.net/Members/david_holder/blockers-to-ipv6-adoption
• https://www.ipv6.com/general/top-10-features-that-make-ipv6-greater-than-ipv4/
• https://www.youtube.com/watch?v=d8wIdd2fNmk

TODO: links to details

Basically no, the principles of IPv6 are very close to IPv4, even more so since IPv4 has more and more converged toward IPv6, using CIDR, multiple addresses, and IPv6 now has NAT, etc. The differences one will have to cope with anyway are:

• 128bit addresses instead of 32bit addresses, with a hexadecimal notation, like 2001:db8:12ab::12 (although it's not mandatory to use a-f letters: one can decide to just use numbers for the right part of the address so as to get the same IPv4 and IPv6 addresses visually, for instance)
• Prefix sizes are thus between 0 and 128, usually one uses /64, e.g. 2001:db8::/64
• Well-known addresses are of course different, e.g. 127.0.0.1/8 is 0::1/128 in IPv6.
• Interfaces always have at least an IPv6 address in fe80::/10, which is only used on the link scope (e.g. for NDP, see below). This is actually quite like IPv4's automatic private IP adressing (169.254.0.0/16), but now systematic.
• DNS entries for IPv6 use “AAAA” records instead of “A” (but they work the same way), a domain will thus have both AAAA entries for its IPv6 addresses, and A entries for its IPv4 addresses.
• IPv6 and IPv4 can not natively talk to each other. More on this below.

Well, in the end, all machines should have IPv6 configured. But that does not mean one has to get rid of IPv4 immediately. One can simply add IPv6 along IPv4, and IPv6 will be used whenever it can be, while IPv4 can still be used as a fallback, even if it is behind a CGN (see about CGN below).

That said, a combination of NAT64 + DNS64 can be used to set up an IPv6-only network, which can still transparently access the IPv4 world, see more on this below.

There is no general answer to this.

For various reasons, IPv6 is faster to process than IPv4 (e.g. no checksum in the IP header, no fragmentation, much simpler routing tables, which brings huge savings for routers, and much less use of Ethernet broadcasts).

For other reasons, it is slower (e.g. bigger addresses, leading to 1.33% bandwidth overhead on typical networks, and implementations might not have yet gotten as optimized as IPv4 ones).

In the end, some applications simply try both, and use the one that connects first, so whichever it is wins :)

Most probably, yes:

• Linux since a long time (2.1.8), considered really stable since 2.6.12 (2005)
  • Debian Etch (4.0, 2007) supports it out of the box. At least Debian Squeeze (6.0) would be preferrable for better application software support.
  • Ubuntu 7.10 (Gutsy Gibbon) supports it out of the box. At least Ubuntu 10.10 (Maverick Meerkat) would be preferrable for better application software support.
  • Fedora 6 (2006) supports it out of the box. At least Fedora 13 (Goddard) would be preferrable for better application software support.
• Windows:
  • On 3.1/95/98/NT, one has to install the Trumpet's winsock implementation
  • On 2000, Microsoft provides a “Technology Preview for Windows 2000”
  • XP has it built-in, although you have to enable it by running netsh interface ipv6 install (or even just ipv6 install with the latest versions).
  • Vista/7 have it built-in and enabled by default.
• MacOS really supports IPv6 since 10.7 (Lion).
• GNU/Hurd: since 2007.
• TODO: others

DNS replies contain both IPv4 answers (in A records) and IPv6 answers (in AAAA records), independently of the protocol which was actually used to transport the request and reply themselves:

$ dig -4 any www.ffdn.org
...
www.ffdn.org.		86400	IN	A	185.233.100.13
www.ffdn.org.		86400	IN	AAAA	2a0c:e300::13
...
$ dig -6 any www.ffdn.org
...
www.ffdn.org.		86400	IN	A	185.233.100.13
www.ffdn.org.		86400	IN	AAAA	2a0c:e300::13
...

You need to achieve three things:

• Bring IPv6 routing up to your host
• Configure your host operating system for IPv6 (unless automatically done through dynamic configuration or stateless auto-configuration)
• Make sure your applications know how to connect through IPv6.

Those are summarized below.

You need to achieve four things:

• Bring IPv6 routing up to your host,
• Configure your host operating system for IPv6 (unless automatically done through dynamic configuration or stateless auto-configuration)
• Make sure your server software listens for IPv6 connections
• Publish DNS AAAA records, so people start connecting to your server through IPv6.

Those are summarized below.

Hopefully, your ISP brings IPv6 up to your router, if not, ask them for it. You then just need to configure the router to route IPv6 (which is extremely similar to IPv4 routing, with BGP and OSPF (version 3) for instance).

If your ISP does not bring IPv6 up to your router, you can use an IPv6 tunnel, see below.

Of course, don't forget to set up a firewall along the way. Yes, a firewall, not NAT, see below.

• France:
  • Renater's core routes IPv6, but a lot of universities and laboratories have not configured their end yet.
  • Free provides a /60 prefix, but as of jan' 2014, it does not provide a firewall feature on the router to protect it.
  • Nerim provides IPv6
  • FDN provides a /48 prefix
  • TODO…
• TODO…

The simplest way is simply not to have to configure it, by just configuring DHCPv6 or stateless autoconfiguration, as well as Router Advertisement (RA) on your router, see the “quick examples” section. Machines on the network will then automatically configure themselves, just like they can do for IPv4.

You can however also configure the IPv6 address, default gateway and DNS server by hand, similarly to manual configuration of the IPv4 address.

You need to make sure IPv6 resolution works. For instance, host www.ffdn.org should report both 185.233.100.13 and 2a0c:e300::13. If not, you need to configure your DNS server to enable IPv6 AAAA records (TODO: tell briefly how in the “quick examples” section).

http://v6.testmyipv6.com/ can be used for instance to easily test that it worked fine.

You can use tcpdump -i eth0 ip6 , or use netstat -Ainet6 , etc. to see how it connects. If the application does not seem to support IPv6, please report a bug to their authors. Nowadays, all applications should really support IPv6.

One can force the application to use IPv6 by specifying the IPv6 address by hand. This can for instance be done in URLs, by putting the address inside braces (to avoid confusion with the TCP port number), for instance http://[2001:db8::1]/

A lot of command-line tools (e.g. ssh, wget, dig, …) have -4 and -6 options to force the use of IPv4 or IPv6.

One can see this in netstat -Ainet6, e.g.:

tcp6 0 0 :::22 :::* LISTEN 5265/sshd

ssh is properly listening on TCPv6 port 22.

Some software may have to be explicitly told to listen to IPv6, by specifying things like

listen = 0.0.0.0, ::

where 0.0.0.0 is for all IPv4 addresses, and :: is for all IPv6 addresses. See the “quick examples” section.

IPv6 AAAA DNS records are just like IPv4 A records, except they contain an IPv6 (which is 4 times bigger than an IPv4, thus the 4 A's :) ). For instance, here 'myserver' has bothe an IPv4 and an IPv6:

myserver IN A 192.0.2.13 myserver IN AAAAA 2001:db8::13

Not natively: there has to be a router R in-between which has both IPv6 and IPv4 configured, and performs NAT64 address translation for instance:

A will send IPv6 packets using its IPv6 address as source, and will encode the IPv4 address of the destination in the 64:ff9b::/96 prefix; for instance, a destination of 192.0.2.128 will become 64:ff9b::c000:0280, which can also be written as 64:ff9b::192.0.2.128 to clearly show the mapping (it's also possible to use any /96 prefix inside your assigned IPv6 address space to perform the translation, instead of the well-known prefix 64:ff9b::/96). B will send and receive IPv4 packets, using its 192.0.2.128 address.

All the magic happens at the router in-between: it will translate both ways, masquerading the IPv6 address of A with its own IPv4 address (stateful translation) or dynamically assigning IPv4 addresses as needed to map IPv6 clients (stateless translation).

Since A should always try to contact B as 64:ff9b::c000:0280, its DNS resolver should provide DNS64. It works by replacing the A records in DNS answers with the corresponding AAAA records in the /96 translation prefix.

See http://www.kafe-in.net/page/15 (in French). TODO: english documentation on this.

No. A will only be able to connect to B by setting up an IPv6 tunnel (i.e. A will not be IPv4-only any more actually). See more about tunnels below.

It is a tunnel with one end connected to the IPv6 world, thus letting a machine in an IPv4 world have a route to the IPv6 world. A huge lot of various tunnel possibilities exist (TODO: mention a list, but without going into details, just URLs). Ideally you should not use a tunnel, and just convince your ISP to bring IPv6 to you natively.

Well, IPv6 does have NAT support nowadays actually (see below), but using NAT has drawbacks (see below).

And anyway, using NAT does not make your network more secure. What can make your network less secure is not using a firewall at all. It happens that enabling NAT would usually automatically enable a firewall. But you can also enable a firewall, thus getting security, without having to enable NAT (which does not bring security but breaks things).

With recent versions of Operating Systems, yes (In Linux: starting from kernel 3.7).

That being said, this is usually not a good idea, as NAT breaks a lot of application protocols, see below, and IPv6 is precisely meant to let all machines have their own public IP.

If you really want to, you can use a random fd00::/8 prefix for defining a private local network, see below.

• In IPv4, it only shifts the lack of addresses a bit: instead of lacking addresses, you are then lacking ports on the few public addresses you are using to masquerade the private addresses. This limits the number of connections each machine can keep open at the same time. This leads for instance to broken images in web pages (because the webbrowser tried to load them in parallel, and that failed).
• It breaks protocols which explicitly use IP addresses
  • FTP
  • Peer to peer
  • IRC's DCC
  • Voice over IP: SIP
  • And any such protocol that anybody on earth might want to invent. Firewall plugins can be written to cope with the protocols above, but they can not automatically work with newer protocols that people invent.
• Consequently, it makes protocols try to deal with NATs, which makes them much more complex.

Well, it's basically the same as NAT, but to a larger scale: Carrier-Grade NAT (CGN) means it is all customers of an ISP which are masqueraded behind the same public IP addresses, and out of control from the customers. As a consequence:

• All users sharing the same public IP address appear the same on the Internet.
  • If one of them gets blacklisted based on its IP address, all of them get blacklisted. This has already happened on a very large scale due to CGN.
  • Tracing a network issue gets more complex when you only have a public IP address behind which there are hundreds of customers.
  • If a customer does bad (really bad) things on the Internet, the police will want to know who that is, but they will only know which pack of hundreds of people happened to use that IP address at some more or less unknown point.
• machines behind the NAT require port forwarding to act as servers. This hinders innovation.
• ISPs have millions of customers, 10.0.0.0/8 contains only 16 million IPs.
• Geolocalisation of customers can not happen any more.
• NAT is usually also performed again at the customer's homes. These two layers of NAT make it rather impossible to support peer-to-peer exchanges.
• The CGN not being controlled by the customer, mostly only TCP and UDP will get through (ICMP too, if the ISP is no too dumb). This hinders possibilities of innovation in the transport layer.

Essentially, no, since IPv6 uses the same basic principles of IPv4. So the firewall rules will essentially be the same. This is thus duplicated configuration lines, but not duplicating thinking about them.

Two exceptions to this are:

• ARP is replaced with NDP, which is contained in ICMPv6, so make sure to enable ICMPv6 (at least types neighbradv and neighbrsol) on prefixes fe80::/64 and ff02:0:0:0:0:1:ff00::/104, so it can work properly.
• Routers do not fragment packets any more, so be sure to let ICMPv6 packet-too-big pass, so clients can discover the PMTU (Path MTU) automatically.

(TODO: any other?)

See the “quick examples” section.

Well, it can be a good opportunity to clean up the addressing scheme. That said, you don't strictly have to, since there is so much room, you could even, for a machine which has IPv4 192.0.2.128, simply give it the IPv6 2001:db8:0:2::128, thus looking very similar to the IPv4.

Since there is so much room, one can use prefix sizes that are multiple of 4, and thus not have to care about bitmasks any more since network/host division will then always be between two hexadecimal digits.

A very strict equivalent would be using prefixes in fec0::/10 (site-local addresses). For instance, one can typically use fec0::/64.

One of the issues in IPv4 is however when merging two networks which already use 192.168.0.0/16, which leads to addresses conflicts. For the same reason, the IPv6 site-local addresses are deprecated, because the very notion of “site” can vary, leading to various issues.

For this reason, it is recommended to rather use Unique Local Addresses (ULA): take one 40-bit random number for your site, and append it to fd00::/8, leading to a /48 prefix. For instance, one could end up with fd12:3456:789a::/48. Then one can define up to 65536 /64 prefixes in it: fd12:3456:789a:1::/64 for instance. That last step is just like when one is defining 10.x.y.0/24 IPv4 prefixes for instance. When two sites merge, since each of them has taken a random number, there is a very low probability of collision. The SixXS database can be used as a registration base. This is voluntary only, but helps reducing any risks of conflicts.

Essentially the same way as IPv4 dynamic routing, simply alongside IPv4, for instance by running a BGP daemon for IPv4, and another one for IPv6. You can for instance have exactly the same peering policy (at least with your peers who support IPv6).

If you configure your network with stateless configuration, and do not enable its privacy extension, yes, your IPv6 address will contain the MAC address of your network board, which happens to contain information about the manufacturer of the board, when, and where it was built (and thus roughly where it was sold). For instance, in 2001:db8::1234:56ff:fe78:9abc/64, the 12:34:56:78:9A:BC MAC address shows up.

But that's only in that case. With static configuration, dhcp dynamic configuration, or stateless configuration with privacy extension (i.e. it basically takes a random address), there is no such issue.

The privacy extension is usually not enabled by default, but can be enabled this way on Linux (here on eth0):

echo 2 > /proc/sys/net/ipv6/conf/eth0/use_tempaddr

TODO: other OSes

No. All equipments which only talk L2 protocols such as Ethernet do not have to be changed: to them, IPv6 is just another kind of payload among others (0x86dd for IPv6 instead of 0x0800 for IPv4). The ethernet protocol itself is completely unchanged.

L3 routers, however, might have to be changed if they are really old, because those will have to talk IPv6.

Hopefully, no. You do not need to modify your software if:

• it does not deal with IPv4 addresses at all,
• and it uses IPv4/IPv6-agnostic programming interfaces, with a runtime that supports IPv6.

For instance, if your software just passes a (hostname,port) pair to its programming interface, the software does not need any modification. One has to make sure that the runtime behind the programming interface supports IPv6, of course. This is now the case for the vast majority of them (TODO: list them?)

Most notably, the historical C network programming interface is not completely IPv4/IPv6-agnostic: gethostbyname does not return enough information to be able to not care about the differences between IPv4 and IPv6. getaddrinfo should be used instead, since it provides exactly what you have to give to socket, bind, and connect.

Most application protocols are available in IPv6, http/ftp/dns of course, but also dhcp/nfs/etc.

(TODO: more protocols).

It was reworked and called Neighbour Discovery Protocol (NDP), and is contained in ICMPv6 instead of a special type of ethernet frame. In the end NDP is basically the same principle as ARP, to translate from L3 addresses to L2 addresses, but implemented in a better way.

This section records some quick-beginner-reference notes

::1

(i.e. 0::1)

::

(i.e. 0::0)

Strictly speaking, one can use prefixes inside fec0::/10, e.g. fec0::/64.

But it is way preferrable to choose one ULA /48 prefix inside fd00::/8, and use /64 prefixes in it. See some details in the FAQ entry about it above.

Out of the box, firefox should use IPv6 connectivity when available. However, it is not visible to the user.

There is a firefox extension that displays whether the current page is loaded over IPv4 or IPv6: https://addons.mozilla.org/fr/firefox/addon/sixornot/

You can test it on this wiki: if you have IPv6 connectivity, you should see a green “6” (loaded over IPv6). Otherwise, you will see an orange “6” (the wiki has IPv6 records in the DNS, but you are still reaching it over IPv4).

If IPv6 connectivity does not work, make sure that it is not disabled: in about:config , make sure that network.DNS.disableIPv6 is set to false

Addresses:

$ ifconfig
...
eth0    Link encap:Ethernet  HWaddr 12:34:56:78:9a:bc
        inet adr:10.0.0.3  Bcast:10.0.255.255  Masque:255.255.0.0
        adr inet6: 2001:db8::1234:56ff:fe78:9abc/64 Scope:Global
        adr inet6: fe80::1234:56ff:fe78:9abc/64 Scope:Lien
...
$ ip addr ls
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
...
    inet6 2001:db8::1234:56ff:fe78:9abc/64 scope global dynamic 
     valid_lft 2591725sec preferred_lft 604525sec
    inet6 fe80::1234:56ff:fe78:9abc/64 scope link 
     valid_lft forever preferred_lft forever

Routes

$ route -6
::/0                           fe80::1234:56ff:fe78:9abd  UGDA 1024 11     0 eth0
fe80::/64                      ::                         U    256 0     0 eth0
$ ip -6 route ls
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::1234:56ff:fe78:9abd dev eth0  proto ra  metric 1024

NDP cache (equivalent of ARP)

$ ip -6 neigh ls
fe80::1234:56ff:fe78:9abd dev eth0 lladdr 12:34:56:78:9a:bd router STALE

Testing DNS

$ host www.example.com
www.example.com has address 93.184.216.119
www.example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

Testing ping

$ ping6 www.example.com
PING www.example.com(2606:2800:220:6d:26bf:1447:1097:aa7) 56 data bytes
64 bytes from 2606:2800:220:6d:26bf:1447:1097:aa7: icmp_seq=1 ttl=54 time=139 ms

Testing http

$ wget -6 www.example.com
Resolving www.example.com (www.example.com)... 2606:2800:220:6d:26bf:1447:1097:aa7
Connecting to www.example.com (www.example.com)|2606:2800:220:6d:26bf:1447:1097:aa7|:80... connected.
...

TODO: how to deactivate ipv4 completely, to check ipv6 for sure?

TODO

TODO

TODO

Generally, it boils down to not specifying any explicit IP, or else explicit both IPv4 and IPv6 public addresses.

Use Listen *:80 instead of Listen 0.0.0.0:80.

Or use Listen 192.0.2.1:80 and Listen [2001:db8::1]:80

Do not use listen-on.

Or else, use listen-on { 192.0.2.1; }; and listen-on-v6 { 2001:db8::1; };

TODO

First, check if your Nginx is compiled with ipv6 support using nginx -V and looking for –with-ipv6.

On Nginx, you need to add listen [::]:80; next to listen 80;. If your server is ipv6only, you can also add listen[::]:80 ipv6only=on;.

Same thing for 443.

To establish the connection with the server using IPv6, add proto tcp6 next to proto tcp, both on client and server config.

To enable IPv6 in the tunnel, TODO.

This announces the server as a router (Router Advertisement, RA), announcing the route for the local network, the default route to the rest of the Internet, and the DNS server address.

interface eth0 {
  AdvSendAdvert on;
  prefix 2001:db8:0:1::/64 { };  # enable stateless configuration within that prefix
  route ::/0 { };  # default route through us
  RDNSS 2001:db8:0:1::1 { };  # announce DNS server.
}

RDNSS can optionally be dropped and a DHCPv6 server configured instead. prefix and route are still necessary to provide hosts with routing advertisement (RA).

Note: DHCPv6 does not provide route information to machines on the network. A router advertisement is necessary for that, e.g. thanks to radvd (or just dnsmasq)

TODO

dnsmasq can provide both DHCPv6 and Router Advertisement (RA).

TODO

Here are examples for home-use firewalls: connections only go from inside to outside, assuming a DSL connection to the Internet. It also accepts NDP (just like ARP is usually accepted), but makes sure it will not be forwarded (hop limit is 255).

# Accept and forward communication error reporting
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-request -j ACCEPT

# Accept local network configuration
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT

# Accept local trafic
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -i eth0 -j ACCEPT

# Accept incoming WAN trafic related to our own requests
ip6tables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# And nothing else
ip6tables -P INPUT DROP

# Accept forwarding trafic from us, and related trafic from WAN
ip6tables -A FORWARD -i ppp0 -j ACCEPT
ip6tables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# And nothing else
ip6tables -P FORWARD DROP

# Accept emiting anything ourself
ip6tables -P OUTPUT ACCEPT

TODO

TODO

This gives examples of how to configure a DNS64 server in order to make client machines automatically use DNS64. One just needs to pick a /96 prefix among one's own addresses, or use the well-known 64:ff9b::/96 prefix, here we will use 2001:db8:0:1::/96 as example.

/etc/bind/names.conf.options

dns64 2001:db8:0:1::/96 {
    clients { any; };
}

The principle is that the router just announces the prefix, e.g. 2001:db8:0:2::/64, and machines just pick an IP address within it as they wish: appending to it the MAC address of the ethernet board, or just appending a random address (privacy extension). A Duplicate Address Detection (DAD) protocol is used to make sure there is no conflict.

This has the same issue as DHCP: if there is a rogue system emitting prefix announces, machines will pick them.

RDNSS can also be used to announce the address of a DNS server. The use of a DHCPv6 server may still be useful, configuring it to not distribute IP address, but distribute other kinds of information, such as SMB network name, SMTP server name, etc.

Although not widely used, this allows a machine to roam between IPv6 networks without losing connections: the machine is carrying a public adress with it, attached to the home LAN of the machine, and packet routing to the machine is automatically done down to the network where the machine happens to go through.

Well, actually, there was. It was however just experimental.