Department of Teleinformatics Network Services Royal Institute of Technology
Download 290.3 Kb.
|
5.3Implementation StatusTo introduce a new protocol such as IPv6, only writing Internet-drafts and specifications are not enough. At some stage implementations of the specifications has to begin to realize the visions and to let people experiment with the new protocol. Implementation of IPv6 stacks and IPv6 adaptation of applications has been underway since 1994, and today there are IPv6 stacks available for almost every platform such as MS Windows, UNIX, SUN OS among others. However, these stacks often lack some functionality such as security, mobility or DHCP. In fact, the DHCP extensions for IPv6 has not yet been fully standardized, thus there are no DHCP implementations available. IPv6 enabled applications have also become available. These applications include the standard net tools such as ping, traceroute and tcpdump. Also more useful applications for using telnet, ftp and http are available. All of the transition mechanisms except for AIIH have also reached implementation. However, the work is still in progress and many implementations still suffer from bugs or other cavities. More details on the implementation status together with where to find IPv6 software can be found in Appendix B. 6Experimental Setup6.1GoalDuring the development of this report, I was also conducting some simple experiments in order to get a greater understanding of IPv6 and verify its functionality. Another goal was to investigate the current implementation status of IPv6 stacks, transition mechanisms, and application for various platforms. The compatibility between the different implementations was also a topic of interest. 6.2ScenarioT  he network which I set up was a very simple “home network” consisting of one home server and two clients as illustrated in Figure 6 .18. The home network was connected to the local Intranet of Telia Research, which only supported IPv4 and therefore simulated the IPv4-only access network. Figure 6.18 Experimental network setup 6.3Experiments6.3.1Hardware and OSAs a first step in the experiments, I acquired the necessary hardware and installed the operating systems. On the ‘rg’, I decided to install Linux as it provides good network support and free server software such as DNS and web servers. I also had previous experience with Linux, which made the final choice the Red Hat Linux 6.0 distribution. The clients were to simulate common home-user environments, so I chose to install Windows 2000 and Windows 98 SE on those machines with default installation options. Until Microsoft’s new OS called Millenium is released, Windows 98 will probably be the number one OS in homes followed by Windows NT or Windows 2000 for distance working people. 6.3.2IPv6 SupportThe next step was to enable IPv6 support on the machines. Initially, I followed Peter Bieringer’s excellent step by step instructions [3] to enable IPv6 on the ‘rg’ and compiled the software by hand. Later, a precompiled RPM-based IPv6 distribution for Linux was announced on Bieringer’s page, which simplified the installation significantly. I then wiped the Linux machine to try this alternative installation method. The installation of the RPM packages was very simple, starting with replacing the kernel followed by additional networking tools for configuration. For the ‘win2k’ client equipped with Windows 2000, the IPv6 stack available was Microsoft Research’s experimental stack (MSRIPv6). To install, I only had to follow the standard procedure for adding a new protocol in Windows from the network properties as shown in Figure 6 .19(a). The rest was automatically configured. In fact, the “Properties…” button was grayed out since there is nothing to configure in IPv6 – everything is based on autoconfiguration.
Figure 6.19 Network configuration in MSRIPv6 (a) and Winsock 5.0 (b) To enable IPv6 support on the Windows 98 machine I used Trumpet Software’s latest release –Winsock 5.0. Actually, the software includes both an IPv4 and an IPv6 stack, and therefore the standard Microsoft TCP/IP stack first had to be removed from the system. Trumpet Winsock also supports autoconfiguration for IPv6. I only had to configure the IPv4 part of the stack to use 10.0.0.2 as IP address. All configuration was made through the configuration panel shown in Figure 6 .19 (b). After the installation of IPv6 stacks on all hosts, I verified that all hosts had been assigned with a link local IPv6 address. On ‘rg’ I used the standard (but IPv6 enabled) command ifconfig to extract the interface information. The output of this command can be found in Appendix C together with the output from the ipv6 program on ‘win2k’ provided with Microsoft’s IPv6 stack. On ‘win98’, Trumpet Winsock’s configuration window provided the necessary information as shown in Figure 6 .19 (b). The IPv6 addresses had been built using the stateless autoconfiguration method. The link local addresses created were based on the MAC addresses of the installed Ethernet NICs according to the mapping described in [13]. 6.3.3Connectivity checkThe next step was to test the IPv6 connectivity between the newly installed IPv6 stacks. To do this, I used the “ping” tool available on all hosts. On ‘rg’, the original ping application was replaced during installation by a new IPv6 enabled version. I first tried to ping ‘win2k’ from ‘rg’: [root@rg ~]# ping fe80::290:27ff:fe72:93b5 PING fe80::290:27ff:fe72:93b5 (fe80::290:27ff:fe72:93b5): 56 data bytes 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.263 ms 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.471 ms 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=2 ttl=64 time=1.568 ms 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=3 ttl=64 time=2.443 ms --- fe80::290:27ff:fe72:93b5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.568/2.186/2.471 ms
tcpdump: listening on eth0 fe80::200:f8ff:fe32:5fc > ff02::1:ff72:93b5 icmpv6: neighsol fe80::290:27ff:fe72:93b5 > fe80::200:f8ff:fe32:5fc icmpv6: neigh adv (SO) fe80::200:f8ff:fe32:5fc > fe80::290:27ff:fe72:93b5 icmpv6: echo request fe80::290:27ff:fe72:93b5 > fe80::200:f8ff:fe32:5fc icmpv6: echo reply fe80::200:f8ff:fe32:5fc > fe80::290:27ff:fe72:93b5 icmpv6: echo request fe80::290:27ff:fe72:93b5 > fe80::200:f8ff:fe32:5fc icmpv6: echo reply ...
arp reply 10.0.0.3 is-at 0:90:27:72:93:b5 10.0.0.1 > 10.0.0.3: icmp: echo request 10.0.0.3 > 10.0.0.1: icmp: echo reply 10.0.0.1 > 10.0.0.3: icmp: echo request 10.0.0.3 > 10.0.0.1: icmp: echo reply ...
6.3.4DNSIPv6 addresses are long and error prone to type in by hand. Therefore, to simplify further application testing I decided to install a DNS server on the ‘rg’ machine. It appeared that the version of Bind (version 8.2-6) provided with the Red Hat Linux distribution already had support for the IPv6 ‘AAAA’ resource record type, which made it the natural choice. Further investigation showed however that this version was not able to communicate over IPv6. It supported ‘AAAA’ records, but IPv4 was the only protocol supported. Despite this lack of IPv6 support, I installed the package and configured a new fictional domain called ipv6.trab.se. For my experimental setup, I typed in all resource records by hand in the master files: ns A 10.0.0.1 AAAA fe80:0:0:0:200:f8ff:fe32:5fc rg CNAME ns
AAAA fe80:0:0:0:210:4bff:fe71:3e2 win2k A 10.0.0.3 AAAA fe80:0:0:0:290:27ff:fe72:93b5 In the future of home networking this will most probably be automatically configured so that a connected device automatically registers its name in the DNS. In fact, dynamic DNS updates have already been covered in RFC2136 [32], and Microsoft has implemented the functionality in Windows 2000. After the DNS server was started, and all nodes’ (IPv4) DNS servers where set to ‘rg’ (10.0.0.1), I could successfully ping the hosts by name such as [root@rg ~]# ping win2k PING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.365 ms 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.453 ms ...
PING win2k (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: icmp_seq=0 ttl=128 time=2.253 ms 64 bytes from 10.0.0.3: icmp_seq=1 ttl=128 time=2.39 ms ...
PING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=3.438 ms 64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.446 ms ...
14:13:34.909032 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad 14:23:00.909021 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad 14:31:44.909017 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad 14:40:19.909023 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad 14:49:38.909020 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad Apparently, the router advertisement is sent to the all-nodes multicast group FF02::1 in intervals of between approximately 4 and 10 minutes. According to the specification of neighbor (and router) discovery [27], the interval should be chosen randomly between 3 and 10 minutes which thus has been verified. On the client side, the router advertisements are received used to configure the interfaces on link with additional addresses and routes. For example, after the first advertisement had reached ‘win2k’, its Ethernet interface was assigned the new site local address fec0::1:290:27ff:fe72:93b5 constructed by concatenating the advertised prefix with the IPv6 suffix of ‘win98’. The routing tables where also updated accordingly with new routes for the prefix and the address. 6.3.6IPv6 connectivityTo further test the IPv6 connectivity, I decided to try connecting my experimental network to the 6bone. The Linux IPv6 stack could handle the IPv6-in-IPv4 tunneling required, so setting up a static tunnel to a site already connected to the 6bone seemed like a minor problem. However, my network was connected to Intranet protected by a very restricted firewall. IPv6 packets encapsulated in IPv4 packets use the IP protocol number 41 as an identifier while the firewall appeared to allow only TCP and UDP packets. Despite several tries to have the firewall opened, I finally gave up since global IPv6 connectivity wasn’t really part of the scenario with an IPv4-only Internet provider. 6.3.7Transition mechanismsAt this stage, the internal nodes where able to communicate internally using IPv6 (and IPv4), while IPv4 was the only working protocol outside ‘rg’. This is the typical scenario for the initial transition towards IPv6 described in Chapter 5. The next step would be to combine these two worlds by using some kind of transition box. This phase of the experiments was the most interesting one. The goal was to have a fully functional IPv6 network where users could use IPv6 to communicate internally, and yet be able to access the IPv4 resources available as described in Section 5.2.2. It should also be possible to use old IPv4 applications to communicate over IPv6 (Section 5.2.4). NAT-PT/NAPT-PTThrough a mailing list available at the IPv6 Information Page [4], I got in contact with Peter Hovell at British Telecom (BT). He announced that BT had an implementation of a NAT-PT available. It was however written for the KAME stack on FreeBSD and seemed hard to port (after some unsuccessful attempts by me). Therefore, I was not able to test the BT NAT-PT at all. Another NAPT-PT was provided by Microsoft in their MSRIPv6 package (originally written by the University of Washington). Since Microsoft’s NAPT-PT required their IPv6 stack running under Windows 2000, I installed Windows 2000 as a secondary OS on ‘rg’. I then installed the software in the form of a simple NT service and configured the mapping parameters in the registry. However, despite several attempts of configuration and discussions through mailing lists, I was unable to get the NAPT-PT working. DSTM (AIIH)Currently, there are no implementations of AIIH available. However, in a mail from Jim Bound (bound@zk3.dec.com) he states that the implementation is now underway and is expected to be publicly available for Linux and “BSDish” OS in spring 2000. Bump in the StackIn this experiment, I wanted to test the dual stack functionality through an IPv4 application using the bump-in-the-stack mechanism described in Section 5.2.4. Luckily, the mechanism is included in the Winsock 5.0 stack installed on host ‘win98’, so no further configuration was needed. Since I did not have access to the 6bone for accessing IPv6 resources, I installed an IPv6 enabled version of the web server Apache on ‘rg’. To be able to choose between IPv4 and IPv6, I also updated the DNS with additional records for separating IPv4 and IPv6 interfaces. In the database file the following lines where added: rg-4 A 10.0.0.1 rg-6 AAAA fec0:0:0:1:200:f8ff:fe32:5fc The DNS server was restarted, and the new configuration verified by pinging the “new” hosts. On the client ‘win98’ I now started up a plain old IPv4 Netscape. I typed in “rg-4” as the URL, and instantly I reached the homepage on ‘rg’. The page had been transferred using IPv4, which also could be verified using tcpdump. Now I tried the IPv6 reference “rg-6” as the URL, and again the home page was instantly visible! Using tcpdump again, I could verify that this time the page had been transferred using IPv6. That is, first Winsock had translated the IPv4 ‘A’ request for “rg-6” from Netscape to a both a ‘A’ and a ‘AAAA’ request. When only the IPv6 ‘AAAA’ response was returned, the protocol translation was used between Netscape and the IPv6 stack. Apparently the bump-in-the-stack mechanism works! SOCKSFor the SOCKS server, NEC provides a publicly available SOCKS5 server-client solution. The server was easy to install on the ‘rg’ and by using an enclosed patch the standard SOCKS server extended with a protocol translator. The server needed no configuration as long as I was confident with web access. On the client side, NEC provides their ‘SOCKSCAP’ software which “socksifies” the application you want to run. I installed the software on both client machines, and using the configuration tool, I created a “profile” for Internet Explorer. I could now for the first time access the global web from both clients, but only using IPv4. The reason for this was that SOCKSCAP only accepted an IPv4 address for the SOCKS server, and thus only uses IPv4 between the client and the SOCKS server. IPv6 support is expected in the next release of SOCKSCAP. Application ProxyIt came to my knowledge that the Apache web server contains proxy code and thus could act as an application proxy for http traffic. To enable the proxy functionality the following lines had to be added to the /etc/httpd/conf/http.conf configuration file: ProxyRequests on order deny,allow deny from all allow from 10.0.0.0/8 allow from fe80::/10 allow from fec0::/10 By running a clean instance of Netscape (without SOCKSCAP) and specifying the proxy server as 10.0.0.1 (IPv4 address of ‘rg’), I could again reach the whole Internet. As with SOCKS, I was only able to test IPv4 connectivity between the client and the proxy server. Download 290.3 Kb. Share with your friends:
|
