IPv4 to IPv6 Converter
Network engineers migrating dual-stack services, cloud architects wiring NAT64/DNS64 gateways, and developers reading Kubernetes or systemd logs all hit the same problem: an IPv4 address appears in a context that expects IPv6, and the correct embedding is not obvious. This tool converts any dotted-quad into IPv4-mapped (::ffff:), NAT64 (64:ff9b::), 6to4 (2002::), or a custom RFC 6052 prefix, with both RFC 5952 compressed and full uncompressed text plus the reverse ip6.arpa record. Private and special-use ranges are flagged so you never publish a non-routable embedding by accident.
—
—
—
Reverse: IPv6 → IPv4
Paste an IPv6 address with a recognized embedding (::ffff:, 64:ff9b::, or 2002::) to extract the embedded IPv4.
How the Converter Embeds IPv4 into IPv6
The dotted-quad is parsed into a 32-bit integer (BigInt to avoid sign issues). Depending on the selected style, the tool writes that integer into the last 32 bits of a 128-bit address after placing the appropriate prefix in the upper 96 bits. IPv4-mapped writes 0000:0000:0000:0000:0000:ffff followed by the IPv4; NAT64 writes 0064:ff9b:0000:0000:0000:0000 followed by the IPv4; 6to4 writes 2002 followed by the IPv4 and 48 bits of zeros. A custom prefix accepts 1–6 hex groups and pads with zeros to fill the 96-bit slot before appending the embedded address.
The 128-bit result is then formatted twice: once as full 8-group uncompressed hex (each group zero-padded to 4 digits) and once with RFC 5952 compression — lowercase hex, leading zeros stripped, and the longest run of two or more zero groups replaced by ::. The reverse ip6.arpa string is built by expanding the address to 32 hex nibbles, reversing the nibble order, and joining with dots before appending .ip6.arpa. A separate classification pass checks the IPv4 against RFC 1918, loopback, link-local, and carrier-grade NAT ranges and surfaces a warning when the embedding is non-routable.
When to use each style
Use IPv4-mapped when reading dual-stack socket dumps or explaining ::ffff: addresses in application logs. Use NAT64 when configuring DNS64 resolvers or documenting IPv6-only client connectivity. 6to4 is historical only. A custom prefix is useful for lab setups that mirror an ISP’s own RFC 6052 allocation.
Parsing compressed IPv6 on the reverse path
The reverse parser splits on ::, expands the head and tail group lists, and fills the middle with the correct number of zero groups so the total is always 8. It also accepts a dotted-quad tail (::ffff:192.0.2.1) which is common in log output. Malformed inputs (too many ::, group values > 0xffff, non-hex characters) return null with an explanatory error instead of guessing.
Before and after: fixing a dual-stack socket log
2026-01-05T12:00:00Z accept
from=[::ffff:203.0.113.45]:51234
to=[::ffff:192.168.1.10]:443
// Which client is this? Is 192.168.1.10 routable?Client (IPv4-mapped): ::ffff:203.0.113.45
→ 203.0.113.45 (Public unicast)
Server (IPv4-mapped): ::ffff:c0a8:1a
→ 192.168.1.10 (Private RFC 1918 — not routable)
ip6.arpa for client:
5.4.3.1.1.0.3.2.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpaUse Cases
| Developer | Production | Workflow |
|---|---|---|
| Interpret ::ffff: addresses in application or proxy logs | Configure DNS64 resolvers with 64:ff9b::/96 embeddings | Audit firewall rules that reference dual-stack peers |
| Generate ip6.arpa PTR records for a new IPv6 range | Document NAT64 gateway addressing for an IPv6-only VPC | Explain 6to4 addresses found in archived configs |
| Validate custom RFC 6052 prefixes before writing Terraform | Flag private-range embeddings in published documentation | Convert a batch of IPv4 allowlists for a dual-stack ACL |
Common Mistakes
- Publishing an IPv4-mapped address as if it were a public IPv6 address. ::ffff:203.0.113.45 is not routable on the IPv6 Internet; it only exists inside a dual-stack socket. Use the embedded IPv4 (203.0.113.45) for external ACLs or firewall rules.
- Using 6to4 (2002::) for new deployments. The global 6to4 relay network has been decommissioned; traffic will black-hole. Prefer native IPv6 or NAT64/DNS64 for transition.
- Ignoring RFC 5952 when pasting addresses into configs. Some parsers accept non-compressed forms, but diffs and logs become unreadable; always normalize to the compressed lowercase form before committing.
- Assuming every IPv6 address contains an embedded IPv4. Only the mapped, NAT64, and 6to4 prefixes do. Arbitrary addresses like 2001:db8::1 are native IPv6 and cannot be reduced to a dotted-quad.
- Forgetting the reverse ip6.arpa zone when adding PTR records. Forward A and AAAA entries without matching PTR break rDNS checks that mail servers and some APIs rely on.
- Embedding a private IPv4 (10.x, 172.16–31.x, 192.168.x) into a NAT64 prefix for documentation. The result is non-routable and confuses readers; use a documentation prefix like 2001:db8::/32 instead.
Best Practices
- Standardize on RFC 5952 compressed text in all configs, logs, and runbooks. Enable a formatter in your CI so hand-typed addresses are normalized automatically.
- Use the reverse ip6.arpa output when adding PTR records. Generate it alongside the AAAA record so forward and reverse stay in sync.
- Prefer IPv4-mapped for internal dual-stack representation; reserve NAT64 for actual transition gateways; avoid 6to4 entirely for new designs.
- Flag private-range embeddings in any public documentation or Terraform state. The generator’s warning pass already does this — treat the warning as a release blocker.
- When writing firewall or security-group rules, extract the embedded IPv4 and write the rule in IPv4 form if the rule engine is dual-stack; do not rely on the mapped IPv6 form alone.
- For bulk conversions, script the same logic used here (parse → BigInt → prefix + embed → RFC 5952 compress) in your pipeline so local previews match production automation.
Frequently Asked Questions
What is an IPv4-mapped IPv6 address?
An IPv4-mapped IPv6 address has the form ::ffff:a.b.c.d (or the expanded 0000:0000:0000:0000:0000:ffff:a.b.c.d). Dual-stack sockets use it internally to represent an IPv4 peer in a 128-bit slot, so an application written for IPv6 can still talk to IPv4-only hosts without a separate code path. These addresses are not routable on the public IPv6 Internet; they only exist inside the host’s address representation.
What is NAT64 and when would I embed an IPv4 into 64:ff9b::?
NAT64 is a transition mechanism that lets IPv6-only clients reach IPv4 servers. The well-known prefix 64:ff9b::/96 (RFC 6052) reserves the last 32 bits for the embedded IPv4 address, so 64:ff9b::192.0.2.1 represents the IPv4 host 192.0.2.1. You will see this form in DNS64 resolver outputs and in documentation for IPv6-only mobile networks. The generator uses the standard 64:ff9b:: prefix by default.
Should I still use 6to4 (2002::/16) addresses?
No. 6to4 (RFC 3056) embeds an IPv4 address in the 2002::/16 prefix, but the global 6to4 relay network has been decommissioned because of reliability and security problems. The generator can still produce the form for reading old logs or understanding legacy configurations, but do not deploy it for new systems. Prefer native IPv6, or NAT64/DNS64 when you need a transition mechanism.
What does the ip6.arpa reverse record represent?
ip6.arpa is the reverse-DNS zone for IPv6 addresses. Each hex digit of the 32-nibble address is written as a label in reverse order, terminated by .ip6.arpa. For ::ffff:192.0.2.1 the record is 1.2.0.0.9.f.f.f.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. The generator emits this string automatically so you can paste it into a PTR zone file.
Why does RFC 5952 compression matter?
RFC 5952 defines the canonical text representation of IPv6 addresses: lowercase hex, leading zeros stripped, and the longest run of zero groups replaced with :: (only when the run is two or more groups). Every compliant tool — dig, ipcalc, Kubernetes logs — emits this form, so matching it makes your configs and logs diffable and searchable. The generator always outputs RFC 5952 compressed text alongside the full uncompressed form.
Can I convert an IPv6 address back to IPv4?
Yes, if the IPv6 address was created with a recognized embedding — IPv4-mapped (::ffff:), NAT64 (64:ff9b::), or 6to4 (2002::). The generator parses the IPv6 input, detects the pattern, and extracts the embedded 32-bit address. Arbitrary IPv6 addresses without a known embedding cannot be reduced to IPv4; the tool returns null in that case and you should treat the address as native IPv6.
Do private IPv4 ranges convert to routable IPv6?
No. An address like 192.168.1.10 is RFC 1918 private space; its mapped form ::ffff:c0a8:a is only meaningful inside your own network or lab. The generator flags private, loopback, link-local, and carrier-grade NAT ranges with a warning so you do not accidentally publish a non-routable embedding in production config or documentation.