IPv6–enabled

19 February 2010

This blog is officially IPv6–enabled, as of a few days ago.

The server-side IPv6 connectivity is admittedly powered by 6to4, which is not quite the real deal, but given that the nearest 6to4 gateway is 0.8msec away, I couldn’t very well pass the opportunity to stress test my new Linode.

I’m a pretty firm believer in the fact that IPv6 adoption is absolutely essential to the continued health and function of the Internet. I’ve been IPv6 tunneling from my house for years, had native IPv6 at my house since November, and though I’m certainly not the first to do so, it’s time to IPv6–enable my blog.

Tagged: , , , | No Comments »

Source IP weirdities with irssi and IPv6

28 January 2010

I’m having a weird problem with irssi and IPv6. The long and the short of it is that irssi is trying to connect to an IRC server on the Internet with a source IP address of ::1, which is incorrect, as ::1 is the loopback address.

My server, glenstorm, is the IPv6 router, which contains the ppp0 interface that connects it to the IPv6 Internet. I am also running irssi on the same machine. It’s a router, so /proc/sys/net/ipv6/conf/all/forwarding is 1.

So, basically, when I fire up irssi, and type “/connect irc.ipv6.freenode.net“, it hangs when connecting. And for good reason: here’s the (edited for clarity) tcpdump output:

IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667

So obviously that’s wrong. And in violation of RFC 4291, I might add (“The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node.”).

I can hack around it by typing “/connect -host 2001:44b8:7df3:b970::14 irc.ipv6.freenode.net” into irssi, which forces it to use the source IP that I specified. But that’s just a hack — I’d like to get to the bottom of what actually causes it.

Update: Finally solved this. It’s because in my irssi config, I had the following directive:

core = {
    real_name = "Jeremy Visser";
    user_name = "jeremy";
    nick = "jayvee_zzZZ";
    resolve_prefer_ipv6 = "yes";
    host = "glenstorm";
};

It was being told to use “glenstorm” as the “host”, which translates to “resolve the IP address of glenstorm and use that as the source IP address” (I think I misunderstood the meaning of the directive when I put that configuration flag in).

Of course, in /etc/hosts, I had the following entry:

::1 glenstorm

So, naturally, irssi decided to use ::1 as the source IP address. So removing the “host” line from the irssi config fixed the problem. While I’m sure that because of the aforementioned RFC, that shouldn’t have resulted in the subsequent symptoms, at the end of the day, it was simply Unix allowing me to shoot myself in the foot.

Tagged: , , | 3 Comments »

Mandatory filter (Clean Feed) trial results announced

16 December 2009

Well, it’s official. Conroy and the DBCDE (hey, that could be the name of a band!) have released the results of the much-debated Clean Feed.

From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!

The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.

This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.

Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.

One quote I found interesting from the report:

Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.

So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.

I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.

Tagged: , , , | 1 Comment »

Native IPv6 ADSL available from Internode

14 November 2009

Internode Logo

On Friday the 6th, Internode went public with the announcement of a native IPv6 trial for their customers. As a fan of IPv6, I’m particularly excited about this, especially seeing as though now Internode is the first ISP in Australia to offer native IPv6 (albeit in an opt-in trial form) to its residential customers.

I’m not going to bore you with details or a dodgy rehash, so I will instead invite you to read the announcement and the IPv6 ADSL Trial pages for yourself.

For those that like to dive in head-first without checking the depth or for the presence of sharp rocks, you can opt-in by changing the @internode.on.net part of your PPP username to @ipv6.internode.on.net.

I got it working on my own connection, and I am very impressed with the performance. The speed of my IPv6 connection is now no slower than my IPv4 connection (unlike connections that use tunnels to get v6 connectivity), and all users are allocated a static /60 subnet, which is absolutely the right way to implement it, in my opinion.

Internode supports up to 4 concurrent PPPoE connections on a single ADSL line, which is handy to know for testing. You can have your IPv4-only “production” connection, and a second IPv6-enabled “experimental” connection that you can play with and not worry about disrupting family members if it breaks. :)

Tagged: , , | 1 Comment »

IPv6 over PPP over a null-modem connection

26 June 2009

I just did my first null-modem serial link today. And yes, I did IPv6. On each computer I ran:

# pppd nodetach noauth local /dev/ttyS0 115200 ipv6 ,

Then, each computer came up with a ppp0 interface that was down by default (for some reason, pppd doesn’t like to bring it up if it’s IPv6-only). So I ran this on one machine:

# ifconfig ppp0 up
# ifconfig ppp0 add fc00:23::1
# ip route add fc00:23::2 dev ppp0

And then on the other machine, the reverse:

# ifconfig ppp0 up
# ifconfig ppp0 add fc00:23::2
# ip route add fc00:23::1 dev ppp0

Then the glorious:

$ ping6 fc00:23::2
64 bytes from fc00:23::2: icmp_seq=1 ttl=64 time=12.0 ms
64 bytes from fc00:23::2: icmp_seq=2 ttl=64 time=11.8 ms
64 bytes from fc00:23::2: icmp_seq=3 ttl=64 time=9.87 ms

Serial is cool.

Update: Added the ‘local‘ keyword in case pppd has ‘modem‘ specified by default in /etc/ppp/options

Tagged: , , , | No Comments »

Older Entries