RD: That’s correct. We have a machine here, actually in my office, that is connected to the 6bone through our stack. And some of the people who downloaded our implementation from the Web are also connected.

RD: Correct. You go to the Network Control panel to add it.

RD: Yes, we designed it as a separate network protocol stack to make it easier to administer, debug, and disable. It's very easy to install or de-install.

RD: In our release we only provide a few applications for testing purposes. There's a ping utility you can use to test connectivity, a tracert utility. Here at MS we have an implementation of FTP ported to IPv6 -unfortunately, we had to leave this out of the download.

RD: Tunneling is one of several transition mechanisms that the IPng transition group is talking about. As you point out, tunneling is useful when there are two v6 machines that want to communicate over a v4 internet. IPv6 packets are encapsulated, transmitted, and de-encapsulated at the other end. To enable a v4 machine to talk to a v6 machine, a technique called translation is more suitable. This is something Marc Fiuczynski has been working on, a v4 to v6 translator.

MF: Translation basically is sending a v6 packet through a v4 network by stripping off the v6 header and replacing it with a translated v4 header.

MR: Some information gets lost, such as quality of service information. But translation works well for most real-world applications, such as HTTP, FTP, telnet, ping, tracert, etc… Although translation may not work for some applications, it does work for most.

RD: Its difficult to say how v6 will be deployed over the Internet . Different approaches are being tried right now. The tunneling approach is being deployed via the 6bone, and you may learn more about that tomorrow in your conversation with Bob Fink. In the end there will probably be a combination of different techniques adapted to different users.

RD: Well, we haven't completely finished implementing all the different features of the protocol. In that sense, some people would classify it as an alpha implementation. It has good functionality, but its not complete.

RD: There's a lot of missing application support. We don't have some of the IP security features specified in IPv6. So there are definite pieces missing here. On the other hand, the main functionality is there, and this should not prevent anyone from downloading this implementation. It has reached the useable point, this is why we decided to go ahead and release this. You can use it to connect to other machines and to connect to the 6bone. It’s a great way to get the feel of IPv6.

RD: You would use it to learn more about IPv6 and NT networking. It wouldn't be used to get daily work done.

RD: Both of those reasons. We don't have the kind of application level support that most users expect -such as web browsers, . But you also need network servers out there with interesting services available for IPv6.

RD: There are changes, but they are relatively minor. The greater part of the TCP protocols remains unchanged.

RD: Our release actually does include a TCP over IPv6 implementation.

RD: There are no changes to Winsock, but you need to use the Winsock helper DLL for IPv6. The nice thing about the Winsock architecture is that it is parameterized and new protocol types can be added. And we were able to take advantage of that architecture and implement a helper DLL for IPv6. That Winsock support is also part of our release.

RD: We are continuing development on it. We are planning to release further versions of this. Some of the missing elements earlier we discussed earlier are high on our priority list.

RD: There's a separate effort under way with the Windows networking group. They're starting to look at IPv6 and figure out what their plans are, what their timelines would be for delivering support for IPv6 in product releases. They're not sure when this will happen, but it will not be in NT5.

RD: The product people will certainly benefit from our experience and our code and they may be able to take away some of the algorithms. Its not clear how much of the code they'll be able to use. That will really depend on several factors, its hard to say exactly.

RD: That's an important point. We provide not only the binary versions, but also the source code. Users that have the Device Driver Kit, DDK, and the SDK can go ahead and make modifications and build their own version of the protocol stack. We made the source code available because we want to encourage programmers to do their own experimentation and do networking research on NT. The source code can be a starting point for people to play with networking on NT, or it can be used as sample code.

TNC: The stack is written entirely in C?

RD: Yes, it's written in C.

RD: The device driver model in Windows 95 is different. In Windows 98 there has been some convergence of the device driver model, called WDM. To be honest, our group hasn’t looked at the specification in very much detail. Its hard for me to say how hard it would be for us to port our code to Windows 98. Our focus has been on NT because most of the people that are interested in doing research are using Windows NT. Obviously, most people who will be using Windows 98 at home are not really interested in this type of research.

RD: There are several a couple parts to the release. One is the binaries and distribution, the protocol stack proper. We also make available an IPv6 protocol parser that works with Microsoft Network Monitor. Network Monitor is actually an extremely useful tool, highly recommended. It captures packets and graphically display network traces. You can filter out packets you are not interested in.

RD: Yes, we found it invaluable in our own work. One of the nice things about Network Monitor is that it has an extensible architecture. Users can add parsers for new protocols. We also include the source code for our parser. That's another good resource for users who are developing new protocols and who need to debug them.

TNC: How did this project get started? What was your motivation?

RD: We wanted to learn more about networking. My background is in operating systems, and I had only a passing acquaintance with networking issues. So I started reading papers on networking and the RFCs and IETF Internet Drafts. That got a little bit dry… and getting in there and implementing some of this stuff I was reading about was the best way to make it concrete and learn something. That's how we got started on the implementation.

RD: It turned out there is enough interest, enough excitement to make it worth it.

RD: Allison is raising the point that we support address auto-configuration, one of the neat new features of our IPv6. You can plug the machine into the network and it will automatically acquire new addresses.

RD: Yes, its something we take advantage of in our implementation.

RD: By contrast, in IPv4 there are many address configuration options. Our stack does not require this configuration.

RD: That's right, there are no property pages to configure. To connect to the 6bone, however, you need to create what is called a configured tunnel. As the name suggests, this requires some configuration. We don't have right now a good graphical way of entering that information. Anyone interested in using our implementation to connect to the 6bone can find instructions on how to do this on our website. It can be done through the registry editor.

TNC: I've seen this on the site. It basically just requires entering an IPv4 address and an IPv6 address.

RD: Yes, its really not complicated.

• Microsoft Research IPv6 website
• The IPv6/IPv4 Network Address Protocol Translator project
• TechNetcast broadcast with IPng WG co-chair Bob Hinden