Summary

  • On 9 June 1996, WIDE recorded its first IPv6 round trip between Nara Institute of Science and Technology and its Tokyo NOC over a serial line, not an IPv6-in-IPv4 tunnel.
  • WIDE split one T1 into a 1,472 kbps IPv4 link and a 64 kbps IPv6 link; its retrospective says this avoided another leased-line cost and kept the two networks from interfering with one another’s operation.

The first packet took a narrow road

The start of WIDE 6bone was not a miniature version of the later global overlay. In its own account, WIDE’s first IPv6 packet crossed a serial circuit between Nara and Tokyo at 15:22 Japan time on 9 June 1996. The project had divided an existing T1: 1,472 kbps stayed with the regular IPv4 network and 64 kbps was assigned to IPv6. The authors give two practical reasons. They did not have to pay for an additional leased line, and IPv6 experimentation would not affect operation of the IPv4 network. This is a report of design intent, not a measured guarantee of isolation or user throughput.

The arrangement also shows that a new protocol could begin as a bounded local service before it depended on a tunnel across the wider Internet. WIDE reports that the University of Tokyo connected to the Tokyo NOC the same day and Osaka University joined a week later. At first, IPv4-compatible IPv6 addresses were used for convenience, while routes were entered manually because routing daemons were not yet available.

Local links became part of a wider testbed

At the June 1996 6bone meeting during IETF 36 in Montreal, WIDE says participants agreed to establish a worldwide 6bone on 15 July. The team changed from its initial IPv4-compatible addresses to the then-current IPv6 test addresses before that date. Cisco became WIDE’s first peer on 16 July. Two days later WIDE added an IPv6-over-IPv4 tunnel with G6. The sequence matters: the first WIDE round trip used a serial link; the later tunnel connected the site to another 6bone participant.

Growth brought a different operating problem. WIDE says its static routes became hard to maintain as participants increased, so it installed RIPng in February 1997. Six months later, the report counted more than ten hops inside WIDE’s network and 300 full routes in the worldwide 6bone. Those are snapshots in a participant retrospective, not a complete deployment census. RIPE’s IPv6 working-group minutes separately reported more than 120 connected sites in 30 countries at an earlier meeting, illustrating that the wider project was already geographically distributed.

Addressing and routing had to move too

The network did not hold one address plan or routing protocol throughout its first years. WIDE reports that an IETF meeting in Munich in August 1997 set two operational changes: renumber from provider-based addresses to the new aggregatable format and move to BGP4+ by 1 November. WIDE had been selected as a pseudo top-level aggregator and received 3ffe:500::/24; it renumbered in October. BGP4+ arrived in January 1998, later than planned, because development of the daemon was delayed.

That transition fits the status of the addresses. RFC 1897 had described early IPv6 test addresses as temporary and told users that renumbering would be necessary. RFC 2471 later assigned test space for the 6bone under the same temporary principle. These documents establish that test allocations were not permanent production prefixes; they do not independently verify WIDE’s local migration dates. RFC 2772’s routing guidance also treated the 6bone as an operational testbed, with registry records, routing rules and experience requirements for pTLA applicants.

WIDE’s case is therefore more specific than a story of IPv6 “using tunnels.” A 64 kbps slice of an existing T1 was enough to start one local network. Peering, a tunnel, changing address plans and a new routing daemon followed as the work widened. The account supports that sequence for WIDE; it does not prove that the same route, budget or adoption path was available to every participant.

Sources

  • WIDE IPv6 Working Group, “Deployment and Experiences of WIDE 6bone”: participant report.
  • Robert Hinden and Jon Postel, RFC 1897, “IPv6 Testing Address Allocation”: RFC.
  • Robert Hinden, Robert Fink and Jon Postel, RFC 2471, “IPv6 Testing Address Allocation”: RFC.
  • Rob Rockell and Robert Fink, RFC 2772, “6Bone Backbone Routing Guidelines”: RFC.
  • Robert Fink and Robert Hinden, RFC 3701, “6bone Phaseout Plan”: RFC.
  • RIPE 28 IPv6 working-group minutes: meeting record.
  • Heng Lu, Note 64, used as an editorial lens only: note.