About

Every IPv4 address can be represented as an IPv6 address through well-defined mapping mechanisms specified in RFC 4291 and RFC 6052. The most common is the IPv4-mapped IPv6 address, which embeds the 32-bit IPv4 address in the lower 32 bits of a 128-bit IPv6 address, prefixed by 80 zero bits and 16 one bits (::ffff:). A misconfigured mapping leads to routing failures, broken dual-stack applications, and DNS resolution errors that are notoriously difficult to debug. This tool computes four distinct representations: the full expanded 128-bit notation, the RFC 5952 compressed form, the mixed notation preserving dotted-decimal readability, and the 6to4 tunnel address (prefix 2002:: per RFC 3056). It validates each octet against the 0 - 255 range and rejects malformed input before conversion. The tool approximates standard mapping behavior and does not account for NAT64 prefix customization or provider-specific Teredo server addresses.

Formulas

An IPv4 address A.B.C.D maps to a 128-bit IPv6 address as follows:

IPv6_mapped = 0000:0000:0000:0000:0000:ffff:hex(A)hex(B):hex(C)hex(D)

Each octet is converted to its 2-digit hexadecimal equivalent:

hex(octet) = octet.toString(16).padStart(2, "0")

For the 6to4 representation (RFC 3056):

Compression (RFC 5952) removes leading zeros from each group and replaces the longest consecutive run of all-zero groups with ::. Only one :: is permitted per address.

Where A, B, C, D = decimal octets, each ∈ [0, 255]. ffff = the 16-bit marker indicating an IPv4-mapped address.

Reference Data

IPv6 Notation Type	Format Example	RFC	Use Case
Full Expanded	0000:0000:0000:0000:0000:ffff:c0a8:0101	RFC 4291	Canonical storage, log parsing
Compressed (RFC 5952)	::ffff:c0a8:101	RFC 5952	Configuration files, display
Mixed Notation	::ffff:192.168.1.1	RFC 4291 §2.2	Dual-stack sockets, readability
6to4 Tunnel	2002:c0a8:0101::	RFC 3056	6to4 relay routing
Teredo (Template)	2001:0000:<server>:<flags>:<port>:<client>	RFC 4380	NAT traversal tunneling
IPv4-Compatible (Deprecated)	::192.168.1.1	RFC 4291	Historic, not recommended
NAT64 Well-Known Prefix	64:ff9b::192.168.1.1	RFC 6052	Stateful NAT64 translation
Loopback IPv4	127.0.0.1 → ::ffff:7f00:1	-	Local testing
Broadcast IPv4	255.255.255.255 → ::ffff:ffff:ffff	-	Edge case validation
Private Class A	10.0.0.0 - 10.255.255.255	RFC 1918	Internal networks
Private Class B	172.16.0.0 - 172.31.255.255	RFC 1918	Internal networks
Private Class C	192.168.0.0 - 192.168.255.255	RFC 1918	Home / small office
APIPA	169.254.0.0 - 169.254.255.255	RFC 3927	Link-local auto-config
Multicast	224.0.0.0 - 239.255.255.255	RFC 5771	Group communication
IPv4 Address Space	32 bits → ~4.3 billion	-	Exhausted (IANA 2011)
IPv6 Address Space	128 bits → ~3.4 × 10³⁸	-	Effectively unlimited

Frequently Asked Questions

An IPv4-mapped address uses the prefix ::ffff: (80 zero bits + 16 one bits) before the embedded IPv4 octets (RFC 4291). An IPv4-compatible address uses :: (96 zero bits) as prefix. IPv4-compatible addresses are deprecated since RFC 4291 §2.5.5.1 and should not be used in new implementations. This tool generates the mapped form by default as it is the current standard for dual-stack operation.

Yes. The conversion is purely mathematical - the mapping embeds any valid 32-bit IPv4 address regardless of its allocation class. A private address like 192.168.1.1 maps to ::ffff:c0a8:101. However, this mapped address has no global routability in IPv6 space. For actual IPv6 connectivity from private networks, you need ULA (Unique Local Addresses, fc00::/7) or proper global prefix delegation from your ISP.

RFC 5952 defines the canonical text representation of IPv6 addresses. Three rules: (1) leading zeros in each 16-bit group are removed (0042 becomes 42), (2) the longest sequence of consecutive all-zero groups is replaced with :: (ties broken by first occurrence), (3) only one :: is permitted. This matters because inconsistent formatting causes string comparison failures in ACLs, firewall rules, and log analysis tools. Always store and compare IPv6 addresses in their canonical compressed form.

A 6to4 address (RFC 3056) encodes an IPv4 address in the prefix 2002:XXYY:ZZWW::/48, where XXYY:ZZWW is the hex representation of the IPv4 address. It enables IPv6 packets to be tunneled over IPv4 infrastructure without explicit tunnel configuration. However, 6to4 has been largely deprecated in favor of native dual-stack or DS-Lite. IETF published RFC 7526 recommending against its use due to reliability problems with relay routers.

The tool strips CIDR suffix before conversion and processes only the host address portion. A /24 IPv4 prefix maps conceptually to a /120 in the IPv4-mapped IPv6 space (96 prefix bits + 24 network bits = 120). If you need subnet calculations, perform them separately on the IPv4 side first, then convert individual addresses.

Dual-stack sockets (AF_INET6 with IPV6_V6ONLY disabled) automatically wrap incoming IPv4 connections in IPv4-mapped IPv6 format. So localhost via IPv4 appears as ::ffff:127.0.0.1, while a native IPv6 loopback connection shows ::1. These are distinct addresses. If your application logic compares them as strings, it will fail. Normalize by extracting the embedded IPv4 address or comparing at the binary level.