IPv6 Addressing Model

There are three types of IPv6 addresses, based on transmission mode:

There is no Broadcast transmission mode in IPv6.

RFC 4291, "IP Version 6 Addressing Architecture", February 2006, is the current specification for the IPv6 Addressing Model. Much of the following is taken from there.

 

IPv6 Unicast Addresses 

Unicast transmissions are from one specific node to another specific node (one to one). Most Internet protocols you are familiar with are unicast, including HTTP/HTTPS (web), SMTP/SMTPS (email sending), IMAP/IMAPS (email retrieval), FTP (file transfer), Telnet (simulated computer terminal), SSH (secure terminal), SCP (secure file transfer), DNS (Domain Name System), etc. All three Transport Layer protocols (UDP, TCP and SCTP) work with Unicast transmission mode.

 

IPv6 Unicast Address Syntax

| 3 |     45 bits         |  16 bits  |       64 bits              |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID |       interface ID         |
+---+---------------------+-----------+----------------------------+
 

Address Prefix

The first 64 bits contain the complete Address Prefix. It consists of the Organizational Prefix combined with the Subnet ID.

The first 48 bits of the Address Prefix contain the Organizational Prefix. This is assigned to you by whoever provided your address allocation (usually your ISP).

The first 3 bits of the Organizational Prefix contain the binary value "001". This puts the address in the address block 2000::/3, which is marked for allocation of unicast global addresses.

The next 45 bits of the Organizational Prefix contain a global routing prefix, which is determined by whoever provided your address allocation.

The next 16 bits of the Address Prefix contain a Subnet ID. Depending on your allocation block size, you may have anywhere from 0 to 16 bits of this to manage. The remaining bits (if any) are assigned by your ISP. If your ISP only gave you a single /64 block, then they have already specified all 16 bits of this. If your ISP allocated more than one /64 block (e.g. a /60 or even a /48), then you have multiple subnets you can manage.

If your IPv6 allocation is only a single /64, then your organizational prefix is the full first 64 bits, and you have no subnet ID. This still includes 264 (about 18 quintillion) public addresses, which is more than enough for any subnet. Actually, a single /64 would be more than enough addresses for the entire world, for the foreseeable future, properly managed. But it is still only a vanishingly tiny fraction (about 10-20) of the entire IPv6 address space.

It is possible for ISPs to provide other allocation block sizes, between a /64 and a /48. Only very large organizations would ever need an allocation larger than a /48. No ISP can ever allocate less than a /64 to a customer (this is the minimum size block for use with SLAAC). Ideally even a home user should get at least 16 /64 blocks (a "/60" allocation), since they someday may want more than one internal subnet (e.g. one for IP phones, one for other consumer electronic devices, one for the kids, and one for the parents). The most common allocation block sizes are listed below:

Block Size    Subnet ID size     Number of /64 subnets

/48              16 bits               65,536  
/52              12 bits                4,096
/56              8 bits                   256
/60              4 bits                    16
/64              0 bits                     1

The organizational prefix is specified by your Internet Service Provider when you sign up for ISP service. You don't have any choice about this (other than possibly the allocation block size). They will allocate the next available block out of their allocation space (which is typically provided to them by a higher level ISP, or their Regional Internet Registry, e.g. APNIC). The block that is available for you determines the bits in those first 48. The first 16 bits will be in the range from 0x2000 to 0x3fff. After that, it depends on what block your ISP was allocated.

As an example, my source of IPv6 service, Hurricane Electric, was allocated a /32 block with the first 32 bits being 2001:470::. A /32 block includes 216 (65,536) /48 blocks (the standard allocation size for organizations. When I obtained service from Hurricane Electric, they provided me with one of those /48 blocks, which happened to be 2001:470:3d::/48. Their next organizational customer probably got block 2001:470:3e::/48.

If Hurricane Electric allocates all of the addresses in their first ISP allocation, they can get another /32 block from ARIN and be able to provide addresses for another 65,536 organizational customers. ARIN was given a /12 allocation, which is enough for 1,048,576 normal /32 allocations to ISPs. ARIN may never need another allocation. If they ever do, IANA has over 500 /12 blocks still untouched from the 2000::/3 block marked for unicast address allocation. This /3 block is 1/8 of the total IPv6 address space. If somehow IANA uses all of those /32 blocks up (which is difficult to imagine, but we thought 4.3 billion addresses was a lot, back in 1983), over half of the IPv6 address space (5 more /3 blocks) is still reserved for future use.

If Hurricane Electric provides only one /64 block for home users, a single one of their /48 block would provide enough allocations for 65,536 home users. If they provide a /60 for each home user, a single /48 block wold provide enough allocations for 4,096 home users. There is no reason for ISPs to be stingy in allocations, even with home users. This is not IPv4, where ISPs can't even give home users a single public address anymore. Hurricane Electric will actually provide anyone with tunneled IPv6 service and a /64 block (or even a /48 block, if you ask) for free. The projects on this website will show you exactly how to obtain this.

 

Address Suffix or Interface Identifier 

The final 64 bits of an IPv6 unicast address contain the address suffix, or Interface Identifier. You control the entire 64 bits of this value.

Each Interface Identifier must be unique in the subnet (as verified by Duplicate Address Detection) and can be:

  • automatically generated by the node, at power-up or during SLAAC
  • assigned by DHCPv6, or
  • manually specified

If the Interface Identifier is automatically generated, the most likely generation methods are EUI-64 (suffix generated from interface's 48-bit MAC address) and Random (suffix randomly chosen from all 264 possible values). The address suffix must be unique within the link.

The EUI-64 algorithm is a way to generate a globally unique 64-bit value from the already globally unique 48-bit MAC (Media Access Control) address belonging to the interface being identified. The MAC address is usually assigned by the vendor of the interface (and "burned" into) the interface hardware. MAC addresses are effectively randomly distributed to various customers (they are not clustered by geography or organization). The first 24 bits of the MAC are the Organizationally Unique Identifier (OUI), which identifies the interface Vendor. A given network vendor might have more than one OUI, but a given OUI belongs only to one vendor. The last 24 bits of the MAC are assigned by the interface vendor in such a way that no two devices with that OUI will have the same low 24 bits. This guarantees that the entire 48 bit address will be globally unique. 

The "EUI-64" algorithm maps the interface's 48 bit MAC address into a globally unique 64 bit value as follows:

Step 1: Obtain the interface's 48-bit MAC address:  50-46-5d-6b-7a-54
Step 2: Split it into two 24 bit groups:            50465d 6b7a54
Step 3: Insert the value 0xfffe in the middle:      50465d fffe 6b7a54
Step 4: Set the 7th bit of the first byte to 1:     52465d fffe 6b7a54
Step 5: Represent it as a 64 bit IPv6 suffix:       ::5246:5dff:fe6b:7a54

You can easily recognize EUI-64 based Interface Identifiers by the "fffe" in the middle.

For Random generation of an Interface Identifier, a pseudo random number generator is used, which should meet certain minimum criteria (even distribution, difficult to predict the next one in the sequence, etc).

RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007, specifies how random Interface Identifiers are generated and used. It also covers Temporary Addresses which are another IPv6 address privacy mechanism.

By default, Windows uses Randomized Interface Identifier generation, but you can disable this if you prefer. If this option is enabled, all automatically generated Interface Identifiers will use Random. If this option is disabled, all automatically generated Interface Identifiers will use EUI-64. The netsh command to enable or disable randomized Interface Identifiers is:

netsh interface ipv6 set global randomizeidentifiers=enabled|disabled

Windows also enables the Temporary Address option by default, but you can disable that if you like. If this is enabled, you will get not just one unicast global address generated during SLAAC, but two - the second one will have a shorter lifetime, and automatically change over time. The netsh command to control this is:

netsh interface ipv6 set privacy [state=]enabled|disabled [maxdadattemps=integer] [maxvalidlifetime=integer] [maxpreferredlifetime=integer] [regeneratetime=integer][randomtime=integer]

Note that both of these options affect all interfaces on your node.

You can also control these options using NetConf. On the IPv6 Settings tab, you can enable or disable Randomize Identifiers or Temporary Addresses.

 

IPv6 Special Addresses (from ::/8)

The first two special addresses are neither unicast nor multicast. Neither can be manually assigned to any interface. The loopback address is automatically assigned to the loopback interface.

The other two special address types are for IPv4 to IPv6 transition or co-existence, and allow sending and receiving of IPv4 packets on an IPv6 socket. They are legitimate IPv6 addresses, and may be used anywhere a regular IPv6 Unicast address can be used (unless this mechanism is not supported by your Operating System).

 

Unspecified Address (::) 

The unspecified address is 128 zero bits. Its external data representation is the extreme case of compression, consisting solely of two colons: "::". In IPv6, there are times when an interface does not have any address assigned to it (e.g. briefly after power up or interface being enabled). If the node has no address, and in certain transmissions (e.g. sending a Network Solicitation message for Neighbor Unreachability Detection) you can use :: as the source address. You can never use the unspecified address as a destination address. Traffic sent using :: as source can be unicast or multicast, depending on the destination, but since you can never use :: as destination, the address itself is neither unicast nor multicast. I suppose you could consider it "no cast".

 

Loopback Address (::1) 

In IPv6, the loopback mechanism (similar to 127.0.0.1 in IPv4) is considered a separate scope. It has exactly one address in it, which is ::1 (127 bits of 0, followed by a single 1 bit). It is not technically a unicast address, since it is not from the 2000::/3 block.

In IPv4, almost any address in 127/8 will behave as a loopback address (127.0.0.1 is the "official" loopback address, but any address except 127.0.0.0 and 127.255.255.255 will work just as well. In IPv6, only ::1 behaves as a loopback address. You can use any Transport Layer protocol (UDP, TCP or SCTP) with traffic sent to the loopback address, including ICMPv6 traffic. You can ping ::1, but only from ::1. Interface-local traffic never leaves the interface. If you are sniffing traffic from outside the interface you will not see anything during interface-local traffic.

You can bind some servers to the loopback address (usually using the nodename locahost), and access them from clients on that same node. For example, I can deploy a SQL Server on my node, binding it to localhost. A SQL Client on that same node can access it using the nodename localhost. A SQL Client on another node cannot access it. On the other hand, if you bind the SQL Server to one of the node's unicast addresses, and allow access via the host based firewall, then a SQL Client on another node can access that SQL Server.

 

IPv4-Compatible IPv6 Address (deprecated) 

An IPv4-Compatible IPv6 Address consists of 96 bits of zero, followed by a 32-bit IPv4 address. They are from block ::/96. A typical address (using mixed mode external data representation) might look like: ::192.168.1.100. Note that the first two of these addresses coincide with the above two special addresses (unspecified address and loopback address). You can't normally use IPv4 address 0.0.0.0 anyway, but 0.0.0.1 is a perfectly valid IPv4 global address. You can't use either of them with IPv4-Compatible addressing.

IPv4-Compatible IPv6 addresses were specified in RFC 2893, "Transition mechanisms for IPv6 Hosts and Routers", August 2000 for use in automatic IPv6 tunneling in IPv4 networks. If you send a packet with one of these as destination, using an IPv6 socket, internally the packet would be switched to the IPv4 code and sent as usual. Incoming packets with an IPv4-compatible IPv6 address would be received by the IPv4 stack, and then handed up to the IPv6 socket bound to that address. In effect you could use a single socket to send and receive both IPv4 and IPv6 traffic. It is much easier to design a server that accepts data from only one socket than from multiple sockets. They were deprecated in RFC 4291, "IP Version 6 Addressing Architecture", February 2006 because of numerous problems, such as the conflict mentioned above.

RFC 3493, "Basic Socket Interface Extensions for IPV6", February 2003, specifies how to enable to disable this IPv4 automatic tunneling feature on an IPv6 socket, using the IPV6_V6ONLY socket option (assuming the underlying Operating System supports this mechanism).

 

IPv4-Mapped IPv6 Address 

IPv4-Mapped IPv6 Addresses were specified in RFC 4291, "IP Version 6 Addressing Architecture", February 2006, to replace the deprecated IPv4-Compatible IPv6 addresses. They work pretty much the same way, but are from IPv6 block ::ffff:0:0/80. They consist of 80 bits of zero, then 16 bits of 1, followed by a 32-bit IPv4 address. A typical address (using mixed mode external data representation) might look like: ::ffff:192.168.1.100.

By default, Windows (since Vista) allows use of IPv4-Mapped IPv6 addresses, as you can see below (to an internal address). These pings were done from node 172.20.2.1.

C:\Users\lhughes>ping 172.20.0.1
 
Pinging 172.20.0.1 with 32 bytes of data:
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 172.20.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\Users\lhughes>ping ::ffff:172.20.0.1
 
Pinging 172.20.0.1 with 32 bytes of data:
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
Reply from 172.20.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 172.20.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

 

Some routers will allow use of IPv4-Mapped IPv6 addresses even to external nodes, but not all (SolidGate does not allow this). Some Operating Systems (like FreeBSD and OpenBSD) disallow their use for security reasons, but you can enable their use if you like.

In general, it is better to avoid IPv4-Mapped IPv6 addresses. Dual-stack servers should use two sockets: one for IPv4 and one for IPv6. This is a little more difficult than a single socket design, but works much better.

 

IPv6 Unicast Address Types

There are several Unicast address types in IPv6:

Link-Local Unicast Address 

The simplest type of Unicast IPv6 address is Link-Local. The address prefix for all Link-Local addresses is "fe80::/64". The 64-bit suffix can be any value, and may be generated using EUI-64, randomly selected from the entire 264 possible values, or manually assigned using any scheme.

Packets with Link-Local addresses cannot cross any router. They can never leave their home link (or subnet). Every IPv6 subnet in the world uses the same "fe80::/64" prefix. There is no potential for address collisions between link local addresses in different subnets, because packets using them as addresses can never leave their home subnet. You could in theory have an "fe80::1" address in every subnet in the world with no problem.

Every IPv6 compliant node will automatically generate one unique Link-Local address when it is powered up (or when its network interface is enabled). Depending on how the node is configured, the suffix may be generated using EUI-64 (based on the interface's MAC address) or randomly generated from all possible values.

Even though it is not usually done, you can modify your autonomously generated Link-Local address, add additional link-local addresses, or even delete Link-Local addresses on a node using the Advanced option of the standard Windows GUI network configuration tool, the netsh command line utility, or the NetConf GUI application. As an example, you might find it useful to set the Link-Local address of the LAN interface of a router to fe80::1, so that it will be easy to remember. You frequently need to enter the Link-Local address of the LAN interface of a router as the default gateway, so making it easy to remember is a good thing. You can also easily recognize fe80::1 in packet captures, as being your router. If you use the automatically generated suffix, you generally have to go look up what that address is because it is a long string of hex digits (the default gateway of my main subnet is fe80::290:bff:fe1b:5762 - I can never remember the whole address).

Be aware though that if you set the Link-Local address suffix manually, then later disable and re-enable the interface, your node may generate a new Link-Local address, with an EUI-64 or random suffix, in addition to the one you set manually. You will now have two Link-Local addresses on that one interface. It may look a bit odd, but things will work fine. Which of the two addresses is used for various things (e.g. Router Discovery) may be difficult to predict.

In practice, it is probably better to leave the automatically generated Link-Local address alone. But the above discussion helps you realize that a Link-Local address is really just another IPv6 unicast address. It just happens that your node will automatically generate one, without help from anyone, and packets using a Link-local address for source or destination are restricted to the local link. I do not recommend doing this in production networks.

Link-Local addresses can be used as the source address of packets being sent to other nodes in your subnet, whether the destination address is Link-Local or some other scope address (even global). On the other hand, if you are sending a packet to a node in another subnet, you should not use your Link-Local address as the source address, because that other node will not be able to reply to your node by using the source address of your packet. If you do this, you will get a "destination unreachable - out of source address range" error when your default gateway tries to forward it to the next subnet.

In some places (e.g. the ping command) when you specify a Link-Local address, you must specify the zone id. This indicates the interface to be used in transmitting the packet. A single node may have multiple interfaces (even if it isn't a router), e.g. one for Ethernet and another for WiFi. The TCP/IP stack won't know which interface to send the packet out, with a Link-Local destination if you don't specify the interface. In Windows, interfaces are specified with an interface number. For example, on my node, my Local Area Connection interface (Ethernet) happens to be interface number 11. In FreeBSD, interfaces are specified with the NIC type code (e.g. "fxp") followed by a digit, which specifies which interface of that type to use (the first one found during booting is number 0, the second one 1, etc). So, a particular interface might be called "fxp1". The Zone ID, is appended to the end of the link local address, following the "%" character. So, to ping the LAN interface of my firewall from my Windows 7 node, I would use the following command:

ping fe80::290:bff:fe1b:5762%11

To ping it from a FreeBSD node, where the NIC connected to the main subnet is fxp1, I would use (note that FreeBSD uses ping6 for IPv6, not ping):

ping6 fe80::290:bff:fe1b:5762%fxp1

In some cases, Operating Systems will be able to figure out which interface to use (no Zone ID specified). However, if you try to ping a Link-Local address without the Zone ID and it fails, try again with the Zone ID. That should always work. It will never hurt to have one when it is not needed.

Zone IDs are not needed with destinations of higher scope, since the Operating System can always figure out which interface to use, based on the address. Zone IDs are needed only with Link-Local addresses. If you specify a Link-Local address for the default gateway in the Windows GUI network configuration tools, you don't need to specify a zone ID. It assumes the interface that you are configuring! In FreeBSD, if you use a Link-Local address to specify the default gateway in /etc/rc.conf, you need to include the zone ID, because it can't figure out the desired interface from the context. So you would need something like this:

ipv6_defaultrouter="fe80::290:bff:fe1b:5762%em0"

Windows includes the Zone ID for all Link-Local addresses listed in ipconfig, e.g.:

Link-local IPv6 Address . . . . . fe80::5246:5dff:fe6b:7a54%11 (Preferred)

Link-Local addresses are used extensively in the inner workings of IPv6, for example in SLAAC, Neighbor Unreachability Detection, Duplicate Address Detection, etc.

You can configure a new Link-Local address in NetConf. Right click anywhere in the IPv6 Unicast ListView and select Add Address. In the dialog box, choose the predefined prefix "fe80::/10". You can generate the 64-bit suffix using Random, Manual or other options. The combined 128-bit address will appear after "Address:". You can specify preferred and/or valid lifetimes, and choose Unicast or Anycast. When you click Add, the generated Link-Local address will be added to your node. You can modify the suffix of the automatically generated Link-Local address by right clicking on it and selecting Edit Address. This can potentially cause some confusion, especially if your node automatically creates another Link-Local address, so you should be careful about how you do this. If you delete your last remaining Link-Local address, certain IPv6 features cannot work. If you disable then re-enable the interface, it will automatically generate a new one.

You should never publish Link-Local addresses in DNS.

 

Site-Local Unicast Address (deprecated) 

Site-Local unicast addresses are similar to Link-Local unicast addresses, except that internal routers will allow them to cross into other subnets (but they should never cross your border router, separating your network from the IPv6 Internet, incoming or outgoing).

Site-Local Unicast addresses use the 64-bit prefix "fec0::". They will still work on all IPv6 devices I've tried (and they are supported in NetConf), but they have been officially deprecated, and should not be used in production environments. This was done in RFC 3879, "Deprecating Site Local Addresses", September 2004. The primary issues leading to this were the ambiguity of addresses and the fuzzy definition of "site". One of the problems has to do with Site-Local addresses "leaking" into the IPv6 Internet by poorly configured border routers. IPv6 Link-Local addresses cannot leak anywhere outside of their home subnet, because all routers block them. With Site-Local addresses, you want them to be able to cross internal routers, but but be blocked at your border router at your gateway to the IPv6 Internet (both incoming and outgoing), except via tunnels to remote parts of your "site".

Like RFC 1918 IPv4 "private" addresses, the main problem is that IPv6 Site-Local addresses are not globally unique, yet can travel outside of their home subnet. A given Site-Local address (e.g. fec0::1) might exist in many subnets. With Link-Local addresses this is not a problem, since those addresses never leave their home subnet - they can't possibly collide with, or be confused with a Link-Local address in another subnet. However, Site-Local address can cross some routers, but not others. If you link two or more sites that have Site-Local addresses together, there is a high probability that there will be address conflicts, just like with IPv4 private addresses. When you link sites together, all of the addresses in every site must now be unique within the combined sites, not just within each original separate site. Usually when sites that have IPv4 private or IPv6 Site-Local addresses are linked together, one or more of those sites must be renumbered (which is a painful process).

All of these issues were addressed by Unique Local Addresses (ULAs), in RFC 4193 in October 2005. Anywhere you would have used Site-Local, you should now use ULA.

Site-Local addresses are covered here for completeness, and so you will understand why we needed ULAs, but you should not normally use them.

You can configure a Site-Local address in NetConf. Right click anywhere in the IPv6 Unicast ListView and select Add Address. In the dialog box, choose the predefined prefix "fec0::/10". You can generate the 64-bit suffix using Random, Manual or other options. The combined 128-bit address will appear after "Address:". You can specify preferred and/or valid lifetimes, and choose Unicast or Anycast. When you click Add, the generated Site-Local address will be added to your node.

 

Unique Local Unicast Address (ULA) 

Unique Local IPv6 Unicast Addresses are specified in RFC 4193, "Unique Local IPv6 Unicast Addresses", October 2005. They are usually referred to with the acronym ULA.

ULAs were created to replace Site-Local addresses, which were deprecated in September 2004. ULAs resolve most of the issues discovered with Site-Local addresses, and may be used anywhere it makes sense to use them. The big difference is each ULA is actually globally unique. There is still some ambiguity as to what constitutes a "site" (or the domain in which a ULA is valid). They still should not be allowed to "leak" into the IPv6 Internet (and we can't simply block them from crossing all routers, as with Link-Local because they still need to cross internal routers). If they do happen to leak into the IPv6 Internet, they won't cause some of the problems caused by leaked IPv4 private addresses, or Site-Local addresses, because each one is globally unique.

There is a lot of confusion regarding when and how to use ULAs. They are not a direct replacement for RFC 1918 Private Addresses in IPv4. Those who are hoping to deploy IPv6 "in the image of the IPv4+NAT Internet" will be disappointed with ULAs. Those people are actually completely missing the point. We don't need NAT in IPv6, and it wasn't a Good Thing. It was a very Bad Thing. It was a necessary evil that was required to keep the IPv4 address space alive for another 10-15 years, while IPv6 matured. Those years ended around 2010.

ULAs have the following characteristics:

Each organization can have one or more globally unique ULA prefixes (with a high probability, but not a guarantee, of uniqueness). Each 48-bit ULA prefix represents a separate, disjoint private internet, that can have up to 65,536 subnets.

ULAs have a well-known prefix (fc00::/7) for easy filtering at site boundaries. You still must configure this on routers or firewalls - this is not built-in on routers as is filtering for Link-Local addresses.

Disjoint sites that contain ULAs can be combined or privately interconnected (via tunnels or VPNs) without creating any address conflicts or requiring renumbering of any sites. This assumes that you have not assigned the same ULA address in multiple subnets. If you use random or EUI-64 suffixes, this will virtually never happen. If you use manually specified suffixes, be careful not to use the same suffix in multiple subnets.

ULAs are ISP independent, and can be used for communication within a site without having any permanent or intermittent connectivity to the IPv6 Internet. As with IPv4 Private addresses, anyone can create their own "private" internet using ULAs. Because IPv6 nodes can have multiple addresses, it is easy to overlay a private internet on top of a network that can also access the public Internet.

If ULAs do leak outside of a site, they should not conflict with other ULAs from other organizations. They also will cause fewer problems than IPv4 private addresses or IPv6 Site-Local addresses that leak onto the public Internet, because each ULA is globally unique.

Network applications can treat ULAs the same way as they do global addresses. ULAs can be routed inside an organization with no changes, using existing routing protocols designed for global addresses.

The syntax of a ULA address is like that of a Global Unicast IPv6 address, except for the 48 bit prefix. With a ULA, the first 7 bits contain the ULA prefix (fc00::/7), the 8th bit is the L flag, then the remaining 40 bits are a global ID value (which must be unique for a given organization). After the first 48 bits ULAs have the usual 16 bit Subnet ID and 64 bit suffix (interface identifier).

The L bit is 1 if the prefix is locally assigned. Currently all ULAs are locally assigned, so the L bit will always be 1 - this means the first 8 bits are fd00::/8. The L bit is 0 if the prefix is centrally managed (e.g. by IANA). There is no mechanism currently to handle this.

The Global ID must be generated randomly (or at least pseudo randomly) using a good random number generator (an acceptable algorithm for pseudo random numbers is described in RFC 4193, section 3.2.2). Usually a given organization need only generate one Global ID. It is possible for one organization to have multiple ULA Global IDs, but each set of interconnected sites should use the same Global ID and will not be able to communicate with nodes that use a different Global ID (at least with ULAs). If you had three disjoint sets of interconnected sites, you would need three separate Global IDs. In general a given organization will only need one or a few Global IDs. The number of Global IDs is on the order of the number of organizations using the Internet, not on the order of the number of nodes on the Internet. The probability of two or more organizations coming up with the same 40 bit value is extremely low (but not zero).

ULA addresses can be published in DNS, but only in DNS servers that can be accessed only by internal nodes (just like IPv4 private addresses). They should never be published in DNS servers that can be accessed by nodes external to the organization. You could create private (Intranet) web servers that have only a ULA address (no Global address). Be aware that such servers will not be able to connect to the external Internet (e.g. for external links). DNS is difficult to "get right" with ULAs.

There is nothing keeping another organization (or hacker) from maliciously using a Global ID belonging to an attack target. If they can get access to any of your sites, they can create ULAs that will communicate with your nodes. Simple sniffing will reveal your Global ID to anyone interested (if they have access to any of your sites). ULAs are not a security mechanism.

ULAs can be automatically configured on all nodes in a subnet the same way that Global addresses are configured, using SLAAC. You can publish 64-bit ULA prefixes in Router Advertisements just like you can publish 64-bit Global prefixes. Nodes with only global unicast addresses can still connect to servers in the same organization (as defined by router configuration) that have only a ULA address, so you don't need to assign ULAs to internal nodes for this purpose. You could provide client nodes with a ULA to allow connections only from organizational nodes to that client, for things like internal VoIP or other end-to-end connectivity limited to organizational boundaries. You can advertise both a Global prefix and a ULA prefix in all subnets. SLAAC will generate both a Global Unicast address (or two) and a ULA Unicast address (or two) on each node. Each node will use the appropriate source addresses automatically for communicating with various nodes (Link-Local for nodes in the same subnet, ULA for nodes in the same site, Global for external).

The really big difference between IPv6 ULAs and IPv4 RFC 1918 private addresses is that there is no "global IPv6 to ULA" NAT mechanism. So nodes with only a ULA address can connect only to other nodes that have a ULA with the same Global ID and private (possibly tunneled) connectivity to those nodes. They cannot connect to nodes on the public Internet, even through NAT. Likewise, only nodes that have a ULA address belonging to the organization (with routing to the organization ULA internet) can connect to that node. To connect to nodes on the public Internet, a node will also need a Global IPv6 address.

NetConf has good support for ULA addresses. You can create a valid ULA organizational 48-bit prefix (using an RFC-compliant random number generator), and one or more ULA 64-bit subnet prefixes from the 48-bit organizational prefix and a 16-bit Subnet ID. You can create and assign 128-bit node addresses using any 64-bit ULA prefix, using EUI-64, Random or various other schemes for generating the 64-bit address suffix.

In NetConf, in the main menu, click Action / Manage IPv6 Prefix Lists. The middle ListView is for ULA /48 Prefixes. Right click anywhere in that, and select Add Prefix. The ComboBox on the top line allows you to create a 48 bit prefix using the pseudo random number generator from RFC xxx, or manually specify one if your organization already has one. For example, it might randomly generate the prefix fd46:d8c4:6349::/48. Either choose Random, or choose Manual and enter an existing prefix. Enter a prefix name (e.g. "Main /48 ULA") then click Add.The new prefix will be added to your list of ULA 48 bit prefixes.

Now right click in the Unicast /64 Prefixes at the bottom. Right click Add Prefix. In the resulting dialog, the top row lets you select one of your existing 48 bit prefixes (global or ULA). Choose the ULA 48-bit prefix you just created. You can then either randomly generate a 16 bit Subnet ID, or enter one manually. Several common Subnet IDs (1000 to f000) are also available to choose from. The dialog will automatically concatenate the prefix and the Subnet ID to create a 64 bit prefix. Give it a name (e.g. "Main /64 ULA"). Dismiss the Prefix Lists dialog box.

In the IPv6 Unicast ListView, right click anywhere, and select Add Address. To create a ULA address, choose the ULA /64 prefix you just created on the top line. You can generate a 64 bit suffix using either Random, EUI-64, manual entry, or other options. The complete 128 bit address will be shown after "Address:". You can enter preferred and valid lifetimes, or use the default "Infinite". Finally you can choose whether you want the address to be Unicast or Anycast. When you click Add, the new address will be added to your node.

NetConf makes working with ULAs really easy.

 

Global Unicast Address 

All IPv6 Global Unicast address come from the block 2000::/3 (i.e. blocks 2000::/16 through 3fff::/16).

Global Unicast addresses can route anywhere in the IPv6 Internet, and packets with a Global destination address can cross any router (that does not specifically block the global address for other reasons). IPv6 Global Unicast addresses correspond to IPv4 public (or globally routable) addresses. The main difference is we have zillions of them, so there is no need for NAT. To give you an idea of how many we have, if the entire IPv4 address space were a ball 1.6 inches in diameter, just the IPv6 allocatable global addresses would be a ball 55 million miles in diameter (63 times the diameter of the sun). If the sun were this large, it would reach halfway to the orbit of Venus. That's a big ball. We're not going to run out of IPv6 global addresses anytime soon.

Any node with a Global IPv6 unicast address can make connections to, or accept connections from any node on the IPv6 Internet (unless a firewall or router is blocking that access). Basically the entire worldwide IPv6 Internet is in some sense a giant LAN. This opens the possibility of true global End-to-End connectivity (which is ideal for VoIP, chat, file transfer, massive multi-player games, client/server applications or any Peer-to-Peer application). Anyone can run globally accessible servers (web, email, whatever) from their own network. There is no need to host  servers in co-location facilities (other than for guaranteed power and connectivity). This will revolutionize network application design. In the legacy IPv4+NAT Internet (which some people call the "InterNAT") there was a need for intermediary nodes. If Alice wants to chat with Bob, they both must make outgoing connections to some central node (e.g. AOL Instant Messenger), and that node must shuttle messages back and both between the two outgoing connections. In the new IPv6 Internet, Alice can connect directly to Bob and exchange messages without any intermediary node. This will improve scalability (there is no bottleneck at any intermediary node) and security (End-to-End authentication and encryption is simple when there is no intermediary node). You also don't have to worry about the intermediary node going down! As long as Alice's and Bob's nodes are up, and there is connectivity between them, they can connect and communicate. Right now, if my home connection to the Internet goes down (or Skype goes down), I can't use Skype to connect to my kids in the next room. With an IPv6 based decentralized system, I would be able to.

VoIP is inherently an End-to-End technology. A VoIP User Agent ("IP phone") can (if properly designed) connect directly to any other VoIP User Agent. VoIP products designed for the IPv4+NAT InterNAT mostly do an outgoing connection to a "VoIP Server" (the real name for a VoIP server is a "Back to Back User Agent"). The person they call must also have made an outgoing connection to a "VoIP server". The servers have public addresses, and can communicate with each other. An IPv6 VoIP User Agent will not have to connect to VoIP "servers" except to communicate with legacy POTS telephones or legacy IPv4-only VoIP products. The IPv6 Internet was made for VoIP. Real 4G telephony (LTE Advanced) is designed to run only over IPv6. If telcos want to still be in business 5 years from now, they had better start deploying IPv6 today.

A few applications have been developed for the legacy IPv4 InterNAT that simulate End-to-End connectivity, such as Skype. These involve very complex NAT Traversal and have many security and reliability issues. It is fairly simple to create IPv6 applications with the functionality of Skype without any of the security or reliability issues (since the developer doesn't have to fight NAT). Sixscape is already working on such next generation network applications. And as I pointed out above, I won't need Skype, or my Internet connection to be up, to connect to the kids in the next room, or someone else in my company. I can just connect directly to them.

NetConf has good support for Global Unicast addresses. You can manually enter your Global organizational 48 bit prefix (given to you by your ISP), and one or more Global 64-bit subnet prefixes from the 48-bit organizational prefix and a 16-bit Subnet ID. You can create and assign 128-bit node addresses using any 64-bit Global prefix, using EUI-64, Random or various other schemes for generating the 64 bit address suffix.

In NetConf, in the main menu, click Action / Manage IPv6 Prefix Lists. The top ListView is for Global /48 Prefixes. Right click anywhere in that, and select Add Prefix. The ComboBox on the top line allows you to manually enter a 48 bit prefix. For example, you could enter the prefix 2001:470:3d::/48 (use your own - that's my prefix!) Enter a prefix name (e.g. "Sixscape HE /48 Global") then click Add.The new prefix will be added to your list of Global 48 bit prefixes.

Now right click in the Unicast /64 Prefixes at the bottom. Right click Add Prefix. In the resulting dialog, the top row lets you select one of your existing 48 bit prefixes (global or ULA). Choose the Global 48-bit prefix you just created. You can then either randomly generate a 16 bit Subnet ID, or enter one manually. Several common Subnet IDs (1000 to f000) are also available to choose from. The dialog will automatically concatenate the prefix and the Subnet ID to create a 64 bit prefix. Give it a name (e.g. "Sixscape HE main /64 Global"). Dismiss the Prefix Lists dialog box.

In the IPv6 Unicast ListView, right click anywhere, and select Add Address. To create a Global unicast address, choose the Global /64 prefix you just created, on the top line. You can generate a 64 bit suffix using either Random, EUI-64, manual entry, or other options. The complete 128 bit address will be shown after "Address:". You can enter preferred and valid lifetimes, or use the default "Infinite". Finally you can choose whether you want the address to be Unicast or Anycast. When you click Add, the new address will be added to your node.

NetConf makes working with Global Unicast addresses really easy.

 

IPv6 Anycast Address 

An IPv6 Anycast address is basically an IPv6 Unicast address for which the Operating System doesn't do Duplicate Address Detection (DAD). Unlike with Unicast addresses, multiple nodes (even in the same subnet) can have the same Anycast address. For example, you could have three nodes that all have the Anycast address 2001:470:3d:3000::10. Any type of address valid for Unicast (Link-Local, Site-Local, ULA or Global) also is valid for Anycast. The GUI tools provided with Windows do not support creating Anycast addresses. NetConf allows you to easily create Unicast or Anycast addresses of any type. You can even convert a Unicast address into an Anycast address or vice versa (using Edit Address).

Normally, Anycast addresses are only assigned to routers (nodes with multiple interfaces that do packet forwarding between subnets), not to hosts (nodes that don't do packet forwarding). However, in IPv6 any node can have an Anycast address.

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.

The DNS root servers all have both IPv4 and IPv6 Anycast addresses. For example, the A root server IPv4 address is 198.41.0.4. Its IPv6 address is 2001:503:ba3e::2:30. There are actually quite a few real DNS servers around the world that have one or both of those addresses assigned to them. If you try to connect to either the IPv4 or IPv6 address, the BGP routers will steer your connection to the nearest one of those servers. This provides very high redundancy.

IPv6 took this concept below the level of the BGP routers. Every IPv6 router automatically generates an Anycast address, which is the 64 bit prefix of that node's Unicast address, with the special suffix of all zeros. For example, if a router's unicast address is 2001:470:3d:3000::1, then it automatically generates an Anycast address which is 2001:470:3d:3000::.

Anycast is good for redundancy. You could have two web servers in your LAN (with Unicast addresses 2001:470:3d:3000::101 and 2001:470:3d:3000::102) that have the same content. Assign both nodes the Anycast address 2001:470:3000::200 in addition to their Unicast addresses. If you surf to 2001:470:3000::200, you will connect to one of the nodes (it's hard to predict which one will get the connection, since the routing metric is the same for both). If either server goes down, you will connect to the remaining server, without having to do any reconfiguration to your node or the network. BTW, note that IIS has no way to bind to an anycast address currently.

Anycast also acts as a poor man's load balancer. With the two web servers set up as above, if lots of people are accessing the Anycast address, some of the connections will go to one web server, and some to the other. If one of the servers goes down, all of the connections will go to the remaining server. Be careful about "sticky" web connections when doing this, as with real load balancers.

To create a global Anycast address, go through the exercise above for creating a Global Unicast address, but select Anycast. Likewise, to create a ULA Anycast address, do the above exercise for creating a ULA Unicast address, but select Anycast.

RFC 4786, "Operation of Anycast Services", December 2006, explains how to use Anycast with BGP routers, for both IPv4 and IPv6.