Dual-stack IPv6 support: working build, looking for direction on library integration

1

Hey @overeasy !

I’ve loved this project for a long, long time, and I figured it’s time to give back. I’m also a big IPv6 advocate, so this is where I wanted to start. :slight_smile:

TLDR; over the past few weeks I built dual-stack IPv6 support for IoTaWatt, it’s been soaking on my own units, and I’d like to get it upstream. The one decision I need your read on before I prepare anything concrete: how would you want the ESPAsyncTCP dependency handled?

  1. Vendor the patched source into the IoTaWatt tree.
  2. Depend on a tagged upstream fork (esphome’s is actively maintained).
  3. Some other arrangement you’d prefer.

That choice shapes how I’d prepare everything else, so it’s the first thing I want your thoughts on.

The rest is the detail behind that ask:

I run a handful of IoTaWatt units on a dual-stack network at home and wanted them reachable over IPv6 the way they already are over IPv4. What works today, on my units:

  • Inbound: the web UI and digest auth over a global IPv6 address (http://[GUA]/), same behavior as over IPv4.
  • Outbound: the uploaders (Emoncms, InfluxDB, PVoutput) over IPv6, with a lightweight happy-eyeballs approach: prefer IPv6, fall back to IPv4 on connect failure. Dual-stack endpoints get v6; IPv4-only endpoints (which is all of them today) resolve and connect exactly as they do now.
  • SLAAC address acquisition and renewal, with the localAccess same-subnet bypass extended to the IPv6 /64 and link-local clients excluded from it.

The most recent build has a multi-day continuous run behind it: heap flat, uploaders posting every cycle, and I OTA’d it to itself over IPv6.

It rides on two dependencies, and both are why I’m asking rather than just sending a PR.

1. ESP8266 core 3.x. IPv6 in lwIP needs the newer core (espressif8266 @4.2.1). I think you moved to core 3 in 2022 and rolled it back after some failures (I pieced the timeline together from the git history). I hit SD-card init failures doing the same migration, and tracked down the mechanism:

  • It was not the partition type byte. It was SdFat 2.x requiring exactly two FAT tables, which rejects single-FAT cards. The factory cards from that batch were single-FAT, if I have that right.
  • There is a one-line bench reproduction: mkfs.fat -F 32 -f 1 on a spare card reproduces the failure on core 3.x and mounts fine on 2.4.0.
  • The fix is greiman’s own: current SdFat accepts one or two FAT tables (the mount check is now fatCount != 1 && fatCount != 2, with matching root-directory and FAT-mirror handling for the single-FAT case). It landed in August 2025 (greiman/SdFat commit cda05731, bundled in with some unrelated exFAT changes), but it hasn’t reached the ESP8266 SdFat fork yet, so for now I backport those few lines at build time.

I’m happy to write that up on its own, since it’s the piece that makes revisiting core 3.x safe.

2. The async TCP stack. The outbound path uses ESPAsyncTCP plus your asyncHTTPrequest. IPv6 needs a small change in ESPAsyncTCP (use IPADDR_TYPE_ANY on connect, and AAAA-capable DNS resolution), plus two small fixes in asyncHTTPrequest (accept bracketed IPv6 literal URLs, and a destructor fix for a connection-cleanup leak that shows up under fast reconnect). The asyncHTTPrequest changes go to your own repo and are small. The ESPAsyncTCP change is the open question from up top: vendor it in-tree, or depend on a tagged upstream fork.

One thing I’ll call out on scope: I intend to keep full IPv6 mDNS (AAAA records over .local) as its own piece of work, separate from the main IPv6 changes. I have it working on my units, a native dual-stack lwIP responder answering A and AAAA over both transports, but it reaches into the lwIP build itself (a rebuilt lwIP), so it’s a deeper change than the rest and better handled on its own. The main IPv6 changes keep the existing IPv4 mDNS, and the device is reachable over IPv6 by address and by AAAA from normal DNS regardless.

2

hello @cr0ntab,

This is a very impressive hack and I commend you on the level of research that you have done as well as getting it running. Stick with me and I’ll explain why I am not interested in adding this to the IoTaWatt firmware.

First, let me say that I don’t quite understand some of the lingo or even concepts that you talk about. I rely on the lower level stack to handle these things and don’t get into the nitty-gritty. I have not needed to get involved with IPv6 and have never to my recollection had anyone inquire about support for it. I’ve gotten tons of inquiries for ethernet capability, PoE and other com related functionality, but not IPv6.

Educate me if I’m wrong but it seems to me that in the IOT space where IoTaWatt lives exclusively in the WiFi domain, there is really no problem with IPv4 as the WiFi router will NAT the local address to whatever is needed on the WAN.

My considerations in avoiding this dual-stack support are twofold:

First, for many years I have avoided integrating code that I don’t understand and cannot support directly. I couldn’t even answer questions about how to use it much less determine if these changes have anything to do with other WiFi issues. I think I can safely say that WiFi issues and SDcard failures are about the only problems that occur, albeit infrequently, with the thousands of units installed worldwide. I feel confident that I can support that base as well as the new users being added with the CircuitIQ units now available.

My second reason is that the code is currently rock solid and will probably run with minimal work for as long as folks want to use it. While I continue to support it via this forum, I’ve stopped working on it (I have a few very minor fixes to put into a release probably in the Fall) but I’m well into my second retirement and don’t really want to do anything that might generate a workload.

Also consider that I have an ESP32 version of IoTaWatt that has been running solid for over a year. It has substantial improvements and innovations over the ESP8266 version. The ESP32 supports dual stack IPv4/IPv6. Unfortunately, bringing that to market in today’s environment does not justify the expense and time. There are just a few minor things left on the punchlist, so I’m contemplating just posting it on Github along with the schematic.

I do appreciate the offer and the work that you have done, and have no objection to you publishing your version in keeping with the terms of the open license.

2 Likes
3

Hey @overeasy,

Thanks for the incredibly thoughtful response!

I hope you enjoy your second retirement and get to focus on what matters most to you. Very much well deserved.

Educate me if I’m wrong but it seems to me that in the IOT space where IoTaWatt lives exclusively in the WiFi domain, there is really no problem with IPv4 as the WiFi router will NAT the local address to whatever is needed on the WAN.

I won’t drag you into the philosophical v4-vs-v6 debates, that’s a whole can of worms. I’ll just say I’m pushing to be v6-first wherever I can in my own environments, and I’m really grateful the firmware is open source so I could build this for personal use. (Definitely the right call investing in the IoTaWatt’s over other options!) Honestly it’s more about network management for me than remote access, though v6 does make remote access a lot simpler once you’re running a handful of units.

I completely understand your concerns around stability and supportability, so I’ll leave that alone.

On the ESP32: I’d been following that for a while and figured it had died on the vine. That’s exactly why I put my effort into what I had in hand, the ESP8266 versions. Hearing it’s been solid for over a year is fantastic news. The IPv6 story on the ESP32 is a much easier lift than the 8266 gymnastics, for what it’s worth. I just finished this same v6 port for the OpenEVSE project and I’m working with them to upstream it, so it’s fresh in my mind.

There are just a few minor things left on the punchlist, so I’m contemplating just posting it on Github along with the schematic.

Please do. That would be huge, not just for me but I suspect for a good chunk of the community. I’d build my own from the schematic in a heartbeat, if only for a future-proof platform now that the 8266 is EoL. Happy to help kick the tires on the IPv6 side if that’s ever useful :wink:

have no objection to you publishing your version in keeping with the terms of the open license.

Thank you for the blessing, that means a lot. I’ll go that route and start a fresh thread with what I’ve got, in case it’s useful to any other silly folks like me. :slight_smile:

Thanks again for taking the time, and for building something worth hacking on in the first place.

1 Like
4

I’d be into this quick smart. Dare I say it but I think one of the vendors that makes lots of ESP32 based devices would probably be into making them (and let them worry about the costs to bring to market) like Kincony. Let them compete on manufacturing based off the public design, but then to cover your effort, license the IoTaWatt ESP32 firmware, so that users can purchase a license and install it upon hardware bought to market by others?