Summary

  • RFC 2185 treated IPv4 and IPv6 reachability as separately computed routing systems, even when an IPv6-over-IPv4 tunnel looked like one ordinary link.
  • Automatic tunnelling made route leaking a control decision: IPv6 reachability had to lead to the correct encapsulator before IPv4 could take responsibility for the outer packet.
  • A preferred endpoint, backup prefix, successful decapsulation or one-way packet receipt proved only a bounded stage. It did not prove policy authority, symmetric return, application delivery or completed migration.

The route had to find the place where the packet changed worlds

The difficult part of an early IPv6 tunnel was not merely putting one header around another. It was deciding where that act should happen.

RFC 2185, published in September 1997, described an extended transition in which IPv4 and IPv6 routing infrastructures would coexist. It called the arrangement a dual-IP-layer transition. IPv4 forwarding used routes learned by IPv4 protocols; IPv6 forwarding, including packets addressed with the era's IPv4-compatible IPv6 form, used routes learned by IPv6 protocols. Even if one integrated routing process later carried both families, the memo said the underlying computation remained dual.

That distinction turns a tunnel into a compound promise. Before encapsulation, the IPv6 route must place the packet at a node authorized and able to wrap it. After encapsulation, the IPv4 route must reach the outer endpoint. A green route in either table says nothing conclusive about the other table. The transition works only where the two decisions meet.

The memo was careful about its own authority. The RFC Editor record and IETF Datatracker entry classify it as Informational, not an Internet Standard. It described a routing design derived from ngtrans work; it did not document adoption, field performance or a completed migration.

One visible hop concealed another network

A manually configured static tunnel simplified the IPv6 view. The endpoints treated the tunnel like a normal point-to-point link, established an adjacency and exchanged routing information across it. To IPv6, the far endpoint was one hop away.

The outer packet did not share that fiction. It crossed whatever IPv4 path current IPv4 routing selected between the tunnel endpoints. The virtual adjacency therefore proved that two endpoints had agreed to behave as neighbors. It did not prove the condition of every intervening IPv4 router, the outer path's capacity, its firewall treatment or the fate of a return packet.

The contemporary transition specification, RFC 1933, supplied the mechanics and showed how much state remained underneath the apparent link: tunnel MTU, fragmentation, IPv4 path-MTU information and the translation of ICMP errors back into the IPv6 layer. RFC 2003 specified generic IP-within-IP mechanics and required prior knowledge that the exit could decapsulate. Those documents explain the wrapper. RFC 2185 asked the different question: which route brings a packet to the wrapper, and why is that wrapper the right one?

Automatic tunnelling turned route export into placement authority

Host-to-host automatic tunnelling was the simplest case. If both hosts used IPv4-compatible IPv6 addresses, the sender could extract the two IPv4 addresses, encapsulate immediately and let IPv4 routing carry the packet all the way to the destination host.

A configured-default tunnel changed the evidence. A host without a suitable local IPv6 router could be told the IPv4 address of a dual router connected to the IPv6 backbone. It sent the outer packet there, the router removed the IPv4 header, and native IPv6 routing resumed. That configured address was not merely a locator; it selected the place where responsibility changed protocol families.

Router-to-host automatic tunnelling exposed the most consequential control surface. The encapsulating dual router had to advertise corresponding IPv4-compatible IPv6 reachability into the IPv6 region. IPv6 routers followed that leaked route to the advertising router. Only there was the packet encapsulated and handed to ordinary IPv4 routing for its final segment.

RFC 2185 defined route leaking as advertising reachability across routing-region boundaries. In this design, the leak was not a neutral copy. It promised, in effect: send this IPv6 destination toward me, because I can complete the next stage over IPv4. The advertisement selected an encapsulator and expanded its operating responsibility.

The scaling choice made that authority visible. For a small IPv4 stub, one summary prefix might suffice. At the border between a major IPv4-only backbone and a dual backbone, the design might feed the entire IPv4 table into IPv6 routing, roughly doubling table size, or require manual selection of only those IPv4 destinations believed to contain IPv6-capable systems. One option spent state; the other spent human judgment. Neither was automatic truth.

Backup reachability was not equivalent service

The configured-default example offered a neat failover pattern. Each capable dual router could advertise a host route for its own endpoint address and also a covering prefix for the shared block. A host's preferred endpoint would win while its host route existed. If it failed, a broader route could carry the packet to another operating endpoint.

That is a useful routing result, but its receipt is narrow. The fallback shows that some router advertising the covering prefix accepted the outer packet. It does not show that the alternate router had the same policy, tunnel state, capacity, filtering, path MTU or downstream IPv6 reachability as the preferred router. It does not show that the other direction selected the same endpoint.

RFC 2185 made directionality explicit. Communication had to work both ways, yet the two directions could use different tunnelling forms according to address type, local connectivity and policy. One host might send through a host-to-host tunnel while its peer returned through native IPv6 plus router-to-host tunnelling. A successful forward trace was therefore not a model of the return path.

The memo's security section also set a hard limit on inference: tunnelling could violate firewalls in the underlying infrastructure, and it discussed no other security issues. A packet emerging from a tunnel was not authenticated merely because routing delivered it.

The useful historical lesson is an evidence ladder

The route table proves that a control process selected reachability. A leaked prefix proves that one routing region advertised a claim into another. A configured endpoint proves a local choice. An adjacency proves that two nodes can exchange control information across a virtual link. Decapsulation proves that one outer packet reached a functioning exit. A one-way application response proves more, but still only for the observed direction and interval.

None of those observations, alone, proves authorized route export, consistent policy, loop-free handoff, symmetric return, sustained capacity, end-to-end delivery or migration completion.

That boundary separates RFC 2185 from adjacent histories. RFC 1955 proposed ENCAPS, relocating a medium-term routing abstraction into autonomous-domain headers, DNS mappings and border routers. RFC 2003 described the envelope. RFC 4213 later documented basic IPv6 transition mechanisms and preserved the revealing model in which a tunnel is one IPv6 hop while an independent IPv4 TTL governs the outer path. RFC 2185's distinctive contribution was to show who had to make those layers meet.

Lu Heng's Running-Code Primacy is a useful attributed lens here: a published route or design is not the same thing as executed, locally verifiable operation. Minimum Initial Specification likewise suggests keeping common invariants narrow while leaving later adoption and policy choices with operators. His dual-stack-tax argument assigns an economic interpretation to parallel routing, policy and troubleshooting surfaces; it is commentary, not evidence that RFC 2185 was deployed. The essay on reality layers supplies the final discipline: configuration and advertisement belong to a different evidentiary layer from an executed packet path and a delivered service.

The 1997 memo did not prove that transition succeeded. It did something more durable for operators: it showed exactly where a claim had to change owners. The IPv6 route promised the right encapsulator. The IPv4 route promised the outer endpoint. Only an observed end-to-end result could say whether both promises were kept.