Sorry folks but now you go off the planet. If one thinks an embedded device can't do IPv6 because of CPU load, think again. An Wireless access point using OpenWRT does support IPv6 and just works. I can't remember how slow those boxes are but their speed is just enough to cope with ethernet and wlan.
Byteswapping of addresses and netmasks takes like a nanosecond on the systems which require swapping. So dont waste your time on that. CRC checking is way more CPU intensive on TCP but that's done nowadays in hardware on the ethernet card on modern systems and its the same for IPv4 and IPv6.
On 02.03.2009, at 23:14, Stanislav Sinyagin wrote:
hi Tonnerre,
From: Tonnerre Lombard tonnerre@bsdprojects.net
What you can fit into 2MB flash is Linux kernel 2.4.x, plus some very limited number of libraries, daemons and utilities. Also, even the newest 2.6.x kernel is permanently popping up with ipv6 improvements and bugfixes. It is physically impossible to run a 2.6.x Linux system from 2MB flash. You can, however, run it from 4MB, and there's even some room for ipv6. The dd-wrt software for Linksys routers seems to support it, but I didn't test it.
A slimmed down NetBSD kernel can fit into 2MB including IPv6 support. (You have to put some work into it though.)
unfortunately, NetBSD is way behind Linux in regards to new hardware support, especially for those consumer-grade devices. Most of the new reference boards come with quite poorly designed Linux BSP, and I haven't heard of any BSD support from the embedded hardware vendors.
Besides, as I told already, this linux/bsd hacking is for geek enthusiasts. Consumer electronics vendors will just push new hardware to the market.
Some of those devices are hardware-fixed to little endian architecture, even if the CPU allows running either BE or LE (bit noth both at the same time). In LE architectures, you have to swap bytes in every packet header in order to get the IP address or TCP port number. This slows down ipv6 processing significantly, as there are many more bytes to swap.
That should only apply if you use arithmetic comparison functions. For pure subnet calculations and matching, you can work on the unswapped data (if you always compare in network byte order, which isn't hard). There goes your bottleneck.
I looked into the ipv6 linux kernel sources, and found quite a lot of hton/ntoh conversions. Also, for example, subnet mask matching is way more complex in foreign endianness :)
(Also, what kind of argument is this? IPv4 also needs to be byteswapped.)
ipv6 has many more bytes to swap in the packet header, that's the only reason :)
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog