For auto-configuration and mobility issues, it was decided to use the lower 64 bits as host part of the address in most of the current address types. Therefore each single subnet can hold a large amount of addresses.
This host part can be inspected differently:
With auto-configuration, the host part of the address is computed by converting the MAC address of an interface (if available), with the EUI-64 method, to a unique IPv6 address. If no MAC address is available for this device (happens e.g. on virtual devices), something else (like the IPv4 address or the MAC address of a physical interface) is used instead.
Consider again the first example
3ffe:ffff:100:f101:210:a4ff:fee3:9566 |
here,
210:a4ff:fee3:9566 |
is the host part and computed from the NIC's MAC address
00:10:A4:E3:95:66 |
using the IEEE-Tutorial EUI-64 design for EUI-48 identifiers.
Because the "automatically computed" host part is globally unique (except when a vendor of a NIC uses the same MAC address on more than one NIC), client tracking is possible on the host when not using a proxy of any kind.
This is a known problem, and a solution was defined: privacy extension, defined in RFC 3041 / Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (there is also already a newer draft available: draft-ietf-ipngwg-temp-addresses-*.txt). Using a random and a static value a new suffix is generated from time to time. Note: this is only reasonable for outgoing client connections and isn't really useful for well-known servers.
For servers it's probably easier to remember simpler addresses, this can also be accommodated. It is possible to assign an additional IPv6 address to an interface, e.g.
3ffe:ffff:100:f101::1 |
For manual suffixes like "::1" shown in the above example it's required that the 7th most significant bit is set to 0 (the universal/local bit of the automatically generated identifier). Also some other (otherwise unchosen ) bit combinations are reserved for anycast addresses, too.