Summary

  • Pim van Pelt helped initiate the IPng.nl tunnel-broker precursor with Cliff Albert in early 2000, before Jeroen Massar joined and the work evolved into SixXS.
  • Pim and Jeroen later co-designed a new SixXS version and jointly operated a distributed IPv6 transition service supported by external points of presence.
  • The operating record includes practical work, such as Pim's 2004 request for more public 6to4 relay operators and his report of sustained relay traffic.
  • By 2017, Pim and Jeroen judged that falling tunnel uptake and provider reliance on workarounds could make SixXS an obstacle to its own native-IPv6 objective.
  • Their joint sunset decision matters because they treated retirement as continuity work: notice, migration time, partner coordination, resource return, service closure and data deletion.

The decision that defines the story

Pim van Pelt's significance in the SixXS story is not captured by a simple founder label. The more revealing arc begins with an improvised transition service, follows its development into operating infrastructure, and ends with a deliberate reversal. Pim and Jeroen Massar jointly decided in 2017 to close a service they had spent years maintaining.

Their stated reason was not that IPv6 had failed. It was that the workaround designed to help IPv6 adoption might, in some cases, make native deployment easier to defer. That assessment belonged to the operators; it was not a universal finding about every internet provider. Even with that boundary, it created a hard institutional question: when does continued usefulness become a reason to stop?

This was a decision about purpose rather than mere activity. A service can remain technically functional, serve real users and still move away from the objective that justified it. SixXS supplied IPv6 connectivity through tunnels to people whose normal access providers did not provide native IPv6. A tunnel, in this context, carries newer IPv6 traffic through an older IPv4 path so that the user can reach the IPv6 internet.

It is a bridge around a missing capability. As native IPv6 became more available and demand for new tunnels declined, the operators saw a different risk: the bridge could reduce pressure on providers to build the permanent route. Their answer was to retire the bridge through an orderly transition rather than preserve it indefinitely.

The episode deserves attention because shutdowns are often described as defeat, neglect or financial exhaustion. The documented SixXS case is different. The operators presented closure as an extension of the service's original goal.

If the institution existed to accelerate a transition, permanent dependence on that institution would be evidence of unfinished work, not necessarily a mandate for endless operation. That does not prove that every tunnel service creates the same incentive, nor does it tell us what happened to every user. It does show Pim participating in a joint decision that placed the mission above the continuation of the organisation built around it.

Before SixXS: the IPng.nl precursor

The chronology matters because later summaries compress a long, continuous effort into an “eighteen-year” SixXS story. The detailed project history is more precise. In early 2000, Pim van Pelt and Cliff Albert set up the IPng.nl tunnel broker as a hobby project with one point of presence, commonly shortened to PoP. A PoP is a location where a network service connects users or exchanges traffic. The precursor was small, but it supplied a practical response to a common problem: people wanted to experiment with IPv6 before their usual providers made it available directly.

Jeroen Massar joined the precursor later in 2000. The first SixXS design followed the lessons of IPng.nl, and the design did not remain static. During 2001 and 2002, Pim and Jeroen designed a second version that entered deployment in 2002 and absorbed the precursor service. From that point through the 2017 sunset, the two men jointly operated and evolved SixXS.

This sequence supports describing Pim as an initiator of IPng.nl and a later co-designer and long-running co-operator of SixXS. It does not support describing him as the sole founder or sole operator, erasing Cliff's early role, or placing the exact later service in 1999 without explaining the predecessor period.

Chronology is not a ceremonial detail here. It changes how responsibility is understood. Cliff belongs in the origin of the precursor, but the available record does not assign him responsibility for every later SixXS version or for the 2017 sunset. Jeroen arrived after the first setup, yet he became Pim's partner in the later design, operation and closure. Pim's contribution spans both phases, but it remains part of a changing team. Accurate credit therefore requires different verbs for different periods: Pim helped initiate the precursor, co-designed the later system with Jeroen, and joined Jeroen in the sunset decision.

That distinction also protects the story from the familiar tendency to turn distributed infrastructure into a heroic biography. A tunnel service is not sustained by one dramatic invention. It depends on software, routing, monitoring, partner networks, address records, support, maintenance and users willing to adapt. SixXS grew through those relationships. Pim's role is visible and substantial, but the system's existence also depended on Jeroen, other staff, external PoP providers and the wider technical community. The early one-PoP project became noteworthy precisely because it did not remain a one-person, one-location experiment.

From experiment to operating infrastructure

The difference between a demonstration and infrastructure is repetition under constraint. A demonstration proves that a path can work once. Infrastructure must keep that path usable when demand changes, partners differ, equipment fails and people need support. SixXS developed from the IPng.nl experiment into a distributed transition service with external PoP providers.

Those partners supplied network locations through which users could establish IPv6 tunnels. Distribution increased reach, but it also created coordination work. The service operators did not own every participating network or control every last-mile provider; they had to make a common system function across organisational boundaries.

For a non-specialist, the underlying problem can be stated simply. Most internet communication was historically addressed with IPv4, whose pool of numeric addresses is limited. IPv6 provides a vastly larger address space and other protocol changes, but it cannot appear everywhere by declaration. Networks, applications and access providers have to support it in running systems.

During that uneven transition, a tunnel broker could give a user IPv6 connectivity over an existing IPv4 connection. The tunnel was useful because the provider-side upgrade was incomplete. Its value came from working code and reachable paths, not from a claim that any single operator possessed authority over the transition.

This practical character is visible in a contemporaneous record from RIPE 48 in 2004. RIPE meetings bring together operators who coordinate and discuss internet infrastructure in the European region and beyond. The meeting minutes identify Pim with BIT BV in that dated context and record him seeking additional operators for public 6to4 relays. A 6to4 relay was one mechanism for carrying IPv6 traffic across IPv4 networks during the transition. Pim reported sustained relay traffic of about 80 megabits per second. The figure is an operational report from that meeting, not proof that he alone designed the relay system or all of SixXS.

The request for more relay operators is revealing because it shows an operator trying to widen capacity through participation rather than presenting a finished object. Sustained traffic creates costs and failure modes. More relay operators can distribute load and improve reach, but each additional participant brings routing and coordination obligations.

The work involves observing traffic, recruiting capacity, keeping routes coherent and responding when reality differs from a diagram. In this sense, Pim's 2004 intervention supplies a concrete example of his role: he was not merely associated with an IPv6 idea; he was engaged with the conditions that kept transition traffic moving.

Yet a single traffic figure should not be made to carry more meaning than it can. It does not establish SixXS-wide scale by itself, and it says nothing definitive about later demand. It is most useful as a dated marker. By 2004, the precursor had evolved into work that required public operational coordination. By 2017, the relevant decision was no longer how to recruit more capacity but how to withdraw the service without treating users and partners as disposable. The contrast between those moments makes the full arc visible: expansion was once responsible; later, retirement became responsible.

Scale through cooperation, not ownership

SixXS eventually served users through a distributed set of external points of presence. The operators' retrospective gives detailed measures of its footprint and use, while independent accounts corroborate substantial activity and the service's international reach in broader terms. Those exact measures should remain attributed to the operators rather than converted into unqualified facts about Pim. What can be said safely is that a small precursor became a substantial transition service, that outside network providers were essential to it, and that it continued long enough to acquire real operational dependencies.

The institutional design matters as much as the technical design. External PoP providers contributed connectivity and resources, SixXS coordinated access and service logic, and users depended on tunnels and delegated subnets for their own IPv6 use. No participant's role eliminated the others. A central service could keep records and coordinate assignments, but records did not create absolute ownership over the underlying number resources.

They helped maintain uniqueness, routing accuracy and operational accountability. When the service later closed, those relationships could not be ended by deleting a website. Resources had to be returned through the provider relationships that made them usable.

This distributed structure explains both SixXS's strength and the complexity of its exit. Cooperation allowed the service to extend beyond the capacity of its initial operators. It also meant that a shutdown required communication across multiple parties. Providers needed to understand the schedule and resource-return process. Users needed notice and time to find alternatives. Service components had to be retired in an intelligible order. Retained data required a deletion plan. The same network of dependencies that enabled scale became the map for responsible withdrawal.

It is tempting to judge infrastructure only by how many people it reaches. Reach matters, but it is incomplete. A transition service also changes the incentives around it. For users, a reliable tunnel can turn a missing provider feature into an immediately solvable problem. For providers, the same workaround may reduce complaints or postpone investment. For the operators, growing use can validate the service while also increasing dependence on it. These effects are not automatically harmful or beneficial. Their meaning changes with the maturity of the technology and the availability of native alternatives.

SixXS therefore cannot be understood as an isolated product competing for perpetual market share. It functioned as a temporary layer in a larger technical migration. Its success depended on a gap between what users needed and what many providers supplied. If that gap narrowed because native IPv6 became more available, falling tunnel demand could be welcome evidence of progress. If some providers still pointed users toward tunnels instead of upgrading, continued availability could also preserve part of the original problem. Pim and Jeroen's later reasoning arose from this double interpretation of success.

