| previous 2/2 next |
Individual components
IPv6
Using Hydrangea as a base, we merged in each company’s code. The code for extension headers is based largely on Toshiba’s contribution. After completing the merge, we actively implemented the RFCs and Internet-Draft. We implemented various things such as the basec specifications, auto-configuration, tunneling, routing, address scopes, API, DHCPv6. Hagino-san and Jinmei-san actively implemented these.
After it was incorporated into BSD, a new problem was born. The problem was that BSD users would become confused when the specifications changed considerably due to a revision in an Internet-Draft. So, we decided, as a general rule, to release the implementation of the Internet-Draft specifications as “snaps” and to reduce the code in BSD to only the implementation of the RFC.
IPsec
The IPsec code can be classified broadly into two parts: the implementation of IPsec itself within kernel space, and the key exchange software in user space. Our IPsec for IPv4 and IPv6 is merged into FreeBSD and NetBSD. Unfortunately, in the future our code will probably be replaced with OpenBSD-derived code that works well with cryptographic hardware. However, it’s fair to say that it was noteworthy that we were able to provide a stable IPsec stack that implemented the specifications without any delay and that anyone can use freely.
The name of the key exchange software is racoon. racoon version 1 was adopted not only in BSD but also in Linux. racoon version 1 now has left the hands of its author, Sakane-san, and is being maintained on sourceforge.net as IPsec-Tools.
Sakane-san, on the other hand, is currently concentrating on implementing racoon version 2. racoon version 2 is being developed by several members. Its primary strengths are that policy management is implemented in user space and that it supports both IKE version 2 and KINK. The IKE version 2 implementation in racoon version 2 showed good results in an interoperability test. racoon version 2 is the first implementation of KINK in the first implementation in the world that anyone can use freely. Another difference from racoon version 1 is that this version had support for Linux from the start. Development work is continuing so that it will be more compliant with the specifications and it can be used for Mobile IPv6.
Mobile IPv6
First, we were merging the Mobile IPv6 code, which Ericsson developed as a loadable module, into “snaps”. Once Shima-san became a “core” person, we started developing our own code in kernel space. Around the time when a large change in the Mobile IPv6 specifications occurred, Momose-san joined the “core” group in the third term and started working on the development and maintenance of the Mobile IPv6 code together with Shima-san. Since it took a long time for the specifications to become an RFC, it was provided in “snaps” only, unfortunately.
We are currently implementing code called SHISA. We are working together with Uehara-san, Wakikawa-san, and Mitsuya-san, who were working on the implementation of Mobile IPv6 at Keio University. It replaces the old code and is released in “snaps”.
In SHISA, the signaling implementation was moved from kernel space into user space. So, even if there are more changes in specifications, which often happened in the past, all we have to do in SHISA is to change the user space program. Because of this, it will not have that much impact on our code being merged into the BSD kernel any longer. In SHISA, in addition to Mobile IPv6, an implementation of NEMO is provided in “snaps” now that we have resolved the patent issues (mentioned below). We are currently considering merging SHISA into BSD.
Multicasting
With IPv4, the multicasting routing was implemented in each OS separately. Because of that, the level of support differed from OS to OS, and APIs also differed among the multicasting-enabled OSes. This divided state was one of the constraining factors for the deployment of IPv4 multicast.
In the KAME project, with Jinmei-san playing the primary role, we implemented the IPv6 multicast routing and routing software so that they are the same on all BSDs, and merged them with all the BSDs. Because of that, you can use the same IPv6 multicast routing software on any BSD. This was a big advancement toward the deployment of multicasting.
Also, the IPv6 multicast routing software developed by the KAME project supports SSM, works on Linux, and is currently being maintained on sourceforge.net as the mcast-tools project.
Furthermore, as part of the KAME project, Suzuki-san has implemented an IGMPv3/MLDv2 host feature for all the BSDs based on the IGMPv3 host implementation for NetBSD developed by Asaeda-san, from INRIA (now at Keio). We plan to merge this feature into BSD in the future.
Patent issues
Regarding patent issues, the IETF’s policy is that even if some parts of a protocol conflicts with a patent, if the patent holder licenses that technology to anyone fairly and impartially, the protocol can be a Proposed Standard. It is okay to require a usage fee or contract.
In the KAME project, we have implemented not only protocols that have no patent issues, of course, but also ones that were already patented, if we could use them free without contracts. However, we had a policy that we did not implement things that required a contract or usage fee.
The reasons for this are as follows. First, the outcomes of the KAME project are free, so it would be a problem if it requires a fee. Next, about contracts, there are two cases. One is when the contract is with the implementer; the other is when it is with the user. If the KAME project, the implementer, is required to agree to a contract, we have a problem because there is no scheme for signing a contact in the KAME project.
If users are required to agree to a contract, the KAME project cannot help them and it is not our wish that restrictions, such as signing a contract, be put on the outcomes of the KAME project. There were also patents that were not clear as to who had to agree to the contact, us or the users, to begin with.
The following is the protocols that have patent issues that caused troubles with the KAME project:
Source Specific Multicast (SSM)
Modular Exponential (MODP)
Network Mobility (NEMO)
Internet Key Exchange version 2 (IKEv2)
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Virtual Router Redundancy Protocol (VRRP)
SEcure Neighbor Discovery (SEND)
NAT Traversal (NAT-T)/UDP-ENCAP
With regards to this policy, there was an opinion within the project that we should not overreact to the patents that companies obtained not in order to gain profits, but in order not to be sued. There was also an opinion that it would be a waste if we didn’t use the code we created because we didn’t realize there were patent issues.
So, we decided to negotiate with the companies that have patents so that we could provide an implementation of KAME. With the help of Keio’s Murakami-san, who is familiar with the law, we resolved the issues with NEMO and ISATAP, and were able to release the implementation.
Goals and evaluation for each term
Below, the goals and self-assessments for each term are shown.
The first term
The objectives for this term were merging code from the multiple IPv6 and IPsec implementations within the WIDE project and compliance with the latest specifications.
These objectives were completely achieved. The details of these objectives covered a wide variety of things, including IPv6 (specifications, API, etc.), IPsec, key exchange software, a translator, and adding support for IPv6 to each application.
It was very successful as you can see from the fact that all four BSDs decided to adopt KAME.
The second term
As with the first term, the objective was to continue development activities and feed back the outcomes of the KAME project to the BSD community, etc.
Once the stable KAME code was merged into all four BSDs, we were able to achieve this objective. Examples of the results of our development activities include the start of a Mobile IPv6 implementation and the development of multicasting-related code. There were also some companies who started building KAME code into their products. So, this part of the project was very successful.
On the other hand, as the KAME project gained fame, we got busy, getting dragged out to lectures, tutorials, events, etc. and so the “three-day rule” was no longer working. This was one of the things that we reflected on.
The third term
The objectives for FY2002 were implementing new protocols and keeping pace with protocol updates. For FY2003, the objectives were to transfer technology in order for each BSD to independently maintain IPv6, IPsec, and Mobile IPv6 after completing the third term; and to continuously implement new protocols and keep pace with the protocol updates.
Since the “core” members became busy, it became difficult to get together at the Karigome office in Fujisawa. So we moved our office to Keio Shin-Kawasaki Town Campus, which is close to Tokyo, at the end of the second term.
We were able to achieve objectives of implementing new protocols and keeping pace with protocol updates to our satisfaction. However, I would not say that we were able to create an ideal environment where BSD or other application developers can continue maintaining the code independently. In fact, among the major technology components, some had not completed the merge to BSD, and the “core” memberswere also often asked for advice about new developments on the BSD side.
The main causes for this were that there were many features and protocols that did not become an RFC due to the delay on developing specifications at the IETF; and that we were not able to merge SSM, ISATAP and VRRP because patent and licensing issues surfaced.
The fourth term
The fourth term started with objectives to create a system where the BSD community can independently maintain the code and to conclude the KAME project. However, in FY2004, we continued implementation of new features.
Confronting the patent issues, we resolved issues with a few protocols and were able to release the code to the BSD community. Also, we are currently focusing on merging the features left in “snaps” into each BSD.
Future development
The “core” members will each be working in the areas they are interested in. There are people who want to focus on advanced protocols that will further expand IPv6. Some others will move their emphasis to applications that can expand the use of IPv6. Of course, they are actively taking part in the BSD community. So, as members of each of the BSD communities, they will be further expanding IPv6 and other code.
Listing of outcomes
The RFCs released as outcomes of discussions by the KAME project members at the IETF meetings are as follows:
3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001.
3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001.
3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003.
3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005.
3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005.
4007 IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005.
4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005.
4074 Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005.
The books written by KAME project members are as follows:
IPv6 Network Programming, Jun-ichiro Hagino, translated by Ayako Ogawa, ASCII
IPv6 Network Programming, Jun-ichiro itojun Hagino, Digital Press
IPv6 Network Programming, Jun-ichiro Hagino, DRMaster
IPv6 Networks Basic Guide, Sumikawa, Suzuki, Oura, Shibata, Watanabe, Nikkei BP
IPv6 Advanced Protocols Implementation, Qing Li, Tatuya Jinmei, Keiichi Shima, Morgan Kaufmann, an Elsevier Imprint (soon to be released)
IPv6 Core Protocols Implementation, Qing Li, Tatuya Jinmei, Keiichi Shima, Morgan Kaufmann, an Elsevier Imprint (soon to be released)
The KAME-related theses are as follows:
“Modeling IP Tunneling and Its Implementation”, Kazuhiko Yamamoto, Computer Software, Vol.15, No. 2, 1998, pp. 38-47.
“Efficient Use of IPv6 Auto-Configuration in a Mobile Environment”, Tatuya Jinmei, Jun-ichiro Ito, Munechika Sumikawa, Information Processing Society of Japan, SIG Mobile Computing, The 7th Research Reporting Session, December 1998
"An overview of the KAME network software: Design and implementation of the advanced internetworking platform",Tatuya Jinmei, Kazu Yamamoto, Jun-ichiro Hagino, Munechika Sumikawa, Yoshinobu Inoue, Kazuhi Sugyo, and Shoichi Sakane, in Proceedings of INET99, 1999.
“IPv6 Operating System Development by the KAME project”, Tatuya Jinmei, Kazuhiko Yamamoto, Jun-ichiro Hagino, Hiroshi Esaki, Jun Murai, Information Processing, Vol. 41, No. 12, 2000, pp. 1367-1372.
"Implementation and Deployment of IPv6 Multicasting", JINMEI Tatuya, in Proceedings of INET 2000, July 2000.
“Making PIM Ready for IPv6”, Tatuya Jinmei, Information Processing, Vol.42, No. 8, 2001, pp. 760-764.
“IP Packet Reception Process Using a Routing Table”, Tatuya Jinmei, Jun Onoue, Kazuhiko Yamamoto, Jun-ichiro Hagino, Hiroshi Esaki, Jun Murai, IEICE Theses Magazine, Vol. J85-B, Nov. 8, 2002, pp. 1331-1338.
"Implementing IPv6: Experiences at KAME project ", Jun-ichiro itojun Hagino, IEEE 2003 Symposium on Applications and the Internet (SAINT2003) workshop, January 2003.
"MLDv2 Protocol Design, Implementation and Evaluation for Source-Specific Multicast over IPv6", Hitoshi Asaeda, Shinsuke Suzuki, IEEE 2003 Symposium on Applications and the Internet (SAINT2003) workshop, January 2003.
"The IPv6 Software Platform for BSD", Tatuya Jinmei, Kazuhiko Yamamoto, Jun-ichiro itojun Hagino, Shoichi Sakane, Hiroshi Esaki, and Jun Murai, IEICE Transactions on Communications, Vol.E86-B, No.2, pp. 464-471, February 2003
"A method of processing inbound IP packets with a routing table", Tatuya Jinmei, Atsushi Onoe, Kazuhiko Yamamoto, Jun-ichiro Hagino, Hiroshi Esaki, and Jun Murai, Electronics and Communications in Japan (Part I: Communications), Vol.86, No.9, September 2003.
“Design and Implementation of Address Management Methods for the Next Generation Internet”, Tatuya Jinmei, Ph.D Dissertation, Graduate School of Media and Governance, Keio University, July 2003.
Links:
KAME project
http://www.kame.net
KAME project News
http://www.mew.org/~kazu/kame
History of WIDE v6 WG
http://www.v6.wide.ad.jp/Events/
| previous 2/2 next |
