Summary

  • RFC 3056, co-authored by Brian Carpenter and Keith Moore in 2001, defined 6to4 as an optional, interim bridge and explicitly directed sites towards native IPv6 when it became available. Its lifecycle problem was therefore not a missing expiry label, but the difficulty of making that label effective after deployment became easy and distributed.
  • Christian Huitema’s anycast extension reduced the configuration needed to find a relay, but it also made successful service depend on routing scope, monitoring, fault isolation and independently managed forward and return paths. Later operating evidence showed how fragile that bargain could become for users who did not know 6to4 was active.
  • Carpenter’s 2011 advisory converted scattered symptoms into a role-specific operating account: black holes, variable delay, path-MTU failures, misleading diagnostics and help-desk costs. Dan Wing and Andrew Yourtchenko’s Happy Eyeballs then contained some client-visible delay without repairing the underlying 6to4 path.
  • RFC 7526, authored by Ole Troan and edited by Carpenter as an IETF Best Current Practice, deprecated anycast 6to4 in 2015 and tightened defaults. It did not deprecate basic unicast 6to4 or the IPv6 prefix 2002::/16, a boundary essential to understanding both the engineering decision and Carpenter’s role in it.

Temporary by design, persistent in operation

“It is not intended as a permanent solution.” That sentence appears in the opening description of RFC 3056, published in February 2001 by Brian Carpenter and Keith Moore. The qualification was not buried in an appendix written to protect the authors from later criticism. It formed part of the mechanism’s definition: 6to4 was optional, interim and meant to let isolated IPv6 sites communicate across an IPv4 network before native IPv6 connectivity was available.

The same document said that sites should migrate to native IPv6 prefixes and connectivity when their providers made that possible. Temporariness was therefore an architectural premise, not a retrospective gloss.

Fourteen years later, RFC 7526 concluded that 6to4 was unsuitable for widespread Internet deployment when used in its anycast mode. Between those statements sits the real story. It is not the familiar morality play in which an inventor releases a flawed technology and eventually kills it. Carpenter was one of two authors of the original mechanism; he neither authored Christian Huitema’s anycast design nor controlled product defaults, relay operators, routing policy or user adoption.

In 2015, Ole Troan was the author of the deprecation document and Carpenter its editor. Both the original design and the later Best Current Practice were products operating within a technical community, not proprietary acts under one person’s command.

The sharper question is how an explicitly temporary mechanism acquired enough persistence to require an operational advisory in 2011 and a formal, bounded deprecation in 2015. The answer begins with a common transition bargain. 6to4 offered value precisely because it could use the existing IPv4 Internet as a carrier without requiring every intermediate network to support IPv6. It lowered the immediate coordination burden for an IPv6 site. But the burden did not disappear.

It moved into address construction, automatic tunnelling, relay availability, routing announcements, filtering, path symmetry and fault diagnosis. The easier the entry into the transition state became, the less likely it was that every party on whom service depended would share one operational plan.

That distinction is central to Carpenter’s record. A temporary label can govern design intent; it cannot by itself govern installed software, default settings or independently operated networks. The 2011 Advisory Guidelines for 6to4 Deployment, authored by Carpenter and published as an IETF consensus document, reported long retry delays, complete failures and users unaware that 6to4 was running. The advisory did not pretend that saying “interim” in 2001 had created a timer in every later host and router.

It treated persistence as an operating condition to be managed.

The 2015 response tested the original boundary without rewriting it. The IETF did not declare every packet using 6to4 illegitimate, reclaim the whole addressing architecture or assert that the mechanism had never worked. It deprecated the anycast transition mechanism and its well-known IPv4 relay address, discouraged its inclusion in new implementations and required disabled-by-default behaviour where it remained. At the same time, it expressly left basic unicast 6to4 and 2002::/16 outside the deprecation.

The result was less dramatic than a universal retirement and more disciplined: withdraw the part for which widespread, unmanaged operation had produced the clearest evidence of harm, while preserving a precise account of what the decision did not cover.

The mechanism and the obligations hidden by convenience

