3 ms·

> A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash m

> A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash memory. Wait a minute, kilobytes? That much? It’s not like one needs to duplicate the entire IP layer, it seems to me the only changing parts are parsing & generating the packets.

jeroenhd 3y ago
For IPv6 you need to implement NDP, RA, and a bunch of changes to the DHCP server. You also need to start paying attention to ICMP. The documentation for ESP-IDF (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/lwip.html?highlight=CONFIG_LWIP_IPV6 https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...) says: > Disabling CONFIG_LWIP_IPV6 can save about 39 KB for firmware size and 2 KB RAM when the system is powered up and 7 KB RAM when the TCP/IP stack is running. If there is no requirement for supporting IPV6, it can be disabled to save flash and RAM footprint. > Disabling CONFIG_LWIP_IPV4 can save about 26 KB of firmware size and 600 B RAM on power up and 6 KB RAM when the TCP/IP stack is running. If the local network supports IPv6-only configuration, IPv4 can be disabled to save flash and RAM footprint. IPv6 takes up more ROM than IPv4, and as far as I know ESP-IDF doesn't actually fully support IPv6 either. At this point we're talking microcents of storage, but unfortunately the 13KB of size difference can make the difference between "the code fits" and "we need to spend a dollar more per unit".
- loup-vaillant 3y ago
  My it really is kilobytes. Okay I guess my next project will be a TCP-IP stack on an 32-bit RISC-V micro-controller, we’ll see how much code this actually requires. My understanding of IP may be off, but I still feel those numbers are about an order of magnitude bigger than they actually need to be. I mean, I can fit an entire cryptographic library¹ in 65Kib of RV32IC object code, and it’s not even particularly optimised for this use case. There’s no way the overhead of supporting IPv6 has to be that big. [1]: https://monocypher.org https://monocypher.org
  - jeroenhd 3y ago
    I think the individual parts will not be that large, but ESP-IDF is a fully features RTOS, not a dedicated microcontroller library. It provides socket APIs that integrate with both WiFi and ethernet, for instance. If you're optimising for size, I bet you can do a lot better, but that's not really what ESP-IDF is doing. It's providing a network stack for TCP+UDP+IP+DHCP+ICMP+NDP+ARP+DNS with (close to) standard C APIs. Microcontroller developers can probably download and use smaller libraries if they wanted to, but ESP-IDF provides a rather comfortable development experience compared to stringing together a whole bunch of libraries and talking to the hardware directly.
    - loup-vaillant 3y ago
      Still, doing a lot of things is not an excuse for the individual components to be bigger. Not unless you can justify it with interaction between components, stuff like TCP and UDP being aware of what goes on in the IP stack below and having to special case v4 and v6 (made up example, I don’t know if that’s true). And now I’m wondering how much it would take to implement a full network stack with a nice C API.

jeroenhd 3y ago

For IPv6 you need to implement NDP, RA, and a bunch of changes to the DHCP server. You also need to start paying attention to ICMP. The documentation for ESP-IDF (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/lwip.html?highlight=CONFIG_LWIP_IPV6 https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...) says: > Disabling CONFIG_LWIP_IPV6 can save about 39 KB for firmware size and 2 KB RAM when the system is powered up and 7 KB RAM when the TCP/IP stack is running. If there is no requirement for supporting IPV6, it can be disabled to save flash and RAM footprint. > Disabling CONFIG_LWIP_IPV4 can save about 26 KB of firmware size and 600 B RAM on power up and 6 KB RAM when the TCP/IP stack is running. If the local network supports IPv6-only configuration, IPv4 can be disabled to save flash and RAM footprint. IPv6 takes up more ROM than IPv4, and as far as I know ESP-IDF doesn't actually fully support IPv6 either. At this point we're talking microcents of storage, but unfortunately the 13KB of size difference can make the difference between "the code fits" and "we need to spend a dollar more per unit".

loup-vaillant 3y ago
My it really is kilobytes. Okay I guess my next project will be a TCP-IP stack on an 32-bit RISC-V micro-controller, we’ll see how much code this actually requires. My understanding of IP may be off, but I still feel those numbers are about an order of magnitude bigger than they actually need to be. I mean, I can fit an entire cryptographic library¹ in 65Kib of RV32IC object code, and it’s not even particularly optimised for this use case. There’s no way the overhead of supporting IPv6 has to be that big. [1]: https://monocypher.org https://monocypher.org
- jeroenhd 3y ago
  I think the individual parts will not be that large, but ESP-IDF is a fully features RTOS, not a dedicated microcontroller library. It provides socket APIs that integrate with both WiFi and ethernet, for instance. If you're optimising for size, I bet you can do a lot better, but that's not really what ESP-IDF is doing. It's providing a network stack for TCP+UDP+IP+DHCP+ICMP+NDP+ARP+DNS with (close to) standard C APIs. Microcontroller developers can probably download and use smaller libraries if they wanted to, but ESP-IDF provides a rather comfortable development experience compared to stringing together a whole bunch of libraries and talking to the hardware directly.
  - loup-vaillant 3y ago
    Still, doing a lot of things is not an excuse for the individual components to be bigger. Not unless you can justify it with interaction between components, stuff like TCP and UDP being aware of what goes on in the IP stack below and having to special case v4 and v6 (made up example, I don’t know if that’s true). And now I’m wondering how much it would take to implement a full network stack with a nice C API.