Skip to main content
Engineering LibreTexts

8.3: Network Prefixes

  • Page ID
    11177
  • We have been assuming that an IPv6 address, at least as seen by a host, is composed of a 64-bit network prefix and a 64-bit interface identifier. As of 2015 this remains a requirement; RFC 4291 [https://tools.ietf.org/html/rfc4291.html] (IPv6 Addressing Architecture) states:

    For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long….

    This /64 requirement is occasionally revisited by the IETF, but is unlikely to change for mainstream IPv6 traffic. This firm 64/64 split is a departure from IPv4, where the host/subnet division point has depended, since the development of subnets, on local configuration.

    Note that while the net/interface (net/host) division point is fixed, routers may still use CIDR (10.1   Classless Internet Domain Routing: CIDR) and may still base forwarding decisions on prefixes shorter than /64.

    As of 2015, all allocations for globally routable IPv6 prefixes are part of the 2000::/3 block.

    IPv6 also defines a variety of specialized network prefixes, including the link-local prefix and prefixes for anycast and multicast addresses. For example, as we saw earlier, the prefix ::ffff:0:0/96 identifies IPv6 addresses with embedded IPv4 addresses.

    The most important class of 64-bit network prefixes, however, are those supplied by a provider or other address-numbering entity, and which represent the first half of globally routable IPv6 addresses. These are the prefixes that will be visible to the outside world.

    IPv6 customers will typically be assigned a relatively large block of addresses, eg /48 or /56. The former allows 64−48 = 16 bits for local “subnet” specification within a 64-bit network prefix; the latter allows 8 subnet bits. These subnet bits are – as in IPv4 – supplied through router configuration; see 8.10   IPv6 Subnets. The closest IPv6 analogue to the IPv4 subnet mask is that all network prefixes are supplied to hosts with an associated length, although that length will almost always be 64 bits.

    Many sites will have only a single externally visible address block. However, some sites may be multihomed and thus have multiple independent address blocks.

    Sites may also have private unique local address prefixes, corresponding to IPv4 private address blocks like 192.168.0.0/16 and 10.0.0.0/8. They are officially called Unique Local Unicast Addresses and are defined in RFC 4193 [https://tools.ietf.org/html/rfc4193.html]; these replace an earlier site-local address plan (and official site-local scope) formally deprecated in RFC 3879 [https://tools.ietf.org/html/rfc3879.html] (though unique-local addresses are sometimes still informally referred to as site-local).

    The first 8 bits of a unique-local prefix are 1111 1101 (fd00::/8). The related prefix 1111 1100 (fc00::/8) is reserved for future use; the two together may be consolidated as fc00::/7. The last 16 bits of a 64-bit unique-local prefix represent the subnet ID, and are assigned either administratively or via autoconfiguration. The 40 bits in between, from bit 8 up to bit 48, represent the Global ID. A site is to set the Global ID to a pseudorandom value.

    The resultant unique-local prefix is “almost certainly” globally unique (and is considered to have global scope in the sense of 8.2   IPv6 Addresses), although it is not supposed to be routed off a site. Furthermore, a site would generally not admit any packets from the outside world addressed to a destination with the Global ID as prefix. One rationale for choosing unique Global IDs for each site is to accommodate potential later mergers of organizations without the need for renumbering; this has been a chronic problem for sites using private IPv4 address blocks. Another justification is to accommodate VPN connections from other sites. For example, if I use IPv4 block 10.0.0.0/8 at home, and connect using VPN to a site also using 10.0.0.0/8, it is possible that my printer will have the same IPv4 address as their application server.