Carpenter and Moore’s design solved a specific bootstrapping problem. A site with a globally unique IPv4 address could derive a 48-bit IPv6 prefix under 2002::/16 by embedding that IPv4 address. IPv6 packets leaving the site could be carried inside IPv4 packets using protocol 41. For traffic between 6to4 sites, the embedded address gave the border router the IPv4 destination it needed; for traffic between a 6to4 site and native IPv6, a relay router joined the two domains.

The attraction was concrete: isolated IPv6 domains could communicate over an IPv4 wide-area network with limited manual configuration and without explicit tunnels between every pair of sites. These design elements and limits are set out in RFC 3056.

The address format did more than allocate a label. It coupled an IPv6 site’s reachability to an IPv4 address that had to be globally unique and correctly embedded. The encapsulating and decapsulating nodes had to reject addresses derived from private, broadcast, multicast or loopback IPv4 space. Address selection also mattered: when native and 6to4 addresses were both available, endpoints needed compatible choices, and the document preferred native IPv6 by default when both peers had both forms. These were not decorative implementation details.

They were conditions under which the shortcut represented a usable route rather than merely an IPv6-looking address.

The relay boundary added another class of obligation. A relay carrying traffic towards a native IPv6 domain had to advertise 2002::/16 within an appropriate scope and actually accept the traffic attracted by that advertisement. Carpenter and Moore warned that incorrect policy could create unreachability or perverse traffic patterns. They described managed options, including explicit default routes or routing relationships between 6to4 routers and willing relays.

The arrangement assumed that an operator would decide which traffic a relay was prepared to carry and would align route visibility with that decision. In other words, 6to4 removed the need to upgrade the intervening IPv4 cloud, but it did not remove the need for accountable edges.

Even the original document’s transition sequence exposed a long tail. A site could begin with 6to4, add a native prefix when native connectivity arrived, let address selection determine which path was used during coexistence, and remove the 6to4 configuration only after its use had ceased—possibly years later. That staged procedure was sensible for continuity. Yet it also meant that exit depended on observation and action at each deployed site. There was no central event that could prove every dependency gone.

The mechanism’s technical decentralisation therefore produced lifecycle decentralisation: the party able to enable an interim path was also among the parties required to notice when it was safe to remove it.

The original specification even anticipated diagnostic opacity. An IPv4 “unreachable” generated inside the carrier network would return to the 6to4 router, which often lacked enough information to deliver a useful ICMPv6 error to the originating IPv6 node. The IPv4 network could consequently appear as an undiagnosable link layer from the IPv6 side. That observation did not predict every later failure, but it identified the structural problem: encapsulation crosses an administrative and diagnostic seam.

A failure below the tunnel can be real while the endpoint’s view above the tunnel remains incomplete.

This is why it would be misleading to describe 6to4 as either effortless or simply defective. Its convenience was conditional. Under managed routing, correct address selection, globally valid addressing, functional relays and compatible filtering, it could provide the interim connectivity it promised. The lifecycle difficulty arose when the visible user proposition—automatic IPv6 across IPv4—became separated from the less visible operating disciplines on which that proposition rested.

The design’s entry cost was low relative to native deployment; its assurance cost was distributed.

Anycast lowered configuration and raised the coordination stakes

The next step was not Carpenter’s design. RFC 3068, authored by Christian Huitema in June 2001, introduced a 6to4 relay anycast prefix and address. Its goal was to simplify configuration for networks that did not participate in IPv6 inter-domain routing and otherwise needed to find and configure a default relay. A 6to4 router could direct traffic to the well-known IPv4 address 192.88.99.1; routing would take it to an available relay advertising the associated prefix.

This made relay discovery automatic and offered routing-based failover to another relay if one stopped advertising service.

The extension addressed a real usability problem in the original managed arrangement. A small network might locate a relay only across the Internet and suffer poor performance, or might fail to configure one at all. Anycast made “which relay?” a routing answer rather than a per-user configuration task. That shift made 6to4 more accessible to small networks and simple gateways. It also changed the character of the dependency. The user no longer selected a named, willing relay.

The routing system selected an instance behind a common address, and the outbound instance need not be the relay later chosen to carry return traffic from native IPv6.

Huitema’s document was explicit that anycast needed operational care. Because the sending router did not directly identify the relay instance, intermittent failure could be hard to assign. The specification required adequate monitoring and fault-isolation procedures. A relay was to stop injecting the route to the anycast prefix immediately if its relay function failed, while a corresponding unicast address could help an operator test a particular relay.

The design also recognised that the nearest relay to a 6to4 site might not offer the best route towards the native destination, and it left possible redirection for further study. Practical deployment, it said, would require monitoring and testing tools, evolving management practices and operational experience.

Those qualifications matter because the anycast lifecycle cannot be judged solely by whether 192.88.99.1 was an elegant discovery device. The service promise existed only while several propositions remained aligned: the route led somewhere useful; the reached relay accepted the sender’s traffic; the relay retained native IPv6 connectivity; monitoring withdrew a bad route quickly; a return relay advertised 2002::/16 near the destination; protocol 41 survived intervening filters; and both directions satisfied security policy.

Anycast reduced the configuration that exposed these choices to the user. It did not eliminate the choices.

This is a recurring form of technical lock-in. It need not involve a vendor contract or an intentionally closed interface. A mechanism can become sticky because convenience spreads state into places where no single operator has a complete inventory. Once hosts, home gateways, transit networks, relays, firewalls and content networks make independent assumptions about the same path, removal becomes a coordination exercise.

A user may possess an address and a default route that look valid even though the service behind them is unwilling, unreachable or impaired. The visible configuration survives while the institutional arrangement that would make it reliable is absent.

The anycast RFC did not conceal this risk, and it should not be blamed on Carpenter in any event. Huitema was the author. Carpenter appears in the acknowledgement of working-group discussion, but that is not authorship of the anycast mechanism. The correct analytical point is broader: standards documents can state management assumptions accurately, yet deployment at scale may still select for the feature that feels automatic rather than for the disciplines that make automation dependable. Later evidence did not reveal a secret intention.

It showed that the operating assumptions were not reliably realised across the public Internet.

Security analysis turned openness into an operating liability

By 2004, the security consequences of automatic tunnelling had received a dedicated analysis. RFC 3964 was authored by Pekka Savola and Chirayu Patel, not Carpenter. It identified two characteristics behind much of the risk: 6to4 routers had to accept and decapsulate protocol-41 traffic from other 6to4 routers and relays, while relay routers had to accept traffic associated with native IPv6 nodes. The resulting trust surface made denial-of-service, reflected denial-of-service and address spoofing easier in several scenarios.

The security problem was not simply that tunnelling existed. It was that the automatic design widened who could present an encapsulated packet for processing while the inner and outer address relationships were not self-authenticating. Savola and Patel described checks that could reject non-global IPv4 addresses, require embedded IPv4 and 6to4 source information to match, prevent a relay from bouncing traffic between two 6to4 destinations, and discard nonsensical native-to-native packets arriving through the tunnel.

These checks were prerequisites for a relatively safe implementation, not a promise that every threat disappeared.

That limitation is important. The analysis concluded that even with correct checks, some threats remained difficult or impossible for a 6to4 developer or relay operator to solve completely. Spoofing and reflection depended partly on filtering outside the mechanism’s own control. A relay could also become hard to distinguish from the source of abuse because it decapsulated or re-encapsulated traffic, creating investigation and administrative burdens for its operator.

Multiple automatic-tunnel mechanisms sharing protocol 41 could make strict classification harder still, because the packet did not carry a separate transition-mechanism identifier.

This evidence changes how the interim bargain should be valued. A relay was not merely a helpful forwarding point donated to the transition. It was a security enforcement surface, a potential target, a possible amplifier and an administrative contact point. “Free relay” described the absence of a direct configuration or payment by the user; it did not mean the relay had no operating cost. Monitoring, filtering, logging, capacity and incident handling were part of the service even when the user never saw them.

None of those findings belongs to Carpenter personally. Savola and Patel performed the analysis and documented the threats. Nor do the threats prove that every 6to4 path was unsafe or failed. Their importance in the lifecycle is evidentiary: they showed that safe operation required more than implementing the short forwarding path. The mechanism’s assurance case depended on behaviour at routers, relays and network edges, including actors that could not compel one another. As that evidence accumulated, the burden of justification shifted.

