From the 1998 RFC to 40%+ global adoption — a complete technical guide to IPv6 address types, binary structure, SLAAC autoconfiguration, and security implications.
IPv6 development began formally in 1994 when the IETF recognised that IPv4's 4.3 billion address space would be exhausted within a decade or two, given the exponential growth of internet-connected devices. The IPv6 specification (RFC 2460) was published in December 1998. The 128-bit address space provides 340 undecillion addresses — a number so astronomically large that even if every atom on Earth's surface received an address, we'd still have effectively unlimited addresses remaining.
Despite this clear technical necessity, IPv6 adoption was painfully slow through the 2000s, hampered by the chicken-and-egg problem of content providers waiting for users and users waiting for content, compounded by ISPs delaying costly infrastructure upgrades. The tipping point came around 2012-2016, driven primarily by mobile networks (which deployed IPv6 natively from the start) and hyperscalers like Google and Facebook enabling IPv6 by default. By 2025, IPv6 traffic accounts for over 40% of global internet traffic on major networks, with mobile networks in many countries exceeding 70% IPv6.
An IPv6 address consists of 128 bits divided into eight 16-bit groups, each expressed as four hexadecimal digits. The two main sections are the network prefix (typically the first 64 bits) and the interface identifier (the last 64 bits). The prefix identifies the network — assigned hierarchically from IANA to Regional Internet Registries, then to ISPs, then to end organisations. The interface identifier uniquely identifies a device within its network, often derived from the hardware MAC address (via EUI-64) or randomly generated (via SLAAC privacy extensions).
The compressed notation using :: makes IPv6 addresses more readable by omitting consecutive groups of zeros. The tool you're reading about shows both forms: the compressed address as entered, and the full expanded form (a critical tool for debugging where two apparently different addresses might actually be identical).
Unlike IPv4 where the same address space is divided into public, private, and special ranges using somewhat inconsistent historical boundaries, IPv6 has a clean, structured type system embedded in the address prefix. Global Unicast Addresses (beginning with 2000::/3) are the public internet addresses — routable worldwide and the IPv6 equivalent of public IPv4. These are what you'll see when you look up the address of a major website or server.
Link-local addresses (fe80::/10) are automatically configured on every IPv6 interface and are used for local network operations like router discovery and neighbour detection. They're scope-limited to the local link — you can't route them beyond the immediate network segment, and different interfaces on different networks can have identical link-local addresses without conflict. Unique Local Addresses (fc00::/7, commonly fd00::/8 in practice) serve as IPv6's private address space, used within organisations' internal networks without internet routability. Documentation and example addresses (2001:db8::/32) appear in this article and RFC examples — they're reserved and will never appear in production routing tables.
IPv6 changes the security landscape in several important ways. The enormous address space makes simple port scanning of an entire network impractical — while a /24 IPv4 network (256 addresses) can be exhaustively scanned in seconds, a /64 IPv6 subnet (2⁶⁴ addresses) cannot be brute-force scanned in any feasible timeframe. However, this doesn't eliminate IPv6 threats — attackers can still target known addresses from logs and DNS, and the transition mechanisms (6to4, Teredo, ISATAP) used during dual-stack deployments often create unintentional security bypasses if not carefully managed.
One critical security consideration: many firewalls and intrusion detection systems that have mature IPv4 rule sets may have incomplete or missing IPv6 equivalents. Organisations deploying dual-stack networking must ensure their security policies explicitly cover IPv6 traffic — an oversight that has allowed IPv6-based attacks to bypass IPv4-focused firewall rules in documented incidents. Our Blacklist Checker and security tools focus on IPv4 at present; IPv6 reputation systems are a rapidly maturing area of the security landscape.
When operating in a dual-stack environment, several practical points are essential: Always test your application's handling of IPv6 literals in URLs — an IPv6 address in a URL must be enclosed in square brackets (e.g. http://[2001:db8::1]:8080/). Socket programming code that assumes IPv4 address formats will fail with IPv6 and must be updated to use getaddrinfo() or equivalent dual-stack-aware APIs. Log analysis becomes more complex because the same client may connect via either IPv4 or IPv6 in different sessions.
Our IPv6 Lookup tool is useful for validating that your servers' IPv6 addresses geolocate correctly, show the expected ASN and organisation, and have the appropriate address type (Global Unicast for public-facing servers). It's also useful when debugging IPv6 connectivity issues — determining whether a given address is link-local (routing problem), ULA (intentional or accidental private address on public service), or a documentation range used accidentally in production configuration.