Skip to main content
Engineering LibreTexts

8.2: IPv6 Addresses

  • Page ID
    11178
  • IPv6 addresses are written in eight groups of four hex digits, with a-f preferred over A-F (RFC 5952 [https://tools.ietf.org/html/rfc5952.html]). The groups are separated by colons, and have leading 0’s removed, eg

    fedc:13:1654:310:fedc:bc37:61:3210

    If an address contains a long run of 0’s – for example, if the IPv6 address had an embedded IPv4 address – then when writing the address the string “::” should be used to represent however many blocks of 0000 as are needed to create an address of the correct length; to avoid ambiguity this can be used only once. Also, embedded IPv4 addresses may continue to use the “.” separator:

    ::ffff:147.126.65.141

    The above is an example of one standard IPv6 format for representing IPv4 addresses (see 8.11   Using IPv6 and IPv4 Together). 48 bits are explicitly displayed; the :: means these are prefixed by 80 0-bits.

    The IPv6 loopback address is ::1 (that is, 127 0-bits followed by a 1-bit).

    Network address prefixes may be written with the “/” notation, as in IPv4:

    12ab:0:0:cd30::/60

    RFC 3513 [https://tools.ietf.org/html/rfc3513.html] suggested that initial IPv6 unicast-address allocation be initially limited to addresses beginning with the bits 001, that is, the 2000::/3 block (20 in binary is 0010 0000).

    Generally speaking, IPv6 addresses consist of a 64-bit network prefix (perhaps including subnet bits) followed by a 64-bit “interface identifier”. See 8.3   Network Prefixes and 8.2.1   Interface identifiers.

    IPv6 addresses all have an associated scope, defined in RFC 4007 [https://tools.ietf.org/html/rfc4007.html]. The scope of a unicast address is either global, meaning it is intended to be globally routable, or link-local, meaning that it will only work with directly connected neighbors (8.2.2   Link-local addresses). The loopback address is considered to have link-local scope. A few more scope levels are available for multicast addresses, eg “site-local” (RFC 4291 [https://tools.ietf.org/html/rfc4291.html]). The scope of an IPv6 address is implicitly coded within the first 64 bits; addresses in the 2000::/3 block above, for example, have global scope.

    Packets with local-scope addresses (eg link-local addresses) for either the destination or the source cannot be routed (the latter because a reply would be impossible).

    Although addresses in the “unique local address” category of 8.3   Network Prefixes officially have global scope, in a practical sense they still behave as if they had the now-officially-deprecated “site-local scope”.

    8.2.1 Interface identifiers

    As mentioned earlier, most IPv6 addresses can be divided into a 64-bit network prefix and a 64-bit “host” portion, the latter corresponding to the “host” bits of an IPv4 address. These host-portion bits are known officially as the interface identifier; the change in terminology reflects the understanding that all IP addresses attach to interfaces rather than to hosts.

    The original plan for the interface identifier was to derive it in most cases from the LAN address, though the interface identifier can also be set administratively. Given a 48-bit Ethernet address, the interface identifier based on it was to be formed by inserting 0xfffe between the first three bytes and the last three bytes, to get 64 bits in all. The seventh bit of the first byte (the Ethernet “universal/local” flag) was then set to 1. The result of this process is officially known as the Modified EUI-64 Identifier, where EUI stands for Extended Unique Identifier; details can be found in RFC 4291 [https://tools.ietf.org/html/rfc4291.html]. As an example, for a host with Ethernet address 00:a0:cc:24:b0:e4, the EUI-64 identifier would be 02a0:ccff:fe24:b0e4 (the leading 00 becomes 02 when the seventh bit is turned on). At the time the EUI-64 format was proposed, it was widely expected that Ethernet MAC addresses would eventually become 64 bits in length.

    EUI-64 interface identifiers turn out to introduce a major privacy concern: no matter where a (portable) host connects to the Internet – home or work or airport or Internet cafe – such an interface identifier always remains the same, and thus serves as a permanent host fingerprint. As a result, EUI-64 identifiers are now discouraged for personal workstations and mobile devices. (Some fixed-location hosts continue to use EUI-64 interface identifiers, or, alternatively, administratively assigned interface identifiers.)

    RFC 7217 [https://tools.ietf.org/html/rfc7217.html] proposes an alternative: the interface identifier is a secure hash (22.6   Secure Hashes) of a “Net_Iface” parameter, the 64-bit IPv6 address prefix, and a host-specific secret key (a couple other parameters are also thrown into the mix, but they need not concern us here). The “Net_Iface” parameter can be the interface’s MAC address, but can also be the interface’s “name”, eg eth0. Interface identifiers created this way change from connection point to connection point (because the prefix changes), do not reveal the Ethernet address, and are randomly scattered (because of the key, if nothing else) through the 264-sized interface-identifier space. The last feature makes probing for IPv6 addresses effectively impossible; see exercise 6.0.

    Interface identifiers as in the previous paragraph do not change unless the prefix changes, which normally happens only if the host is moved to a new network. In 8.7.2.1   SLAAC privacy we will see that interface identifiers are often changed at regular intervals, for privacy reasons.

    Finally, interface identifiers are often centrally assigned, using DHCPv6 (8.7.3   DHCPv6).

    Remote probing for IPv6 addresses based on EUI-64 identifiers is much easier than for those based on RFC-7217 identifiers, as the former are not very random. If an attacker can guess the hardware vendor, and thus the first three bytes of the Ethernet address (2.1.3   Ethernet Address Internal Structure), there are only 224 possibilities, down from 264. As the last three bytes are often assigned in serial order, considerable further narrowing of the search space may be possible. While it may amount to security through obscurity [https://en.wikipedia.org/wiki/Securi...ugh_obscurity], keeping internal global IPv6 addresses hidden is often of practical importance.

    Additional discussion of host-scanning in IPv6 networks can be found in RFC 7707 [https://tools.ietf.org/html/rfc7707.html] and draft-ietf-opsec-ipv6-host-scanning-06 [https://tools.ietf.org/html/draft-ie...t-scanning-06].

    8.2.3 Anycast addresses

    IPv6 also introduced anycast addresses. An anycast address might be assigned to each of a set of routers (in addition to each router’s own unicast addresses); a packet addressed to this anycast address would be delivered to only one member of this set. Note that this is quite different from multicast addresses; a packet addressed to the latter is delivered to every member of the set.

    It is up to the local routing infrastructure to decide which member of the anycast group would receive the packet; normally it would be sent to the “closest” member. This allows hosts to send to any of a set of routers, rather than to their designated individual default router.

    Anycast addresses are not marked as such, and a node sending to such an address need not be aware of its anycast status. Addresses are anycast simply because the routers involved have been configured to recognize them as such.

    IPv4 anycast exists also, but in a more limited form (10.6.8   BGP and Anycast); generally routers are configured much more indirectly (eg through BGP).