Internet Initiative Japan, Inc.
| previous 1/2 next |
Having achieved its objective, the KAME project will conclude its 8-years of operation in March 2006. The code that we implemented, such as our IPv6 code, will be maintained by the individual BSD communities and further developed. We are supportedby ipv6style.jp this time to summarize the purpose of establishing the KAME project, its activities and the outcomes.
Before the KAME project
Although the KAME project was established in 1998, it would be helpful if we start the story in 1992.
At INET ’92, held in Kobe in June 1992, it was reported that IPv4 Class B addresses were going to run out. People started looking into IPng, Internet Protocol next generation, and various candidate protocols were proposed and discussed. After two years of competition, SIPP was finally chosen to be IPng at the 30th IETF meeting held in Toronto in July 1994. The version given to it was 6, and it would become known as IPv6 after that.
Now that there was a unified plan for IPv6, engineers who previously competed with one another now collaborated, and work on standardization moved forward. As a result, in December 1995, RFC1883, which lays down the core specifications, was issued.
4 months before that, the board members of the WIDE project held a study group meeting in Fukuoka. The theme was IPv6, which was a popular topic within the IETF. Around that time, Minami-san from Keio University (hereafter Keio), who was one of Mr. Murai’s students, was already working on implementing IPv6. Also, companies participating in the WIDE project, such as NEC, Hitachi, Fujitsu, etc. were working on implementations as well.
Around that time, the most important thing regarding IPv6 was to test the specifications to see if there were any misdesigns. In order to do this, interoperability needed to be verified using multiple independent IPv6 implementations.
If we only needed to test interoperability, we could have just used the implementations by Minami-san and those companies. However, the companies would not release the source code for their IPv6 implementations. In order for us to proceed with our IPv6 research, we decided that we needed one more implementation of IPv6, which had source code that could freely be used as a reference, to compare multiple implementation methods. Around that time, I was an researchassociate at the Nara Institute of Science and Technology (hereafter NAIST) and I undertook the task of creating another IPv6 implementation as an assignment from the study group.
The person who worked on the implementation at NAIST was one of my students then,. Shima-san. We named this implementation “Hydrangea,” after the temple in Nara known as Hydrangea Temple. Both the Keio and NAIST implementations were being developed on BSD/OS. FreeBSD and NetBSD already existed around that time, however, BSD/OS was used because it had the best support for notebook PCs.
Within the WIDE project, we created an IPv6 Working Group in September and gained deeper understanding and experience by having discussions on IPv6. In December, we gathered at Keio’s Shonan Fujisawa Campus for an interoperability test. We often found new bugs each time we made let different implementations communicate. We also noticed that we sometimes misinterpreted the specifications.
As you can see, more than anything else, it was an advantage to have multiple implementations within the same group. From that time onward, the IPv6 Working Group in the WIDE project periodically conducted interoperability tests.
In February of the following year, the project members from Keio, NAIST and Hitachi visited the University of New Hampshire for a conformance test. I remember well that it was very cold, with temperatures of -2ºF, and that the seasonal Maine lobsters tasted good.
In June, we built an IPv6 backbone by adding a multiplexer into the WIDE project’s backbone and making a 64Kbps line that we took out from the T1 line as an IPv6 dedicated line. This means that we progressed from single network interoperability tests to routing tests among multiple networks. Kato-san, from the University of Tokyo, implemented the routing software using RIPng in Hydrangea in a very short time.
That same June, we connected to Cisco in California using a tunnel and became one of the initial members of the global 6bone. Sumikawa-san, who was the successor to Shima-san, played a big role in this.
Our rivals around that time were INRIA, which targeted NetBSD/FreeBSD, and NRL, which targeted the four BSDs. INRIA had already released their source code.
We, on the other hand, were cautious about releasing Hydrangea. It is true that this was because we didn’t want to release it until the quality was good. However, the biggest issue was that we targeted BSD/OS, which was a commercial product. If we had simply released it, there could have been a conflict with the BSD/OS licensing agreement. So we were continuously negotiating with its developer, BSDI.
In March 1997, Hagino-san ported Hydrangea to FreeBSD. In September of the same year, we discovered that BSDI adopted NRL code. We had no choice but to switch to FreeBSD.
In the end, Hydrangea was only released within the WIDE project and was never released to the public. However, you will soon see that this wasn’t a step backwards, but actually the first step towards major progress.
The 40th IETF meeting was held in Washington, DC, in December 1997. The breakfast for the IETF meeting was set up in the hotel foyer in a buffet style. When I was drinking coffee, Atarashi-san, from Hitachi (currently works for ALAXALA Networks), Mr. Esaki, from Toshiba (currently works for the University of Tokyo), and others gathered around me.
In the past, it had been an advantage to have multiple implementations within the WIDE project. However, at that time, We felt that it was becoming a hindrance. Now that we had confirmed that there was no fatal flaw in the IPv6 specifications, it was inefficient to work separately on the same things. When I candidly broached the subject, the people there agreed with me and decided to look into whether the implementation efforts could be integrated.
On the same day, to discuss this matter, We visited Mr. Murai who was staying in the same hotel. When I got to the door of his hotel room, I felt as if there was a new world waiting for us behind that door.
Founding the KAME project
With Mr. Murai’s support, the people who came to be called “big brothers” quickly started taking action to gather manpower.
Companies such as Fujitsu, Hitachi, NEC,Toshiba, etc., who, under normal circumstances, would be in competition with one another, were going to work on an IPv6 implementation together. Moreover, the deliverable would be released as free software. An ambitious goal had been set, one that was unlikely to have been achieved in Japan until that point.
Since this unconventional project was going to involve companies, the project had to be successful. In order to be successful, it was necessary for the companies to send their top guns in for this project. So, the condition for programmers to participate was that they had to be the most active members of the IPv6 Working Group. This was because “people come first.”
The job of choosing top guns was left to me as I was chosen as the technical leader. Around that time, I decided to change my employer from NAIST to Internet Initiative Japan in Tokyo.
After choosing top guns, we had to get approvals from the companies where those top guns worked and ask them to send these people to the project. Mr. Murai visited each company with his bag full of a dream; “contributing to the world by creating free reference code and propagating IPv6”.
We called the people sent by each company who actually wrote code “core”, their bosses “papa” and the people who worked on various things in-between “big brother”. By the time anyone realized, those nicknames had stuck.
In order for the “core” members to concentrate on the implementation, it was necessary to secure time where they weren't constrained by miscellaneous tasks at their companies. So, we created a “three-day rule”. The office was located in the building that Mr. Murai was renting in Karigome. It is near Keio’s Shonan Fujisawa Campus, far from Tokyo. They had to come to this office three days a week to concentrate on the implementation.
The KAME project was established in April 1998. Naturally, the WIDE project and each company signed official contracts. When We think back now, We would say it was nothing less than astonishing that those preparations were done within only 4 months.
The following is the list of participating companies at the start of the project.
Fujitsu Limited
Hitachi, Ltd. (The unit that participated in the KAME project has become ALAXALA Networks Corporation.)
Internet Initiative Japan, Inc.
NEC Corporation
Toshiba Corporation
Yokogawa Digital Computer Corporation (The unit that participated in the KAME project was transferred to Yokogawa Electric Corporation.)
Yokogawa Electric Corporation
This has already been discussed exhaustively, but I would like to explain the source of the project name. The code name while we were preparing the project was “the kame project” (“kame” means turtle and/or tortoise).
It was in October 1997 when that small incident happened. The interoperability test by the WIDE IPv6 Working Group was being conducted at the Japan Advanced Institute of Science and Technology. Hagino-san was working on a bug in Hydrangea. However, he could not figure out the reason for the bug. So he hugged the plush turtle by his side and shouted, “oh, Kame-san, help me!” After that, the word “kame” became popular among us.
In the preparation meeting in March 1998, we were to decide the official name for the project. I opposed the name “KAME,” a word that non-Japanese poeple cannot pronounce correctly, and suggested the shortened version of Hydrangea, “Hydra”. However, in the end, we decided on “KAME”.
So, the name is coming literally from the animal “kame”. There is no official view as to whether it is a turtle or a tortoise.
History of operations
The goal of the KAME project is to “provide reference code for IPv6, IPsec, and advanced network protocols”.
Looking at the history of the Internet, BSD’s contribution is shining. The BSD provided by CSRG, University of California, Berkeley, became the reference code for IPv4. I imagine many engineers learned from this code and then wrote their own code for products. TCP/IP Illustrated Vol. II, which describes the BSD’s networking code, by W. Richard Stevens, is a bible to engineers.
The KAME project wanted to play the same role in IPv6 propagation as BSD played in IPv4 propagation.
In 1998, there were four BSDs that were derived from 4.4BSD. They were the commercial BSD/OS, and three free BSDs: FreeBSD, NetBSD and OpenBSD. It was going to be a lot of work, but the KAME project planned to provide code to all the BSDs.
The following is the three forms of code that we were going to provide:
- snap
This is the snapshot of the latest implementation at the time. Since it is the latest implementation, it may be unstable. Released every Monday. - stable
This is code which has had its stability confirmed after removing unstable code. Released every odd month whenever possible. - release
This is the code we call “stable” that is released at each milestone of the KAME project. To users, there is no difference between this and “stable”.
The reason for providing possibly unstable “snap” was based on what we learned from Hydrangea. Because Hydrangea was never publicly released due to our fixation on quality, it ended not having much visibility worldwide.
So, we decided to release the code even when it could still be improved without feeling self-conscious about it. Of course, there was a possibility that we might give people a bad impression; however, there was a greater possibility that it would have positive effects. First, people from outside would be able to see we actively work on the code, and second, it would give us incentive to immediately improve the code in order not to feel embarrassed about it.
Code integration was done by merging each company’s stellar parts, using Hydrangea as a base. For the collaboration tool, we used CVS. First, we decided on a coding style. After that, each individual, at his own discretion, started merging in parts of his implementation. If merging the code caused a conflict, it was the responsibility of the person whose code caused the conflict to fix it later. In other words, when merging, it was on a first-come basis.
It was commonplace that the “core” members stayed over night at the Karigome office, and we were able to release the first “snap” in May and the first “stable” in June. Releasing “snap” every week has been done continuously up until now. Even after merging completed, we continued to implement the latest specifications using this development process.
We participated in every conformance and interoperability test. Also, in order to objectively verify the quality of the code provided by the KAME project, the WIDE project started the TAHI project, in which people such as Okabe-san, from Yokogawa Electric, and Miyata-san, from Yokogawa Digital Computer (now works for Yokogawa Electric), played primary roles. It seems that the TAHI project has received recognition for its steady activities, and that the testing tool provided by this project has now become the de-facto standard.
Our wish was to provide code that would run equally well on the four BSDs. In spite of the fact that those four were derived from the same 4.4BSD, each BSD network implementation is very different from the others. The IPv6 code and other code that we wrote was written from scratch, so we were able to broadly standardize it. However, many complicated condition cases were put in the code in order to deal with differences among each OS.
Furthermore, when each BSD released a new version, we had to support both the old and new versions. There was one time when we were managing 10 versions for 4 OSes.
These efforts were rewarded and the KAME project gradually came to be recognized. By the summer of 1999, it was decided that all BSDs were going to adopt it. This was also because the NRL and INRIA project s were having difficulty continuing due to financial and human resource problems.
The NRL IPv6 code was removed from BSD/OS and was replaced with the KAME code. The free BSDs adopted the KAME code as is. However, OpenBSD’s IPsec code is implemented independently. It was at the end of the year 2000 that its ubiquity on BSD was achieved.
Dates when the KAME code was merged on each BSD, and the BSD version at the time are
BSD/OS 4.2 |
November 29, 2000 |
FreeBSD 4.0 |
March 14, 2000 |
NetBSD 1.5 |
December 6, 2000 |
OpenBSD 2.8 |
December 1, 2000 |
The outcome of the KAME project was used in the following products, among others:
Hitachi router/switch, GR/GS series
Fujitsu router, GeoStream R900 series/GeoStream Si-R series
IIJ router, SEIL
Extreme switches
ALAXALA Networks routers/switches
CEC camera servers
Ricoh printers
Also Mac OS X is based on FreeBSD, which adopted the KAME code. If you would like to try out the KAME code, you can use Mac OS X.
The KAME project was recognized by the IETF as well and has become an influential player. Hagino-san becoming a co-chair for the IETF v6ops working group and a member of the IAB symbolizes this.
Our activities were also recognized by the Japanese government, and we were given an award for our contributions to the promotion of Information Technology by the Ministry of Internal Affairs in October 2002. The reasons for the award were as follows:
Through its research and development on IPv6, the next generation Internet protocol, and its release of the results, the KAME project has internationally shown leadership in IPv6 research and development and in its standardization and implementation, and has contributed greatly to the propagation of IPv6.
Furthermore, Mr. Murai’s work on IPv6 development and contribution to its propagation were recognized, and he was awarded the Postel Award in the 63rd IETF meeting in Paris in August 2005.
As you can see, the KAME project has more than accomplished its goal of providing reference code. This may seem like bragging, but as a summarization of this project, the two books shown below will be published shortly. (see the Listing of outcomes for details)
IPv6 Core Protocols Implementation
IPv6 Advanced Protocols Implementation
These books explain our code and were written by people including Jinmei-san and Shima-san, who are “core” members. I hope that these books become a guide for engineers interested in learning about IPv6.
| previous 1/2 next |
