Axel, Thanks for your help, my replies are inline. On Mon, Apr 5, 2010 at 1:23 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > 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. > Ah, OK. > 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 thing with IPSec is that it's mandatory for IPv6 but not that much used... even for IPv4. At least it has not become the "one and only" network layer encyption and authentication method, as probably its role was envisioned by the people who designed it, and by the people who wrote IPv6 related RFCs more than ten years ago. I have even seen rumours that it will not be mandatory anymore. See for example http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html. They say: "IPSec support that is currently a MUST will become a SHOULD". (BTW, uIPv6 stack does not implement IPSec and still claim "IPv6 Ready" compliance.) In any case, implementing IPSec seems much too complicated to be seriously even considered at this stage. At least the Linux IPSec kernel implementation (the "xfrm" thingies) looks simply terrifying ;) > 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). > This is really cool and will make adding IPv6 much easier. As for the TCP & UDP, I agree with you and with Andreas Färber. > 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 > work. > 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). I totally agree. Since writing my first email I have looked through code and indeed saw that in many cases adding IPv6 indeed can be as simple as defining HAVE_IPV6 and recompiling programs, at least in userspace. After reviewing the code I jotted down this updated list: ( I will start with the kernel parts, obviously): What IPv6 support Haiku already has and what is required: Utility programs: ----------------------- Existing IPv6 support (can be enabled by recompiling): - ftp, ftpd - tcpdump - telnet, telnetd - wget Needed IPv6 support: - ifconfig - route - netcat (perhaps could just integrate newer version of netcat from that has ipv6 support, if such thing exists?) - netstat - ping (ping6?) - dhcp client (?) - ppp (but looks like there is no ipv4 specific code, at least grepping "AF_INET" fails) Libraries: ----------------------- Existing IPv6 support: - libbind - getnameinfo(), getaddrinfo(), inet_ntop(), inet_pton() functions - struct sockaddr_in6 and other stuff in headers/posix/netinet6/in6.h - struct ip6_hdr and stuff (should be moved from src/libs/compat/freebsd_network/compat/netinet/ip6.h to somewhere else?) Needed IPv6 support: - ? Kernel: ----------------------- Existing IPv6 support: - routing table is totally address family independent - multicast code is nicely parametrized by address families, so adding IPv6 there shouldn't be hard Needed IPv6 support: - addressing - routing (?) - ICMPv6 - UDP, TCP over IPv6 - IPv6 specific socket option getting and setting, for example, IPV6_TCLASS option - "struct IPv6Multicast", similar to existing "struct IPv4Multicast", should be defined and used. Note that the multicast code is already templatized by address types.