First, you may already have IPv6 service. If you are running Windows, bring up a command prompt and type the command ipconfig /all. If you have IPv6, you should see something like this:
ipconfig on a Dual Stack Node
If you see something similar to this, congratulations, you already have IPv6 service, your ISP is up to date, your network infrastructure supports both IPv4 and IPv6, and your node has IPv6 enabled and configured. The giveaway is the line that says “IPv6 Address” followed by an address that starts with “2XXX” (in this case, 2001). Even without IPv6 service, your node might configure a “Link Local” IPv6 address that starts with “fe80”. If that is the only IPv6 address you have, you don’t have IPv6 service.
Let’s talk through this information, found under Ethernet adapter Ethernet:
The Physical Address is the Link Layer (MAC) address of this network interface. It is a 48 bit value, represented in 6 fields of 8 bits each, each with a hexadecimal pair of digits, separated by dashes (5C-F3-70-85-17-CE). The first 3 groups (24 bits) indicate the vendor of the network interface, the last 3 groups (24 bits) were assigned by that vendor to your specific interface when it was built. No other network interface in the world should have this particular 48 bit value. 248 is about 281 trillion, so we are not at risk of running out of MAC addresses. And if we do, there are MAC64 addresses!
The DHCP Enabled field (showing “No”) means that this node is not listening for a DHCPv4 server to provide configuration. The IPv4 node address, the subnet mask, the IPv4 default gateway and the IPv4 addresses of DNS were manually configured.
The Autoconfiguration Enabled field (showing “Yes”) means that this node is listening for a DHCPv6 server to provide configuration, and in this case, there was a DHCPv6 server, and it provided one of the public IPv6 addresses. It also provided the IPv6 addresses of DNS. Note that you can have more than one IPv6 address on a single interface (in fact this is very common). This is very different from IPv4.
The first IPv6 Address (2001:470:ed3d:1000::2:1) was manually configured. It is currently in the preferred state (see Address Lifetimes). Since this address was manually configured, it has infinite preferred and valid lifetimes – it will never expire. With the right tools, I could actually manually assign a static address with non-infinite lifetimes, then the static address would first enter the deprecated state, then later expire (and disappear from the node).
The second IPv6 Address (2001:470:ed3d:1000:3:392:a7c7:2a6d) was provided by DHCPv6 (I know this came from DHCPv6 because on my network, the two DHCPv6 servers provide addresses with either 3 or 4 in the fifth 16 bit group – also, the DHCPv6 lease information follows this address). This address is currently in the preferred state. The preferred lifetime is about 7 days (it will remain in the preferred state for about 7 days from the time it was obtained). The valid lifetime is about 11 days (about 4 days after it enters the deprecated state it will expire and be removed from the node – and a new DHCPv6 assigned address will be obtained). I used another tool (NetConf) to check the address lifetimes (see below). MS does not show these in ipconfig.
The DHCPv6 lease was obtained on October 15, 2017 at 10:03:09 am. It will expire 13 days later on October 28, 2017 at 1:58:05pm (before which a new IPv6 address will be obtained from DHCPv6). This is longer than the preferred lifetime (7 days) so the address will go into the deprecated state for a while before being replaced. It is shorter than the valid lifetime (11 days), so DHCPv6 will renew the assigned address with a different one before the old address expires and is removed.
The Link Local IPv6 Address of this node (see IP Address Types) is fe80::c02b:81c4:60d4:f01a%3 (the Zone ID, 3, identifies the network interface this address can be found on). This address was autonomously configured by the IPv6 stack on this node, when the interface first powered up. This checked if anyone else was already using this address, and would have stopped the interface IPv6 configuration if so. It is also in the preferred state (it will never expire – link local addresses normally have infinite lifetimes). You can actually ping this address (or use it as a destination) but don’t forget the Zone ID (unlike with global addresses, ping can’t tell which interface you meant if you leave that off).
Unicast address info for this interface as shown in NetConf:
The IPv4 Address is 172.20.2.1. It was manually assigned at configuration time. It is also in the preferred state, and will never time out.
The IPv4 Subnet Mask is 255.255.0.0. This subnet is a /16 (first 16 bits of the subnet mask are 1, the rest are 0). The subnet mask is used to split an IPv4 address into the subnet address (172.20.0.0 in this case) and interface identifier (0.0.2.1 in this case). This is accomplished by anding the node address with the subnet mask.
There are three default gateway addresses:
One for IPv4 (172.20.0.1), manually configured.
One IPv6 default gateway is a link local address (fe80::2e8:4cff:fe68:43d9%3). This was discovered automatically with Neighbor Discovery Router Discovery (from the source address of the RA messages my firewall is sending into the network).
The other IPv6 default gateway address (2001:470:ed3a:1000::1) was manually configured. It is not really needed. Nodes can use either the link local or global address for the default gateway – they identify the same interface – the LAN interface of the subnet router (firewall).
The DHCPv6 IAID (60578958) helps identify this interface for DHCPv6 address reservations.
The DHCPv6 Client DUID contains the 48 bit MAC address, plus some other unnecessary information (a time stamp which is never used). This also is required to create a DHCPv6 address reservation. Note that is simpler to let DHCPv6 assign an address then promote it to an address reservation.
Finally, we have the IPv6 addresses of the DNS Servers in this subnet (both manually configured and discovered via the RA messages and DHCPv6), and the IPv4 addresses of the DNS Servers in this subnet (manually configured). In this case there are really only two DNS servers, each of which has both an IPv6 and an IPv4 address.
ipconfig on an IPv4-only Node
On the other hand, if you see something more like this, you are still on the legacy (Second) Internet only. Either IPv6 is disabled on your node, your subnet does not yet support IPv6, or your ISP is not providing IPv6 service to your network. If IPv6 is enabled on this interface, it will autonomously configure a Link Local IPv6 address (starting with “fe80”). Don’t get excited – if this is the only IPv6 address you have, you don’t have IPv6 service.
Your ISP might not have even announced that they are providing IPv6 service. That is starting to happen around Singapore now. Some ISPs are just quietly turning IPv6 on. In some cases you might have to ask them to enable (turn on) IPv6 for you. There should not be any additional charge for adding IPv6 service – soon there may be an extra charge for keeping IPv4 service! There are already large extra charges for a single IPv4 public address, if you can even get one. I can’t recall ever having seen a single public IPv4 address on a cellphone. There is an essentially unlimited number of IPv6 public addresses. You can have as many as you want. Even on your phone.
If your ISP tells you they have IPv6 “on the roadmap”, ask them when it will go live and can you get on the notification list. Any answer of six months or longer means they haven’t even started thinking about it yet. If they say “IPv what?”, ask them to check around to see if anyone knows what IPv6 is, and can tell you when they will deploy it. If nobody there even knows what IPv6 is, or they tell you they have no plans to deploy it, you need to get a new ISP soon, because your current one is a dinosaur and it is not going to make it through this transition. The IPv6 comet is already on the way. With every major transition there are some casualties (like Lotus 123 when Windows hit). This is one of the biggest sea changes ever in IT, and there will be a lot of dead dinosaurs. We IPv6 mammals scurrying around in the undergrowth are about the inherit the Internet. If your university is not teaching IPv6 yet, demand that they do. If they won’t start teaching IPv6, you might consider moving to a better university or suing them for incompetence.
Enabling IPv6 on your Node
In Windows, IPv6 is enabled by default ever since Windows XP, but it’s possible it may be disabled for some reason on your node. There are still many consultants and authors of networking articles who don’t understand IPv6 and will tell you to disable IPv6 regardless of what problem you are trying to solve – soon these people will all retire, or be retired. Hint: it may be a career limiting move to advise people to disable IPv6, or to ignore it, hoping it will go away. If all you know is IPv4 you are already obsolete. Start learning IPv6 now, plan on retiring, or look into some other career, perhaps in the fast food industry.
In Control Panel / Network and Sharing Center / Local Area Connection (or other interface name) / Properties you can enable or disable IPv6 and IPv4. In most cases, both should be enabled, unless you specifically need IPv4-only or IPv6-only operation for some reason (e.g. QA testing). Note that this only affects your node, and if there is no IPv6 present in your network, enabling IPv6 on your node is not going to magically make IPv6 service happen. Enabling is done by clicking the check mark in front of Internet Protocol Version X (TCP/IPvX). IPv6-only networks (ones with no IPv4 present) are not common today, and are probably not something that novices should attempt. If you do, you will find many of your favorite websites, email servers and other external services (ones that only support IPv4) will no longer be available to you. For fun, you might try disabling IPv4 on your node and see what stops working. You might be surprised how much does work today. Over 25% of the Alexa 1000 sites already support IPv6. We are still in the transition from all IPv4 to all IPv6. You should probably use Dual Stack (IPv4 + IPv6) on every node and subnet for now.
The downside with Dual Stack is that you keep all the old problems with IPv4 – NAT, congestion, broadcast storms, etc. The good news is anything that uses the IPv6 side works great. You also have doubled the effort and cost of network management, and worst of all, doubled the attack surface. Hackers will attack you through the weakest side of your network or node (IPv4 or IPv6 side). Be sure the IPv6 side of your network is as secure as the IPv4 side. IPv6 security is going to be a very hot job for some time to come.
Eventually network admins will move to IPv6-only subnets, with translation gateways (e.g. NAT64) at the border, for legacy users and apps (that are still running only on IPv4). On mobile devices, 464XLAT is a good solution. The telco can provide IPv6-only service between the phone and the telco, but legacy IPv4-only apps will still run just fine. The legacy IPv4 gets upconverted to IPv6 in the phone, goes over the IPv6 connection to the telco, and downconverted to IPv4 at the telco, where it goes out to the legacy (second) Internet.
You can configure IPv6 on this connection by double clicking on Internet Protocol Version 6 (TCP/IPv6) in the above:
This is similar to IPv4 configuration, but here Obtain IPv6 address automatically means via SLAAC or DHCPv6 (whichever is present). Use the following IPv6 address allows manual assignment of an IPv6 address to this node. The Subnet prefix length corresponds to the IPv4 “subnet mask”, and will pretty much always be 64. The Default gateway can be assigned manually (and must be assigned manually if you don’t select automatic address configuration). This can be specified as a global IPv6 address (as above) or as a link local IPv6 address (e.g. fe80::c02b:81c4:60d4:f01a%3 – the “%3” zone ID specifies what interface to use – if you manually configure a link local IPv6 default gateway, don’t forget the zone ID).
Here Obtain DNS server address automatically means to obtain the IPv6 addresses of DNS via DHCPv6 or SLAAC (depending on what is available), while Use the following DNS server addresses allows manual configuration of the IPv6 addresses of DNS for this node. If you manually configure the IPv6 node address, you must also manually configure the IPv6 DNS addresses (this is a holdover from IPv4 MS network configuration, and is not a real requirement in IPv6).
Note that while IPv6 works quite differently from IPv4, Microsoft tried to hide those differences by using pretty much the same configuration page as with IPv4. For example, even if you manually configure the node address, in IPv6 the default gateway and IPv6 addresses of DNS could still be automatically determined, but there is no way to select that. You should also be able to specify whether to get a node address automatically from DHCPv6 or SLAAC.
It is perfectly normal to have multiple IPv6 addresses on one node (but only one IPv4 address on a node). You might have one link local address (configured automatically by the node), plus one or more IPv6 global addresses (from manual configuration, DHCPv6 configuration, a static address from SLAAC and even a temporary address from SLAAC.
IPv6 addresses assigned by SLAAC also have lifetimes (preferred lifetime and valid lifetime) and can expire. IPv4 addresses do not have lifetimes and can’t expire. None of this appears in the above control.
While Microsoft was probably trying to make users feel “comfortable” by making IPv6 configuration look a lot like IPv4 configuration, it really just confuses people, hides useful information and limits their choices. IPv6 works differently from IPv4. The network configuration should be different. Imagine if Cessna tried to provide a private plane with exactly the same controls as a car – it would be very difficult to control the plane. Planes work differently from cars.
Even if your ISP is providing IPv6 service, there are a few things you must set up in your network for IPv6 to be fully functional – these include a default gateway for outgoing IPv6 traffic, a source of Router Advertisements (for SLAAC to work), and DNS server(s) that support AAAA records (ideally accessible over IPv6).
Router Advertisement Messages: In IPv6 there is a new mechanism in routers that sends general subnet information in a special Neighbor Discovery message (called a Router Advertisement message). This message includes the default IPv6 prefix(es), various default timeouts (e.g. how long generated addresses remain preferred and how long they remain valid), and (as of RFC 8106), it also includes the IPv6 addresses of DNS for nodes in this subnet. Internal nodes can do Router Discovery (determine the address of the router), and autonomously generate valid public addresses based on this information using SLAAC (Stateless Address Auto-Configuration). IPv4 has nothing even vaguely like SLAAC – DHCPv4 is very different and not as powerful.
If enabled on the subnet router, Router Advertisement (RA) messages are sent by the subnet router into the subnet periodically, and in response to a Router Discovery (RD) message from any internal node. All RA messages are sent with a multicast destination address (“all nodes in subnet”) so that all nodes can update their subnet information if they want to, regardless of who sent the RD message. When a node is first powered up, it sends an RD message so that it can obtain the subnet info necessary for automated network configuration of the node. For details on RA and RD messages, see the section on Neighbor Discovery messages.
Without a source of RA messages, an internal node will not generate any public addresses on its own. You can manually configure one or more IPv6 addresses for the node, and it can obtain a managed IPv6 address from DHCPv6. But for internal nodes to generate valid public addresses autonomously (via SLAAC) there must be a source of RA messages in the subnet.
pfSense can provide RA messages for each internal network interface with excellent control over the content of these messages. It also has very good firewall rules for IPv4 and IPv6, as well as supporting 6in4 tunneling (to bring in tunneled IPv6 service through an IPv4-only ISP). This will be covered in the section on pfSense.
Routing: any border router that connects your subnet to upstream infrastructure must be configured correctly to allow incoming traffic destined for some block of IPv6 addresses, and provide a default gateway (where to send transmitted packets with a non-local destination IP address – normally this will belong to a upstream router that knows how to forward those packets towards their target subnet.
DNS: as with IPv4, all nodes need to have access to a DNS server that can resolve nodenames to internal IP addresses. With IPv4, these IP addresses are published via “A” records. With IPv6, these IP addresses are published via “AAAA” records (get it? if one A is 32 bits, then four A’s are 128 bits). While a dual stack network can work with a DNS server that listens only on IPv4 for DNS queries, to operate in an IPv6-only mode, the DNS server must (also) listen on IPv6. Whether the DNS request is received via IPv4 or IPv6, the response contains A and/or AAAA records, depending on the configured information for the node in question. The response is sent via the IP version used in the request (if received over IPv4, the response is over IPv4 – if received over IPv6, the response is over IPv6). Windows XP could function in a dual stack network, but not in an IPv6-only network because it could only make DNS queries (and get DNS replies) over IPv4. Since Vista, MS OSes can make DNS queries (and get DNS replies) over both IPv4 and IPv6 (so nodes with Vista or later MS OSes will work in IPv6-only networks).
Note that Microsoft DNS server (since 2008) supports A and AAAA records, and accepts queries over both IPv4 and IPv6. BIND has supported dual stack operation for ever longer. pfSense can also provide a DNS server (or DNS relay agent) with full support for IPv6. Many DNS hosting services have good support for IPv6 (e.g. DynDNS). This is important for external DNS.
DHCPv6: you can configure DHCPv6 for your subnet, but it’s not really much use. Before RFC 8106 DHCPv6 was the only way you could automatically discover the IPv6 addresses of DNS. But there is no way to discover the default gateway of the subnet via DHCPv6 (unlike DHCPv4) so you can’t do full network configuration of a node with just DHCPv6. Normally you discover whether DHCPv6 is even available on the subnet via RA messages, but you could also try sending a DHCPv6 request to the multicast address for “all DHCPv6 servers or relay agents on subnet” and see if anyone replies. You can manually configure the default gateway on all nodes, or it can be discovered via RA messages. If you configure RA messages, since RFC 8106 that also provides the IPv6 addresses of DNS, so there is little need for DHCPv6 anymore. DHCPv6 will probably phase out slowly over the next few years.
The one trick possible with DHCPv6 (that can’t be done any other way currently) is to automatically assign a static global address to a node based on its MAC address (actually in IPv6, the MAC address has some additional info added and it is called a DUID, but it’s basically the node’s MAC address). This is called DHCPv6 Address Reservation. Servers should have a static (unchanging) public address (SLAAC assigned addresses can change over time). You can either manually assign a static public address on each server, or automatically provide servers with static IPv6 addresses via DHCPv6 Address Reservation.
Microsoft Windows Server has provided full function DHCPv6 in Windows Server for some time. You can easily provide DHCPv4 and DHCPv6 in your subnet using the Microsoft DHCP servers. pfSense can also provide a DHCPv6 server or a DHCPv6 relay agent that works fine.