🌐 IPv4-Mapped IPv6 Converter – RFC 4291 §2.5.5.2 Reference Tool
The IPv4-Mapped IPv6 Converter translates standard dotted-decimal IPv4 addresses into their IPv4-mapped IPv6 representation — and reverses the process. This notation, defined in RFC 4291 §2.5.5.2, is the standard mechanism used by dual-stack operating systems and socket APIs to bridge IPv4 and IPv6 address spaces without requiring two separate sockets or listeners.
📐 What Is an IPv4-Mapped IPv6 Address?
An IPv4-mapped IPv6 address is a 128-bit IPv6 address that encodes a 32-bit IPv4 address in its lower bits. The structure is always:
| 80 bits (all zero) | 16 bits (0xFFFF) | 32-bit IPv4 address |
| :: | ffff: | a.b.c.d |For example, the IPv4 address 192.168.1.1 becomes ::ffff:192.168.1.1 in compressed notation, or 0000:0000:0000:0000:0000:ffff:c0a8:0101 in its full 128-bit expanded form.
🔄 Supported Conversion Modes
IPv4 → IPv4-Mapped IPv6
Enter any valid IPv4 address and the tool outputs three equivalent IPv6 representations:
| Notation | Example |
|---|---|
| Compressed | ::ffff:192.168.1.1 |
| Expanded (128-bit) | 0000:0000:0000:0000:0000:ffff:c0a8:0101 |
| Hex-Segment | ::ffff:c0a8:0101 |
IPv4-Mapped IPv6 → IPv4
Paste any ::ffff:a.b.c.d or ::ffff:XXXX:YYYY address and the tool automatically extracts the original dotted-decimal IPv4. It accepts both the compressed and hex-segment forms as input.
🔬 How the Conversion Works
IPv4 → IPv6-mapped: The four IPv4 octets [w, x, y, z] are split into two 16-bit pairs. Each pair is expressed as a 4-digit hex group: wx and yz. These are appended after ::ffff: to form the hex-segment notation. Zero-padding all 128 bits yields the fully expanded form.
IPv6-mapped → IPv4: The tool verifies that bits 0–79 are zero and bits 80–95 equal 0xFFFF, then extracts the final 32 bits and converts them back to dotted-decimal. Inputs in hex-segment notation (::ffff:c0a8:0101) are handled identically.
⚠️ IPv4-Mapped vs. IPv4-Compatible Addresses
::x.x.x.x form (no ffff block) is the IPv4-compatible address defined in RFC 4291 §2.5.5.1. It was used in early IPv6 transition experiments and is now deprecated — modern dual-stack systems do not use it. This tool supports displaying it for historical and educational purposes only (enable "Show IPv4-Compatible" toggle).🖥️ Why Dual-Stack Servers Show ::ffff: Addresses
When a Linux, BSD, macOS, or Windows server opens an AF_INET6 socket and accepts an incoming IPv4 connection, the kernel automatically maps the client's IPv4 address to the ::ffff:a.b.c.d format. The application then sees a single unified address family regardless of whether the peer used IPv4 or IPv6. This is why server logs often contain addresses like ::ffff:10.0.0.1 — they represent real IPv4 clients connected through a dual-stack listener.
📦 Batch Conversion
The batch mode accepts multiple IPv4 or IPv6-mapped addresses — one per line — and converts all of them at once. Results are displayed in a structured table showing the original input, compressed IPv6, expanded IPv6, hex-segment form, extracted IPv4, and address-type classification. The full batch can be downloaded as a CSV file for use in spreadsheets, scripts, or network documentation.
🏷️ Address Type Classification
Each converted address is automatically classified into one of the following categories based on the embedded IPv4 prefix:
| Type | IPv4 Range | Common Use |
|---|---|---|
| Loopback | 127.0.0.0/8 | Local host testing |
| Private | 10/8, 172.16/12, 192.168/16 | LAN / internal networks |
| Link-Local | 169.254.0.0/16 | Auto-assigned (no DHCP) |
| Documentation | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | RFC examples |
| Multicast | 224.0.0.0/4 | Group communication |
| Public | All other addresses | Internet-routable |
🔢 Binary Representation
Enabling the Show Binary toggle displays the full 128-bit binary breakdown of the address, colour-coded by segment:
Gray — 80-bit zero prefix: always 00000000 × 10
Orange — 16-bit 0xFFFF marker: 11111111 11111111
Blue — 32-bit IPv4 payload: four octets in binary, separated by dots
📚 RFC References
This tool implements the address formats defined in RFC 4291 – IP Version 6 Addressing Architecture:
- §2.5.5.2 — IPv4-Mapped IPv6 Address (
::ffff:a.b.c.d) — current standard for dual-stack socket programming - §2.5.5.1 — IPv4-Compatible IPv6 Address (
::a.b.c.d) — deprecated; shown for historical reference only
💡 Common Use Cases
- Server log analysis — decode
::ffff:entries from nginx, Apache, or application logs back to plain IPv4 - Firewall rules — generate IPv4-mapped forms when writing iptables / nftables rules for dual-stack interfaces
- Socket programming — verify addresses returned by
getpeername()oraccept()in C, Go, or Python networking code - IPv6 migration planning — understand how existing IPv4 services will appear to IPv6 clients during a dual-stack transition period
- Security auditing — identify whether a logged IPv6 address is truly native IPv6 or an embedded IPv4 connection that warrants different ACL treatment