If you have enabled IPv6 on your computer, and in an idle moment you’ve browsed through the interface configuration information for IPv6 addresses you may have been a little surprised by the fact that there’s not just one IPv6 address that’s been loaded, but many. With IPv4 there was a single address that was bound to each interface, but when using IPv6 its not so clear, and an interface can have a number of IPv6 addresses simultaneously. Its also common to have automatic IPv6 over IPv4 tunnelling interfaces be created, and they also are configured with IPv6 addresses. The result can be impressive in terms of the number of IPv6 addresses that are configured into a single host system. Here’s an example collection of IPv6 addresses:
What do each of these IPv6 addresses mean? Which IPv6 addresses are useable, and in which context? In this article I’d like to look at the IPv6 address plan, and describe the various address prefixes.
The authoritative reference for IPv6 addresses is RFC4291, and the related the IPv6 Address Space registry is operated by the IANA, at http://www.iana.org/assignments/ipv6-address-space.
The major division within the IPv6 address architecture is between Unicast and Multicast Addresses. The IPv6 addresses in the block FF::/8 are Multicast addresses, while all other addresses are Unicast addresses.
Currently, IPv6 Unicast addresses are generically structured as a two part address: a 64-bit Topology part, used by routers to forward a packet to its intended destination network, and a 64-bit Interface Identifier, that identifies a particular end point.
IPv6 Multicast addresses are used to forward a packet to a group of end points, each of which is associated with a multicast group identity.
IPv6 Unicast Addresses
The address of all zeros (::) is the ‘Unspecified Address’. This is never a valid destination address, but may be used as a source address by an initializing host before it has learned of its own address.
The address of a single 1 in bit 128 is the loopback address, and is the way for a host to address itself.
IPv4-Mapped IPv6 addresses are used to embed IPv4 addresses in an IPv6 address. One use for this is in a dual stack transition scenario where IPv4 addresses can be mapped into an IPv6 address. This is described further in RFC4038.
FC00::/7 Unique Local Addresses
This address block is analogous to the private address space in IPv4. This address space is intended to have a scope that equates to an enterprise environment, as distinct from global public address space. At this stage the address block FD00::/8 is defined, using a self-assigned Global ID, where the Local bit is set to 1. The Global ID is not assured to be unique, and there is no form of address registration. Packets with these addresses in the source or destination fields are not intended to be routed in the public Internet, but are intended to be routed in scoped contexts.
The address prefix FC00::/8 (where the local bit set to 0) is currently undefined.
Unique Local Addresses are described in RFC4193.
FE80::/10 Link-Local Addresses
IPv6 uses the concept of scoped addresses, and addresses that use the FE80::/10 prefix are scoped for use a single link or a non-routed common access network, such as an Ethernet LAN. Their uniqueness is not required in contexts that are broader than this link scope.
While the prefix FE80::/10 is reserved for this purpose, the only defined prefix in this address block is FE80:0:0:0::/64 (i.e. the following 54 bits are zero).
Link-local addresses may appear as the source or destination of an IPv6 packet, and are bound to interfaces. Routers must not forward IPv6 packets if the source or destination contains a Link-local address.
2000::/3 Global Unicast
IPv6 global unicast addresses are assigned from the address prefix 2000::/3. These assignments are made to Regional Internet Registries, and the address blocks that have been assigned are registered in the IANA IPv6 Global Unicast Address Assignment Registry (http://www.iana.org/assignments/ipv6-unicast-address-assignments). All other address prefixes are currently unallocated, and should not be seen in the source or destination address of any IPv6 packet in the context of global routing.
All global unicast addresses are allocated via the Regional Internet Registry system with three exceptions:
2001:0000::/23 IANA Special Use
Address prefixes in the range 2001:0000::/23 are allocated by the IANA for special uses cases, as described in RFC4773. They are registered in the IANA IPv6 Special Use address registry (http://www.iana.org/assignments/iana-ipv6-special-registry). To date, there have been three such assignments:
This is a mapped address to allow IPv6 tunnelling through NATs, as described in RFC 4380. Packets with Teredo address prefixes in the source of destination field of the packet may be encountered in scoped or global routing contexts
This is a non-routeable address prefix to be used in the context of benchmarking tests, See RFC 5180 for details. This is not a routeable address prefix, and packets with these addresses in the source or destination fields should not be seen on local scoped or global networks.
This is a fixed term experimental address allocation intended to support routeable cryptographic hash identifiers. These identifiers are intended to be visible only on an end-to-end basis, and routers should not see packets with these addresses in the source or destination address fields of any packet, in either local or globally scoped contexts.
In addition to these special purpose allocations, there is a mapped address prefix used to support auto-tunnelling of IPv6 packets over IPv4 in non-NAT contexts.
A 6to4 gateway adds its IPv4 address to this 6to4 prefix, forming the 48 bit address prefix: 2002:w.x.y.z::/48. This prefix is used as the common prefix for all IPv6 client hosts that are serviced in IPv6 from this 6to4 gateway. This is described in RFC 3056.
This is the reserved documentation prefix. Packets should not carry addresses with this prefix in either source or destination fields in the IPv6 packet header.
All other addresses in this range are held by the IANA, and assigned to the Regional Internet Registries on an as-required basis to allow the RIR to have a local pool of addresses from which address assignments can be made.
Assignments from the RIRs to Local Internet Registries or ISPs are made in accordance with prevailing address management policies. Current policies specify a minimum assignment size of a /32 prefix (this was previously a /35). There is no fixed end site prefix size (previously this was a fixed /48 prefix), and it is left to the local practices to assign end site prefixes of an appropriate size between a /48 and a /64. /48 and /56 prefixes are commonly used for end sites.
All Others Reserved
All other addresses in the unicast range are reserved by the IETF for future definition. IPv6 packets should not use addresses from this range in either the source or destination fields in private, scoped or global contexts at this point in time.
This is the IPv6 multicast address prefix, which is used to identify multicast groups. An interface may belong to a number of multicast groups. Multicast addresses must not be used as a source address in an IPv6 packet, only as a destination.
The following 4 bits of this multicast address are flags, defined as follows:
0 must be zero
R defined in RFC3956 – embedded rendezvous point
P defined in RFC3306 – unicast prefix based multicast address
T defined in RFC4291 – 0 = IANA assigned, 1 = Transient
The next 4 bits are a scope identifier, defined as follows:
1 Interface-Local scope
2 Link-Local scope
4 Admin-Local scope
5 Site-Local scope
8 Organization-Local scope
E Global scope
Deprecated IPv6 Addresses
There are a number of IPv6 address prefixes that were assigned in the past, but these assignments have been deprecated for one reason or another, and the addresses have reverted back to their original designation.
::w.x.y.z/128 IPv4 Compatible IPv6 Address
This form of mapped address, where an IPv4 address was padded out to 128 bits in length by the addition of leading zeros was originally thought to be a useful technique in the IPv4 to IPv6 transition. No technique has been devised to use this form of mapped Ipv4 address, and the assignment has deprecated.
This prefix was intended to be used to map certain OSI Network Service Access Point addresses into IPv6 addresses, as defined in RFC1988. This approach was subsequently deprecated (RFC4048) and the assignment of this address prefix was cancelled.
This prefix was used in the second phase of operation of the IPv6 test network, the 6Bone. This experimental network allocation was described in RFC2471. It was shut down as of the 6th June 2006 (RFC3701).
5F00::/8 IPv6 Test Network
This address prefix was used in the first phase of the operation of the IPv6 test network, as described in RFC1897. The assignment was deprecated with the second phase of the IPv6 test network, the 6Bone, RFC2471.
FEC0::/10 Site Local
In earlier versions of the IPv6 address plan this prefix was intended for use in a scoped context that corresponded to a “site”, analogous to the IPv4 private use address prefixes described in RFC1918. This address assignment was deprecated by RFC3879, and the function of scoped addresses has been replaced by Unique Local Address prefixes, described in RFC4193.
IPv6 Registry Lookup
In order to determine the end user of an IPv6 address is necessary to determine which registry holds the assignment information.
The registry that contains the IPv6 address plan is:
IPv6 Address Registry IANA http://www.iana.org/assignments/ipv6-address-space
The Unicast address assignments are contained in the Global Unicast Registry:
Global Unicast Registry IANA http://www.iana.org/assignments/ipv6-unicast-address-assignments
Special Use Address IANA http://www.iana.org/assignments/iana-ipv6-special-registry
The local and mapped IPv6 addresses are mapped as follows:
IPv4 mapped address – lookup IPv4 address w.x.y.z
Unique Local Addresses.
No registry is used for these addresses
Link Local Addresses
No registry is used for these addresses
Bits 33 – 64 of the address contain the Teredo server address
Bits 65 – 80 contain flags:
a Cone NAT flag (C),c
the Universal (U) flag (set to 0),
the Individual/Group (G) flag (set to 0),
a reserved flag (R),
a 12 bit random value (A) used to deflect intrusion attacks.
The field format is: CRAA AAUG AAAA AAAA
Bits 81 – 96 contain the external IPv4 port address, XORed with 1′s
Bits 97 – 128 contain the external IPv4 address XORed with 1′s
For example, the Teredo IPv6 address: 2001:0:cf2e:308c:0:323d:3fa1:c0b0
can be mapped as follows:
Teredo server IPv4 address is cf.2e.30.8c = 22.214.171.124
External Obscured Port of client is 323d = port 52674
External Obscured IP address of client is 3f.a1.c0.cb = 126.96.36.199
Bits 17 – 48 contain the IPv4 address of the 6to4 gateway
For example, the 6to4 address 2002:cb0a:3cdd:1::1
has the IPv4 gateway address of cb.0a.3c.dd = 188.8.131.52
Other addresses are allocated through the RIR system and the corresponding registry lookup for the end user for the address is of the form:
whois -h <whois Registry> <ipv6 address>
whois -h whois.apnic.net 2001:dc0:2001:10:20e:7fff:feac:d687
The following table lists the IPv6 address prefix ranges and the corresponding whois registry where allocation details can be found.
Start Prefix End Prefix whois Registry
2001:0200 2001:03FF whois.apnic.net
2001:0400 2001:05FF whois.arin.net
2001:0600 2001:0BFF whois.ripe.net
2001:0C00 2001:0FFF whois.apnic.net
2001:1200 2001:13FF whois.lacnic.net
2001:1400 2001:3BFF whois.ripe.net
2001:4000 2001:5FFF whois.ripe.net
2001:8000 2001:BFFF whois.apnic.net
2003:0000 2003:3FFF whois.ripe.net
2400:0000 24FF:FFFF whois.apnic.net
2600:0000 260F:FFFF whois.arin.net
2610:0000 2610:01FF whois.arin.net
2620:0000 2620:01FF whois.arin.net
2800:0000 28FF:FFFF whois.lacnic.net
2A00:0000 2AFF:FFFF whois.ripe.net
2C00:0000 2CFF:FFFF whois.afrinic.net
The ISP Column is published as a service to its members. The opinions expressed within do not necessarily represent the views of the Asia Pacific Network Information Centre, nor those of the Internet Society.
About the Author
GEOFF HUSTON holds a B.Sc. and a M.Sc. from the Australian National University. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of a number of Internet-related books, and is currently the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He was a member of the Internet Architecture Board from 1999 until 2005, and served on the Board of the Internet Society from 1992 until 2001.