int64.org

May 2008 Archives

Enabling IPv6 and PNRP in Windows Vista

Win­dows Vista is the first ver­sion of Win­dows to sup­port IPv6 out of the box. Even those of us with an IPv4 con­nec­tion can make use of this, using a tech­nol­ogy called Teredo to get IPv6 con­nec­tiv­ity over IPv4. With Google fi­nally get­ting IPv6, now seems like a good time for oth­ers to start too.

The steps to en­able IPv6 are sim­ple:

1. Open up a com­mand prompt with ad­min­is­tra­tor priv­i­leges. Start->All Pro­grams->Ac­ces­sories, right click on Com­mand Prompt and se­lect Run as ad­min­is­tra­tor.
2. If you aren’t on a router, or if your router sup­ports UPNP, enter netsh interface teredo set state client.
3. If you want to man­u­ally for­ward a port or your router doesn’t sup­port UPNP, enter netsh interface teredo set state client clientport=12345, sub­sti­tut­ing 12345 with the port you want to use. You will have to for­ward UDP over this port to your com­puter.
4. Now wait for a minute or so and run netsh interface teredo show state. It should show “qual­i­fied” under State.
5. Now if you run ip­con­fig, it should come up with a Tun­nel adapter Local Area Con­nec­tion with an IPv6 ad­dress start­ing with 2001:0.
6. You can test if it’s work­ing by vis­it­ing Google IPv6, or the KAME pro­ject’s fa­mous danc­ing kame.

Now for the sec­ond part of the post. PNRP (Peer Name Res­o­lu­tion Pro­to­col) ver­sion 4.0 was also in­tro­duced in Win­dows Vista. With PNRP, every com­puter can have a host­name point­ing to it that al­lows any XP SP2, Vista, and Server 2008 com­puter to con­nect to it via the in­ter­net. This can be in­cred­i­bly use­ful if you’re on the go and wish to re­mote in to your com­puter. An­other use I’ve found for it is to en­able it on rel­a­tive’s PCs for those in­evitable tech sup­port calls that we geeks de­spise so much.

PNRP func­tions solely over IPv6, so you will need to have a valid IPv6 ad­dress to make it work. The above Teredo in­struc­tions should work fine if you don’t. Here’s how you en­able it:

1. Open up a com­mand prompt with ad­min­is­tra­tor priv­i­leges.
2. Run the com­mand 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 host­name to use in the for­mat p.<ran­dom hex here>.​pnrp.​net. Record this name, and you can use it to talk to your ma­chine re­motely just like any other host­name.

De­vel­op­ers aren’t left out ei­ther: Win­dows comes with an ex­ten­sive P2P frame­work, and PNRP is only one of the things built on it. WCF for in­stance has full in­te­gra­tion with P2P.

The failure of Freenet

Freenet 0.7 has just been re­leased, after being in de­vel­op­ment for years. It’s not ex­actly new – most users have been on this ver­sion 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 im­por­tant con­cept. On it you get com­plete free­dom of speech: the abil­ity to dis­cuss and spread your ideas, with full anonymity and free­dom from cen­sor­ship. Of course, this means that you will prob­a­bly come across things on it that will go against your be­liefs. Maybe some things that truly shock and dis­gust you. While noth­ing forces you to ac­tu­ally visit these freesites, you will have to come to terms that this might be cached on your com­puter even with­out you vis­it­ing them. But this is im­por­tant to free­dom of speech: if peo­ple where able to cen­sor any­thing, the sys­tem just wouldn’t work.

So why does Freenet fail? Lack of doc­u­men­ta­tion. I don’t mean ease of use in the in­ter­face – I mean for the pro­to­cols and net­work de­sign. A sys­tem as im­por­tant as Freenet—one that peo­ple ex­pect un­fal­ter­ing anonymity and se­cu­rity from—should be rig­or­ously and metic­u­lously doc­u­mented.

But it’s not. In fact, if you bring it up with the Freenet de­vel­op­ers they will gladly tell you this is in­ten­tional—that they use se­cu­rity through ob­scu­rity to guard against some­one find­ing a way to break the sys­tem.

So—do you trust your free­dom with the com­pe­tency of a hand­ful of de­vel­op­ers to make a good de­sign? I don’t. I want as many peo­ple look­ing at the sys­tem as pos­si­ble. I want peo­ple to re­ally bash on it, to try to break it. This gives me con­fi­dence, not worry, be­cause prob­lems will be solved sooner than later.

This would also open up the pos­si­bil­ity of more than one client to ac­cess the net­work. If you have two sep­a­rate clients that im­ple­ment the same strict pro­to­col and one of them messes up, it’s likely to be caught far sooner than with just one. An im­me­di­ate ex­am­ple of where this would have helped is with a bug that ex­isted in 0.7’s AES im­ple­men­ta­tion for a very long time, where the data wasn’t being en­crypted prop­erly.

The Freenet de­vel­op­ers don’t want mul­ti­ple clients ei­ther—again, they worry that one might break the net­work. This line of thought is in­com­pre­hen­si­ble to me, be­cause as a de­vel­oper I would want things that could break my net­work to be dis­cov­ered as soon as pos­si­ble so I could fix the de­sign.

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 par­tic­u­larly want to learn Java just so I can re­view Freenet’s code. As a C++ de­vel­oper I might be able to read and un­der­stand most of it, but I don’t trust my­self to re­view some­thing so im­por­tant with­out years of prior Java ex­pe­ri­ence—the chance that I’d miss some­thing is just too great.