ipv6 support (by updating lwip) #302

Closed
flokli opened this Issue Mar 18, 2015 · 52 comments

Comments

Projects
None yet
@flokli

flokli commented Mar 18, 2015

According to http://www.esp8266.com/viewtopic.php?f=21&t=1347, IPv6 support should be relatively straightforward by updating the lwip library.

@momorientes

This comment has been minimized.

Show comment
Hide comment
@momorientes

momorientes Apr 22, 2015

+1 IPv6 would be a great feature

+1 IPv6 would be a great feature

@FreshXOpenSource

This comment has been minimized.

Show comment
Hide comment
@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Jun 6, 2015

Collaborator

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.

Collaborator

TerryE commented Jun 6, 2015

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.

@flokli

This comment has been minimized.

Show comment
Hide comment
@flokli

flokli Jun 6, 2015

@TerryE Sure, but IPv6 ULAs are also a much nicer way for private IP ranges. Additionally, you can route them from trusted devices ;-)

flokli commented Jun 6, 2015

@TerryE Sure, but IPv6 ULAs are also a much nicer way for private IP ranges. Additionally, you can route them from trusted devices ;-)

@FreshXOpenSource

This comment has been minimized.

Show comment
Hide comment
@FreshXOpenSource

FreshXOpenSource Jun 6, 2015

... 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.

... 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.

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Jun 6, 2015

Collaborator

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.

Collaborator

marcelstoer commented Jun 6, 2015

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.

@flokli

This comment has been minimized.

Show comment
Hide comment
@flokli

flokli Jun 6, 2015

According to RFC6540, IPv6 already is mandatory for all IP-Capable Nodes.

Additionally, new IoT protocols like 6LoWPAN suggest enabling IPv6 support even more. So I strongly suggest to consider adopting it!

flokli commented Jun 6, 2015

According to RFC6540, IPv6 already is mandatory for all IP-Capable Nodes.

Additionally, new IoT protocols like 6LoWPAN suggest enabling IPv6 support even more. So I strongly suggest to consider adopting it!

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Jun 6, 2015

Collaborator

RfC6540 is not a standard but merely a best practice documentation. Nothing wrong with that, I don't think anybody disagrees with RfC6540...

This memo documents an Internet Best Current Practice.

Collaborator

marcelstoer commented Jun 6, 2015

RfC6540 is not a standard but merely a best practice documentation. Nothing wrong with that, I don't think anybody disagrees with RfC6540...

This memo documents an Internet Best Current Practice.

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Jun 7, 2015

Collaborator

@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.

Collaborator

TerryE commented Jun 7, 2015

@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.

@cal101

This comment has been minimized.

Show comment
Hide comment
@cal101

cal101 Jun 7, 2015

Contributor

@TerryE Do you have any foundation for that claim?
We are not talking about an IPV6 router, just a client.
A quick search in the internet made be hope that for basic stuff it's <200 bytes more for lwip IPV6.

Contributor

cal101 commented Jun 7, 2015

@TerryE Do you have any foundation for that claim?
We are not talking about an IPV6 router, just a client.
A quick search in the internet made be hope that for basic stuff it's <200 bytes more for lwip IPV6.

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Jun 7, 2015

Collaborator

@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 😒

Collaborator

TerryE commented Jun 7, 2015

@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 😒

@cal101

This comment has been minimized.

Show comment
Hide comment
@cal101

cal101 Jun 7, 2015

Contributor

Sorry, not me at the moment.

Contributor

cal101 commented Jun 7, 2015

Sorry, not me at the moment.

@wnagele

This comment has been minimized.

Show comment
Hide comment

wnagele commented Aug 6, 2015

+1

@MarsTechHAN

This comment has been minimized.

Show comment
Hide comment
@MarsTechHAN

MarsTechHAN Aug 9, 2015

Contributor

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.
And I believe Espressif will support IPv6 when it is necessary.

Contributor

MarsTechHAN commented Aug 9, 2015

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.
And I believe Espressif will support IPv6 when it is necessary.

