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 <[email protected]>
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
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
