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