Support for IPv6

Hello

I have a sensor up and running since May 1st and I am impressed. But there is one thing that disappoints me: it does not support IPv6!

IPv6 has been around everywhere for well over a decade now and IMNSHO it can no longer be ignored. Is there any chance it will be implemented in the foreseeable future? By a firmware upgrade?

Hello,

every new feature needs more memory. But the ESP8266 has very limited resources. You could check the amount of additional memory by modifying our firmware, it’s open source. Enabling IPv6 should be only changing a compile switch in the file platform.io. Search for IPv6, that should find a comment where you can also read why we haven’t implemented this until now even as we had the needed memory.

As for the additional memory usage when enabling IPv6:

With IPv6:

RAM:   [====      ]  43.9% (used 35944 bytes from 81920 bytes)
Flash: [=======   ]  69.6% (used 726907 bytes from 1044464 bytes)
Reported free memory: ~ 26K

Without IPv6:

RAM:   [====      ]  41.9% (used 34300 bytes from 81920 bytes)
Flash: [=======   ]  67.2% (used 702159 bytes from 1044464 bytes)
Reported free memory: ~ 28K

There is also a github issue IPv6 Support · Issue #605 · opendata-stuttgart/sensors-software · GitHub with some background on the main reason it is currently not enabled.

IPv6-enabled IoT-devices with limited resources heavily depend on security policies on the perimeter (the router). Most consumer-grade IPv6-enabled routers nowadays should however by default block incoming IPv6 connections but the risk of exposing the WebUI to the public Internet is still a bit higher with IPv6.

Besides that there are also other issues. Just enabling IPv6 in platformio.ini by default won’t do much. You will be able to connect to the WebUI over IPv6 and you can configure IPv6-only API-servers. But most traffic will just be over IPv4 unless you use a compile time switch to prefer IPv6 DNS-resolving (AAAA records) over IPv4 (A records). That however will break the firmware on IPv4 only networks.

Also the IPv6-enabled firmware won’t work in an IPv6-only network. The code expects an IPv4 address and will start AP-mode without that (amongst other issues).

So without additional code modifications the benefits of just enabling IPv6 are minor.

If you have a working dual-stack network you can try the code at GitHub - Phaze-III/sensors-software at feature/enable-ipv6 . Firmware binaries can be downloaded from the actions page at Workflow runs · Phaze-III/sensors-software · GitHub Select the most recent run and download the ‘artifacts’.

That one prefers IPv6 connections (but as said won’t work on IPv4-only nor IPv6-only networks) and will upload data over IPv6 to Madavi and Sensor.Community. It even does OTA-upgrades over IPv6 :slight_smile:

@ricki-z
I found the compile switch in platformio.ini. Although I have done my fair share of programming for stand alone devices, that was over 30 years ago when such things were written in assembler and burned into EPROM. I have been out of the loop for too long and I no longer have the resources and the knowledge to compile and build a new firmware myself.

I didn’t realise that the ESP8266 was so spartanic on memory that adding IPv6 might be a problem. It reminds me of my advertures with the Science of Cambridge MK14 when an extra 256 bytes of memory was a gift from heaven. :wink:

@Phaze-III
Tnx for your response. It took me a couple of days to let it sink in…

  1. I am pleased to see that IPv6 has not been ignored and that a lot of it is already potentially there.

  2. Regarding memory: Looking at the numbers you gave, I do not think it is serious problem. With IPv6 enabled there is still room for other new features I’d say…

  3. Regarding te UI being accesable from outside with IPv6 anabled: I do not think that is a problem either. It may have been an issue in the early days of IPv6, but not any more. I have been playing around with IPv6 for more than 15 years and I have never had a router in my hand that does not have a firewall that does not block all unsollicited incoming IPv6 packets by default.

  4. Of course IPv6 should be prefered when making connections, with fall back to IPv4 when an IPv6 connection fails. You mention that setting that compile switch will break the firmware in IPv4 only networks. What exactly will it break and does the break only occur in client mode or also in AP mode?

  5. A pity that with full IPv6 enabled the device can not function in Single Stack networks. I have had Full Dual Stack for some 15 years so for me it is not a problem. But I am already experimenting with IPv6 only in my lab. The device - like any other network - device should eventually be able to function in an IPv6 only environment but I accept that for the moment this is a bridge too far. And of course - while IPv4 is still around - it should also work in an IPv4 only environmemt.
    My understanding is that it goes into AP mode when it has not been served an IPv4 addrese within two mintutes after boot up. Is that the only problem with IPv6 only?

  6. I’d love to test the experimental IPv6 version for which you provided a link. As soon as I have figured out how to load that into my ESP8266. And how to recover when something goes wrong. As I mantioned I have not done such things in a long time. Can you give me some pointers on how to flash alternate firmware into the device?

  7. Just something that popped up in my mind: For the future: How about instead of one or more compile switches, making it a user switch in the configuration. In the “advanced, only know what you are doing” section of course. A switch that is off by default. And to save the user from painting him/herself into a corner have it only apply to client mode and leave the AP mode IPv4 only for the time being?

Re 3.: The switch used to prefer IPv6 DNS lookups will just do that, when connecting to a server the firmware will lookup the IPv6 address (DNS AAAA record) of the hostname. If there is no AAAA record it will look for an A record (IPv4 address). It will then connect to the first found address. When, for whatever reason, that connection fails there is no fall back or retry.

Without additional code modifications it will also do that on an IPv4 only network. Which means that connections to hosts with an AAAA record will always fail.

This is in client mode. For AP mode it doesn’t really matter since in AP-mode there is no connected network and the node runs with a predefined IPv4 address. There won’t be outgoing connections in AP-mode.

Note that this option might not be the best way to do things, I didn’t do a deep dive in the LWIP code to look for other/better methods. The main goal was to get the firmware to use IPv6 without major modifications.

Re 4.: Going to AP-mode is the main problem. Other potential issues are NTP and mDNS and I’m not sure how the used framework/library handles the various IPv6 autoconfiguration setups.

Re 5.: The provided link only shows a downloadable file with firmware builds for registered github users. I’ve also created a ‘release’ where you can get the firmware builds without github-account: Release NRZ-2024-136-B1 with IPv6 enabled (preliminary test builds) · Phaze-III/sensors-software · GitHub

For flashing the firmware I use esptool (esptool.py or esptool.exe) from the command line. esptool can be found at Releases · espressif/esptool · GitHub . On Linux/Mac esptool(.py) is also available in most package repositories.

From the command line you can use something like the following to flash the firmware (Windows):

esptool --port COM3 --baud 115200 write_flash 0x0 latest_nl.bin

or (on Linux/Mac)

esptool.py --port /dev/<yourdevice> --baud 115200 write_flash 0x0 latest_en.bin

Existing settings on the sensor are preserved and if it breaks you can always go back to the official firmware with the airrohr-flasher (which I assume you used already).

If you’re not comfortable with the command line you can (Windows only) use a small graphical utility from Releases · BattloXX/ESPEasyFlasher · GitHub which basically provides a simple GUI to call esptool with the above mentioned parameters.

Re 6.: Making IPv6 configurable certainly would be an option although ideally it should not be needed. However it needs to be coded, just as the modifications needed to fix the above mentioned issues. For me that might be a bridge too far at the moment.

@Phaze-III
Thank you for your elaborate reply. Once again it took me a while to let it sinki in.

Re 3: I agree the the present way of choosing between IPv4 and IPv6 is not optimal. OTOH, Happey Eyeballs" may be a bit of an overkill for this application. I think it will do for now, even for a public release.

Re 4: Maybe we should just forget about IPv6 only networks for now and leave that for the next version. If it works on dual stack networks that is better than no iPv6 at all.

Re 5: I have not used the airrohr flasher yet. This is a project from the municipality (Utrechtse Heuvelrug). With some 20 participants we assembled it from a kit. The firmware was preloaded, we only needed to enter the SSID and password of the WiFi to make it go on-line.

But I found a link to a desription (in Dutch) on how to use the flasher, so I will probably all right when it comes ti that, Or I could try to find the guy who flashed the firmware into the units in the kit.

I am familiar with the command line. The concept of “USB to serial” is new for me however. :smile: I think I can make it work when I get a round toit.

Re 6: I agree that in the end IPv6 should work without having to activate it as an option. It may however be a work around for the moment. I had hoped that we could have a public release with IPv6 working. So without the need to install special beta versions. If making it an option would make that possible without extensive modifications to the code, it would be nice. Especially it it would arrive as a reular OTA update.

BTW, I have firmware version NRZ-2024-135/EN (Apr 9 2024) So pretty recent.