[ipv6-wg] IPv6 and embedded systems was: Re: 96 more bits... time for some magic after all?

As threatened...

Benedikt Stockebrand <bs at stepladder-it.com> writes:

> Hi Yannis and list,
>
> Yannis Nikolopoulos <dez at otenet.gr> writes:
>>>> Are discussion on moving away from /64's on the wire to...
>>> It's not just autoconfiguration, but when it comes to embedded
>>> system/microcontroller implementations, changing that is rather
>>> difficult.
>>
>> care to elaborate on that?
>
> Yes, but I'd rather do that in a separate thread/with a new subject...

Ok, sorry but this will be longish.  I'll try to organize things a bit.

Design considerations
---------------------
Embedded systems are generally designed and built for a fixed purpose.
(Arduino et al are development/prototyping platforms not really fit for
production use.)  When building for production it is essential to pick
the smallest, most limited microcontroller or CPU that can do the job
and only put things in there that are known to be needed.  In the
networking world you'd follow a similar approach when building a custom
firewall setup, in case you've ever tried to do so.

There are several reasons why it is so important to put effort into this
minimization when building embedded systems.

First of all, it reduces cost.  And in a market where a few cents in
price make the difference if your product or your competitors makes it
to the shelves of the major electronics outlets, this is absolutely
critical.  If you sell your SIP phone for example at 15.30
Euro/USD/whatever and your competitor sells at 15.20, then you are out
of business; if you manage to reduce your price by .15, then you
survive.  It's as simple as that.

Next, whatever isn't there can't break; this is particularly important
because many embedded systems simply *must* work, no matter what.  If
your car's anti-skid system crashes at the wrong moment, so will you.
In Germany a few years ago, some ISPs touted DSL, promising
"availability of up to 99%".  Aside from the obvious logical nonsense in
here, even if they had promised a 99% availability, that's several
orders of magnitude too bad for many embedded systems.  As a
consequence, people building embedded systems will habitually strip them
down to the absolute minimum.

Finally, especially when talking battery powered devices, power
consumption is usually a significant issue.  If it isn't there, it can't
consume power.  If it can't consume power, a smaller and less heavy (and
less expensive) battery can be used and recharge times may be reduced.
And when micro energy harvesting enters the equation, this gets even
more important.

In "normal" IT it is generally reasonable to buy somewhat oversized
because our systems tend to grow over time.  Embedded systems built for
a fixed purpose don't grow, so the entire way of thinking here is going
exactly the opposite way we've been taught in our line of business.

Operational aspects
-------------------
Embedded systems frequently don't assume a system administrator to be
around.  They are built to be handled by ordinary end users, like you in
your car, or an airline pilot in a---surprise---airliner.  And despite
various rumors, the onboard engineers of the past haven't been replaced
by a system/network administrator.

This means that embedded systems must frequently be built so people
without any particular knowledge can safely and reliably operate them.
This also applies to more mundane systems, like "smart" TVs or network
controlled heating radiator valves or such.

And when it comes to confronting end users with questions they can't
possibly answer, simply because they don't have the necessary technical
knowledge, that's enough for yet another thread---but not this time.

System updates
--------------
Updating an embedded system is troublesome in a number of ways.  First
of all, people frequently don't care about updates, as some recent
events at least here in Germany have shown.  My personal experience here
is more from a security point of view; let's say that a customer of mine
was kind of embarrassed when I happened to I mention security updates on
network printers...

Next, in a Harvard or even modified Harvard architecture, updates are
difficult to implement.  The larger AVR microcontrollers (see below)
support the concept of a "management system" called a boot
loader---which needs extra flash memory, of course.  But to do an
update it is necessary to trigger that update externally; there are no
automatic updates.

Even if there was a way to do automatic updates, how would one time
them?  Even a downtime of a few seconds may be unacceptable to your
power brake system while in heavy traffic.

As soon as embedded systems are used in critical environments, changes
need to be tested, validated and certified.  What's worse, if the
functionality is "improved", things that can happen are shown for
example here: 
http://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_751

Technical properties
--------------------
While some embedded systems have significant computational power
comparable to a full-blown computer, for example in the Linux-running
ones, microcontrollers are generally more limited.  

Just to give you some ideas; I'll stick with the Atmel AVR line of
microcontrollers, because I am most familiar with them and thanks to the
Arduino line of prototyping boards they are best known in general.
These are Harvard architecture devices, so they have separate (flash)
memory for code, (static) RAM for volatile data and EEPROM for
non-volatile data.  And no, there's no MMU, memory caches or DRAM; which
isn't altogether bad when building systems to hard realtime
requirements.

ATtiny13: 
  1 kB of flash memory, 64 bytes of RAM, 64 bytes of EEPROM
  5/6 GPIO pins, no dedicated I/O hardware

  This is rather limited for any kind of communications, except maybe
  via bitbanging the GPIO pins.  Yes, these devices are actually used.
  No, these are not the smallest ones available, but they are the
  smallest that can be programmed in-system.

ATtiny25:
  2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM
  5/6 GPIO pins, alternatively used for I2C or SPI

  These can actually be put on an I2C or SPI bus and combined with I2C
  or SPI peripherals that way.  It may be possible to use them with a
  USB or TCP/IP/Ethernet chip, but I don't have any reliable data, let
  alone personal experience, on this.

ATtiny2313:
  2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM
  11/12 GPIO pins, alternatively used for I2C, SPI or U(S)ART

  These can also do serial communication (RS-232/422/485 using suitable
  driver chips.  Even more interesting: With a few external components
  (Zener diodes and resistors?) they can also do USB in software, using
  about 1100 to 1300 bytes of their flash memory; search for V-USB for
  details.

ATmega328:
  32 kB flash, 2 kB RAM, 1 kB EEPROM
  23 GPIO pins, alternatively used for I2C, SPI, U(S)ART 
  Boot loader support

  These are used in the Arduino Uno board.  Combined with a hardware
  TCP/IP/Ethernet chip like the Wiznet W5100, they can do TCP/IP.  See
  below.

ATmega1284:
  128 kB flash, 16 kB RAM, 4 kB EEPROM.
  32 GPIO pins, alternatively used for I2C, SPI, 2x U(S)ART
  Boot loader support

  The most powerful AVR microcontroller available in a DIP package.
  Beyond that, it is SMD only.  But beyond this it's mostly more I/O
  stuff anyway.

To add network capabilities, this requires some extra hardware except
for the V-USB thing mentioned with the t2313.  

If you want to use the USARTs for RS-xxx: Maxim has a range
of driver chips with built-in charge pumps to convert between TTL and
RS-xxx voltages.

In case you want to limit yourself to USB, take a look at the FTDI
FT245BL.

There are Ethernet-only chips like the ENC 28J60.  According to a
statement during the last IETF meeting in Berlin, it is possible to
implement IPv6 with "only" 32 kB of flash and 4 kB of RAM.  In other
words, this is not an option for the Arduino Uno.  The Wiznet W5100 used
on the Arduino Ethernet shields implements IPv4 in hardware, or at least
parts of it---among the things missing are for example fragmentation.
So far I don't know of any similar chip implementing IPv6, let alone
dual-stack.

And to return to Yannis' original question: If I was to implement IPv6
in a setup like this I'd read the RFCs in question very closely---and
then I'd take every simplification I could get away with.  Hardcoding a
/64 subnet prefix length in that implementation would be one I'd have
absolutely no problem with; doing so would be standards compliant, save
a few bytes of flash, and a lot of frustration for end users who in all
likelyhood wouldn't know what value to set it to anyway, but try just
about anything if things don't work out of the box.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.        http://www.stepladder-it.com/