IPv6 vs. IPv4 for embedded devices

Hi,
I am just gathering informations on how to equip an existing device with 
an ethernet interface in order to enable remote tcp/ip access. Most of 
the available tcp/ip stacks as well as chips with built-in tcp/ip 
functionality I found so far only support ipv4. My question is: isn't 
this a dead end? Don't I have to expect the demand to upgrade to ipv6 
quite soon? I know ipv6 puts a lot more requirements on the hardware, 
but on the other side the growing number of internet-enabled devices is 
one of the reasons why the larger address space of ipv6 is needed.
I would be glad to hear some opinions on this topic,
yours
    Dirk

On 2008-09-12, Dirk Zabel <zabel@riccius-sohn.com> wrote:

> I am just gathering informations on how to equip an existing
> device with an ethernet interface in order to enable remote
> tcp/ip access. Most of the available tcp/ip stacks as well as
> chips with built-in tcp/ip functionality I found so far only
> support ipv4. My question is: isn't this a dead end?

That depends on your target market, but I doubt it.

> Don't I have to expect the demand to upgrade to ipv6 
> quite soon?

That depends on your target market, but I doubt it.

> I know ipv6 puts a lot more requirements on the hardware, but
> on the other side the growing number of internet-enabled
> devices is one of the reasons why the larger address space of
> ipv6 is needed. I would be glad to hear some opinions on this
> topic,

For a local network IPv4 works fine and always will.  If your
device never has to communicate over the internet, the it may
never need ipv6.  If it does need to communicate over the
internet, then it might someday need ipv6.

You're going to have to ask your customers.  We've no way of
knowing what they're going to want.

-- 
Grant Edwards                   grante             Yow! My BIOLOGICAL ALARM
                                  at               CLOCK just went off ... It
                               visi.com            has noiseless DOZE FUNCTION
                                                   and full kitchen!!

On 2008-09-12, Dirk Zabel <zabel@riccius-sohn.com> wrote:
> Hi,
> I am just gathering informations on how to equip an existing device with 
> an ethernet interface in order to enable remote tcp/ip access. Most of 
> the available tcp/ip stacks as well as chips with built-in tcp/ip 
> functionality I found so far only support ipv4. My question is: isn't 
> this a dead end? Don't I have to expect the demand to upgrade to ipv6 
> quite soon? I know ipv6 puts a lot more requirements on the hardware, 
> but on the other side the growing number of internet-enabled devices is 
> one of the reasons why the larger address space of ipv6 is needed.
> I would be glad to hear some opinions on this topic,

IMHO widespread deployment of IPv6 always seems to be a couple of
years away.  It does now, it was a couple of years ago, and indeed,
it was even maybe ten years ago.  However, it is inevitable that
some day IPv6 networking will be the rule rather than the exception.
Probably in a couple of years time for most machines, but embedded
devices will likely have a little longer in practice to make the
switch.

As for integrating support into devices then like anything else in
the embedded world then surely it depends on the nature of the
device.  Things like IPsec will take a lot of space so if your
device is PIC, AVR or MSP430 based you may well find IPv6 won't
fit without going up to a much more capable device family.

Consider also what the device does.  We seem to have got into the
habit of saying any IPv4 device can be controlled from anywhere in
the world regardless of how much sense that actually makes.  If a
device would naturally only be controlled within an organisation
then does it really matter if it only supports IPv4 when the wider
Internet is only running IPv6?  As long as your own LAN can support
both (and the two protocols are designed to coexist well) you
shouldn't have any problems.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

Dirk Zabel wrote:
> Hi,
> I am just gathering informations on how to equip an existing device with 
> an ethernet interface in order to enable remote tcp/ip access. Most of 
> the available tcp/ip stacks as well as chips with built-in tcp/ip 
> functionality I found so far only support ipv4. My question is: isn't 
> this a dead end? Don't I have to expect the demand to upgrade to ipv6 
> quite soon? I know ipv6 puts a lot more requirements on the hardware, 
> but on the other side the growing number of internet-enabled devices is 
> one of the reasons why the larger address space of ipv6 is needed.
> I would be glad to hear some opinions on this topic,
> yours
>    Dirk

Hi Dirk

Contiki has an extremely rudimentary IPv4 and IPv6 implementation, that 
is chosen at compile time. Contiki has been ported to many platforms:

http://en.wikipedia.org/wiki/Contiki

/Glenn

Andrew Smallshaw schrieb:
> On 2008-09-12, Dirk Zabel <zabel@riccius-sohn.com> wrote:
>> Hi,
>> I am just gathering informations on how to equip an existing device with 
>> an ethernet interface in order to enable remote tcp/ip access. Most of 
>> the available tcp/ip stacks as well as chips with built-in tcp/ip 
>> functionality I found so far only support ipv4. My question is: isn't 
>> this a dead end? Don't I have to expect the demand to upgrade to ipv6 
>> quite soon? I know ipv6 puts a lot more requirements on the hardware, 
>> but on the other side the growing number of internet-enabled devices is 
>> one of the reasons why the larger address space of ipv6 is needed.
>> I would be glad to hear some opinions on this topic,
> 
> IMHO widespread deployment of IPv6 always seems to be a couple of
> years away.  It does now, it was a couple of years ago, and indeed,
> it was even maybe ten years ago.  However, it is inevitable that
> some day IPv6 networking will be the rule rather than the exception.
> Probably in a couple of years time for most machines, but embedded
> devices will likely have a little longer in practice to make the
> switch.
> 
We are in the HVAC market, and in the past our devices were expected to 
work for 10~15 years. And it is not as easy to update a device as it is 
to update a desktop application.

> As for integrating support into devices then like anything else in
> the embedded world then surely it depends on the nature of the
> device.  Things like IPsec will take a lot of space so if your
> device is PIC, AVR or MSP430 based you may well find IPv6 won't
> fit without going up to a much more capable device family.
> 
> Consider also what the device does.  We seem to have got into the
> habit of saying any IPv4 device can be controlled from anywhere in
> the world regardless of how much sense that actually makes. 
That is true, of course, but what customers SAY what they need and what 
the actually DO need (and what they are ready to pay for, btw.) is not 
always the same. But we do in fact have very common cases, where the 
devices are controlled remotely over modem connections (sometimes the 
devices are in the same city as the controling site, but not always). So 
the devices are really expected to be available from outside, i.e. by 
connecting then to the internet via a router.
  If a
> device would naturally only be controlled within an organisation
> then does it really matter if it only supports IPv4 when the wider
> Internet is only running IPv6?  As long as your own LAN can support
> both (and the two protocols are designed to coexist well) you
> shouldn't have any problems.
> 
Unfortunately I cannot be sure that the devices are only running in such 
isolated networks. Would be tunneling (ipv4 over ipv6) solution?

Thank you for your comments,
-- Dirk

Glenn M�ller-Holst schrieb:
> Dirk Zabel wrote:
>> Hi,
>> I am just gathering informations on how to equip an existing device 
>> with an ethernet interface in order to enable remote tcp/ip access. 
 >> [..]
>>    Dirk
> 
> Hi Dirk
> 
> Contiki has an extremely rudimentary IPv4 and IPv6 implementation, that 
> is chosen at compile time. Contiki has been ported to many platforms:
> 
> http://en.wikipedia.org/wiki/Contiki
> 
> /Glenn
Hi Glenn,
thank you for the link. I took a quick look into Contiki, and it seems 
they are using the uIP stack from Adam Dunkel. I was aware of this 
stack, but as far as I see it is ipv4 only.
Has a nice porting list, reminds me of some experiences *very* long ag: 
commodore pet, apple II,... :-)
--
   Dirk

On 2008-09-12, Dirk Zabel <zabel@riccius-sohn.com> wrote:

> Unfortunately I cannot be sure that the devices are only running in such
> isolated networks. Would be tunneling (ipv4 over ipv6) solution?

It could be, but NAT is probably much more common.

-- 
Grant Edwards                   grante             Yow! Somewhere in DOWNTOWN
                                  at               BURBANK a prostitute is
                               visi.com            OVERCOOKING a LAMB CHOP!!

Hi,

[snip]

> So the devices are really expected to be available from outside, i.e. by 
> connecting then to the internet via a router.

So, I did get that right that using a router is actually within the scope of 
options for your projects?

> Unfortunately I cannot be sure that the devices are only running in such 
> isolated networks. Would be tunneling (ipv4 over ipv6) solution?

If you are contemplating solutions like tunneling and are using a router - 
would it be an option to have your solution use IP4 and have the router's 
NAT deal with the outside world's IP6 (if and when applicable) ?

Stefan 

Dirk Zabel wrote:
> Glenn M�ller-Holst schrieb:
>> Dirk Zabel wrote:
>>> Hi,
>>> I am just gathering informations on how to equip an existing device 
>>> with an ethernet interface in order to enable remote tcp/ip access. 
>  >> [..]
>>>    Dirk
>>
>> Hi Dirk
>>
>> Contiki has an extremely rudimentary IPv4 and IPv6 implementation, 
>> that is chosen at compile time. Contiki has been ported to many 
>> platforms:
>>
>> http://en.wikipedia.org/wiki/Contiki
>>
>> /Glenn
> Hi Glenn,
> thank you for the link. I took a quick look into Contiki, and it seems 
> they are using the uIP stack from Adam Dunkel. I was aware of this 
> stack, but as far as I see it is ipv4 only.
> Has a nice porting list, reminds me of some experiences *very* long ag: 
> commodore pet, apple II,... :-)
> -- 
>   Dirk