@rsrchboy

This comment has been minimized.

Show comment
Hide comment

+1

@Aeprox

This comment has been minimized.

Show comment
Hide comment
@Aeprox

Aeprox Aug 23, 2015

Contributor

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.

Contributor

Aeprox commented Aug 23, 2015

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.

@cralli

This comment has been minimized.

Show comment
Hide comment
@cralli

cralli Sep 18, 2015

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:
http://the-internet6.blogspot.com.es

cralli commented Sep 18, 2015

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:
http://the-internet6.blogspot.com.es

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Sep 18, 2015

Collaborator

@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.

Collaborator

TerryE commented Sep 18, 2015

@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.

@TheSkorm

This comment has been minimized.

Show comment
Hide comment
@TheSkorm

TheSkorm Sep 26, 2015

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.

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.

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Sep 26, 2015

Collaborator

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.

Collaborator

TerryE commented Sep 26, 2015

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.

@eyaleb

This comment has been minimized.

Show comment
Hide comment
@eyaleb

eyaleb Sep 26, 2015

@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

eyaleb commented Sep 26, 2015

@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

@wnagele

This comment has been minimized.

Show comment
Hide comment
@wnagele

wnagele Sep 26, 2015

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.

wnagele commented Sep 26, 2015

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.

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Sep 27, 2015

Collaborator

See #625. We need a current SDK to do this and getting one is proving tighter that a duck's a**e.

Collaborator

TerryE commented Sep 27, 2015

See #625. We need a current SDK to do this and getting one is proving tighter that a duck's a**e.

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Sep 27, 2015

Collaborator

At this point the discussion has become pretty pointless for me to continue and I suggest to close this issue. IMO:

  • Some would benefit from IPv6 support, others couldn't care less.
  • For the majority of use cases there's nothing you can do with IPv6 you can't do with IPv4.
  • None of the core contributors is interested in this feature and, therefore, won't spend any time on it. So, unless someone provides a PR this won't be implemented regardless of how many upvotes it gets.
  • IPv6 support is best addressed at the SDK level.
  • Sooner or later i.e. by upgrading to a recent SDK we'll get this feature automatically.
Collaborator

marcelstoer commented Sep 27, 2015

At this point the discussion has become pretty pointless for me to continue and I suggest to close this issue. IMO:

  • Some would benefit from IPv6 support, others couldn't care less.
  • For the majority of use cases there's nothing you can do with IPv6 you can't do with IPv4.
  • None of the core contributors is interested in this feature and, therefore, won't spend any time on it. So, unless someone provides a PR this won't be implemented regardless of how many upvotes it gets.
  • IPv6 support is best addressed at the SDK level.
  • Sooner or later i.e. by upgrading to a recent SDK we'll get this feature automatically.
@nickandrew

This comment has been minimized.

Show comment
Hide comment
@nickandrew

nickandrew Oct 3, 2015

Collaborator

👎 Close. Fully discussed :-)

Collaborator

nickandrew commented Oct 3, 2015

👎 Close. Fully discussed :-)

@TerryE TerryE closed this Oct 3, 2015

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Oct 3, 2015

Collaborator

Suggest that we revisit this if and when we have a chipset and build that has sufficient resources to support it.

Collaborator

TerryE commented Oct 3, 2015

Suggest that we revisit this if and when we have a chipset and build that has sufficient resources to support it.

@ffrediani

This comment has been minimized.

Show comment
Hide comment
@ffrediani

ffrediani Oct 18, 2015

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.
I understand by this discussion that some people don't even believe, don't want to understand or don't want to give a try to make it happen, which doesn't help with the progress and search for a proper solution. This is certainly not a good approach for improvement of any kind. Make up their mind before even trying.

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.
I understand by this discussion that some people don't even believe, don't want to understand or don't want to give a try to make it happen, which doesn't help with the progress and search for a proper solution. This is certainly not a good approach for improvement of any kind. Make up their mind before even trying.

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Oct 18, 2015