It was no longer enough to show that the mechanism could connect two domains; continued widespread use had to be weighed against the cost of keeping an open, automatic relay system trustworthy.

The 2011 advisory: from protocol possibility to user-visible evidence

Carpenter’s most direct individual contribution to the mechanism’s later lifecycle was RFC 6343, which he authored as an informational IETF community-consensus record after public review. Its purpose was practical rather than confessional. It addressed internet-service providers, content providers and implementers, including networks that did not themselves offer IPv6, because their customers and help desks could still be affected by 6to4.

The advisory’s opening reverses the viewpoint of a protocol specification. Instead of asking whether packets can be encapsulated and relayed under stated conditions, it asks what a user experiences when those conditions are only partly met. The answer included long retry delays or complete failures. Some end systems and customer-premises routers supported 6to4, and some equipment enabled it by default, so users could encounter the mechanism without knowing it was active. When they sought help, the underlying cause was difficult to diagnose.

The document labels as anecdotal the observation that many help desks advised disabling IPv6 altogether; it does not claim a universal survey.

That anecdote nevertheless reveals an important causal reversal. 6to4 had been intended to encourage early IPv6 use where native service was absent. If an impaired 6to4 path taught users and support staff that “IPv6” was the thing to disable, the transition tool could damage confidence in the destination technology. The failure was not only a dropped packet. It was a misleading attribution at the human interface: the automatic bridge failed invisibly, while the broader protocol family received the blame.

The advisory distinguished Router 6to4 from Anycast 6to4. The original router design assumed managed, cooperative configuration, including a relay willing to carry outbound traffic. The anycast variant removed the need for a user to make that arrangement by supplying a default relay address. In practice, Carpenter’s consensus record said that few if any public deployments followed the managed Router 6to4 recommendations and that Anycast 6to4 predominated.

A host or gateway could see a global IPv4 address, resolve an IPv6 destination and infer that sending towards 192.88.99.1 would work. That inference could be wrong even though every local indicator looked plausible.

The recorded failures formed a chain rather than a single bug. An outbound black hole could exist when a route to the anycast prefix was accepted but led to a filter, an unwilling relay or nowhere useful. An inbound black hole could occur after the outbound packet reached a relay and the native destination replied, because a protocol-41 filter blocked the returning encapsulated packet. A return relay might be missing, or a relay advertising reachability to 2002::/16 might reject traffic it had attracted.

When both directions existed, unmanaged and possibly different relays could still produce large or variable round-trip times.

Path-MTU discovery created a more deceptive failure. Encapsulation reduced the useful path MTU. Small diagnostic packets and even the opening TCP handshake might succeed while larger data packets vanished if “Packet Too Big” information did not travel correctly or maximum-segment-size handling failed. A user might therefore reach one site, merely ping another and see no obvious indication that the tunnel was the dividing line.

This is a higher-cost fault than a clean rejection because successful preliminaries send an operator down the wrong diagnostic path.

Other failures exposed the coupling between address evidence and reality. A global-looking IPv4 value used as if it were private space could produce a 6to4 prefix with no valid return path. Carrier-grade address translation could break the assumption that the embedded address represented the reachable tunnel endpoint. Some implementations reportedly activated even with private IPv4 addresses, contrary to the original specification. Reverse-DNS checks could also reject 6to4 clients that lacked delegations.

No one of these conditions was universal; together they made a symptom such as “web pages are slow” compatible with too many causes.

RFC 6343 included measurements reported from experiments, but it did not turn them into a universal deployment statistic. It cited observed 6to4 connection-failure ranges of 9–20 per cent in one experiment and 9–19 per cent in another, under their stated methods. It also described an overall loss measured as a fraction of one per cent of attempts to dual-stack content servers because only a subset of clients attempted 6to4. The advisory explicitly noted considerable successful use.

The disciplined conclusion is therefore not that a fixed proportion of the Internet was broken. It is that failures among the 6to4 attempts studied were material, while even a small aggregate share could matter to providers and generate user delay and support demand.

The document associated those failures with financial impact for content providers and likely help-desk costs, but it supplied no exact total and did not assign those costs to Carpenter. Vendor defaults, operator routing, relay behaviour, firewalls and client fallback determined particular outcomes. Carpenter’s accountable act was to assemble the mechanism-level and operating evidence into a record that named the affected roles. He did not convert distributed deployment history into a story about his own success or failure.

