BestUtilitiesORG
RFC 4291 • RFC 6052 • Dual-Stack Transition Standards

IPv4 to IPv6 Transition & Embedding Tool

Convert standard dotted-decimal IPv4 addresses into all standardized dual-stack IPv6 embeddings: IPv4-Mapped (::ffff:), NAT64 (64:ff9b::), and 6to4 prefixes with instant clipboard copying.

100% In-Browser Bitwise Transition Engine • Zero Server Logging
RFC 4291 • RFC 6052 • RFC 3056

IPv4 to IPv6 Transition & Embedding Tool

Embed legacy IPv4 addresses into standard dual-stack IPv6 formats (IPv4-Mapped, NAT64, 6to4, ISATAP).

Presets:
32-Bit Bitwise Decomposition
Octet 1
192
0xC0
11000000
Octet 2
0
0x00
00000000
Octet 3
2
0x02
00000010
Octet 4
33
0x21
00100001
IPv6 Lower 32-bit Hextet Pair: c000:022132-bit Hex: c0000221
IPv4-Mapped IPv6 (RFC 4291)
Dual-Stack Sockets
::ffff:192.0.2.33
::ffff:c000:0221

Used by operating systems to represent an IPv4 node as an IPv6 socket address. Begins with 80 bits of zeros, 16 bits of ones (::ffff:), and the 32-bit IPv4 address.

NAT64 Well-Known Prefix (RFC 6052)
64:ff9b::/96
64:ff9b::192.0.2.33
64:ff9b::c000:0221

Used by Stateful NAT64 and DNS64 translators to allow IPv6-only clients (e.g. cellular carriers and cloud VPCs) to communicate with legacy IPv4-only Internet services.

6to4 Tunneling Prefix (RFC 3056)
2002::/16
2002:c000:0221::/48
2002:c000:0221:1::1

Allocates a dedicated /48 IPv6 prefix to any public IPv4 address by prepending 2002: to the 32-bit hex address for automated tunneling over IPv4 backbones.

ISATAP Link-Local (RFC 5214)
Intra-Site Tunneling
fe80::5efe:192.0.2.33
fe80::0:5efe:c000:0221

Intra-Site Automatic Tunnel Addressing Protocol embeds IPv4 inside an interface identifier using the standard :5efe: marker for dual-stack LAN coexistence.

Sponsored Diagnostic PartnerCLS = 0 Guaranteed
Ad Space (responsive) • Slot: ipv4-to-ipv6-converter-banner-ad

Reserved banner container configured with strict Core Web Vitals CLS = 0 layout preservation.

Dual-Stack Transition: Why IPv4 Addresses Are Embedded in IPv6

The global transition from IPv4 to IPv6 is not an instantaneous overnight migration. Instead, both protocols have coexisted for over a decade under a framework known as dual-stack deployment. Because IPv4 addresses are 32 bits wide and IPv6 addresses are 128 bits wide, the Internet Engineering Task Force (IETF) standardized several mathematical methods for embedding a 32-bit legacy IPv4 address into specific portions of a 128-bit IPv6 address.

These embedding mechanisms serve critical functions across modern cloud architectures: enabling operating system network stacks to accept both protocols over a single listening socket, allowing IPv6-only mobile phones to access legacy IPv4 web servers, and establishing automated point-to-point tunnels across public Internet backbones.

The Four Standardized IPv4-in-IPv6 Formats

1. IPv4-Mapped IPv6 (RFC 4291)

Written as ::ffff:192.0.2.33 or ::ffff:c000:0221. This format allows dual-stack network socket applications (such as Node.js, Go, or Java servers) to listen on an AF_INET6 socket and accept incoming TCP connections from legacy IPv4 clients without creating separate IPv4 sockets.

2. NAT64 Well-Known Prefix (RFC 6052)

Written as 64:ff9b::192.0.2.33 (or 64:ff9b::c000:0221). Utilized by stateful NAT64 gateways and DNS64 resolvers. When an IPv6-only device attempts to contact an IPv4-only domain, the DNS64 synthesizer prepends the 64:ff9b::/96 prefix to the IPv4 address so the traffic can be routed through a translation gateway.

3. 6to4 Anycast Tunneling (RFC 3056)

Written as 2002:c000:0221::/48. Any publicly routable IPv4 address is automatically granted an entire /48 IPv6 network prefix (yielding 65,536 /64 subnets). The 32-bit IPv4 address is converted directly into hexadecimal and inserted into the second and third hextets of the 2002::/16 prefix.

4. ISATAP Link-Local (RFC 5214)

Written as fe80::5efe:192.0.2.33. Designed for dual-stack nodes on an enterprise intranet that need to tunnel IPv6 packets over an IPv4 LAN infrastructure. The interface identifier includes the 16-bit marker 0000:5efe: followed by the IPv4 address.

Step-by-Step Bitwise Conversion Math

Converting an IPv4 dotted-decimal address into an IPv6 hex representation requires breaking the 4 decimal octets into two 16-bit hextets:

  1. Convert each octet to an 8-bit hexadecimal number: For example, with 192.0.2.33:
    • 192 = 0xC0 (11000000)
    • 0 = 0x00 (00000000)
    • 2 = 0x02 (00000010)
    • 33 = 0x21 (00100001)
  2. Pair the octets into 16-bit words:Combine octets 1 and 2 to form the upper word: 0xC000. Combine octets 3 and 4 to form the lower word: 0x0221.
  3. Format into standard IPv6 notation:The combined 32-bit segment is written as c000:0221.

Frequently Asked Questions (FAQ)

What is the difference between IPv4-Mapped and IPv4-Compatible addresses?

IPv4-Mapped addresses (::ffff:192.0.2.33) contain 16 bits of ones (ffff) and are actively supported by all modern operating systems for dual-stack sockets. In contrast, IPv4-Compatible addresses (::192.0.2.33) consisted of 96 leading zeros and have been deprecated by RFC 4291.

Can I route ::ffff:192.0.2.1 across the public Internet?

No. IPv4-mapped IPv6 addresses are strictly internal operating system representations for API compatibility. Internet routers will drop packets addressed to ::ffff:0:0/96 because they are non-routable on the public IPv6 backbone.

What is NAT64 and why is the 64:ff9b::/96 prefix important?

NAT64 is an IETF transition technology defined in RFC 6146. When an IPv6-only network (such as Apple iOS or AWS IPv6-only VPCs) needs to communicate with IPv4 servers, the system routes packets destined for the Well-Known Prefix 64:ff9b::/96 through a stateful translator that dynamically maps IPv6 headers into IPv4 packets.