Collaborator

@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?

Collaborator

TerryE commented Oct 18, 2015

@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?

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Oct 18, 2015

Collaborator

don't understand the importance of IPv6 to the IoT world

Importance is subjective. Don't assume that because other people don't share your priorities they don't understand. Over and out.

Collaborator

marcelstoer commented Oct 18, 2015

don't understand the importance of IPv6 to the IoT world

Importance is subjective. Don't assume that because other people don't share your priorities they don't understand. Over and out.

@ffrediani

This comment has been minimized.

Show comment
Hide comment
@ffrediani

ffrediani Oct 18, 2015

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.
Imagine for example OpenWrt project if people had said in the past that was impossible to have a working and amazing Linux distribution running in just 4MB of flash memory !

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.
Imagine for example OpenWrt project if people had said in the past that was impossible to have a working and amazing Linux distribution running in just 4MB of flash memory !

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Oct 18, 2015

Collaborator

@ffrediani, actions not words. If you feel that strongly, then put in the effort and do it yourself. IMO, IoT and IPv6 are orthongal.

Collaborator

TerryE commented Oct 18, 2015

@ffrediani, actions not words. If you feel that strongly, then put in the effort and do it yourself. IMO, IoT and IPv6 are orthongal.

@jmattsson

This comment has been minimized.

Show comment
Hide comment
@jmattsson

jmattsson Oct 27, 2015

Collaborator

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).

Collaborator

jmattsson commented Oct 27, 2015

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).

@nickandrew

This comment has been minimized.

Show comment
Hide comment
@nickandrew

nickandrew Oct 27, 2015

Collaborator

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.

Collaborator

nickandrew commented Oct 27, 2015

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.

@jmattsson

This comment has been minimized.

Show comment
Hide comment
@jmattsson

jmattsson Oct 27, 2015

Collaborator

@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!

Collaborator

jmattsson commented Oct 27, 2015

@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!

@nickandrew

This comment has been minimized.

Show comment
Hide comment
@nickandrew

nickandrew Oct 27, 2015

Collaborator

@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?

Collaborator

nickandrew commented Oct 27, 2015

@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?

@grahamehorner

This comment has been minimized.

Show comment
Hide comment
@grahamehorner

grahamehorner Oct 27, 2015

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.

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.

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Nov 6, 2015

Collaborator

we did enable IPv6 in the ESP8266 RTOS SDK! and it will be in ESP32 as well.

https://twitter.com/EspressifSystem/status/662658821307797504

Collaborator

marcelstoer commented Nov 6, 2015

we did enable IPv6 in the ESP8266 RTOS SDK! and it will be in ESP32 as well.

https://twitter.com/EspressifSystem/status/662658821307797504

@ardje

This comment has been minimized.

Show comment
Hide comment
@ardje

ardje Jan 31, 2016

I know this is closed. And will be opened again when sdk supports it.
I only wish for ipv6 link-local to work, since I then always know the address of the device.
Furthermore, it would relieve the system of tasks like dhcp, and other administrative tasks related to ipv4. So the ipv6 stack can be more lightweight than the v4, with optional adding public addresses.
This would bring the system on-par with 6lowpan devices which only link-local addresses.

ardje commented Jan 31, 2016

I know this is closed. And will be opened again when sdk supports it.
I only wish for ipv6 link-local to work, since I then always know the address of the device.
Furthermore, it would relieve the system of tasks like dhcp, and other administrative tasks related to ipv4. So the ipv6 stack can be more lightweight than the v4, with optional adding public addresses.
This would bring the system on-par with 6lowpan devices which only link-local addresses.

@danrl

This comment has been minimized.

Show comment
Hide comment
@danrl

danrl May 5, 2016

+1 for IPv6. +1 for TLS over IPv6.
Make it optional if you think that makes it more appropriate for the common user. I'd love to be able to disable IPv4 stack, to save RAM. I don't use IPv4 in my IoT network anyway. Also, maybe we can make IPv4 optional as well?