That choice of form matters. A retrospective written around personal intention might have asked whether the 2001 authors had been right. The advisory instead asked what each current actor could do. Vendors and implementers were told not to enable Anycast 6to4 by default and to correct implementations that activated on private addresses. Networks without IPv6 were told to verify that the route to the anycast address was explicit, stable, reasonably close and accepted by a willing relay.

Networks with native IPv6 were encouraged to direct users away from 6to4 and ensure they had not accidentally become relays. Transit and content providers received separate routing, return-path, capacity and filtering guidance.

This role-specific structure is evidence of engineering accountability because it follows control. A vendor can change a default but cannot repair every transit route. An access provider can test reachability or return an explicit failure but cannot force a distant content network to operate a return relay. A content provider can place a relay near its servers but cannot remove a user’s faulty gateway.

Assigning advice to the actor with the relevant control surface avoids two opposite errors: treating a collective failure as nobody’s responsibility, or making one named standards author responsible for every implementation and network decision.

Mitigation exposed the cost of keeping the interim state alive

The 2011 guidance was not yet a deprecation. It tried to reduce harm while a large installed base remained. For a provider without IPv6 service, a route to 192.88.99.1 had to be more than a default route: it needed to lead to a functional, stable and willing relay. If that could not be established, the advisory suggested considering an explicit unreachable response so some clients might fall back faster, while acknowledging limited operational experience with that tactic.

Simply dropping protocol 41 was not a clean solution because it silently worsened 6to4 and also harmed deliberately configured IPv6 tunnels.

For transit providers that chose to support the service, the obligations were substantial. The IPv4 anycast prefix had to be announced only towards client networks whose traffic would be accepted. The 2002::/16 route had to be scoped so that any traffic attracted by it could actually be relayed. The relay’s return-source address had to be selected with stateful firewalls and ingress filtering in mind. Protocol 41 and necessary ICMPv6 messages had to pass.

Capacity had to be monitored and expandable, while unmanaged relays had to be avoided. These requirements came from RFC 6343, not from an assertion that one configuration fit every operator.

Content providers faced a particularly revealing asymmetry. A 6to4 client could reach a dual-stack server through one relay while the server’s response depended on a different route to 2002::/16. The advisory recommended a locally positioned return relay and careful routing scope so that the return path was short and functional. That meant a provider that had deployed native IPv6 correctly could still need infrastructure for clients using an unmanaged transition mechanism elsewhere.

The cost of compatibility had migrated towards the party serving the destination, not necessarily the party that enabled 6to4.

This is where software lifecycle and network-resource evidence meet. A feature can be “legacy” in design intent while remaining current in operational cost. Routes, packet filters, relay capacity and support cases are not abstract traces of old code; they are resources consumed now. The 2011 advisory effectively made those resources visible. It showed that preserving compatibility was an active service requiring monitoring and policy, not passive tolerance of an old address format.

It also exposed the weakness of a binary decision between “works” and “does not work”. Anycast 6to4 could work for many paths and fail for a subset depending on route scope, relay willingness, firewall state, MTU and return topology. A mechanism with partial, path-dependent success is harder to retire than one that fails cleanly, because successful users have a legitimate interest in continuity while unsuccessful users may not even know which feature is responsible.

The appropriate response must therefore reduce new automatic activation, preserve explicit operation where justified and remove shared infrastructure only with regard for residual traffic. That logic would become the backbone of the 2015 boundary.

Happy Eyeballs contained damage; it did not repair 6to4

Client software supplied another layer of mitigation. RFC 6555, authored by Dan Wing and Andrew Yourtchenko in 2012, addressed the delay a dual-stack application experiences when an IPv6 path is impaired but IPv4 works. Broken 6to4 was one of several listed causes, alongside other broken tunnels, absent IPv6 connectivity and peering problems. The algorithm quickly attempted the other address family when the preferred connection did not complete, used the successful connection and could remember outcomes to avoid repeatedly stressing the network.

