White dot for spacing only
The Dice Project

352: IPv6 investigation: Unicast addresses

There are various different forms of IPv6 address assignment. This page lists the most likely to be encountered, and notes some of the specific issues with each. The project's index page has links to relevant documentation, and in particular the IPv6 Addressing Architecture (RFC4291).

This document covers only unicast addresses. For anycast and multicast addresses (there are no specfic broadcast addresses) please refer to the RFCs.

IPv6 addresses are 128 bits long, and are written as eight four-hexit chunks separated by colons and sometimes enclosed in square brackets ("[]"). Leading zeroes can be suppressed, and the longest block of all-zero can be elided to "::". For example, 2001:630:3c1:160::1 is the same as 2001:0630:03c1:0160:0000:0000:0000:0001.

The address is usually formed of two 64-bit parts: the (high-end) "prefix" and the (low-end) "interface ID". In the example above 2001:630:3c1:160::/64 is the prefix and ::1 is the interface ID. For this reason IPv6 subnets are almost always /64.

The interface ID may be explicitly specified, but it is often automatically generated. For example, given a 48-bit MAC address, an interface ID can be formed by flipping the second bit (in MAC address numbering, remembering its DEC heritage; that is, the "universal/local" bit), inserting FF-FE in the middle (see the note at the end of Appendix A of RFC4291), and reformatting as an IPv6 address. Following this scheme 2001:630:3c1:32:a00:27ff:fe13:9044 corresponds to MAC address 08-00-27-13-90-44.

Machines are required to validate their IPv6 addresses using Duplicate Address Detection ("DAD") before using them.

In addition to a loopback address (defined to be ::1/128), machines will generally have several addresses, from the types listed below. The "unspecified" address ::/128 may also be encounted occasionally.

Link local addresses

Link-local addresses have prefix fe80::/10 and (usually) a generated interface ID. For example, fe80::a00:27ff:fe13:9044. All machines will have at least one of these, in addition to any global addresses (see below) which they might have. The address-search box on the netmon page knows how to translate these back to MAC addresses. (The followup MAC lookup has to be done on the site-specific page, of course.)

Packets using link-local addresses are not routed. They are contained within the specific subnet they are sent on. Within that constraint they are full first-class addresses, and can be used for any purpose within a subnet where a global address might also be used. Because of that constraint, however, they are usually used for infrastructure things such as Neighbor (sic) Discovery ("ND") and Router Advertisement ("RA").

Machines with one MAC address used across several network interfaces are likely to find the same link-local address applied to all of those interfaces. Where it is necessary to disambiguate, the physical interface name can be appended, separated from the IPv6 address with a '%'. For example, fe80::ca1f:66ff:feb9:9954%vlan33.


Don't even think about trying to put a link-local address in the DNS!

MAC-based global dynamic addresses

The prefix for a global address is further broken down into two parts: a global routing prefix and a subnet ID. For EdLAN, the global routing prefix is 2001:630:3c1::/48, and the scheme which is being adopted uses the VLAN tag in BCD as the subnet ID (as was previously done in general for IPv4 addresses). The periodic Router Advertisement packets contain a prefix-list, inter alia. The interface ID is then generated as described above.

So for 2001:630:3c1:32:a00:27ff:fe13:9044, for example, the global routing prefix is the EdLAN one, the subnet ID corresponds to "wire S32", and the interface ID is generated from the MAC address. This is the most common form of address used for StateLess Address AutoConfiguration ("SLAAC").

It's important to note that these are not second-class addresses. Even though they're configured automatically, based on a MAC address, they are just as valid as manually assigned static addresses. They're only "dynamic" in the sense that they're derived from some other configuration detail, though of course that other detail doesn't change often.

This is the most straightforward way to obtain an IPv6 address (but see below).

IPv6 address space is sparsely populated. Unless someone knows your MAC address and can use it to construct a likely IPv6 address then you would be unlikely to be scanned, even in the absence of perimeter filters, if you use an address of this form. However, because of this, the reuse of IIDs across networks can allow machines to be tracked. See the section on "privacy" addresses below.


If you're happy to use a MAC-based address, and you would like to be listed in the DNS, you can do this in a couple of easy steps:

  1. Have your machine on one of the subnets where we generate SLAAC-style forward and reverse addresses for everything which looks as though it has a corresponding IPv4 address. Make sure your MAC address is correctly registered in the lcfg dhclient.mac resource.


  1. Make sure your MAC address is correctly registered in the lcfg dhclient.mac resource. This propagates in a spanning map which makes the address available on the DNS master.
  2. Add the line
       %slaac <yourprofilename>
    to the dns/inf6 rfe file in the relevant %subnet section. Note that while the DNS is case-independent (but preserving), looking up your MAC address in the spanning map is not. If the generating tool, makeDNSv6 can't find your MAC address then it will complain.

Both forward and reverse entries will be generated, linking the name and address.

You can use dig to look up IPv6 addresses. The RR type for IPv6 forward addresses is AAAA. For example:

    [farg]gdmr: dig +short rabbit.inf.ed.ac.uk aaaa
(or omit the +short flag for the full details). The reason "216" appears twice here is that the first one is the subnet number and the second corresponds to a MAC address starting 00-16.