Sorry for posting in a closed thread.

danrl commented May 5, 2016

+1 for IPv6. +1 for TLS over IPv6.
Make it optional if you think that makes it more appropriate for the common user. I'd love to be able to disable IPv4 stack, to save RAM. I don't use IPv4 in my IoT network anyway. Also, maybe we can make IPv4 optional as well?

Sorry for posting in a closed thread.

@jonathanmbradshaw

This comment has been minimized.

Show comment
Hide comment
@jonathanmbradshaw

jonathanmbradshaw Aug 4, 2016

+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

+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

@pjsg

This comment has been minimized.

Show comment
Hide comment
@pjsg

pjsg Aug 4, 2016

Collaborator

In practice, people don't implement IPSEC in IPv6 (you have all the key management problems of TLS to worry about).

Collaborator

pjsg commented Aug 4, 2016

In practice, people don't implement IPSEC in IPv6 (you have all the key management problems of TLS to worry about).

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Aug 4, 2016

Collaborator

It may incidentally be related to #1435 as Espressif appears to have included IPv6 in SDK 2.0.

Collaborator

marcelstoer commented Aug 4, 2016

It may incidentally be related to #1435 as Espressif appears to have included IPv6 in SDK 2.0.

@jmattsson

This comment has been minimized.

Show comment
Hide comment
@jmattsson

jmattsson Aug 5, 2016

Collaborator

They did?? I didn't see a mention of that. Do we have any RAM left now?

Collaborator

jmattsson commented Aug 5, 2016

They did?? I didn't see a mention of that. Do we have any RAM left now?

@marcelstoer

This comment has been minimized.

Show comment
Hide comment
@marcelstoer

marcelstoer Aug 5, 2016

Collaborator

They did?? I didn't see a mention of that.

Espressif's "John Lee" sort of confirmed that on Twitter (2.0 announcement).

Collaborator

marcelstoer commented Aug 5, 2016

They did?? I didn't see a mention of that.

Espressif's "John Lee" sort of confirmed that on Twitter (2.0 announcement).

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Aug 5, 2016

Collaborator

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.

Collaborator

TerryE commented Aug 5, 2016

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.

@synnack

This comment has been minimized.

Show comment
Hide comment
@synnack

synnack Nov 11, 2016

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?

synnack commented Nov 11, 2016

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?

@TerryE

This comment has been minimized.

Show comment
Hide comment
@TerryE

TerryE Nov 11, 2016

Collaborator

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.

Collaborator

TerryE commented Nov 11, 2016

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.

@pjsg

This comment has been minimized.

Show comment
Hide comment
@pjsg

pjsg Nov 11, 2016

Collaborator

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.

Collaborator

pjsg commented Nov 11, 2016

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.

@ffrediani

This comment has been minimized.

Show comment
Hide comment
@ffrediani

ffrediani Nov 14, 2016

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.

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.

@nickandrew

This comment has been minimized.

Show comment
Hide comment
@nickandrew

nickandrew Nov 14, 2016

Collaborator
Collaborator

nickandrew commented Nov 14, 2016

@washichi

This comment has been minimized.

Show comment
Hide comment
@washichi

washichi Mar 18, 2017

Is ipv6 working on the NodeMCU? if so, how can I use it?
(I want to use it to solve all the port forwarding hassle)

Is ipv6 working on the NodeMCU? if so, how can I use it?
(I want to use it to solve all the port forwarding hassle)

@SpComb

This comment has been minimized.

Show comment
Hide comment
@SpComb

SpComb Apr 20, 2017

With the 2.0 release and "Net functionality rewrite on top of LWIP (#1379)", which no longer seems to use the IPv4-only espconn layer, would net module support for IPv6 now be more feasible than before?

SpComb commented Apr 20, 2017

With the 2.0 release and "Net functionality rewrite on top of LWIP (#1379)", which no longer seems to use the IPv4-only espconn layer, would net module support for IPv6 now be more feasible than before?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment