 bound to a specific network (unless Mobile IPv4 is used [162]). However, with IPv6 and SLAAC, a node can create an IPv6 address by using an IID derived from network interface's unique identifier (see Section 3.1.6), such as the link layer's MAC address [73]. The MAC addresses are usually burned into hardware and hence very static in nature. The problem with hardware- derived IIDs is that even if the node's point of network attachment changes, and an IPv6 prefix changes, the IID remains static! Hence with IPv6, it is possible to track a node in the Internet even when node a changes its point of network attachment (the tracking would ignore IPv6 prefixes and just track IIDs). The solution for this problem, in the case of SLAAC, is presented in RFC 4941 [11]. This RFC introduces the concept of Temporary Addresses, which are used only for a short while - from hours to days - after which a new Temporary Address is generated. In some networks, IPv6 address changing nodes can become problematic for the network administrators, for example, if access control lists require IPv6 address informa- tion [98]. The problems related to combining needs for privacy and management calls for additional solutions. IETF is currently working on stable but privacy enhanced addresses for SLAAC. This solution proposes an algorithm to generate IIDs in a manner that results in constant IIDs within each subnet. The algorithm takes a set of input parameters, includ- ing a network prefix, a secret key, a network identifier, such as Service Set Identifier (SSID), the interface index, and the DAD counter. The algorithm produces a random looking result, which is very hard to guess, but is always the same given the same input parameters. This solution of 'stable privacy enhanced addresses' is still at the working group stage, and may significantly change prior to publication as standard. The tracking enabled by static addressing is not only a problem with SLAAC, but can also appear to a lesser extent with other address allocation schemes. For exam