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
That depends on your target market, but I doubt it.
That depends on your target market, but I doubt it.
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!!
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.
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.
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
Unfortunately I cannot be sure that the devices are only running in such isolated networks. Would be tunneling (ipv4 over ipv6) solution?
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,... :-)
So, I did get that right that using a router is actually within the scope of options for your projects?
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) ?
That seems rather odd. I would think it a very useful and not too difficult (based on a somewhat superficial understanding of IPv6). I would think an internal IPv4 network that shows up as a single IP address on an external IPv6 network would be quite a common thing for many years to come.
--
Grant Edwards grante Yow! Hold the MAYO & pass
at the COSMIC AWARENESS ...
visi.com
I had thought that there was a provision so that the entire IPV4 address range had a slot within the IPV6 address range.
Maybe nobody uses it. ?
--
ArarghMail809 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Dunno, but the concept of a single IPV4 address range is somewhat nonsensical given the prevalence of NAT firewalls.
There are millions of sets of overlapping IPV4 addresses ranges. Many of those have ever-shifting mappings into a single address within a publically visible address range. I don't see any reason why that single publically visible address of a NAT firewall has to be IPv4 just because the NAT'ed network behind it is IPv4.
--
Grant Edwards grante Yow! Are we wet yet?
at
visi.com
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ISTR the same thing too. From memory if the first 96 bits of the IPv6 address are all zero it is taken to be an IPv4 address. But I'm thinking back around ten years that I heard that so don't hold me to it.
this week was released the uIPv6 stack, which works in Contiki, and obtained the IPv6-ready logo (certification)
It was developed jointly by Cisco, Atmel and SICS.
The release comes with an implementation of 6lowpan RFC4944, and a port to Atmel RAVEN board, which embeds an 8-bit AVR microcontroller and a low power 802.15.4 chipset.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.