Currently, some experiments on IPv6 large networks such as 6bone have been conducted. However, to spread IPv6 to the end of the networks, it is time to consider networks used for small organizations or the home. In this paper, we discuss the methodology to construct IPv6 networks for small organizations. Furthermore, we propose an IPv6 INS (N-ISDN in Japan) router as a key element for IPv6 small networks, and developed the IPv6 INS router. We also describe the design and implementation of the IPv6 INS router, and evaluate it by some experimental operations.
With the growth of the Internet, significant problems have appeared on IPv4. In response to these problems, IPv6 was designed at theInternet Engineering Task Force (IETF). The worldwide IPv6 backbone is the main research theme.
On the contrary, the authors focus on networks for small office and home office (SOHO). We discuss the methodology of constructing IPv6 networks for SOHO, and describe the design and implementation of the IPv6 INS router in this paper.
IPv4, which is widely used in the current Internet, has problems such as a shortage of address space and the explosion of the routing tables, etc. To counteract these problems, several techniques, such as CIDR and NAT, were introduced. However, these countermeasures are not real solutions.
To solve these problems, the new Internet Protocol (IP), IPv6, has been standardized at IETF. IPv6 has many advantages, such as the following:
The shortage of address spaces is a serious problem in developing countries and small organizations.
When users in Japan connect to the Internet from small offices or their homes, they usually use low-speed leased lines, N-ISDN, and analog modems, etc. Most of these services allocate only one or a few IP addresses. There are not enough addresses to be allocated to all hosts in a Local Area Network (LAN). In these cases, private addresses are allocated to the hosts, and translated to global address at the edge router by NAT. This problem is not limited to the small organization; some developing countries use private addresses in their country's backbone.
Basically, the host that is allocated a private address cannot be connected from the outside directly. A special setting is required for NAT if a private address is allocated to a server that should be connected from the outside. NAT is only a temporary countermeasure. The communication model in the Internet should be between end hosts that have unique IP addresses. Use of NAT violates this model.
A real solution to the shortage of IP address space is to spread the address space. Ipv6's large address space provides sufficient addresses to small organizations and developing countries. In addition, it revives the end-to-end communication model in the Internet.
IPv6 is indeed practical in small organizations and developing countries.
In this section, we focus on SOHO networks and summarize techniques used to introduce IPv6 to SOHO networks.
Currenty, most intranets use IPv4. To introducing IPv6 to intranets, IPv4 and IPv6 must coexist. In this case, it is recommended to transition to IPv6 without suspending the various services that are already provided over the IPv4 networks. The goal is to move all services to IPv6. However, during the switchover, only those applications that are compliant with IPv4 will be used for IPv6.
In the sections below, we describe the methodology of the coexistence of IPv4 and IPv6 from two aspects: host requirements and network requirements.
Hosts should be dual stacks that can process both IPv4 and IPv6. The host communicates via IPv6 to hosts that are compliant with IPv6. If the destination host is compliant with IPv4 only, that host uses IPv4. In both cases, the protocols are transparent to the users.
The network application programming interface (API) was changed along with the length of the IP address. Therefore, modifications to the applications are necessary. Although it is ideal that all applications become IPv6 compliant, some of them are no longer maintained. Hence, a mechanism that comprehensively translates applications for IPv4 into IPv6 should be introduced. Two methods could be used as the mechanism: translating whole networks using "translator" and translating protocol in a host.
All intranet routers must be able to forward both IPv4 and IPv6 packets. As IPv6 routers, they must provide router advertisement (RA). Also, there must be a mechanism for connection outside of the IPv6 network. In the beginning of the transition to IPv6, most of the Internet will use only IPv4. In this case, IP tunneling is used to carry IPv6 packets through the IPv4 networks. At the end of the transition, most of the Internet will use IPv6. Then IPv4 over IPv6 tunneling would be used. In addition, protocol translators are needed so that hosts in the IPv4 networks can use IPv6 services.
When users in Japan connect to the Internet from SOHO, they usually use low-speed leased line, N-ISDN, and analog modem, etc. In these cases, the throughput is 128Kbps or lower.
Comparing 128Kbps leased line with INS (the name of service of N-ISDN in Japan), the former costs 112,000 yen per month, and the latter costs about 8 yen per minute. Therefore, if connecting time is shorter than 8 hours per day, INS is less expensive. In many cases, the INS connection is suitable for SOHO to connect to the outside network in Japan.
In this section, we compare two methods to connect to the outside network via IPv6: using INS bridges and using INS routers.
When the authors began to make connections via IPv6 in 1997, no IPv6 INS routers were commercially available. Then, we decided to make connections via IPv6 using INS bridges. The topology of networks using INS bridges is shown in figure 1.
Figure 1: Network topology using INS bridges
The authors observed the following problems while operating these networks:
Based on our experiences, we considered the necessity of IPv6 INS routers. Using the INS routers, the topology of connections is shown in figure 2.
Figure 2: The network topology using IPv6 INS routers
Using IPv6 INS routers, the following benefits appear:
The authors have been developing the IPv6 INS router since 1998. This project is the joint research project of Ohno Laboratory, Tokyo Institute of Technology, and the Yamaha corporation. The IPv6 protocol stack is implemented on Yamaha's INS router, using the development code WS-One. WS-One is implemented on an embedded Realtime Operation System (RTOS). In the current implementation, IPv6 transaction is separated from the other tasks. A reduction in speed caused by the passing of IPv6 packets was predicted in this design. However, by estimating the decrease of the speed and priority of the development efficiency, we have accepted the design, which enables IPv6 protocol stacks to be developed without the constraint of IPv4 protocol stacks.
The clients targeted to use Yamaha's INS routers range from SOHO users to high end users such as ISPs. Developing IPv6 protocol stacks for these routers is effective from SOHOs to ISPs. This makes a great contribution to the deployment of IPv6.
Currently, the firmware compliant with IPv6 is in the alpha testing phase. We have distributed the firmware to some members of the Widely Integrated Distributed Environment (WIDE) project, to examine it. In Japan, only this implementation is in the alpha testing phase and is distributed to users.
As an example of the construction of IPv6 networks, we introduced networks in our laboratory, where our main research theme is the methodology of the construction and administration of networks, especially networks for small organizations. We also considered the mobility of networks and hosts. Under the model we proposed, the mobility of a host is a special case of separation and migration of a portion of the networks. Therefore we discussed how to divide and move networks.
We began to construct our networks in 1997. At that time, we constructed the independent IPv6 segment, which was connected to a neighbor organization using INS. From the neighbor organization, it was connected to 6Bone with a leased line. The IPv6 segment was connected with the IPv4 segment inside the laboratory, then all the segments became IPv6 complient in the laboratory at the end of 1998. When our laboratory separated into two sites in 1999, we prepared the IPv6 connection using INS to connect both sites (see figure 3).
Figure 3: Laboratory networks
The migration to IPv6 required the replacement of all server software, routers, and clients. Usually, this replacement is difficult. However, the PICKLES system, which was developed in our laboratory, solves this problem. PICKLES is the common OS platform in our laboratory. Currently, PICKLES is based on BSD/OS, which is a PC-UNIX operating system. We introduced KAME IPv6 protocol stacks to PICKLES.
Basically, PICKLES divides software modules. In designing PICKLES, we separated information on the UNIX system depending on who has responsibility, and recorded this information in separated modules. For instance, PICKLES developers are responsible for OS and applications, which were stored in the system disk. Therefore, administrators can upgrade the OS only by exchanging the system disk, without reconfiguring the hosts. When we upgraded all hosts in the laboratory to be complient with IPv6, we replaced only the system disks. PICKLES made the deployment of IPv6 in the laboratory much easier.
Many applications are already compliant with IPv6, and we intend to introduce IPv6 applications to PICKLES. Below, we describe the some of the applications installed on PICKLES.
Even in small organizations, which have few members, security is mandatory. Because IPv6 is just becoming popular, there is still little possibility it's code can be "cracked." However, IPv6 security tools are also being developed. Therefore, it is time to give careful consideration to IPv6 security.
The most significant specification of IPv6 is large address space. This allows for the revival of the original Internet communications model, end-to-end host communication. This model might be not suited to the network security model that uses firewalls. For IPv6, we must consider security for individual hosts, not for organizations. Although the communication circuit between hosts can be protected by IPsec, we must consider the protection method against attacks from the outside.
If each host is administered independently, the security level depends on the skill of administrator of each host. Although software components for security are unified by using PICKLES, the low skill of newbie administrators in a laboratory might not assure the proper security level.
In our laboratory, we constructed an IPv4 firewall. We decided to construct an IPv6 firewall, too. As packet filtering software, we ported ip6fw for FreeBSD to BSD/OS, then installed it on PICKLES.
In this section, we describe the operations of IPv6 experimental networks, and evaluate those networks.
Operation of the laboratory networks is divided into two aspects: deployment and outside connection.
As an experiment with IPv6 in our laboratory, we set up an "IPv6 day." During IPv6 day, we stopped forwarding IPv4 packets in our intranet. We examined the following services at the end of the day.
From this experiment, we determined that IPv6 is robust enough for daily use. In addition, we considered the unavailability of some basic services, such as printing services.
As described above, our laboratory used an INS bridge to connect to a neighbor organization. To replace the INS bridges with INS routers, we connected our laboratory with Yamaha using WS-One. The experiment was conducted from 14-15 September 1999. The test was successful. Address advertisement of WS-One worked without problems, too.
The WIDE project workshop was held from 6-9 September 1999. We prepared a pair of WS-One's to provide connection from the workshop network to the outside. More than 200 people participated the workshop. The aim of our experiment was to evaluate the performance and stability of WS-One.
In this experiment, we prepared a pair of WS-One's, and provided the INS connection from the workshop networks to the outside. We used static routing. In the first plan, only some services would pass through WS-One. However, because WS-One have worked fine, all of IPv6 traffic was passed through WS-One during the workshop days.
The results of the experiments are shown in figures 4 through 8. In the graph, a cross-axis shows time and a spindle shows the number of channels.
Figure 4: Results on 6 September 1999
Figure 5: Results on 7 September 1999, a.m.
Figure 6: Results on 7 September 1999, p.m.
Figure 7: Result on 8 September 1999, a.m.
Figure 8: Results on 8 September 1999, p.m.
During those three days, there were only two abnormal terminations. We guessed that the rapid up and down of the ISDN interface caused the terminations. Finally, WS-One could work at least 24 hours in the experiments. From these results, we have successfully determined the expected stability of WS-One.
By the experiments, it was proven that we can depend on IPv6 for daily use. Opensource software can easily be modified for compliance with IPv6. Utilization of DNS is essential. Dynamic DNS update of IPv6 addresses, which are allocated automatically, is necessary. Statically allocating alias addresses is practical.
Moreover, private addresses for IPv4 and global addresses for IPv6 may be used in SOHO. In this case, the name server must return IPv6 global addresses and IPv4 global addresses for inquiry from outside, and must return IPv6 global addresses and IPv4 private addresses for inquiry from inside. With a single name server, we must use the name database properly in every source address of each inquiry. However no implementation that has this function exists at present. When name servers for the inside and the outside are separated, a method to synchronize the databases of the IPv6 global address becomes necessary.
Some ISPs in Japan have already announced that they will provide IPv6 services. Thus, an environment in which users can connect to the IPv6 backbone will soon exist. Currently, INS connection is suitable for SOHO users. From the results of experiment in the WIDE workshop, we have determined that INS connection is suitable when a short-term Internet connectivity is necessary. In the experiment, the connecting time was about 10 hours a day. Including the installation fee, INS was less expensive than the leased line in that case.
When we compare INS bridges and INS routers, we find that the latter do not need unnecessary segments and equipment. In addition, setting of packet filtering is reduced, which results in lowered administration costs.
We considered the methodology to construct IPv6 networks for SOHO. As an example of this methodology, we constructed IPv6 networks for our laboratory and evaluated them. In addition, we designed and implemented WS-One, IPv6 INS router, to provide the connectivity to the outside for SOHO. WS-One is easy to set up and is low priced. WS-One would contribute to the deployment of IPv6 in Japan.
The large address space of IPv6 allows all hosts in the Internet to have a global address. Then the end-to-end communication model of the Internet could be revived. The appearance of the application based on the equal communication model between the hosts such as agent technology is expected, so that the worth of that model is proved. However, under this model, security for individual hosts is required, rather than security for networks by firewalls. Therefore, we must discuss the deployment of IPv6 in accordance with the security of independent hosts.
As described above, we considered the methodology to construct networks for SOHO, especially focused on the mobility of networks. Under the aspect of this model, a mobile host is special case of a separated and migrated network. We considered the independence of the hosts and the security of each host. Thus, our methodology is suitable for IPv6 network for SOHO.
The authors are grateful to members of our department and the WIDE project for their helpful comments. We would also thank to alpha testers of WS-One.