[haiku-development] Re: GSoc - IPv6 implementation for Haiku OS

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 05 Apr 2010 12:23:17 +0200

Atis Elsts <the.kfx@xxxxxxxxx> wrote:
> What follows is a rough draft of the list of the points that are
> required for IPv6 support (in my opinion). Please make your comments
> about this list and the scope of its tasks.

Beware, I haven't really looked into IPv6 besides using its API yet.

> * Addressing:
> - basic IPv6 static addressing support

The first thing you would need to do is to add an ipv6 module to the 
kernel that supports IPv6 addressing. In theory, that should already 
allow the upper level protocols (TCP/UDP) to work with IPv6 (though the 
devil might be in the details).
Especially supporting "dual" sockets will probably need extra support 
in the protocols (ie. accepting IPv4 connections over IPv6 sockets).

> * Routing
> - connected route support
> - default route support
> - static route support

You shouldn't need to do anything for routing, at least the code there 
should be totally address family agnostic.

> * API:
> - AF_INET6 family support for sockets
>   This includes: [Vijayakumar]
>   adding sockaddr_in6 structure
>   writing support for IPv6 specific getsockopt and setsockopt calls
>   adding getnameinfo(), getaddrinfo(), inet_pton() and inet_ntop() 
> functions

You probably haven't looked into Haiku deeply yet, as this is all there 
already. IOW you can compile your applications with IPv6 support now, 
and once the network stack itself supports it, your apps should just 
All userland stuff should be done and working (there is one case where 
I temporarily disabled IPv6 addresses for getaddrinfo(), though, but 
it's a matter of removing a #if 0).

> * Tools:
> - ifconfig utility - allow to work with IPv6 addresses
> - route utility - allow to work with IPv6 routes

Those two have already been prepared for use with different address 
families, so the changes should be pretty easy to do (just a matter of 
adding the hooks for parsing and printing IPv6 addresses).

> - ping - for testing IPv6 connectivity and ICMPv6 support
> - traceroute over IPv6 (UDP over IPv6 support required first)
> - telnet over IPv6 (TCP over IPv6 support required first)
> (later tasks:)
> - FTP over IPv6 and wget over IPv6 (TCP required first)

This might have been simply disabled from the versions we have in our 
repository, or maybe you'll need newer ones. This userland level stuff 
is the last you should worry about, anyway.

> * Protocols:
> - limited ICMPv6 support, as much is needed to make address neighbor
> discovery, DAD, autocofiguration, and ping to work.
>   Message types that need to be supported: [ICMPv6] [AutoConf] 
> [NeighDisc]
>   - Echo Reply Message
>   - Echo Request Message
>   - Neighbor Solicitation Message (similar to ARP request for IPv4)
>   - Neighbor Advertisement Message (similar to ARP response for IPv4)
>   - Router Solicitation Message (Tx only)
>   - Router Advertisement Message (Rx only)
> (not sure about whether there will be enough time for these:)
> - TCP support over IPv6
> - UDP support over IPv6

As I said, the latter two probably don't require a lot of work, at 
least to get them basically working (in IPv6 only mode).

> The list does not contain points like "DHCPv6 client" or "tunnelling
> support", that according to [von Gluck] can be supported without
> implementing them in Haiku OS itself.

Since we are using our own DHCP client implementation, that's not 
entirely true, though.

> The lost also does not include support for RADVD (router side address
> autoconfiguration). I don't think it's needed at all, at least for 
> the
> first releases of the OS, because Haiku OS is meant to be a host side
> OS, not a router, right?

I'm looking forward to your application.

Basically, you should try to be able to test what you do as early as 
possible. IOW you should add stuff in the order it is needed for IPv6 
to work. The hardest part of IPv6 is probably IPsec, anyway. The network 
stack has been designed in a way that should make supporting other 
address families relatively easy, without affecting other modules unless 
special functionality is needed (like IPv4/v6 dual sockets).


Other related posts: