IPv6 and IPv4 nodes can’t talk to each other. These are two separate protocols, both of the Internet layer. So when some nodes in a network have moved on to IPv6 we need a transition mechanism to enable the remaining IPv4 nodes to talk to these IPv6 nodes. ISATAP is one such transition mechanism.
ISATAP stands for Intra-Site Automatic Tunnel Address Protocol. From the name itself we get an idea of what it is about:
- Intra-Site: It is meant for use within a site. That is in an Intranet, LAN, private network. Not for communication over the public Internet.
- Automatic: All configuration is automatic. Once the network is “aware” that ISATAP is in use, all hosts will auto-configure themselves (without the need for DHCP, static IPs, etc).
- Tunnel: Communication happens via tunneling of IPv6 packets within IPv4 packets. That is how IPv4 nodes are able to communicate with IPv6 nodes and vice versa. IPv4 packets have a field in their header called “Protocol”. This field tells the receiving end of the type of data in the packet. Usually the data is TCP, UDP, or ICMP (protocol numbers 6, 17, or 1) but other types too are possible (when and IPv4 packet contains an IPv6 packet the Protocol field is set to 41). This is an efficient way of carrying IPv6 packets within IPv4 because the only additional bits to the IPv6 packet are the IPv4 headers (20 bytes). Since the MTU of Ethernet is 1500 bytes a single IPv4 packet can carry up to 1480 bytes of an IPv6 packet.
- Address: ISATAP interfaces automatically configure themselves with an IPv6 address. The 64 bit network prefix could be a link-local, unique local, or global prefix. The 64 bit interface address is the IPv4 address (32 bits) prefixed with
0000:5EFE (for a private IPv4 address) or
0200:5E5E (for a public IPv4 address) (32 bits). The IPv4 address is written in the dot-quad notation (a.b.c.d) so it is easy to identify the IPv4 address from an ISATAP IPv6 address.
- Protocol: ISATAP is a protocol that defines all the above as well as the communication between the IPv4 and IPv6 nodes. ISATAP is defined in RFC 5214
ISATAP is not meant to be a permanent solution or for organization-wide deployment. It is only a transition strategy, for use in test labs or for parts of the Intranet while IPv6 addressing schemes and routing are being planned.
Windows Vista and above have ISATAP built into the OS. Separate ISATAP interfaces are created for each physical interface connected to a different DNS suffix. On Windows Vista (with Service Packs) and above, the interfaces are left in a “media disconnected” state unless the name
isatap.<dnssuffix> can be resolved. If the name can be resolved then ISATAP IPv6 addresses are assigned to that virtual interface. On Windows Vista ISATAP IPv6 addresses are assigned anyways and the state is not “media disconnected”. In both cases the ISATAP IPv6 addresses have a link-local prefix but additional ISATAP addresses can be assigned via SLAAC (more details later). This way two hosts with ISATAP interfaces can talk to each other through IPv6, without any additional configuration, simply by using the link-local ISATAP addresses.
isatap.<dnssuffix> name is supposed to point to an ISATAP router.
Native IPv6 hosts discover the IPv6 routers on their network via multicast messages (they send a Router Solicitation message to the multicast address
fe02:2 which stands for link-local scope, all routers, and is subscribed to by all routers on that link). Routers that receive this message respond with a Router Advertisement message to the host. But… on an IPv4 network there’s no way for hosts to discover an IPv6 router – unless they use IPv4 multicast as some transition technologies tend to do, something that may not always be possible – so what we need is for a way to specify the router address to hosts directly. This is what the
isatap.<dnssuffix> address is supposed to be. It is an ISATAP router that will help hosts with auto-configuring as well as routing to other IPv6 networks. Hosts contact this router by sending Router Solicitation messages to this unicast address, and the router will respond.
isatap.<dnssuffix> name is only one way of specifying the ISATAP router address. (The
isatap.<dnssuffix> name can be resolved using DNS, the
hosts file, or NetBIOS). Other ways are to specify the router address are directly via PowerShell,
netsh, or GPOs.
Turning on ISATAP is a very easy process. Consider the network below:
WIN-DC01, WIN-DC02, and WIN-GW01 are IPv6 enabled machines Windows Server machines. They have both IPv4 and IPv6 addresses, but the IPv4 addresses don’t matter as I want clients to connect to these servers via IPv6. WIN-CLIENT03 and WIN-CLIENT12 are Windows 8 and Windows 7 machines. They are in a separate IPv4 only network, connecting to the main network through a router. The fact that they are in a separate network doesn’t matter. I just put them in a separate network to illustrate something later.
I want WIN-CLIENT03 and WIN-CLIENT12 to connect to WIN-DC01 and WIN-DC02 through IPv6. Currently they can connect via IPv4 but soon the servers will be IPv6 only and I want to ensure everything works well over IPv6. As this is a temporary situation I will use ISATAP to ensure the clients can connect to the servers until the permanent solution is ready. Here’s what I have to do:
- Decide a machine that will act as the ISATAP router (any Windows Server would do; you can use Linux too). The ISATAP router will have a virtual ISATAP interface created on it. If the idea is to have ISATAP hosts connect to an IPv6 network then the router must have an IPv6 interface too on which it will send and receive IPv6 packets. On the other hand if hosts won’t be connecting to any IPv6 network and all you need is automatic configuring then the IPv6 interface is not needed.
I chose WIN-GW01 as my ISATAP router. Note that it’s in a separate network from the clients but that doesn’t matter.
- Name this machine
isatap.<dnssuffix> (or assign it as a CNAME via DNS or as as additional name via the
hosts file). Alternatively set this machine as an ISATAP router for itself – via PowerShell,
netsh, or GPOs.
C:\>netsh interface isatap set router 10.50.0.254
This enables ISATAP on WIN-GW01. It is still not ready as an ISATAP router, that will be done in the next step.
- To configure WIN-GW01 as an ISATAP router I have to enable advertising on the ISATAP virtual interface. Optionally, if I want the clients connecting to it to have a global or unique local prefix, I can configure one.
netsh interface ipv6 set interface isatap.rakhesh.local advertise=enabled
netsh interface ipv6 add route fdcc:7c4e:3651:2002::/64 isatap.rakhesh.local publish=yes
fdcc:7c4e:3651::/48 is a unique local prefix.
2002 is a subnet I assigned for ISATAP hosts.
WIN-GW01 is now ready as an ISATAP router. That’s it!
Here’s the output of
ifconfig for the ISATAP interface:
Tunnel adapter isatap.rakhesh.local:
Connection-specific DNS Suffix . : rakhesh.local
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : fdcc:7c4e:3651:2002:0:5efe:10.50.0.254(Peferred)
Link-local IPv6 Address . . . . . : fe80::5efe:10.50.0.254%18(Preferred)
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 10.50.0.20
NetBIOS over Tcpip. . . . . . . . : Disabled
Notice it has a link-local address – which would be the only address if I hadn’t specified a unique-local prefix – and also a unique-local address. Both have the IPv4 address embedded in it.
- Optionally: Since WIN-GW01 has an IPv6 and ISATAP interface, I can enable routing between them and also advertise WIN-GW01 as the default router for the ISATAP hosts connecting to this.
On WIN-GW01, I do the following:
netsh interface ipv6 set interface LAN-10.50.0 forwarding=enabled
netsh interface ipv6 set interface isatap.rakhesh.local forwarding=enabled
The first command enables routing on the 10.50.0.0/24 interface. The second command enables routing on the ISATAP interface. Lastly, I advertise to hosts on the ISATAP network that WIN-GW01 is the default router:
netsh interface ipv6 set interface isatap.rakhesh.local advertisedefaultroute=enabled
- All that’s left to be done now is to enable ISATAP on the clients. One can use DNS, GPOs, PowerShell, or
netsh. I went with
netsh. The command is same as that on the ISATAP router:
C:\>netsh interface isatap set router 10.50.0.254
Here’s the output of
ifconfig for the ISATAP interface on one of the clients:
Tunnel adapter isatap.dyn.rakhesh.local:
Connection-specific DNS Suffix . : dyn.rakhesh.local
IPv6 Address. . . . . . . . . . . : fdcc:7c4e:3651:2002:0:5efe:10.50.1.202
Link-local IPv6 Address . . . . . : fe80::5efe:10.50.1.202%5
Default Gateway . . . . . . . . . : fe80::5efe:10.50.0.254%5
It has picked up a unique-local ISATAP address, auto-configured a link-local ISATAP address, and is correctly pointing to the ISATAP interface of WIN-GW01 as the default router. The unique-local address would have also registered with DNS (this is why I created unique-local addresses).
- And that’s it. Let’s test IPv6 connectivity via
C:\>ping -6 win-dc01
Pinging win-dc01.rakhesh.local [fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b] with 32 by
tes of data:
Reply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time=2ms
Reply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1ms
Reply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1ms
Reply from fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b: time<1ms
Ping statistics for fdcc:7c4e:3651:1:2495:4a1a:beb4:f01b:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
Here’s the IPv6 routing table on the client:
C:\>route print -6
3...00 0c 29 a9 17 63 ......Intel(R) 82574L Gigabit Network Connection
1...........................Software Loopback Interface 1
5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
IPv6 Route Table
If Metric Network Destination Gateway
5 266 ::/0 fe80::5efe:10.50.0.254
1 306 ::1/128 On-link
5 266 fdcc:7c4e:3651:1::/64 fe80::5efe:10.50.0.254
5 266 fdcc:7c4e:3651:2002::/64 On-link
5 266 fdcc:7c4e:3651:2002:0:5efe:10.50.1.209/128
3 266 fe80::/64 On-link
5 266 fe80::5efe:10.50.1.209/128
3 266 fe80::5433:29e5:3d43:3e7c/128
1 306 ff00::/8 On-link
3 266 ff00::/8 On-link
The neat thing about such tunneling mechanisms is that the underlying IPv4 link is treated as a local link. Even though the clients and servers are in different networks, that does not matter for IPv6. As far as IPv6 is concerned they are on the same link and it is up to the underlying IPv4 protocols to route packets between the IPv4 networks.
Also notice from the routing table above how the
fdcc:7c4e:3651:2002::/64 network has an on-link route rather than via the ISATAP router. This is because communication between ISATAP hosts happen directly, without router involvement. The hosts know each others IPv4 address from destination IPv6 address, so the ISATAP interfaces talk to each other over IPv4. The IPv4 address is still required because unlike native IPv6 which discovers the MAC address of an IPv6 address through Neighbour Discovery, ISATAP has no such luxury. It must discover the MAC address through other means – i.e. use the IPv4 address and leave it to the IPv4 protocols to do the routing.
And that’s all! Pretty straightforward stuff.
Update: To disable ISATAP if you set the router via
netsh or PowerShell do either of the following:
Set-NetIsatapConfiguration -Router ''
netsh interface isatap set router ''
A neat thing about IPv6 is that IPv6 nodes can be up and running and talking to each other without much infrastructure support.
For instance, IPv6 nodes can self configure their address via SLAAC. If a network prefix is published, well and good, hosts can use that; but if not hosts will have link-local addresses (
fe80::/10). How will these stateless addresses talk to each other though? As in, say the name WIN-CLIENT02 has the link-local address fe80::e070:559a:8794:8c01, how will another client WIN-CLIENT01 know thus? These are stateless addresses, not published in DNS, so how will name resolution take place?
Similarly, even if the address were manually configured – a Unique-local or Global unicast address, for instance, set by the node user – how will name resolution take place? Organizations might have DNS to help with this, but home users can’t be expected to have DNS. With IPv4, one could hope to remember the IPv4 address, but IPv6 addresses are not human-friendly so some form of help is required.
This is where Link-Local Multicast Name Resolution (LLMNR) comes into the picture. It is a way of name resolution that works for the link-local scope only and uses multicast.
What is LLMNR?
All nodes on a link subscribe to a multicast address called ff02:1:3. From my previous post you’ll know what this means –
ff00::/8 is the prefix for multicast addresses;
2 indicates the address has a link-local scope; and
1:3 is the group ID for LLMNR hosts. So the way things work is that when WIN-CLIENT01 wants to resolve the name of WIN-CLIENT02, it sends an LLMNR query (basically a UDP packet similar to a DNS query; remember multicast only works with UDP) to port 5355 of the ff02:1:3 multicast address. Since WIN-CLIENT02 is subscribed to this group it receives this query and responds with its addresses.
Here’s a Wireshark capture when one of my clients is trying to ping WIN-CLIENT02 and hence look up its name. First it queries DNS (step 5350), doesn’t get an answer (step 5353), so it sends a multicast query to ff02:1:3 asking for the IP address (step 5354). Note that the multicast query is sent to the IPv4 multicast address too (188.8.131.52) for the IPv6 AAAA record – this is because I had asked ping to only use the IPv6 address.
(The Wireshark output only shows LLMNR and DNS messages as I am filtering for traffic to ports 5355 and 53).
WIN-CLIENT02 replies (step 5357) and its reply has all its IPv6 addresses.
Suppose I hadn’t insisted ping use the IPv6 address, the above queries would be for the A record instead (including the one to the IPv6 multicast address). And when no replies come from WIN-CLIENT02, NetBIOS over TCP/IP (NetBT) will be used to try and find the IPv4 address.
While playing with this I realized that by default Windows clients do not respond to LLMNR queries. This is because Network Discovery is turned off – even for Domain connected interfaces. So if you too find that LLMNR queries are being sent but not responded to, check the Network Discovery setting on your machine (go to “Network and Sharing Center” in the Control Panel > “Change Advances Sharing Settings” > and turn on Network Discovery for whichever network profile you are connected to) .
You can also enable Network Discovery via GPO for domain joined computers. The setting is at
Computer Policy\Policies\Administrative Templates\Network\Link-Layer Topology Discovery – there are two settings there, the second one is what you want.
Multicast MAC address
On an unrelated note, just like Unicast IPs have a corresponding MAC address, so do Multicast IPs. They have a special MAC address that start with
33:33 and the remaining four octets (group of 8 bits or group of 2 Hex digits each) are the last four octets of the Multicast IP address. So for a multicast IPv6 address ff02::1:3 – which can be expanded as ff02::0001:0003 – who last four octets are 00, 01, 00, and 03, the MAC address would be 33:33:00:01:00:03. So all hosts subscribed to this multicast address will create a special MAC address on their interfaces so packets sent to this MAC are passed on to the upper layers for processing. That’s how multicast works behind the scenes.
On Windows machines, you can use the
arp command to view IPv4 address to MAC address mappings. But
arp doesn’t work for IPv6 as there’s no ARP protocol in IPv6. Instead we have the Neighbor Discovery Protocol (NDP) and to see the mappings discovered through that we have to use
netsh. Here’s the full command:
C:\> netsh interface ipv6 show neighbors
In the output you can see many other MAC addresses starting with
33:33 for the various IPv6 multicast groups the node is automatically a member of.
From my previous post you know that IPv6 hosts can autoconfigure themselves if they get the network prefix from a router (or server running this service). Windows Server (and Clients) can send Router Advertisement messages without any additional software. This functionality is in-built and can be configure via the
Here’s what I did on the Server Core 2012 which functions as the “router” for my test lab.
- Visit https://www.sixxs.net/tools/grh/ula/ and get a ULA prefix for myself. This is a /48 block – meaning I have to fill in the remaining 16 bits of subnet ID to make this a /64 block. I can have 2^16 subnets. I got the fdcc:7c4e:3651::/48 prefix, I’ll just use subnet 1 for now, so my network prefix will be fdcc:7c4e:3651:1::/64.
- I assigned an IPv6 address “fdcc:7c4e:3651:1::254”, netmask 64, to the server.
- Next, I issued the following command on the server to enable router advertisements:
netsh interface ipv6 set interface "Local Area Connection" advertise=enabled
This enables Router Advertisements. But this doesn’t advertise any prefixes.
Below is a Wireshark capture on that interface from a client:
Notice that Router Advertisement messages are being sent. The messages specify two options – MTU and the link-layer address of the router.
Here is the result of
ipconfig for that interface on the client:
The only IPv6 address is the link local address. No gateway is set either.
- To specify prefixes the publish, I issued the following command on the server:
netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yes
In case that command gives an error – maybe you don’t have that route entry already – replace it with the following:
netsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yes
This tells the server to publish this prefix on the Router Advertisement messages on that interface. Without
publish=yes the command tells the server that the fdcc:7c4e:3651:1:::/64 network is on the “Local Area Connection” interface for routing purposes – that the prefix for devices on this interface is (or will be) fdcc:7c4e:3651:1:::/64. The
publish=yes bit tells the server to publish this prefix information in Router Advertisement messages.
Below is a Wireshark capture once prefix publishing is enabled:
Notice the prefix information is now published.
ipconfig too shows the automatically generated addresses:
- So far the server isn’t functioning as a router (i.e. it is not forwarding packets). If we want the server to function as a router that can be enabled:
netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled
- Once the server functions as a router we can also tell it to include this information in the Routing Advertisement messages. This way clients can automatically pick up the router as a default gateway!
netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabled
Checking the Wireshark capture will now show a new option in the Router Advertisement messages:
ipconfig will show a default gateway is automatically set:
Ain’t that cool!
- To view the current configuration of that interface on the server, the following command can be used:
netsh interface ipv6 show interface "Local Area Connection"
- The neat thing with Router Advertisement messages is that they can work in conjunction with DHCPv6. The Router Advertisement messages can tell clients to also contact DHCP for an IPv6 address and additional options, or contact DHCP not for an IPv6 address but only for additional options.
For the former do this:
netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabled
For the latter do this:
netsh interface ipv6 set interface "Local Area Connection" otherstateful=enabled
Here’s the Wireshark output after I enabled managed address. The output is similar to the previous ones except for the flags (it’s
0x80 now in contrast to
0x0 before). So I have expanded it.
The way clients will behave now is thus:
- If the client’s interface is set to Managed Address as disabled (i.e it is not looking for DHCPv6 address configuration), since the Router Advertisement now sets it to enabled it will start looking for DHCPv6 address configuration.
- If the client’s interface is set to Managed Address as enabled, since the Router Advertisement too sets it as enabled it will behave as before.
In the opposite scenario – suppose Router Advertisement messages were setting Managed Address as disabled (which is the default) clients ignore this and continue working based on what their own Managed Address configuration is.
If you don’t want Windows clients to listen for Router Advertisements, do the following on the client:
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
As with the server, to view the interface configuration on the client the following works:
netsh interface ipv6 show interface "Local Area Connection"
Lastly, suppose you have enabled prefix publishing on the server, and Wireshark shows the information is being sent but clients aren’t picking it up, the following might be helpful. By default the site prefix is set to /64 but if your network prefix is (say) /48 either by mistake or intentionally, clients will ignore this network prefix. Correct the prefix setting then, or the network prefix mask if it’s a typo. The first time I played with this I had forgotten to change the mask from /48 to /64 once I added the subnet ID bits, so the server was advertising it with /48 and clients were ignoring it.
I spent the last two weeks studying IPv6. It began because I was experimenting with DirectAccess on my virtual lab and that uses IPv6, which I was sort of familiar with from my FreeBSD days but hadn’t explored in a while (and it’s been a while). What follows is my notes from the various blog posts and articles I read. It is not meant to be an explanatory post, mainly something for me to refer back to later.
- IPv6 has 128 bit addresses vs 32 bit addresses of IPv4
- The “v6” and “v4” stand for version 6 and version 4 respectively. Before I began reading about IPv6 I though the 4 and 6 stood for the number of dot or colon separated groups (which is all the more silly because IPv6 addresses have 8 groups and not 6!)
- IPv4 puts these 32 bits as 4 groups of 8 bits (a byte). 8 bits gives you 256 combinations (2^8) so that’s why each group is a number from 0-255.
- IPv6 puts these 128 bits in 8 groups of 16 bits each. That is, twice the number of groups as IPv4 and twice the bits in each group. Remember that!
- 16 bits in each group means you have 65536 (2^16) combinations. So each group can have a number from 0-65535.
- To make the number in each group smaller and easier to handle, one can increase the number of digits used. That is, instead of restricting to digits 0-9 we also add a-f, giving us a total of 16 digits to use (‘a’ is short for 10, ‘b’ short for 11, and so on). This way of representing numbers is called Hexadecimal and while the range was from 0-65535 with 10 digits (decimal), now it is from 0-FFFF with 16 digits (hexadecimal).
- To avoid confusion hex digits can be prefixed with a
0x to indicate their nature. So
0xa is the hex digit
a, not the alphabet a.
- In an IPv4 unicast address (an address which specifies a single device on the network) the address has a variable host part and network part. But in the case of an IPv6 unicast address half the bits (64) are for the host and half the bits (64) for the network.
StateLess Address AutoConfiguration (SLAAC)
The advantages behind IPv6 are not only that it has more addresses, but also that it has features not present in IPv4. One of these is stateless address autoconfiguration (SLAAC).
- Devices on the network use the Neighbour Discovery Protocol (NDP) to get details of the network (the network prefix, the MTU, duplicate addresses, redirects, etc). (See also this page).
- IPv6 routers periodically send Router Advertisement messages. These are also sent in reply to Router Solicitation messages sent by devices on the network.
- It is not not necessary to have routers for the Router Advertisement messages. Servers too can send this. Linux has the Router Advertisement Daemon. Windows has this in-built and it can be enabled & configured via
- Devices also send each other Neighbour Solicitation messages and reply with Neighbour Advertisement messages. This way they can ensure the neighbour device is still reachable.
- One of the items (optional) in the Router Advertisement is the network prefix. This is a globally unique 64-bit value. Consists of a 48-bit globally unique prefix followed by a 16-bit subnet ID that is unique within the network.
- Devices can autoconfigure their IPv6 address using the network prefix and their MAC address and/or a random number.
- This method is called Stateless because no one keeps track of the addresses. Routers don’t know the device IPv6 addresses, unlike a DHCP server. All routers do is to provide the network prefix, rest is up to the devices.
- For more on SLAAC, including the process and advantages disadvantages see this article. SLAAC has its disadvantages (devices may use the SLAAC address instead of their DHCP or static address and you may not want that).
- SLAAC can be disabled on the device. Or the router can be configured to not send the prefix information.
- On Windows the
netsh command can do both of this.
Writing the Address
While IPv4 addresses use a period to separate the groups, IPv6 uses colons. Since IPv6 addresses are very long, there are a few tricks to shorten them:
- One or more leading zeroes in a group can be omitted. So 0017 can be written as 17.
- Just once, one or more consecutive groups of zeroes – viz in 0000:0000:1234 – can be replaced with a double colon like this – ::1234. This can only be done once and the recommendation is to not do it for just one group of zeroes.
- To give an example, say we are given an address such as 2001:12cd::1. To work out what this stands for we start with remembering that there must be 8 groups. There’s only 3 here, and since then double colons indicate groups of zeroes, in this case they indicate 5 groups of zeroes. Also the final group of 1 is actually 0001.
- This is why the double colon can only be used once. If there were two double colons there would be no way of know how the hidden 5 groups of zeroes are to be distributed.
- Unspecified address: :: (all 128 bits are 0)
- Used as the source address, but never as destination address, when the interface is yet to get an address.
- Default route: ::/0 (equivalent to 0.0.0.0./0)
- Loopback address: ::1/128 (equivalent to 127.0.0.1/8)
- Unlike IPv4 only ::1 can be used as the loopback address. Cannot use ::2 etc.
- Global unicast addresses: 2000::/3 prefix
- 64 bits of network prefix followed by 64 bits of host address.
- Network prefix is 48 bits of Organization prefix followed by 16 bits of subnet ID.
- First three bits are 001. How? 2000::/3 prefix means only the first 3 bits are set. So even though 2000 looks like a 16 bit hex number, only the first 3 bits are used, rest 13 don’t matter. 2 = 0010, so the first three bits are 001.
- The first group is then written as (001x)(xxxx)(xxxx)(xxxx). (001x) can be 0010 or 0011 – i.e. 2 or 3. So the actual range of the first group is 2000::/16 to 3ffff::/16.
- Next 45 bits are the global routing prefix. These are the assigned by whoever allocates you IPv6 addresses (usually an ISP).
- Subnet ID is unique within the organization.
- However, you don’t always get this – it is decided by the address allocator.
- The allocator need not always go with a /48 (3+45 bits) block address. They could use the subnet ID bits too and assign a /64 block – leaving you with no subnets!
- If a /64 block organization prefix is assigned, it means you have no bits for subnets. If a /60 block is assigned you have some bits (4 bits for subnet – so 2^4 = 16 subnets). And so on … This is what the /xx subnet mask of your network prefix means for you – how many subnets you can have.
- /64 block => 0 subnets
- /60 block => 16 subnets
- /56 block => 256 subnets
- /52 block => 4096 subnets
- /48 block => 65536 subnets
- The 64 bits of host address is manually specified, automatically generated via SLAAC or assigned by DHCPv6.
- See this page for more.
- Link-local addresses: fe80::/10 prefix; the actual assignment is from fe80::/64 so easier to remember it as /64. (equivalent to 169.254.0.0/16)
- First 10 bits are FE8 (
0xF is 1111,
0xE is 1110,
8 is 1000). Rest 54 bits are 0 – i.e a single subnet of all zero bits.
- The 64 bits of host address are automatically assigned (randomly or by expanding the MAC address via EUI-64). These may also be assigned manually.
- There can be multiple link-local addresses. In Windows when you disable and enable a network interface a new link-local address is assigned (in addition to the manually assigned addresses, if any).
- Unlike IPv4, IPv6 requires a link-local address to be assigned to every network interface on which the IPv6 protocol is enabled, even when one or more routable addresses are also assigned. So IPv6 devices have more than one IPv6 address assigned to them.
- On Windows link-local addresses are created by default for ISATAP too. The host bit is created by prefixing 0200:5efe (for public IPs) or 0000:5efe (for private IPs) in front of the 32 bits of IPv4 address.
- Packets with source address as a link-local IP cannot cross the router. All IPv6 networks use the same fe80::/64 prefix.
- These addresses are not to be published in DNS as they are unique only for the link. Not unique even within the organization.
- Suggestion: Set fe80::1 as the router address for each interface. This way you don’t have to remember the longer address. Also easy to troubleshoot.
- Unique local addresses (ULA): fc00::/7 (equivalent to 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Similar to link-local addresses but routers will allow them to cross subnets within the site (no clear definition of what constitutes a site; it is up to your border router to block the fc00::/7 packets from crossing out – you define your site!).
- Unlike link-local addresses, these are globally unique addresses (not guaranteed, but there is a high probability it will be globally unique if you followed the correct steps).
- Since the mask is /7, only the first 7 bits are used.
0xF = 1111,
0xC = 1100,
0x0 = 0. So the first 7 bits are 1111110 – basically the
0xFC bits. The zeroes in fc00 are not really zeroes. They are only put as zeroes to complete the group and they don’t matter for the network prefix (because of the mask).
- Notice though that while the first 7 bits are 1111 –
0xF – and 110 –
0xC – the latter can be written as
0xC only if the eight bit is 0. This is because
0xC is 1100, but since the last bit doesn’t come under the network mask it is not fixed and can be 1 too. In which case
- This is intentional. This way the fc00::/7 prefix can be thought of as as two prefixes – fc00::/8 and fd00::/8.
- This 8th bit is called an L flag. L == Local. The idea being that in future there could be a central authority that might assign globally unique ULAs. To avoid any clashes with such a scenario, addresses assigned by that authority will have the L flag set as 0 (not local) while addresses generated by non-central now will have the L flag set as 1 (local). Thus –
- fd00::/8 == Unique Local locally assigned Addresses
- fc00::/8 == Unique Local centrally assigned Addresses
- All ULAs generated by users are supposed to be in the fd00::/8 prefix.
- So that’s the first 8 bits. You still have 64 – 8 = 56 bits for the network prefix. These are made thus:
- 40 bits of a random number. Generated by you. High probability of uniqueness. Suggested algorithm here.
- 16 bits for subnets.
- That’s 65536 subnets so an organization mostly only needs one 40 bit random number for all its networks. Everything can be a subnet of that.
- ULAs can be published in DNS. As they work across the site.
- See this page for more. And this. Also see RFC 4193 on how to generate, and the rationale behind ULAs.
- Visit https://www.sixxs.net/tools/grh/ula/ to generate ULAs following the RFC 4193 method and also register the address with the website. If everyone were to do this, the website can ensure ULAs are unique.
- Stateless IP/ICMP Transition address: ::ffff:0:0:0/96
- If a device has IPv4 address a.b.c.d then its IPv6 address can be assigned as ::ffff:0:a.b.c.d.
- The IPv6 network bit takes 96 bits. Balance is 32 bits for the host – which is the IPv4 address.
- The network block is all zeroes (hence the ::).
- The host bit has 16 bits of ones (ffff) followed by 16 bits of zeroes (0), followed by 32 bits of the IPv4 address.
- This prefix was chosen to yield a zero-valued checksum to avoid changes to the transport protocol header checksum (RFC 2765).
- Anycast address: Any IPv6 Unicast address (just like in IPv4).
- Any type of address valid for Unicast (Link-Local, Site-Local, ULA or Global) also is valid for Anycast.
- A sending node does not do anything special when sending traffic to an Anycast destination. The network will route your traffic to the nearest one of the nodes (in the network metric sense) that has had that anycast address assigned to it.
- An Anycast connection is still one-to-one, just like Unicast. It just is done to the closest node that has the Anycast address assigned to it. All three Transport Layer protocols (UDP, TCP and SCTP) work with Anycast.
- Multicast address: ff00::/8 prefix (i.e. 8 ones and 8 zeros, but the 8 zeros don’t matter as the mask is /8. They are zeros just to complete the group)
- Only for UDP and SCTP (TCP is too complex to do multicast; sender has to keep track of all the recipients, whether they received etc).
- A multicast address contains a group.
- Multicast address format is thus:
- 8 bits of 1 (the “
0xff”) – this is the mask so these are the fixed bits
- 8 bits of flags & scope:
- 4 bits of flags
- 4 bits of scope –
0xf – so the last digit in the first group of the IPv6 address tells you the scope
- Scope 1 = Interface-local
- Scope 2 = Link-local (the subnet)
- Scope 4 = Admin-local (smallest scope that can be administratively managed … whatever that means)
- Scope 8 = Organization-local (the collection of sites managed by the organization, linked by VPN or whatever)
- All the above scopes are LOCAL. The next one is global.
- Scope E = Global (any node on the Internet, not filtered by routers).
- 112 bits of group ID
- There are many well known groups apart from the user defined ones. Examples:
- Group 1 = Node
- Group 2 = Router
- Group 5 = OSPF IGP router
- Group 1:2 = DHCPv6 servers/ relay agents
- Group 1:3 = DHCPv6 servers or LLMNR hosts (depends on the scope)
- Remember multicasts are only for UDP …
- Every IPv6 node (that is not forwarding) is a part of the following groups:
- ff01::1 – All nodes in local interface
- Scope is 1 (interface-local), Group is 1 (node)
- ff02::1 – All nodes in local link
- Scope is 2 (link-local/ the subnet), Group is 1 (node)
- Windows nodes are part of the following groups:
- ff02::c – Simple Service Discovery Protocol
- Scope is 2 (link-local/ the subnet), Group is c
- ff02::1:3 – Link-Local Multicast Name Resolution
- Scope is 2 (link-local/ the subnet), Group is 1:3 (LLMNR hosts)
- Every IPv6 router is a part of the following groups:
- ff02::5 – All nodes in local site
- Scope is 2 (link-local/ the subnet), Group is 5 (IGP routers)
- Solicited node multicast address: created for each unicast and anycast address
- ff02::1:ff___, with last 24 bits equal to last 24 bits of the unicast/ anycast
- Scope is 2 (link-local/ the subnet)
- Used for link-layer address resolution via NDP.
- From here:
- The solicited-node address facilitates efficient querying of network nodes during address resolution. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform address resolution. However, instead of using the local-link scope all-nodes address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used. The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.
- For example, for the node with the link-local IPv6 address of FE80::2AA:FF:FE28:9C5A, the corresponding solicited-node address is FF02::1:FF28:9C5A. To resolve the FE80::2AA:FF:FE28:9C5A address to its link layer address, a node sends a Neighbor Solicitation message to the solicited-node address of FF02::1:FF28:9C5A. The node that is using the address of FE80::2AA:FF:FE28:9C5A is listening for multicast traffic at the solicited-node address and, for interfaces that correspond to a physical network adapter, has registered the corresponding multicast address with the network adapter.
- The result of using the solicited-node multicast address is that address resolution, which commonly occurs on a link, is not required to use a mechanism that disturbs all network nodes. In fact, very few nodes are disturbed during address resolution. In practice, because of the relationship between the Ethernet MAC address, the IPv6 interface ID, and the solicited-node address, the solicited-node address acts as a pseudo-unicast address for very efficient address resolution.
- More info on this page.
- Some well-known multicast groups:
- Remember! Last digit of first group is the scope (link, organization, site, global, etc). Last digit of the last group is the group (nodes, routers, etc).
- ff02::1 – Scope 2 (link-local), Group 1 (nodes)
- ff05::1 – Scope 5 (organization-local), Group 1 (nodes)
- ff02::2 – Scope 2 (link-local), Group 2 (routers)
- ff05::2 – Scope 2 (organization-local), Group 2 (routers)
- ff02::fb – Scope 2 (link-local), Group fb (DNS servers)
- ff05::fb – Scope 5 (organization-local), Group fb (DNS servers)
- ff02::1:3 – Scope 2 (link-local), Group 1:3 (DHCPv6 servers)
- ff05::1:3 – Scope 5 (organization-local), Group 1:5 (DHCPv6 servers)
- Teredo: 2001:0::/32 prefix.
- 6to4: 2002::/16 prefix.
- ISATAP: fe80::/64 (ISATAP addresses are link-local)
- Host bit is 0200:5efe (for public IPs) or 0000:5efe (for private IPs) followed by 32 bits of IPv4 address
- Unicast has 1) Link-local, 2) Global, 3) Unique-local, and 4) Interface-local (loopback).
- Multicast has 1) Link-local, 2) Global, 3) Interface-local, 4) Organization-local, 5) Site-local, and 6) Admin-local.
- Note: No Unique-local.
- The interface-local scope spans a single interface only. A multicast address of interface-local scope is useful only for loopback delivery of multicasts within a node, for example, as a form of interprocess communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses can be joined on any interface (from this page, has good info on the other scopes too).
- More here.
This is just the tip of the ice berg, of course!