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 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!
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:
dhclient.mac
resource.
Otherwise...
dhclient.mac
resource. This propagates in a spanning map which
makes the address available on the DNS master.
%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 2001:630:3c1:216:216:3eff:fee8:e4f2(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 rabbit.inf.ed.ac.uk.(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.
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:
inf.ed.ac.uk
domain.
makeDNSv6
can't find your MAC address then it will
silently skip this step.
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.
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.
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?
%slaac
line
to dns/inf6
if required.
%slaac
address an alias.
(Fix this!)
But remember that CNAMEs are not IPv4- or IPv6-specific.
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:
If we don't advertise a prefix in RA multicasts then no recipients will know to try to set up SLAAC-style addresses.
"1-bit 'Managed address configuration' flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol" (RFC4861 page 20; RFC5175 contains a list of currently-defined RA flags).
If the M bit is not set then the O bit "indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network."
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.
$Id: Addresses.html,v 1.91 2016/09/20 13:51:20 gdmr Exp $