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:
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:
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:
netsh interface ipv6 install (or even just ipv6 install with the latest versions).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:
Those are summarized below.
You need to achieve four things:
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.
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.
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:
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:
(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:
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.