Happy Eyeballs changed the user-visible consequence of a bad path. Instead of waiting through a long IPv6 timeout before trying IPv4, an application could race or closely stagger attempts and continue on the working family. That was valuable damage containment. It reduced the probability that a user would experience the full delay described in RFC 6343, and it weakened the incentive to disable IPv6 wholesale merely to make applications responsive.

But the distinction between containment and repair must remain exact. Happy Eyeballs did not make a missing relay appear, open a protocol-41 filter, correct an invalid embedded address, restore path-MTU discovery or secure a 6to4 tunnel. It selected around an impaired path at the client. Wing and Yourtchenko also noted the trade-off: extra attempts create some network and server load, so the algorithm should avoid indiscriminate simultaneous connections and abandon non-winning ones.

The mitigation could also make infrastructure faults less visible. RFC 6555 observed that applications using the technique are, by default, less useful for diagnosing a particular address family because a successful alternative masks the failure. RFC 7526 later said many browsers had hidden 6to4 failure modes from users through Happy Eyeballs. “Hidden” here does not mean solved. It means the user’s transaction may succeed while the failed 6to4 attempt remains part of the network’s background condition.

This creates a lifecycle paradox. A good compatibility mechanism protects users during transition, but by softening symptoms it can reduce the pressure to remove the cause. The correct lesson is not to reject client resilience. It is to keep the layers distinct in policy: measure and repair or retire the impaired network mechanism even when applications have learned to route around it. Otherwise success at the application layer becomes false evidence that the underlying transition service remains healthy.

The 2015 decision was deliberately narrower than “retire 6to4”

The title of RFC 7526 states its scope: “Deprecating the Anycast Prefix for 6to4 Relay Routers.” Ole Troan was the author; Brian Carpenter was the editor. The document was published in May 2015 as an IETF Best Current Practice representing community consensus. It made RFC 3068 and the related provider-managed anycast framework Historic, deprecated the anycast mechanism and associated address 192.88.99.1, and recommended that future products not support 6to4 anycast.

The negative space is just as important. RFC 7526 explicitly says that basic unicast 6to4 as defined by RFC 3056 and the IPv6 prefix 2002::/16 were not deprecated. Peer-to-peer use independent of the anycast service was outside the target. The document did not recommend general filtering of all 6to4 traffic or routes. Operators could continue return relays for residual clients, and those continuing anycast service were still directed to the operational guidance in RFC 6343.

Implementation defaults did become stricter. New implementations were advised not to include anycast 6to4; if they did, it had to be disabled by default. Host implementations also had to leave unicast 6to4 disabled by default and support the updated IPv6 address-selection policy. Router implementations had to disable 6to4 by default, and enabling IPv6 forwarding could not silently enable it. These provisions did not contradict the statement that unicast 6to4 was not deprecated.

Status and default are different policy instruments: one preserves a defined mechanism for explicit, bounded use; the other prevents accidental activation from reproducing the unmanaged deployment problem.

Operational withdrawal was similarly staged rather than instantaneous. A network was not to originate a route to 192.88.99.1 unless it actively operated and monitored an anycast relay. Existing relay operators were told to review whether service could be discontinued as traffic diminished. Providers advertising 2002::/16 to their customers were to do so only when it led to a correctly functioning return relay.

This recognised that a deprecation document does not erase deployed clients and that a premature withdrawal can create the very black holes the policy is trying to reduce.

The document even clarified that “deprecate” was being used in its ordinary sense of expressing disapproval, not as a magic normative operation that removed code from the Internet. A deprecated function might remain for years for backwards compatibility. That is an unusually useful statement of lifecycle realism. Standards status can change the direction of new implementation and deployment. It cannot synchronously update every product, route or operator decision.

Carpenter’s editorial role belongs inside that bounded institutional act. It is reasonable to see continuity between the temporary boundary he co-authored in 2001, the operational account he authored in 2011 and the limited deprecation he edited in 2015; the IETF Datatracker record lists those roles. It is not reasonable to turn that continuity into a claim that he personally retired 6to4. Troan authored RFC 7526, and its authority came from the IETF Best Current Practice process and community consensus.

That distinction protects the quality of the technical history. Personalising the decision would exaggerate Carpenter’s control over standards status while obscuring the evidence supplied by operators, implementers, researchers and users. Depersonalising it completely would miss the accountability expressed by staying engaged across the lifecycle.