When the bridge changes the incentives

By 2017, new tunnel uptake had declined. The operators connected that trend to growing availability of native IPv6, while also arguing that some providers treated tunnel brokers as a reason to postpone their own deployment. Independent technology reporting and outside analysis broadly corroborated the closure, the fall in growth and the operators' stated concern. The careful formulation matters: Pim and Jeroen assessed that the workaround could weaken the incentive for native service. The evidence does not establish that every provider behaved that way or that SixXS alone determined global adoption.

Still, the concern created a genuine conflict between users' immediate needs and the transition's long-term objective. Keeping SixXS open would continue to help people whose providers had not completed the upgrade. Closing it could impose migration work on those same people, including some who had used the service for years.

At the same time, indefinite continuation could signal that a volunteer-supported or partner-supported workaround would remain available whenever native investment lagged. The operators had to decide which form of continuity mattered more: continuity of the bridge, or continuity of movement toward native connectivity.

Three broad options were plausible. They could continue operating the existing service, accepting its support and coordination burden. They could reduce it gradually, perhaps restricting new use while retaining more legacy arrangements. Or they could announce an orderly retirement with time for users and providers to respond. The record shows that they chose the third course. That choice did not eliminate cost. It redistributed cost away from the operators and their partner system and toward a transition that users and access providers now had to complete through other means.

This is where the leadership dimension becomes visible. Starting a useful system often aligns reputation, user enthusiasm and technical curiosity. Ending one separates those incentives. Operators may feel loyalty to users, pride in the system, and reluctance to abandon work accumulated over years. A continuing service also provides visible evidence of relevance. Retirement gives up those benefits before every uncertainty disappears. Pim and Jeroen acted on a judgment about the service's changing role even though they could not know every downstream result.

The decision can be called a reversal, but not a repudiation of the earlier work. A bridge can be necessary at one stage and counterproductive at another. The earlier decision to build addressed the absence of native access. The later decision to close addressed the risk of permanent workaround dependence. Both decisions can be coherent if the governing objective is IPv6 transition rather than organisational survival. What changed was the environment: native availability had improved, tunnel demand had fallen, and the operators believed the remaining service could cushion providers from pressure to complete deployment.

Shutdown as an operating project

The sunset was announced rather than sprung on users. Pim and Jeroen's plan included a migration interval before the service closed in June 2017. The plan required contact with PoP providers, retirement of tunnels and subnet services, return of delegated resources and deletion of retained user data. Independent reporting confirms the closure. These are supportable operating facts, although the available material does not establish that every user migrated successfully or experienced the same disruption.

Notice is a practical form of continuity. It gives users a period in which to ask their access provider for native IPv6, seek another tunnel option, redesign a setup or accept the loss of IPv6 connectivity. It does not guarantee a solution, and the burden is not evenly distributed. A hobbyist testing a home connection and an organisation depending on a stable subnet face different consequences. By allowing time rather than closing without warning, the operators acknowledged that a transition service had become part of other people's working systems.

Partner coordination carried a different obligation. External PoP providers had supplied the network footholds that made the service distributed. They needed a shared understanding of how connections and delegated resources would be wound down. An address record, route or delegation is useful only when the operational parties agree on what it represents and keep the running configuration aligned. During retirement, accuracy means removing or returning resources in a way that prevents stale expectations. The registry or service database records the change; it does not create a sovereign claim over the internet.

Data deletion belongs in the same picture. A service that has accumulated user information cannot treat closure as freedom to forget stewardship. A retirement plan needs to determine what is still required, what must be retained for a limited reason, and what should be removed. The documented SixXS plan included deletion of retained user data. That detail is easy to overlook beside routing and address resources, but it shows that an exit involves information obligations as well as network operations.

Sequencing tied these duties together. Announcing a final date before removing working paths gave users a visible deadline and providers a coordination window. Retiring service components before returning related resources reduced the chance that records and running configurations would contradict one another.

Removing retained information after the operational need had ended limited the residue of a service that no longer existed. The available accounts document the plan and the eventual June closure more clearly than every intermediate execution detail, so the distinction between intended steps and independently observed completion should remain explicit.

Even so, the plan shows that the operators treated shutdown as a chain of dependencies rather than one administrative act. That is a practical test of continuity: not whether all change can be avoided, but whether each party can understand when its connection, resource or obligation will cease.

