skip to content

Why can an IPv6-only host not talk directly to an IPv4-only host, and which three families of transition mechanism bridge the gap?

level: juniorimportance: must knowfreq 42%

answer

  1. two headers, two address spaces
  2. run both, wrap one, rewrite one
  3. tunnels join like to like
  4. only translation crosses families

basics

~20 s

IPv4 and IPv6 are separate protocols with different headers and address sizes, so neither stack can read the other's packets. Coexistence comes from dual stack (run both), tunnelling (carry IPv6 inside IPv4) or translation (NAT64 rewriting headers).

solid answer

~40 s

IPv6 is not an extension of IPv4: the version number, the fixed 40-byte header and the 128-bit addresses are all different, and an IPv4-only node simply does not understand IPv6. So there are three ways to make them coexist. **Dual stack** (RFC 4213) gives a node both protocols and lets it use whichever the destination supports. **Tunnelling** wraps IPv6 packets inside IPv4 (IP protocol 41, or UDP for Teredo) to join IPv6 islands across an IPv4-only network, but both ends still speak IPv6. **Translation** — stateful NAT64 (RFC 6146) with DNS64 (RFC 6147), and 464XLAT (RFC 6877) on top — rewrites headers between the two, and it is the only family that lets an IPv6-only client reach an IPv4-only server.

go deeper

for a junior

Recall that IPv4 and IPv6 are different protocols on the wire, then name the three families — dual stack, tunnelling, translation — with one sentence on what each does.

for a middle

Explain who can reach whom under each family: tunnels join IPv6 to IPv6 across IPv4, and only translation connects an IPv6-only client to an IPv4-only server.

for a senior

Show the costs that drive the choice: dual stack keeps IPv4 demand, tunnels shrink MTU and hide traffic from IPv4 filters, translation breaks IPv4 literals and anything outside TCP, UDP and ICMP.

for a principal

Frame transition as a portfolio: which parts of an estate stay dual stack, which go IPv6-only behind translators, and what evidence would tell you it is time to retire the IPv4 side.

## Why the two protocols cannot simply talk IPv4 (RFC 791) and IPv6 (RFC 8200) share a purpose and a lot of vocabulary, but on the wire they are **different protocols**: - The first four bits of the packet carry a different **Version** value (4 or 6), and everything after them is laid out differently. - IPv4 addresses are **32 bits**; IPv6 addresses are **128 bits**. An IPv4 header has no field that can hold an IPv6 address, and an IPv6 header cannot name an IPv4 destination except by embedding it in an IPv6 address that something else must interpret. - IPv6 has a fixed **40-byte** base header with a chain of extension headers; IPv4 has a variable header (20 bytes without options) with its own checksum and fragmentation fields. RFC 4213 defines an **IPv4-only node** as one that "does not understand IPv6", and an **IPv6-only node** the other way round. Neither has any way to originate, forward or receive the other's packets. Whatever bridges them has to do one of three things: run both protocols, carry one inside the other, or rewrite one into the other. ## The three families | Family | What it does | Who can then reach whom | Main specifications | |---|---|---|---| | **Dual stack** | Each node runs IPv4 and IPv6 side by side and picks per destination | Anything, as long as the node holds both kinds of address | RFC 4213; client choice by Happy Eyeballs, RFC 8305 | | **Tunnelling** | Encapsulates an IPv6 packet inside an IPv4 packet to cross an IPv4-only network | IPv6 to IPv6, across IPv4 | RFC 4213 (configured, IP protocol 41), RFC 3056 (6to4), RFC 4380 (Teredo, over UDP), RFC 5214 (ISATAP) | | **Translation** | Rewrites the IPv6 header into an IPv4 header and back | An IPv6-only client to an IPv4-only server | RFC 6146 (stateful NAT64), RFC 6147 (DNS64), RFC 6052 (address format), RFC 6877 (464XLAT) | ## Dual stack Dual stack is the baseline the other mechanisms are measured against. A host with both stacks resolves a name, gets IPv6 (AAAA) and IPv4 (A) answers, and connects over whichever works — today normally by racing them with Happy Eyeballs. Nothing is translated or encapsulated, so nothing breaks end-to-end. The cost is that **every node still needs an IPv4 address** (public, or private behind an IPv4 NAT) and every network carries two routing and filtering policies. Dual stack does nothing about IPv4 address exhaustion; it only stops the IPv4 dependence from getting worse. ## Tunnelling A tunnel treats an IPv4 path as if it were one link for IPv6. The encapsulator puts an IPv4 header in front of the IPv6 packet; the decapsulator strips it and forwards the original IPv6 packet unchanged. RFC 4213 models such a tunnel as a **single hop** from IPv6's point of view, and recommends a static tunnel MTU of 1,280 bytes (anything from 1,280 to 1,480 is allowed), because the IPv4 header costs at least 20 bytes. The essential limit: **both ends of the conversation are IPv6**. A tunnel connects IPv6 islands; it never lets an IPv6-only host exchange packets with an IPv4-only one. ## Translation A translator sits between an IPv6-only network and the IPv4 internet and rewrites headers. Stateful NAT64 maps many IPv6 clients onto a small pool of shared IPv4 addresses, much as an IPv4 NAPT does, and DNS64 fabricates IPv6 addresses for IPv4-only names so that unmodified IPv6 clients have something to connect to. 464XLAT adds a second, stateless translator on the device or customer router for software that insists on IPv4. Translation is the only family that crosses between single-stack hosts, and it pays for that: the path is no longer end-to-end, only TCP, UDP and ICMP are translated by RFC 6146, and anything that carries an IPv4 address inside its payload can break. ## Choosing between them 1. Where IPv4 addresses are still available, **dual stack** is the least surprising choice. 2. Where IPv4 addresses are scarce and the clients are new — mobile networks are the classic case — **IPv6-only with NAT64/DNS64** (plus 464XLAT for IPv4-only software) avoids giving every device an IPv4 address. 3. Where an IPv6 network must cross IPv4-only transit, a **tunnel** does the job — preferably a configured one between known endpoints. Many real networks use all three at once in different places.

  • If a tunnel cannot connect IPv6-only to IPv4-only hosts, what is it actually good for?
    Joining IPv6 hosts or networks across an IPv4-only stretch: a site with no native IPv6 transit can reach the IPv6 internet through a configured tunnel to a provider, or two IPv6 islands can talk across IPv4. The inner IPv6 packet arrives unchanged, so unlike translation nothing end-to-end is lost; only the MTU shrinks by the IPv4 header.
  • Why does dual stack not solve IPv4 address exhaustion?
    Because a dual-stack node still needs an IPv4 address alongside its IPv6 ones — public, or private behind an IPv4 NAT. Dual stack adds IPv6 without removing any IPv4 demand. Only running IPv6-only and reaching IPv4 through a translator lets a network stop handing out IPv4 addresses to every host.

Tunnelling is sealing a letter in a foreign country's envelope so its postal service will carry it; the reader at the far end must still speak the letter's language. Translation is an interpreter who rewrites the letter so a reader of the other language can understand it.

saying these in an interview costs you the question

  • A tunnel lets an IPv6-only host reach an IPv4-only server.
  • IPv6 is backward compatible, so IPv4-only routers can forward it.
  • Dual stack removes the need for any IPv4 addresses on hosts.
  • NAT64 is IPv4 NAT with longer addresses; the header layout stays the same.