For reverse lookups it is possible to query the PTR value directly, but it's tedious to have to reverse the address and convert it into dotted nibble format. Instead use the -x flag:

    [farg]gdmr: dig +short -x 2001:630:3c1:216:216:3eff:fee8:e4f2
(or again omit the +short flag to see the full details, including that reversed dotted nibble form!).

Note that if you do have a DNS entry of this form and you have edge filter holes registered then they will also be added for IPv6 using this address. These are very definitely not second-class addresses or names.

Explicitly assigned global static addresses

For explicitly assigned global static addresses, the interface part has few constraints, other than to avoid forms which might be generated, such as the MAC-based global dynamic addresses described above, to avoid potential clashes, DAD blockages, and consenquent obscure problems. For IPv4 we have generally "reserved" part of each subnet for infrastructure use (routers, nameservers and the like). For IPv6 the same general effect can be achieved by reserving all interface IDs with ':' in them, at least in the first instance until we gain more experience with setting up and using IPv6. This still leaves the full range [1,ffff] available, which is considerably more than on any IPv4 subnet.

How you actually apply your global static address to your machine's interface is very much system-specific. For DICE SL6 and SL7 machines we have an interim mechanism using the NETWORK_IPV6_ADDR() macro from the live/netinf-macros.h header. This takes three parameters: the interface name (which is also used as a tag-list tag); the subnet number; and the interface ID part of the address. In due course it would be good to have a "supported" mechanism.


If you've gone to the trouble of setting up an explicitly assigned global static address, chances are you'll want to publish it in the DNS. To do this, rfe the dns/inf6 map and add your interface ID to the relevant %subnet section. This will result in the following being added:

Note that a forward mapping for the MAC-based address is not automatically generated, as it may not always be desirable for such an address to be visible externally. If you do need to have a forward mapping for one of these addresses in addition to your global static address then you can simply add a %slaac line to dns/inf6 in addition to your interface-ID entry.

You can of course use dig as above to query the nameservers.

Bear in mind that the nameservers will amalgamate all of the RRs corresponding to a label. In particular, if a CNAME (alias) points at a label then all of the RRs for that label become linked to it. The DNS has no particular concept of IPv4 or IPv6, other than for the A and AAAA RR types. For example:

    [farg]gdmr: dig netmon.inf.ed.ac.uk aaaa
    netmon.inf.ed.ac.uk.      2401  IN  CNAME  dutoit-s33.inf.ed.ac.uk.
    dutoit-s33.inf.ed.ac.uk.  2401  IN  AAAA   2001:630:3c1:33::1:13
In this case the CNAME comes from dns/inf while the AAAA comes from dns/inf6. The two maps are merged as they are loaded by the DNS master.

As before, if you have any edge filter holes registered then they will be applied for your IPv6 addresses too.

"Privacy" addresses

For a portable machine using a MAC-based address, as above, the interface-ID part is likely to be both fixed and globally unique, and this of course opens you to the possibility of being tracked across IPv6 networks based on your use of such an address. (See Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC4941) for a full discussion.)

Some systems will therefore generate ephemeral "privacy" addresses, probably under some kind of host configuration control. These will usually be based on a cryptographic hash of the MAC address, some saved history information, and a random seed. This address will be used for a "short" time (configurable, up to a few hours) before a new one is generated. Once the old one is no longer in use for any data streams it can be discarded.

(A similar issue arises with fixed MAC addresses, which can also allow a machine to be tracked. For this reason Windows 10 can use random MAC addresses. The outsourcing of wireless provision in public areas to a few large providers, prompted by the ubiquity of phones with built-in wireless networking, means that this is becoming more of an issue.)


If you are advertising a service then it really doesn't make sense to use one of these "privacy" addresses. If you have one as casual user, however, then the question of adding a reverse mapping in the DNS does become a bit more reasonable.

As our DNS is currently provisioned, there is no way in which one of these addresses could easily be inserted in to our reverse domains. Adding one manually through dns/inf6 could be done, but it would be tedious to have to track the changes. For further study if it ever really becomes a problem.

Static or dynamic addresses?

Given that dynamic addresses can be used in pretty well exactly the same ways as static addresses, which do we think we should prefer to use?

DHCP or SLAAC for SM machines?

Do we care about assigning specific IPv6 addresses to self-managed machines, or are we (reasonably) happy for them to use SLAAC ones? Whatever we do we'll need to have the audit tools in place to track MAC and address use, so from that point of view it doesn't really matter.

If we do care then there are a few things which can be set or not in the RA broadcasts:

However, going by Sam's findings we may not have a lot of option other than to support both DHCPv6 and SLAAC for at least the self-managed wires: "Google are refusing to do DHCPv6 on Android, which means that if you want to provide IPv6 DNS info you have to use RFC 6106 [i.e. RDNSS over RA]. Microsoft are refusing to implement RFC 6106 so you have to do DHCPv6, either stateful (M-bit) or stateless (O-bit)". And given that we would need the right tools in place to support SLAAC anyway, there's probably not a lot of merit in supporting stateful DHCPv6 on those wires.

Addresses.html,v 1.91 2016/09/20 13:51:20 gdmr Exp

 : Units : Infrastructure : Projects : 352-IPv6 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line