The June closure provides an observable organisational result: the chosen course ended the tunnel and subnet service through a planned retirement. It does not tell us every result that followed. We do not have a complete ledger of individual migrations, a controlled measure of provider behaviour after the closure, or a way to isolate Pim's contribution from Jeroen's, the providers', the users' and wider market forces. A responsible account therefore separates the decision and completed service closure from claims about global causation.

Who carried the costs and who gained

For users who still needed SixXS, the immediate effect of closure was loss of a familiar path and the need to act. Some may have gained native access, some may have found another transition mechanism, and some may have lost IPv6 capability for a period. The sources available here do not resolve those individual outcomes. That uncertainty should not be hidden behind the operators' strategic rationale. A mission-aligned decision can still impose real costs on people who have the least control over their access provider.

For PoP providers, retirement reduced an ongoing service relationship but required closeout work. For Pim, Jeroen and the wider SixXS operation, sunset ended maintenance and support obligations, yet it also ended a long-running institution in which they had invested technical effort and identity. For access providers, the removal of a prominent workaround may have made the absence of native IPv6 more visible to customers. The extent to which that visibility changed investment decisions remains unresolved; the operators' expectation should not be mistaken for measured universal effect.

For the IPv6 transition more broadly, SixXS left two legacies that should be held together. First, it demonstrated that operators could make IPv6 practically reachable across an uneven deployment landscape. Second, its shutdown argued that a successful workaround should not automatically become permanent infrastructure. The first legacy is about running code and cooperation. The second is about incentives and exit discipline. Neither requires turning the operators into owners of the transition or treating their judgment as a rule that every other tunnel broker had to follow.

Pim's particular contribution is strongest where the record is concrete. He helped set up the precursor with Cliff. He co-designed the later version with Jeroen. He appeared in an operating forum seeking relay participation and reporting traffic. He jointly operated SixXS over many years and jointly made the closure decision. The organisational results, however, remained collective. External providers supplied PoPs, users generated demand, staff and peers supported operations, and market conditions shaped the usefulness of tunnels. Individual recognition is warranted only when those adjacent contributions remain visible.

What the case supports, and what it does not

The SixXS record supports a bounded conclusion: Pim van Pelt participated in building a transition bridge and later in dismantling it when its operators believed continued availability could preserve the dependency the bridge was meant to overcome. It supports a story of organisational change, not merely a biography. The turning point is observable, the constraints are identifiable, the chosen option led to an actual closure, and the uncertainty around broader effects can be stated plainly.

The record does not prove that the shutdown caused providers everywhere to deploy IPv6. It does not prove that tunnels are inherently damaging, that every SixXS user completed a smooth migration, or that Pim alone created the service's scale. It also does not justify treating address allocations or service records as property claims beyond their operational purpose. Those boundaries do not weaken the story. They show which lesson survives without exaggeration: infrastructure leadership includes deciding whether an institution still advances the problem it was organised to solve.

The deepest lesson is therefore about reversibility of institutions, not disposability of users. SixXS could be shut down, but doing so responsibly required acknowledging dependencies and sequencing the exit. The documented operating plan covered notice, migration time, partner coordination, route and resource cleanup, service retirement and data deletion; it turned the strategic judgment into a concrete withdrawal programme. Without those planned safeguards, the same decision could have been an abandonment. The quality of the reversal depended on the care taken between announcement and closure.

That distinction is useful well beyond IPv6. Temporary platforms, emergency programmes, compatibility layers and transition funds often acquire constituencies and operating routines. Their continued activity can look like proof of need even when it also delays the intended destination. Leaders should not assume that survival equals success, but neither should they announce an exit based on theory alone. They need evidence of changing conditions, a clear account of whose dependence has formed, plausible alternatives and a closeout plan that respects the system's real users.

Pim's story is notable because it includes both halves of that discipline. The early work made a missing capability usable. The later decision asked whether continued operation served the same purpose. The available evidence cannot tell us every consequence, but it shows a joint operator willing to let the institution end. That is a less celebratory form of achievement than indefinite growth, and often a more demanding one.

Image disclosure

The accompanying image is an AI-generated photorealistic editorial scene of an anonymous network operator, seen strictly from behind while routing cables. It is not a photograph or likeness of Pim van Pelt and does not depict his appearance. The equipment is generic rather than SixXS equipment, and the scene does not represent a documented event. Its purpose is to illustrate ordinary network-operations work without making a false documentary or identity claim.

Sources