Address configuration

The IPv6 address numbering consists of the following potential addresses that may all be present on a device interface:

 Link-local address (LLA) – RFC4291 (Hinden & Deering, 2006)

 Unique-local address (ULA) - RFC4193 (Hinden & Haberman, 2005)

 Global Unicast address (GUA) – RFC4291 (Hinden & Deering, 2006)

 Cryptographically Generated addresses (CGA) RFC3972 (Aura, 2005)

The various IPv6 address types are implemented for specific functionality, for example the Link-local address which facilitates the Neighbour discovery that replaced the ARP functionality and the Unique Local addressing that is used for much the same purpose as the RFC1918 (Rekhter, Moskowitz, Karrenberg, de Groot & Lear, 1996) private address ranges. The LLA is only significant locally in a layer 2 network domain and does not facilitate connectivity between multiple layer 3 domains. Broadcast traffic on the network has been replaced by link-local scope multicast, thereby reducing the amount of broadcast flooding (Biondi, 2007).

Owing to the changes from IPv4 to IPv6 DHCP, the IPv6 address pool management strategy will need to take a new direction. Currently in DHCPv6 there is no provision for a default gateway configuration field. This means that the network gateway configuration is still locally managed by the router advertisement on the layer 2 segment (Jinmei, 2007).

An IPv6 address auto-configuration mechanism has been developed in order to provide either stateful or stateless configuration methodologies or processes. The latter, stateless auto-configuration, allows the host device to generate its own IPv6 address based on a combination of locally available information advertised by the router and a locally significant interface identifier such as the device MAC address for Modified EUI-64 (Jinmei, 2007). In contrast, stateful configuration with DHCPv6 provides managed configuration with a host of configuration options that may include an address and other information, which may be carried by DHCP option values as described in RFC3315 (Droms, Bounds, Volz, Lemon, Perkins & Carney, 2003).

Unlike IPv4, where devices under normal situations only configure a single address, IPv6 configures a number of interface addresses based on the auto - configuration methods provided by the Router advertisement. Interfaces which have IPv6 enabled will always

have a Link-Local address configured, which by combining the fe80::/64 prefix with a 2007). It provided the node with a temporary privacy preserving addressing that could not be tracked. The temporary address does introduce management complexity in enterprise deployment: the privacy provided to the node, reduces the ability of administrators to bind physical assets to their respective IP addresses.

In Table 8 Carrell (2013) documents the various IP address configurations in an IPv6 environment. The configuration options are identified in the ICMPv6 Router advertisement flags.

DHCPv6 provides managed address configuration and supplementary information to the router auto-configuration. The protocol is based on ICMPv6 and is able to supply additional information such as DNS, domain name, download servers and NTP servers to the client devices - as specified in RFC 3315 (Droms et al., 2003).

2.6.1 Link-local address

The node generates the Link-local address when an interface that has IPv6 capabilities is enabled. As described in RFC 4862 (Jinmei, 2007) in section 5.3, the interface address is formed by combining the FE80::0/10 Link-local prefix which is defined by Hinden and Deering (2006) and a modified IEEE EUI-64 identifier which has the inverted “u” bit. The EUI-64 process is well defined in Appendix A of RFC 4291 (Hinden & Deering, 2006, Appendix A) and illustrates how the MAC is used to populate 48bits of the identifier and the shim of hexadecimal numbers 0xFF and 0xFE are inserted before the 25^th bit.

2.6.2 Unique-local address

The Unique-local address is best compared to the RFC1918 private addresses in IPv4 which are used in private environments and behind NAT perimeter devices. The address prefix fc00::/7 has been allocated to the address type and is not routed on the global IPv6 Internet.

This address space has been defined in RFC 4193 (Hinden & Haberman, 2005) for use in private sites and can span multiple sites where the traffic is privately routed, or tunnelled and does not travers the public boundary. The use case for NAT may still exist in certain enterprises, and for this reason, this address space can be used in conjunction with ratified frameworks for IPv4/IPv6 translation such as RFC 6411 (Baker, Li, Bao & Yin, 2011) and contentious⁶ RFC 6296 (Wasserman & Baker, 2011) .

2.6.3 Global unicast address

The Global unicast address is the IPv6 space that is routed for normal use on the IPv6 Internet which consists of the 2001::/3 network. This is defined in RFC 4291 (Hinden &

Deering, 2006) which rendered RFC 3513 obsolete.

2.6.4 Temporary/Privacy address

The Stateless Address Autoconfiguration (SLAAC) method of assigning addresses using a unique interface identifier i.e. the device’s unique MAC address which is used in the Modified EUI-64 format, has been presented as a potential leak for personally identifiable information. According to Nour El-Kadri and Sowmyan Jegatheesan, privacy issues will complicate the use of IPv6 owing to the inclusion of a globally significant fixed identifier

6 As described by Tom Hollingsworth in the Networking Nerd blog (Hollingsworth, 2011)

(Individually identifiable information) that can form a part of a node’s global IP address.

By using the Identifiable information, Internet services will be able to track a device and therefore its user across various disparate networks, regardless of the network Prefix (Oliphant, 2011; El-kadri & Jegatheesan, 2013).

To prevent Individually identifiable information from being linked to the IPv6 address, RFC 4941 (Narten et al., 2007) was proposed in order to provide a temporary address that could be used from which to initiate connections. The temporary address is generated generated using a pseudo-random address suffix that is used in the SLAAC process to configure the interface. Although the pseudo-random address provides an abstracted address, it is important to refresh the interface and deprecated the previous address, which removes the value of tracking the address. As the addresses are refreshed, the open connections should still continue, and the newly generated address should be used for any new connections from the device.

2.6.5 Cryptographically generated address

The lack of attribution and repudiation in network traffic formed the base requirement for CGA as standardised in RFC 3972 (Aura, 2005). The address is generated as part of the SEcure Neighbour Discovery (SEND) protocol, described in RFC 3971 (Arkko, Kempf, Zill & Nikander, 2005).

Using the Secure Hashing Algorithm (SHA-1) one-way hash in conjunction with a public key (and other auxiliary information) the address is cryptographically generated. The SEND protocol has not been widely adopted as it requires a trusted central certificate authority, such as Microsoft CA and can be used in layer 2 attacks. This element will be discussed in section 3.1.