Hi Dirk

Look at:

Re: [6lowpan] 6lowpan implementation for TinyOS 2.0:
http://www.ietf.org/mail-archive/web/6lowpan/current/msg00645.html
Quote: "...
I have implemented a 6lowpan/IPv6 stack for TinyOS 2.0.
...
More details can be found in my MSc Thesis
http://www.eecs.iu-bremen.de/users/harvan/docs/msc-thesis.pdf

Source code is available from [link do not work]
http://www.eecs.iu-bremen.de/users/harvan/files/6lowpan.tar.gz
..."

Connecting Wireless Sensor Networks to the Internet - a 6lowpan 
Implementation for TinyOS 2.0
http://www.inf.ethz.ch/personal/mharvan/talks/6lowpan.pdf

NanoStack is a 6lowpan IPv6 + IEEE 802.15.4 protocol stack, enabling 
wireless embedded and sensor networking:
http://sourceforge.net/projects/nanostack/
http://www.sensinode.com/top/information.php?info_id=14

-
-

 From Contiki:

Makefile.include
"...
#include $(CONTIKI)/core/net/ipv6/Makefile.ipv6
..."

-

uip.h
( http://www.sics.se/~adam/uip/uip-1.0-refman/a00203.html )
"...
#if UIP_CONF_IPV6
typedef uip_ip6addr_t uip_ipaddr_t;
#else /* UIP_CONF_IPV6 */
typedef uip_ip4addr_t uip_ipaddr_t;
#endif /* UIP_CONF_IPV6 */
...
#define uip_ip6addr(addr, 
addr0,addr1,addr2,addr3,addr4,addr5,addr6,addr7) do { \
                      (addr)->u16[0] = HTONS(addr0); \
                      (addr)->u16[1] = HTONS(addr1); \
                      (addr)->u16[2] = HTONS(addr2); \
                      (addr)->u16[3] = HTONS(addr3); \
                      (addr)->u16[4] = HTONS(addr4); \
                      (addr)->u16[5] = HTONS(addr5); \
                      (addr)->u16[6] = HTONS(addr6); \
                      (addr)->u16[7] = HTONS(addr7); \
                   } while(0)
...
#if !UIP_CONF_IPV6
#define uip_ipaddr_cmp(addr1, addr2) ((addr1)->u16[0] == (addr2)->u16[0] 
&& \
				      (addr1)->u16[1] == (addr2)->u16[1])
#else /* !UIP_CONF_IPV6 */
#define uip_ipaddr_cmp(addr1, addr2) (memcmp(addr1, addr2, 
sizeof(uip_ip6addr_t)) == 0)
#endif /* !UIP_CONF_IPV6 */
...

/* The TCP and IP headers. */
struct uip_tcpip_hdr {
#if UIP_CONF_IPV6
   /* IPv6 header. */
   u8_t vtc,
     tcflow;
   u16_t flow;
   u8_t len[2];
   u8_t proto, ttl;
   uip_ip6addr_t srcipaddr, destipaddr;
#else /* UIP_CONF_IPV6 */
   /* IPv4 header. */
...

/* The ICMP and IP headers. */
struct uip_icmpip_hdr {
#if UIP_CONF_IPV6
   /* IPv6 header. */
   u8_t vtc,
     tcf;
   u16_t flow;
   u8_t len[2];
   u8_t proto, ttl;
   uip_ip6addr_t srcipaddr, destipaddr;
#else /* UIP_CONF_IPV6 */
   /* IPv4 header. */
...
#define UIP_PROTO_ICMP6 58

/* Header sizes. */
#if UIP_CONF_IPV6
#define UIP_IPH_LEN    40
#else /* UIP_CONF_IPV6 */
#define UIP_IPH_LEN    20    /* Size of IP header */
#endif /* UIP_CONF_IPV6 */
..."

/Glenn

On Fri, 12 Sep 2008 10:36:54 -0500, Grant Edwards wrote:
> On 2008-09-12, Dirk Zabel <zabel@riccius-sohn.com> wrote:
>
>> Unfortunately I cannot be sure that the devices are only running in such
>> isolated networks. Would be tunneling (ipv4 over ipv6) solution?
>
> It could be, but NAT is probably much more common.

I have limited experience with IPV6 but from what I've read there
appears to be no NAT between IPV4 and V6. Many of the managed network
service providers are going dual stack (IPV4 talks to IPV4, IPV6 to
IPV6 and never the twain shall meet). The whole thing is quite
confusing and I don't think it will be settled anytime too soon. 

-- 
Linux Home Automation         Neil Cherry       ncherry@linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies