MavEtJu's Distorted View of the World - IPv6

Internode IPv6 over ADSL project
Internode to support IPv6 tunneling (and more)
FreeBSD IPv6 Divert socket adventures (3)
FreeBSD IPv6 Divert socket adventures (2)
FreeBSD IPv6 Divert socket adventures
IPv6 training and thoughts
APNIC IPv6 training
MavEtJu goes IPv6

Back to index

Internode IPv6 over ADSL project

Posted on 2009-11-06 18:00:00
Tags: FreeBSD, IPv6

Internode has announced IPv6 capabilities for their ADSL users and I have volunteered for the pilot. My ADSL router, a Linksys WAG54G2 running version 1.00.17, didn't support it out of the box, so I needed to do it via the FreeBSD host sitting behind it. The FreeBSD host is running 8.0-RC2 at this moment, but it should work with previous versions too:

The first step is to turn the ADSL router into an ADSL modem by changing the Encapsulation on the WAN side from RFC 2516 PPPoE to Bridged Mode Only. From that moment in time you have lost your internet connection :-)

Add to your /etc/rc.conf:

` That was simple. Reboot :-)

Setup PPP on the FreeBSD host, add this to your /etc/ppp/ppp.conf:

    set authname ""
    set authkey "secret"
    set device PPPoE:sk0
    enable lqr echo
    nat enable yes
    set cd 5
    set dial
    set login
    set redial 0 0
    set ifaddr
    add default HISADDR                 # Add a (sticky) default route
    add default HISADDR6                # Add a (sticky) default route
Notes: and start the ppp service:
[~] root@k7>ppp pppoe6
Loading /lib/
Loading /lib/
Loading /lib/
Loading /lib/
Loading /lib/
Loading /lib/
Loading /lib/
Working in interactive mode
Using interface: tun0
ppp ON k7> dial
ppp ON k7> Warning: deflink: Reducing configured MRU from 1500 to 1492
Ppp ON k7> Warning: deflink: Reducing configured MRU from 1500 to 1492
PPp ON k7> Warning: ::/: Change route failed: errno: No such process
PPp ON k7> 
PPP ON k7> 
and the the PPP interface has been setup:
[~] root@k7>ifconfig tun0
tun0: flags=8051 metric 0 mtu 1492
        inet6 fe80::20f:eaff:fe2c:d518%tun0 prefixlen 64 scopeid 0x4 
	inet --> netmask 0xffffff00 
	Opened by PID 35920
And the default gateways have been set:
[~] edwin@k7>netstat -rn | grep default
default       UGS         0      340   tun0
default                           fe80::20c:86ff:fe75:241b%tun0 UGS        tun0
Now we have the IPv6 configuration setup, but can't do much except for pinging out default gateway:
[~] edwin@k7>ping6 -c 1 fe80::20c:86ff:fe75:241b
PING6(56=40+8+8 bytes) fe80::20f:eaff:fe2c:d518%tun0 --> fe80::20c:86ff:fe75:241b
16 bytes from fe80::20c:86ff:fe75:241b%tun0, icmp_seq=0 hlim=64 time=10.544 ms

--- fe80::20c:86ff:fe75:241b ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 10.544/10.544/10.544/0.000 ms
[~] edwin@k7>ping6 -c 1
PING6(56=40+8+8 bytes) fe80::20f:eaff:fe2c:d518%tun0 --> 2001:4f8:fff6::21

--- ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

The next step is to grab an allocation of IPv6 addresses for our network: First install the net/dhcp6 port and use the following configuration for /usr/local/etc/dhcp6c.conf:

interface sk0 {

interface tun0 {
	send ia-pd 0;
id-assoc pd {
	prefix-interface sk0 {
		sla-id 1;
		sla-len 4;
Notes: The dhcp6c program is not very informative with its output:
[~] root@k7>dhcp6c -f -d  tun0
Nov/06/2009 11:59:35: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Nov/06/2009 11:59:35: client6_init: failed initialize control message authentication
Nov/06/2009 11:59:35: client6_init: skip opening control port
But ifconfig sk0 now gives the proper output:
[~] root@k7>ifconfig sk0
sk0: flags=8843 metric 0 mtu 1500
	ether 00:0f:ea:2c:d5:18
	inet6 2001:44b8:7bf1:a51:20f:eaff:fe2c:d518 prefixlen 64 
	media: Ethernet autoselect (100baseTX )
	status: active
I don't know why it says there that the prefix-length is 64 bits, but the IPv6 connectivity is there:
[~] root@k7>ping6 -c 1
PING6(56=40+8+8 bytes) 2001:44b8:7bf1:a51:20f:eaff:fe2c:d518 --> 2001:4f8:fff6::21
16 bytes from 2001:4f8:fff6::21, icmp_seq=0 hlim=56 time=194.522 ms

--- ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 194.522/194.522/194.522/0.000 ms

Now you have one FreeBSD computer with IPv6 connectivity. The next step is to enable it on the rest of the network. Add to your /etc/rc.conf:

As seen earlier, sk0 is the ethernet interface of my FreeBSD machine.

To enable IPv6 connectivity on the other computers....

Show comment | Share on Facebook | Share on Twitter

Internode to support IPv6 tunneling (and more)

Posted on 2008-07-21 09:00:00
Tags: IPv6, Australia, FreeBSD

At About Internode and IPv6, Internode announces that their internal network is supporting IPv6, and that they have IPv6 connectivity to the rest of the IPv6 world.

If you want to use their Tunnel Broker service on FreeBSD (i.e. have an IPv6-over-IPv4 tunnel towards their IPv6 gateway), then use the net/freenet6 port. Make sure you are using version 5.1_x.

The required configuration changes in /usr/local/etc/gw6c.conf are:


Besides being a tunnel broker they also support a native IPv6 connection if you have an ethernet- or fibre link with them.

No comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures (3)

Posted on 2008-05-13 23:00:00
Tags: IPv6, FreeBSD, Networking

Victory! Tonight I managed to get the nat6to4 daemon working. Remember what went wrong yesterday:

IPv6 packet does not go from the nat6to4 daemon into divert. What?!?!?
Yes, that would have worked in one go if I actually had pushed the data in the right IPv6 socket instead of in the wrong IPv4 socket. It happens, specially when you are copying whole functions around.

As a demo:

[~] edwin@freefall>telnet 2001:5c0:8fff:ffff::c3 80
Trying 2001:5c0:8fff:ffff::c3...
Connected to 2001:5c0:8fff:ffff::c3.
Escape character is '^]'.

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Date: Tue, 13 May 2008 14:10:23 GMT
Expires: Thu, 26 Oct 1995 00:00:00 GMT
Last-Modified: Tue, 13 May 2008 14:10:23 GMT
Pragma: no-cache
Content-Length: 32
Server: Allegro-Software-RomPager/4.34

Connection closed by foreign host.
That is pretty uninteresting for the naked eye, but the thing is that the Allegro-Software-RomPager doesn't support IPv6, it's mapped via the nat6to4 gateway.

So, my nat6to4 daemon works for mapping the TCP or UDP payload of basic IPv6 packets (single header, nothing fancy) onto IPv4 packets: Now I can make all basic services on my jails (webservers, LDAP servers, DNS servers, POP and IMAP servers) available via IPv6.

Now I have to put netinet6/ip6_divert.c into a shape so that it gets accepted by the FreeBSD project, right now there are too many things commented out because I didn't know what they are for. Yes, I feel like an apprentice magician left alone with a hand full of scrolls and asked to find out if they are interesting.

Patches for FreeBSD 6.3 are available from
The nat6to4d is available from
And the ipfw rules:

01005   606   245695 divert 8664 ip from any to
01006   452    33304 allow ipv6-icmp from any to me6 via tun1
01006   517    51742 divert 8666 ip6 from any to me6 via tun1
65535 79349 20349420 allow ip from any to any

Show 2 comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures (2)

Posted on 2008-05-12 10:00:00
Tags: IPv6, FreeBSD, Networking

A small update:

So what works and what doesn't?

I'm not sure what goes wrong here: sendto() says that it is accepted, but the packet is expected to end up on the div6_send() function but it doesn't end up there. For some reason. Which is kind of annoying. Robert Watson suggested to check the GDB debugger what happens in the sendto() call.

But that is an adventure for later when I have some spare time again... work and two kids, that doesn't leave much time adventures like this (except between 22:00 and 01:00 which is very bad for everybody)

No comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures

Posted on 2008-05-06 10:00:00
Tags: IPv6, FreeBSD, Networking

This whole IPv6 Divert idea seems to be a little bit optimistic now. As all new technology (I wouldn't call IPv6 new technology, but still) not everything you have available now is supported in it.

So, how far did we get?

So, this is getting trickier and trickier for an userland guy like me to experiment with on a sunday afternoon... But I'm not going to give up! (yet)

On the other hand, an interesting paper by Dr. Goto (I'm not kidding) and friends available at IPV4/V6 NETWORK EMULATOR USING DIVERT SOCKET says:

We have ported divert socket to IPv6 by adding about 1000
lines of C program code either on FreeBSD and Linux kernel
for this research.
I have asked him if he wanted to share his code but haven't heard anything back from him.

No comments | Share on Facebook | Share on Twitter

IPv6 training and thoughts

Posted on 2008-05-03 09:00:00
Tags: IPv6, Networking

After two days of the IPv6 training workshop organized by APNIC, I think I'm ready for it. Mentally that is. I will guide BarNet safely into the 21st century! (Yes, I know that that century is already eight years old, but then IPv6 is already more than eight years old)

There are a couple of interesting things about IPv6: The first one is the absence of the checksum field in the IP header. Had an IPv4 header a checksum which had to be recalculated on every router it went through (that's no fun for highspeed routers I tell you), IPv6 packets don't have to do this anymore.

The second thing is the absence of the ARP protocol: It's gone now. It's over for it. Bye! It's now part of the ICMPv6 protocol: If you need to know the ethernet address of a host, you send an ICMP packet asking for it. I'm pretty sure that RARP (RFC903) is obsolete now.

The third one is the absence of subnet broadcast address: No more all 1's, it just doesn't exist. If you want to tell something to all hosts, use a local multicast.

Related to the third one is that the network troubleshooting trick to see how many hosts are alive by pinging everybody in the subnet, which is now an /64, is obsolete, because it will take seventeen days before you have complete the full sweep.

The famous IPv6 autoconfiguration... It is great for a simple network where hosts have everything (DNS, WINS, proxy etc) statically configurated, but I don't really believe in it for a properly managed network: DHCPv6 is the way to go. Still. I will have to figure out how it works: I saw that the ISC-DHCP port in the FreeBSD ports tree was very outdated and that there wasn't a 3.1 not 4.x version in it... I will have to take things in my own hands!

With regarding to our network equipment I'm not too worried: The routing Extreme Networks boxes and the Juniper boxes do support IPv6, the Cisco PoE switches should be fine. The FreeBSD, Linux and Windows 2K3 devices do support it. And PIPE networks does support it.

With the FreeBSD boxes there is a small problem right now though... In the past we carefully designed our network and services with jails and such, and jails support only one IP address. That's the whole idea behind a jail, nothing you can do about it. And that works great, oh, except for the fact that in dual stack mode you need two IP addresses: an IPv4 and IPv6 one. I know that there are patches around for FreeBSD 7.0 to support multiple IP addresses, but that doesn't help me yet because we have just migrated everything to 6.3...

So, how can provide IPv6 access to our services easily? The simplest way is to make some kind of IPv6-to-IPv4 gateway, which translates an IPv6 packet into an IPv4 packet and forwards that to our servers.
Confused? Here is an example: has an DNS A record of The IPv6 DNS AAAA record would be 2001:0DF0:0009::CA53:B0F8 (or 2001:DF0:0009::0202:0083:0176:0248 to prevent nasty dec-to-hex conversion errors). As you can see, the last 32 bits is the IPv4 address, the first 48 bits is our network. The IPv6-to-IPv4 gateway would carefully craft an IPv4 packet with the right IPv4 address and send it of to my webserver. The answer would be translated back into an IPv6 address.

Nothing difficult, this is just plain NAT. And it would expose all our services in one go to the IPv6 world, without anything to change on the services. Okay, you would lose the information of who it really was who asked it, but that is just a small price to pay until the full IPv6 service is in place. Let's do some hacking!

No comments | Share on Facebook | Share on Twitter

APNIC IPv6 training

Posted on 2008-05-01 09:00:00, modified on 2008-06-01 09:00:00
Tags: IPv6, Trains, Rant, Memories

The coming two days I'll be at the IPv6 Workshop of APNIC. Of course this workshop is in the middle of nowhere, which is impossible for a Sydney based event so let me rephrase it: It is held in a non-central location unreachable by train. The options? Take the train to the city (one hour) and then the bus (one hour) or take the train to Parramatta (1.5 hours) and take a taxi from there.

But the good news is: thanks to the speed of the Cronulla / Bondi train this morning I was able to catch one train earlier at Redfern, and that one only stops at Strathfield, Lidcombe, Granville and Parramatta, which will save me some hassles... I hope :-)

On the sideline, I checked out when my first IPv6 capable program was created: It was the Fatal Dimensions Mud server and the commit date was 29 April 2000, eight years ago. The IPv6 connection came via FreeNet6 in Canada and that was a IPv6-over-IPv4 tunnel. Thanks to my FreeBSD port of their tunnel software I got a tshirt from them!

Update: That taxi took half an hour to get there....

No comments | Share on Facebook | Share on Twitter

MavEtJu goes IPv6

Posted on 2008-04-12 09:00:09, modified on 2008-04-12 09:00:00
Tags: IPv6, Networking

In a whimp last month I decided to apply for a chunk of IPv6 IP space at APNIC. Why? No idea, but it was influenced by the advertisements of APNIC about IPv6 training in Sydney and a request of PIPE Networks about searching for people who want to do IPv6 on their regional internet exchanges in Australia. It took some time before I my hands on it, mostly due to incorrect configured webservers whose emails get blocked because their SMTP envelope from addresses are not verifiable. But that's being taken care of by APNIC :-)

Last thursday I got an email that I have been allocated a chunk of IPv6 IP space:

[~] edwin@k7>whois -A barnetwork-ap-20080410
% [ node-2]
% Whois data copyright terms

inet6num:     2001:DF0:9::/48
netname:      barnetwork-ap-20080410
descr:        BarNetwork Pty Limited, Internet Service Provider, Sydney, Austral
country:      AU
admin-c:      EG46-AP
tech-c:       EG46-AP
mnt-by:       APNIC-HM
remarks:      -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks:      This object can only be updated by APNIC hostmasters.
remarks:      To update this object, please contact APNIC
remarks:      hostmasters and include your organisation's account
remarks:      name in the subject line.
remarks:      -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed: 20080410
source:       APNIC
Woohoo! This /48 is mine.

A /48 is big. If you take into consideration that an IPv6 address is 128 bits, then it's very big. But luckely that IPv6 subnets are the upper /64 of an address, so we only have (in the old IPv4 terms) an IPv4 /16. An IPv4 /16 is big too, it's 65536 subnets we can allocate now. 65535 subnets of the size of an /64 is bigger, It's something like 1.2 * 1024.

Anyway, how good are we at this IPv6 stuff? Our FreeBSD and Linux servers will have no problem with it. Windows boxes also will be fine, the ones that run Windows 2003 that is. Our Extreme Networks backbone network equipment is fine with it. Our Juniper IPSec routers do support it. Our Cisco Call Manager based telephone system does not support it. Oh well, enough to play with.

The first thing I need to do is to get APNIC to create DNS NS records for to our nameservers. I keep you posted on the progress!

No comments | Share on Facebook | Share on Twitter