The accurate middle is stronger: Carpenter participated in defining the temporary mechanism, later put his name to its operating costs, and edited a community decision whose scope was drawn narrowly enough to match the evidence.

What accountable engineering looks like across a long transition

The 6to4 record offers three tests for engineering accountability. The first is whether the original promise contains its own boundary. RFC 3056 did. It described 6to4 as optional and interim, preferred native IPv6 where available and laid out a sequence for eventual removal. Carpenter and Moore did not market a tunnel over IPv4 as the permanent architecture of IPv6.

The second test is whether later evidence is allowed to change the operating recommendation. RFC 6343 did not defend the mechanism by repeating its intended topology. It started from observed user outcomes and traced them back through routes, relays, filters, address assumptions and MTU behaviour. It also kept evidentiary limits visible: some help-desk behaviour was anecdotal; particular failure rates belonged to cited experiments; successful use existed; no universal cost total was claimed.

That discipline matters because weak evidence can produce an overbroad remedy just as easily as denial can preserve a harmful default.

The third test is whether withdrawal is proportional to what the evidence establishes. RFC 7526 targeted anycast 6to4, the mode judged unsuitable for widespread Internet use. It tightened defaults more broadly to prevent invisible activation, but it did not pretend that basic unicast use and 2002::/16 had been abolished. It preserved operational guidance for residual service and tied route origination to active monitoring. The remedy followed the failure mechanism instead of the desire for a simple headline.

These tests also explain why Carpenter’s story should not be framed as triumph. Native IPv6’s destination does not convert every transitional experiment into a heroic stepping stone, and the frozen record supplies no basis for claiming that 6to4’s adoption or withdrawal belonged to him. Nor is it a story of personal failure. Vendors chose defaults; operators chose routes and filters; relay instances behaved differently; applications chose fallback strategies; users experienced the combined path.

Causal responsibility was distributed because control was distributed.

What Carpenter’s documented roles show is a willingness to remain attached to the consequences of earlier work without claiming command over them. Co-authorship in 2001 created a public technical commitment with stated limits. Authorship in 2011 accepted that real deployment had produced costs the original mechanism could not explain away. Editing in 2015 helped express a consensus remedy that did not overreach. This is less cinematic than invention followed by repentance.

It is also a more useful pattern for infrastructure, where no author gets to decide alone how long deployed code, addresses and routes will persist.

There is a broader lesson about institutional legitimacy here, but it is grounded in the mechanism rather than in a general essay about standards. Legitimacy came from matching claims to roles and remedies to evidence. Huitema remains the author of the anycast extension. Savola and Patel remain the authors of its dedicated security analysis. Wing and Yourtchenko remain the authors of the client-side latency mitigation. Troan remains the author of the deprecation, with Carpenter as editor.

Clear attribution prevents authority from being manufactured around one famous name and makes the causal account auditable.

The record also shows why network-resource evidence matters to lifecycle decisions. A transition mechanism is not retired merely because a newer architecture is preferable. Its continued value and cost appear in reachable prefixes, working relays, failed handshakes, path delays, MTU behaviour, filtering and residual client traffic. Those signals are imperfect and distributed, but they are closer to the mechanism than a declaration of intent.

The 2015 decision became credible because it connected the original interim boundary to years of security and operational evidence, then drew a scope that operators could actually implement.

Conclusion

6to4 began with an expiry condition but no universal clock. Carpenter and Moore expected migration to native IPv6; Huitema’s anycast extension made the interim route easier to enter; Savola and Patel documented the security burden; Carpenter’s 2011 advisory showed how distributed failures reached users and support desks; Wing and Yourtchenko contained some delay at the client; and Troan’s 2015 Best Current Practice, edited by Carpenter, deprecated the anycast mode without declaring all 6to4 dead.

Carpenter’s significance in that sequence lies in continuity without appropriation. He did not control the collective deployment, and he did not personally retire it. His record instead demonstrates a harder form of responsibility: state the temporary bargain, document when its hidden operating costs become visible, and help narrow the remedy to the mechanism the evidence can justify.

Sources