Update - 31.05.2010

This update will be short. In last week I was able to work on GSoC only for one day due to various reasons. One being that in Saturday we had to work after Monday's work schedule, as everyone in Latvia, because of "moved" days due to national holidays at beginning of May.

What I have done so far:
- modified ifconfig program to support ipv6 addresses
- copied kernel/network/protocols/ipv4/ to kernel/network/protocols/ipv6/ and started editing those files. There is going to be gIPv6Module and gIpv6AddressModule.

The biggest problem that crept out so far is the fact hat there can be only one address per struct net_interface. Don't know if it is bad, but it seems to be, because at first look net_interfaces are supposed to have unique names. In ipv4 the interface naming problem is solved by creating aliases. But in ipv6 world:
1) multiple IP addresses per link is a much more frequent situation;
2) in any case, there can be both ipv4 and ipv6 address for a link! (Probably solved by having multiple net_domains.)

Is it better to take ip6_hdr from system headers and use it, or to define my own "struct ipv6_header" in ipv6.cpp (like struct ipv4_header is defined in ipv4.cpp)? I will go with system headers for now.

I also got the IPv6 book from Amazon (pictured). It was delivered in 24th May, precisely at the first day of GSoC. Have been using the book as a bedtime reading, and learning about the KAME software. At this point it's probably ridiculous to criticize other IPv6 implementations, but I jotted a quick notes to myself about "what could be done better than KAME did":
1) C++ vs. C. It's no secret that C++ does provide better and easier data structure interface. All these "list_next" fields in structures.. We can get rid of the in C++ and avoid mixing low level implementation details and functionality.
2) The hack with storing scope id's inside link local addresses. Just. Ugly. Good thing we don't have to keep "historical compatibility".
3) mbuf's - BSD network memory buffers. Hope that Haiku buffer management feels better. I know that Linux does.

The first post

I have decided to make this blog for documenting my endeavours with Haiku [1] IPv6 code as part of Google Summer of Code 2010. The coding start date for GSoC 2010 is approaching very fast now - 24th is the next Monday. So far I have setup Haiku development environment (the jam build tool is something new to learn), setup testing environment (qemu with Haiku works just fine, I can even browse the Net), and registered a git repository at github.com [2] for storing my code and tests.

Building Haiku:
$ jam -q haiku-image

Building a specific application:
$ cd src/apps/networkstatus
$ touch NetworkStatus.cpp
$ jam NetworkStatus

Using qemu:
$ sudo qemu -hda generated/haiku.image -snapshot -net nic,vlan=0 -net tap -m 256

Checking out the code: (Not sure at the moment how the syncing with Haiku SVN will be done)
$ git clone git://github.com/kfx/haikuipv6.git

When looking at the future, it seems that time management probably is going to be the biggest issue. The IPv6 project is pretty big even as it is at the moment, not to mention that it has the potential to become much bigger. Implementation of IPSec (a required part of IPv6 standard for now), implementation of MLD, implementation of Mobile IPv6, and so on... Another big and important area of potential improvements is automatic tunnelling. It's not as much that it would be so hard to make, it's more that it's not clear what exactly to make. There seems to be a myriad of different standards that are competing each other at the moment, and the general direction of evolution is not even clear. (Are they going to add protocol translation NAT to IPv6? Most likely not... Being able to rely on that would certainly make things easier for host operating systems.)

I wonder whether it makes sense to go to the local IT administrator and convince him to make an IPv6 tunnel to the global IPv6 Internet. I know that Hurricane Electric are providing free tunnel broker services. The tunnels are available to anyone who has a public IPv4 address. (Free anycast IPv6 tunnelling is theoretically available, and it does not even require any tunnel brokers, but I have never been able to make it work.) That would be kind of cool, but would that also be useful?

So, about time management. Since I have another part-time job, and realistically I am not going to code 14-or-so hours a day , I have decided to avoid the usual approach with project management (that being "do it until it's completed"), and instead go for something I have never tried before: a fixed schedule for this specific project. Initially 30 hours a week, as promised in my GSoC proposal [3], and full time during our week vacation in July. The idea is that I am going to work on my GSoC project in Thursday, Friday, and Saturday (that makes 24 hours) and gather the remaining 6 hours in the rest of the week. We shall see how well that is going to go...

On a side note, I have ordered IPv6 Core Protocols Implementation from Amazon and am waiting for it now. Delivery is somewhat lagging behind my expectations, since I hoped to start reading it before the coding starts... Well, whatever. It was pretty costly too, but I hope to get back the money soon.

The authors of that book, Qing Li et al, were part of the now defunct KAME project [4] that produced an IPv6 stack used by the various BSDs. I have no previous experience with KAME software (Linux uses IPv6 stack originally created by USAGI project [5], another Japanese effort), but seems that they did a pretty good job. Let's see how good they are at explaining it.

Another source of inspiration for the Haiku IPv6 stack could be the uIPv6 (micro-IPv6) stack [6] produced in a joint effort by the Swedish Institute of Computer Science, Cisco, and Atmel. The stack is released as part of the Contiki open source operating system. Contiki seems to to be one the most popular "low-cost networked device" operating systems out there, and it usually does have clear and readable code, which is not exactly typical in that area of software.

Looks like this is going to be a busy summer.

References:
[1] - http://www.haiku-os.org
[2] - http://github.com/
[3] - http://www.haiku-os.org/blog/kfx/2010-04-28_gsoc_ipv6_implementation_haiku
[4] - http://www.kame.net/
[5] - http://www.linux-ipv6.org/
[6] - http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html