Device-os: IPv6 support for Photon

[m-mcgowan]

The WICED SDK supports IPv6 out of the box, and it's a often requested feature, and necessary to support the bazillions of Photons that will be used around the world.

The WICED SDK interface is straightforward - it provides an address structure that can be either IPv4 or IPv6. The tricky part is extending the wiring API to accommodate IPv6.

IPv4 currently touches these areas:

• IPAddress - a structure containing 4 bytes for the IPv4 address.
• Spark_Connect() cloud connection assumes 4 byte address, and 4-byte address stored in flash as part of cloud endpoint config
• WLanConfig in HAL - DNS, IP, Gateway etc.. each address is hard-coded to 4 bytes
• inet_ping in HAL takes a 4 byte address
• inet_gethostbyname in HAL fetches a 4 byte address
• sockaddr_t in HAL has a 14-byte structure, with 4 bytes reserved for the IPv4 address and 2 bytes for the port.

(There may be others - these were the first ones to come to mind.)

The IPAddress class in wiring can be extended to contain a flag indicating the address version. (4 or 6) and the internal storage extended to 16 bytes.

The parts of the system that work with IP addresses should be extended to accomodate IPv6 addresses.

Where IPv4 addresses are passed as arrays, one possibility is the use of a struct with 16 bytes for the address and a selector to indicate IPv4 or IPv6.

Another option is to provide parallel functions that operate specifically with IPv6 addresses, such as inet_gethostbyname_ipv6, and socket_create_ipv6(sock_addr_ipv6_t addr).

Finally, all IPv6 support may be compile-time conditional to avoid any adverse affects on the wiring and hal for the core. (There's no point passing a 16-byte structure to code that will never use it.)

[m-mcgowan]

To get IPv6 on WICED 3.3.1 requires that we change both the RTOS and the Networking stack to ThreadX/NetXDuo. We could investigate this to see how feasible it is. Another alternative is to replace LwIP with a later version that includes IPv6 support. This too many be tricky since the WICED SDK does contain some changes to the LwIP code.

[monkbroc]

My initial investigations found that LwIP does not yet have a dual-stack version. Their have an IPV4 version and an IPV6 version.

It we switch the Photon to ThreadX it would help our sanity to also switch the Electron.

I'll keep investigating.

[m-mcgowan]

ThreadX is not available on the Electron at present unless we obtain a license, and we would prefer to continue to use open source libraries where possible.

[m-mcgowan]

The details here say that LwIP is either IPv4 or dual stack - http://lwip.wikia.com/wiki/LwIP_IPv4/IPv6_stacks. Also here - http://stackoverflow.com/questions/25782862/lwip-ipv6-config.

[monkbroc]

NetX Duo is Express Logic’s new TCP/IP stack that provides both IPv4 and IPv6 capabilities in a dual-stack product

So for IPv4 and IPv6 we'd need to switch to ThreadX/NetX_Duo.

[m-mcgowan]

No, there's a dual stack version of LwIP, so we don't need to go to closed-source libraries.

[m-mcgowan]

Dual stack is already in release candidate stage on their repo. http://git.savannah.gnu.org/cgit/lwip.git/commit/?h=STABLE-2_0_0&id=33955c636d17bee230cde746a92e1cff11a7a177

The WICED SDK has some (relatively small) changes to LwIP 1.4.0-rc.1 that SDK 3.3.0 is based on, so we cannot simply drop in LwIP 2.0.0-rc.1. Instead, we'll need to figure out what the differences between WICED LwIP 1.4.0-rc.1 and the stock LwIP 1.4.0-rc.1 are, and apply them as needed to LwIP 2.0.0-rc.1.

With dual stack LwIP in release candidate stage, we can start making forward motion to including that in our WICED stack. This would be ideally done as an additional network stack option at compile time - LwIP_Duo - adding to the existing LwIP, NetX and NetX_Duo network stacks.

[owendelong]

This topic hasn't been touched since May 3, 2016. Many of us were really hoping to see IPv6 on the 0.5.0 firmware, which didn't happen.

I love my photons and am looking forward to loving my electrons, but I _REALLY_ _REALLY_ need IPv6 support, especially in the cellular environment.

Is there any chance this much needed feature promised for 2016 can see forward progress in 2017?

[owendelong]

Still no response from Particle on github. I opened a ticket and their response was "watch github".

Maybe this will get their attention... Hey Particle, you're about to get passed by:
https://www.kickstarter.com/projects/smartmachine/6lowpan-devices-designed-for-network-and-iot-appli

[dmiddlecamp]

Hi @owendelong,

Thanks for the ping! Sorry we haven't been able to respond yet! Please know that we're discussing this issue internally, and other people are interested in this feature as well.

Also, we love makers, innovators, and new kickstarter campaigns! Best of luck to Smartmachine! Excited to see more 6lowpan devices.

Thanks,
David

[sparksis]

@monkbroc @dmiddlecamp Can we get an update on these "internal discussions"? It seems that you're not very committed to the IoT ideology that each device should be addressable... Your APIs rate limit way too quickly and under IPv4 it is not feasible to have one ip address per device.

I've spent $250 on you guys for hobby project based on your board but am looking for alternatives due to the lack of support around IPv6/fast rest.

[dmiddlecamp]

Hi @sparksis,

Thanks for the ping! We're a small team and there's a big list of features we're working on at any given time. I'll bring this up with the team and see if we can give an update.

Thanks!
David

[sparksis]

@dmiddlecamp Thanks for the quick response. I appreciate that you have a lot of pressure on you to deliver features but from my point of view many of the other core features are available. IPv6 is the one component that is limiting me from taking any of my projects to the next level.

[sparksis]

@dmiddlecamp

[sparksis]

4 month check in. Any chance we can get that update? If not can you close this ticket as will not fix?

[monkbroc]

IPv6 is a feature request that we revisit often when reviewing the firmware roadmap. Up to now it has not been feasible to implement without uprooting up a good portion of the network stack. That said we are still looking for ways to make IPv6 on Particle happen.

[ScruffR]

Update needed:
https://community.particle.io/t/photon-ipv6-support/9158/31

IPv6 was promised for Dec. 2015. Back then reason (excuse) for the delay was Electron development, are we now using running the same risk with Gen3?

[owendelong]

Another year gone by with no apparent progress?

[owendelong]

Espressif has replaced Particle for my general iOT development platform at this point due to IPv6 support.

[owendelong]

Got the new product message today, so decided to review where this issue stands.

Looks like still no progress, so guess I'll be ordering another batch of ESP chips.

[jenschr]

I'm also getting requests for IPv6 from customers. It's a little sad to have to say that I just don't know :-/

[alexiri]

It's a little sad to have to say that I just don't know :-/

It's been almost 5 years since this issue was opened. I think we know.

[owendelong]

It's quite obvious at this point that any promise of IPv6 support was dramatically overblown and that Particle has no intention of supporting IPv6 in anything resembling a reasonable timeframe.

Perhaps this explains why I'm buying so many of my IoT things from vendors that do.