May 2008 Archives

Enabling IPv6 and PNRP in Windows Vista

Posted on May 14, 2008

Windows Vista is the first version of Windows to support IPv6 out of the box. Even those of us with an IPv4 connection can make use of this, using a technology called Teredo to get IPv6 connectivity over IPv4. With Google finally getting IPv6, now seems like a good time for others to start too.

The steps to enable IPv6 are simple:

  1. Open up a command prompt with administrator privileges. Start->All Programs->Accessories, right click on Command Prompt and select Run as administrator.
  2. If you aren’t on a router, or if your router supports UPNP, enter netsh interface teredo set state client.
  3. If you want to manually forward a port or your router doesn’t support UPNP, enter netsh interface teredo set state client clientport=12345, substituting 12345 with the port you want to use. You will have to forward UDP over this port to your computer.
  4. Now wait for a minute or so and run netsh interface teredo show state. It should show “qualified” under State.
  5. Now if you run ipconfig, it should come up with a Tunnel adapter Local Area Connection with an IPv6 address starting with 2001:0.
  6. You can test if it’s working by visiting Google IPv6, or the KAME project’s famous dancing kame.

Now for the second part of the post. PNRP (Peer Name Resolution Protocol) version 4.0 was also introduced in Windows Vista. With PNRP, every computer can have a hostname pointing to it that allows any XP SP2, Vista, and Server 2008 computer to connect to it via the internet. This can be incredibly useful if you’re on the go and wish to remote in to your computer. Another use I’ve found for it is to enable it on relative’s PCs for those inevitable tech support calls that we geeks despise so much.

PNRP functions solely over IPv6, so you will need to have a valid IPv6 address to make it work. The above Teredo instructions should work fine if you don’t. Here’s how you enable it:

  1. Open up a command prompt with administrator privileges.
  2. Run the command netsh p2p pnrp peer set machinename publish=start autopublish=enable.
  3. Now if you run netsh p2p pnrp peer show machinename, it should show you a hostname to use in the format p.<random hex here>.pnrp.net. Record this name, and you can use it to talk to your machine remotely just like any other hostname.

Developers aren’t left out either: Windows comes with an extensive P2P framework, and PNRP is only one of the things built on it. WCF for instance has full integration with P2P.

The failure of Freenet

Posted on May 08, 2008

Freenet 0.7 has just been released, after being in development for years. It’s not exactly new – most users have been on this version for quite a while now. But for those who haven’t used it since 0.5, it might be time to give it a try.

Freenet is an important concept. On it you get complete freedom of speech: the ability to discuss and spread your ideas, with full anonymity and freedom from censorship. Of course, this means that you will probably come across things on it that will go against your beliefs. Maybe some things that truly shock and disgust you. While nothing forces you to actually visit these freesites, you will have to come to terms that this might be cached on your computer even without you visiting them. But this is important to freedom of speech: if people where able to censor anything, the system just wouldn’t work.

So why does Freenet fail? Lack of documentation. I don’t mean ease of use in the interface – I mean for the protocols and network design. A system as important as Freenet—one that people expect unfaltering anonymity and security from—should be rigorously and meticulously documented.

But it’s not. In fact, if you bring it up with the Freenet developers they will gladly tell you this is intentional—that they use security through obscurity to guard against someone finding a way to break the system.

So—do you trust your freedom with the competency of a handful of developers to make a good design? I don’t. I want as many people looking at the system as possible. I want people to really bash on it, to try to break it. This gives me confidence, not worry, because problems will be solved sooner than later.

This would also open up the possibility of more than one client to access the network. If you have two separate clients that implement the same strict protocol and one of them messes up, it’s likely to be caught far sooner than with just one. An immediate example of where this would have helped is with a bug that existed in 0.7’s AES implementation for a very long time, where the data wasn’t being encrypted properly.

The Freenet developers don’t want multiple clients either—again, they worry that one might break the network. This line of thought is incomprehensible to me, because as a developer I would want things that could break my network to be discovered as soon as possible so I could fix the design.

Sure, you could look at the source code. It is Open Source, after all. But what if you don’t know Java? I don’t particularly want to learn Java just so I can review Freenet’s code. As a C++ developer I might be able to read and understand most of it, but I don’t trust myself to review something so important without years of prior Java experience—the chance that I’d miss something is just too great.