ipv6 support (by updating lwip) #302
Comments
|
+1 IPv6 would be a great feature |
|
+1 |
|
The thing that concerns me here is that until Espressif come out with Rev B silicon with 2x or 4x the RAM, if we keep adding features, then we might end up with a wonderfully featured firmware that can only run a 10 line application. Personally the last thing that I wan't is my IoT devices directly addressable on the Internet. Mine will always run in a privarte address space and any external or end-user access will be through a properly secured HA layer. |
|
@TerryE Sure, but IPv6 ULAs are also a much nicer way for private IP ranges. Additionally, you can route them from trusted devices ;-) |
|
... and - in a proper setup - control via a firewall what gets thru to the device. i guess in a modern "cloud" / IoT world ipv6 is a mandatory feature. |
It only becomes a mandatory feature when IPv4 is widely not supported anymore. Or if the intended context in which a system is used requires it. Currently, IMO neither of those applies to ESP8266/NodeMCU. |
|
RfC6540 is not a standard but merely a best practice documentation. Nothing wrong with that, I don't think anybody disagrees with RfC6540...
|
|
@flokli, The IPv6 stack will probably leave the current ESP8266 with little or no available RAM. On the next generation of IoT devices with 256KB RAM it will be a good idea, but so would decent security and a more functional OS. |
|
@TerryE Do you have any foundation for that claim? |
|
@cal101 Carsten, we just need someone to prepare the patch, preferably with a user define to give users the option of disabling it. We can do the sizing then. At this growth rate on the firmware size, we'll have no room let for Lua apps in a year's time 😒 |
|
Sorry, not me at the moment. |
|
+1 |
|
Espressif change some function of LWIP and it is no more opensource now. To change it will be hard job, when comparing to the good that ipv6 give us, that not worth. |
|
+1 |
|
Just for reference: espressif recently released an open-source patch of lwip. They say it's "based on SDK 1.3.0", that might be a problem? Still could be worth investigating by someone more knowledgeable on the subject. |
|
So more than 20% of hits to Google from the USA and Germany are over native IPv6 and you guys say that your firmware/sw will not support it (against the suggestion of the IETF for IP capable stacks).. The unique reason for IPv6 today in digital/Internet products is business continuity. Good luck! For those interested, I keep more Internet6 stats/info here: |
|
@cralli, IMO you are missing an important issue here and that is security. This generation of IoT devices simply does not have the capacity or capability to run a secure OS and S/W stack. Anyone who attaches this sort of device or their fridge or garage door to the public Internet deserves any hacking or malicious attack that they open themselves up to. Again IMO, the only sensible way to open these devices up to the public internet is through some firewall / bastion tier which contains the HA system running on a properly configured and locked-down Linux instance. In this use case the devices will be running on a private LAN in a private address space, so IPv6 is hardly an issue. At the moment we are struggling the SDK and firmware into this device and still leave enough RAM/Flash available to implement a minimal real-world application. If you want IPv6 then come back in 3-4 years when the devices have the capacity to run a proper IoT OS which has all of the necessary security in place. |
|
NAT isn't a security measure :) any consumer router should be dropping inbound connections from the internet on v6 anyway. IPv4 subnets are at a premium now. Agree on the memory constraints though. Be nice if it were an option to turn on and off and same with the v4 stack. The great thing about v6 and IoT is that you don't need to handle NAT punching to get two IoT things to talk to each other over the internet. IoT not the private subnet of things. |
|
I entirely agree that NAT is not a security measure in its own right. My point is that any sensible security architecture using current technology would firewall and proxy through an application tier such as a properly configured home automation system so you may as well use a private address space for your IoT devices. The idea of allowing any IoT to present itself on the Internet give me the willies. Feel free to do this work and issue the pull request. I am not interested in helping. |
|
@TerryE , I am 100% with you here. I am constantly shocked to see how people who should know better actually are comfortable with cloud services, trusting everything to it. And now same people want to expose their devices to the same (unknown) cloud. If we learnt anything in the last few years it is that there is no security and no privacy on the 'net. We call is the "cloud" but we should really call it "public arena". Everyone sees the convenience and is blind to the cost. It started by people making their whole life public, now they want to make it physically public. The fact on the internet is: when you allow access to one (e.g. yourself, accessing your home devices) you allow everyone. And remember: just because I am paranoid does not mean they are not after me... Back on topic: now that we are all agreed on the above :-) , there is no reason to have IPv6 in the house. cheers |
|
This discussion is odd. How people are implementing things is not something you can control by providing or not providing a network stack. People are going to build/have built stupid shit and only once that creates issues will there be progress towards more secure systems. If you want to change that you have to change the way our current market economy works. The question here is simple - can a IPv6 stack be made to work on this architecture (maybe not even dual stack with IPv4). If so - it's worth doing, cause future and stuff. If it's something that is not possible due to restrictions in the hardware - well then that's that. Other products will appear that have sufficient capability and will serve that need. |
|
See #625. We need a current SDK to do this and getting one is proving tighter that a duck's a**e. |
|
At this point the discussion has become pretty pointless for me to continue and I suggest to close this issue. IMO:
|
|
👎 Close. Fully discussed :-) |
|
Suggest that we revisit this if and when we have a chipset and build that has sufficient resources to support it. |
|
What a shame, whatever reason this is not going ahead. Either because some people can't care less (and don't understand the importance of IPv6 to the IoT world) or because the device "might" not have suitable resources for that. |
|
@ffrediani, we have been working on the sdk 1.4 based release which includes the open LWiP stack. So instead of moralising, and telling us what to do or what not to do, why don't you fork the repo and prepare, test and propose the patch yourself? |
Importance is subjective. Don't assume that because other people don't share your priorities they don't understand. Over and out. |
|
Folks, I never said it was "my priorities", but that IoT has everything to do with IPv6, and that giving up without trying isn't something good. |
|
@ffrediani, actions not words. If you feel that strongly, then put in the effort and do it yourself. IMO, IoT and IPv6 are orthongal. |
|
Ignoring hardware resource constrains, another issue is that LWIP is really tightly tied to the SDK, and ships as a binary library by default. When doing the upgrade to 1.4.0 I ended up having numerous emails back and forth with Espressif to sort out various issues in this are, and Espressif released updates and fixes along the way. A large change such as introducing IPv6 would require a substantial amount of ongoing maintenance as well, and would make SDK upgrades more challenging. Great if someone wants to do it, even better if that someone is Espressif (assuming the hardware can cope, that is). |
|
IPv6 support would be great but I think resources are too constrained for it at present. What I'd rather see first is an ultra-stable platform, one which does not experience random watchdog resets and "MEM CHECK FAIL" errors. |
|
@nickandrew The old "MEM CHECK FAIL" is but a memory now after the SDK upgrade! Espressif has replaced it with the much less dire sounding text "don't use rtc mem data". It was never an actual error as far as I understand, it just indicated that the SDK didn't find any stashed away calibration/what-not data in RTC memory on boot. I completely agree it sounded scary though - the first time I failed to flash a NodeMCU firmware onto a fresh board and only saw that message I thought I'd broken my hardware! |
|
@jmattsson My device, built from https://github.com/nickandrew/nodemcu-firmware/tree/onewire-power started rebooting 10 times a second with that error - but not always, and believe it or not - placing a finger on the can often made it stop. Is that the typical behaviour of the error the SDK fixed? |
|
just to add my two pennies +1 for ipv6 +3 for stable platform including HTTPS client support as 90% of the services I require to communicate with are HTTPS. I'm looking into HTTPS/SSL/TLS issues across a number of project using the epsressif ask in hope to bottom out what I think is an sdk bug. |
https://twitter.com/EspressifSystem/status/662658821307797504 |
|
I know this is closed. And will be opened again when sdk supports it. |
|
+1 for IPv6. +1 for TLS over IPv6. Sorry for posting in a closed thread. |
|
+1 for IPv6 Perhaps I have miss understood IPv6/IPSec but TLS (unless TLS is a requirement at the application layer) is unnecessary in IPv6. Transport layer encryption for network connections is available in the IPv6/IPsec stack. All the Best JMB |
|
In practice, people don't implement IPSEC in IPv6 (you have all the key management problems of TLS to worry about). |
|
It may incidentally be related to #1435 as Espressif appears to have included IPv6 in SDK 2.0. |
|
They did?? I didn't see a mention of that. Do we have any RAM left now? |
Espressif's "John Lee" sort of confirmed that on Twitter (2.0 announcement). |
|
IIRC, the standard LWiP open-source has configuration defines to enable IPv6 compilation. If Espressif wave picked up this version then we should at least be able to make IPv6 support configurable if users don't require it and don't want to take the RAM hit. |
|
Good to hear. At least make IPv4 configurable too, because why take the RAM hit on a protocol from the 1980s that's completely obsolete these days? |
I agree that it's obsolescent, but it's not going to be obsolete until the majority of home routers and ISPs support IPv6 as standard. I know it's my personal opinion, but IMO anyone who allows external Internet access for their IoT devices (now or for the foreseeable future) has no idea of the security threat of doing so. IPv4 on a private subnet will do me for the next 10 years, at least. |
|
I don't know which of the various v4/v6 transition technologies are supported by LWIP. As time marches on, v6 will become dominant and may become the only native transport (my cellphone only has v6 connectivity native (tmobile) and uses a transition technology to support v4). I'm using lwip-2.0.0 on another project which is 99% v6 and it works well. |
|
Obsolete it is not. It is old, and will stay around for at least a decade. Move towards IPv6 is always great, but remove support for IPv4 isn't certainly a good thing. So just leave both options as optional. |
|
Much as I prefer IPv6 whenever possible, no way is IPv4 obsolete.
|
|
Is ipv6 working on the NodeMCU? if so, how can I use it? |
|
With the 2.0 release and "Net functionality rewrite on top of LWIP (#1379)", which no longer seems to use the IPv4-only |
|
+1 |
|
+1 |
|
Exactly. I don't want dhcp and stuff like that. IPv6 link local is the only thing I want. And it will clear a lot of issues. And if your browser is incapable of IPv6 link local, it's a bug in the browser, that's easy to circumvent with socat. |
|
It looks as thought the IDF supports ipv6. It would seem that the easier approach would be to make the lua network layer understand v6 on the esp32 branch. |
and others
According to http://www.esp8266.com/viewtopic.php?f=21&t=1347, IPv6 support should be relatively straightforward by updating the lwip library.
The text was updated successfully, but these errors were encountered: