I was surprised to learn that SmartThings doesn’t yet support IPv6. Especially considering Samsung is on the Thread working group.
Any idea as to when SmartThings will support IPv6?
1 Like
I believe it’s the next milestone on the roadmap after enabling Bluetooth. 
6 Likes
The V2 hub has been identified as being “thread capable.” Not “thread ready” or “thread enabled” just capable. But that does imply that they can turn on IPv6 support if and when they’re ready.
No timelines given, however.
been on my wishlist for over 2 years. No response from ST though. I doubt it will happen anytime soon.
1 Like
Curious what folks use cases are for IPV6 on the ST hub?
Seems to me RFC 1918 IPV4 addressing is better for the types of networks that host Smart Home devices and we would NAT that access to the internet so it would be natted to non-RFC 1918 IPV4 or V6 addy at the perimeter by a gateway/router device.
I, for one, have no interest in using IPV6 internal to my home network. Why would I want to when I can easily remember and type in IPV4 addresses whereas that is simply not possible with IPV6?
That being said, I am eternally annoyed by devices that don’t support IPV6.
Mostly you need it for Thread, assuming that ever gets real.
http://threadgroup.org/news-events/blog/ID/112/Why-Thread-Chose-IPv6#.V_WEMtRHahA
2 Likes
LMAO…
1 Like
At the risk of being a joke killer I think OP may have taken that literally.
In any event OP, don’t count on it.
You buried the lede and made a devil’s advocate argument for the status quo, but in time it’s not an argument that stands:
RFC 1918 IPV4 addressing is better for the types of networks that host Smart Home devices
I don’t think this is true. I think that the ideal network for Smart Home devices is zero-configuration, stateless (as far as addressing), secure, and dynamic. IPv4 networks don’t hit all these points.
we would NAT that access to the internet…to non-RFC 1918 IPV4 or V6 addy at the perimeter
This is the biggest problem with IPv4. It impedes “stateless” and “zero-configuration” networking, and it’s mostly a band-aid over IPv4’s other problems, and creates plenty of its own. NATing v4 to v6 is not a good idea.
Why would I want [IPV6 internal to my home network] when I can easily remember and type in IPV4 addresses whereas that is simply not possible with IPV6?
Why would you want to type in addresses at all? Stateless, zero-configuration networking means using mDNS for name resolution, SLAAC for addressing, no silly NAT or port-forwarding rules, 100% of the same security coverage with a firewall at the edge. Addresses are deterministic when you actually need them (no “static IPs” or DHCP reservations to manage), and names can be meaningful and usable without a DNS. IPv4 can’t do this (because APIPA doesn’t provide a gateway, for one thing).
It’s probably a good thing our home-automation protocols mostly aren’t IP-based, or we’d have already run out of space in the standard /24 granted on most home networks. IPv6, of course, has no such limitation. My home network has a /64 prefix assigned to it, and IPv6 performance is better for it, partially because my router doesn’t have to NAT anything.
IPv6 everything!
Ipv6 theory is great. I don’t know what it will look like in practice to replace all IPV4…
Why? Well, despite years of Ipv6 availability and endless pending doomsday IPV4 scenarios, not one single fortune 100 company I work with has adopted Ipv6. Sure they have some perimeter based systems to service IPV6 traffic inbound for web, mail, etc… but that is the extent of it.
So despite wide industry experience for several decades, I still personally lack extensive production IPv6 experience.
I think that’s a tall claim. I am not aware of comprehensive enterprise network security stacks that have end to end seamless IPv6 multivendor solutions including Loadbalancers, WAF, Firewalls, URL Filtering, Sandboxing, VPN, AV, etc, etc… all need to be integrated to handle all the traffic at perimeters, for example, and while these things are all individually possible, the integration of complete end to end systems using Zero IpV4 is still a real challenge. Especially so for organizations that are not willing to completely fork lift entire stacks in order to accommodate Ipv6 at greater costs elsewhere (operational efficiency for one).
There are significant challenges I think you may be overlooking in that regard. One such challenge is how such organizations would even define security policies using IpV6 addressing or completely dynamic networks under the zero configuration paradigm that is IPv6 using their existing or at least enterprise ready network security stacks. Addressing the challenges of dynamic networks is something the industry is working on but it is not quite there yet. SDN and SDDC technologies have really done much more to move forward those efforts than IPv6 has in the last decade, very few care about Ipv6 and even less care about extending it into their data centers… This is a significant roadblock, and I am sure it will be overcome - but there is nothing today that gives me confidence that we are ready to address this head on in such a holistic fashion that would allow an enterprise to extend Ipv6 to everything and banish IPv4 without concern for issues, including but not limited to network security stacks and the relevant policies.
Correct. Systems are not there yet… however. This is pure aspiration and not realistic for the majority of organizations. If I get a chance to offer my prediction it would be that once we have immersive and ubiquitous SDN environments, IPV6 will make much more sense for organizations and vendors, due to the fact that their products will then be built to support such dynamic environments, will also be in a better position to also support IPV6.
I am with you, but unfortunately it is not a flip the switch and you are done scenario. There is a lot of work yet to do to get all systems up to spec to be able to support this aspirational desire.
The least of which is not the fact that most residential ISP services in the US are Ipv4 based, so you need a tunneling service and the minute you do that - you’re no longer “IPv6 Everything!”… you’re going from IPv6 to Ipv4 to Ipv6 and perhaps back yet again… what fun! This kills any desire I may have to migrate my own systems to IPv6, despite having a a Ipv6 tunneling service and lab Ipv6 networks.
1 Like
Enterprise IPv6 readiness is an interesting conversation, but the context here was “smart home” networks. It’s going to happen sooner or later anyway, but Enterprises can probably put it off longer than Service Providers, who have already had to make the switch for their subscriber networks.
Organizations shouldn’t aspire to stateless, zero-config networking in the first place. Homes should, and can, and it’s nearly doable today with the technologies I mentioned. We’re not there yet because as you point out, not all providers offer prefix delegation, not all home routers support DHCPv6-PD, and it’s certainly not on by default. Every major home OS has IPv6 on by default, though, and some tech like Windows HomeGroups use IPv6 exclusively. If the provider puts in the support, it’s just flipping a switch at the edge. I’d keep an eye on your provider. They may have already implemented IPv6 PD and not bothered to tell anybody.
You seemed to make the claim that even after IPv6 is the primary Internet protocol that home networks should stay with RFC1918 IPv4 (“nat to an ipv6 address”), which is the assertion to which I object, because at that point it’s not worth the resources to maintain IPv4 even on private home networks.
Not at all, simply that in the right here and now there is little to gain (in fact, it’s a pain in the ass) for the average joe, and not much more for me, to migrate to ipv6.