As threatened... Benedikt Stockebrand <bs@stepladder-it.com> writes:
Hi Yannis and list,
Yannis Nikolopoulos <dez@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/