Virgin Media Community

[matthewsteeples]

Yeah, bring back the good old days when Skype was a true peer to peer app. Used to just leave it connected for hours on end (back before it did video) and had a virtual housemate! 

[VMCopperUser]

---

@matthewsteeples wrote:

---

@ksim wrote:

My point: IPv6 is needed now in our homes for IoT devices. I already have around 10-15 devices/services. It is an easy plug and play with IPv6, but requires a lot of knowledge to make NAT/PROXY/Forwarding work with IPv4. IPv4 is how VM creates a bad user experience today.

Want Nest secure? -> learn tunnels, and VM will cap you. Want to access CCTV footage without exposing it to somebody else servers? -> learn port forwarding and proxy. Simple things become 100 times more complex.

---

The problem is that a) we're in a majority and b) IPv6 won't change a lot of the things you're complaining about. 

Don't get me wrong, I want IPv6 and believe it's the future, but I disagree with the reasons you're saying.

I've currently got (according to the Hub) 20 devices connected to the internet, for 3 humans.
1 of them is a manufactured camera which works with their app inside and outside the house without any port forwarding required (no account required, and I assume it goes via a server, I've not checked the traffic. There's a slim chance it could be opening a port).
1 is a smart thermostat which works with their app without any port forwarding required (which I'd be amazed if your Nest Protect doesn't do too).
3 of them are "smart speakers"; again no config required
n of them are Raspberry Pis (which do require config, but they'd require config on IPv6 too)

IPv6 makes "inbound" connections a lot easier, but the majority of IoT doesn't want inbound connections because it's a massive security risk. IPv6 isn't going to change any of the communication pathways for the average user: the thermostat is still going to go through their web service, which is what it should do (at least when you're outside the house). If you think port forwarding is hard to configure, wait until you have to explain to someone that they need to update the firmware on their lightbulbs because all of a sudden it's passively sniffing their network traffic and relaying information out to China.

So on to the bits that we want. It's still going to require some configuration, but rather than port forwarding we're going to have to configure some form of DNS settings (unless you're memorising or hardcoding 128 bit values) and firewall rules (how do you control whether a device is accessible outside of your network, as everything would have a public address by default). It makes no difference to me whether I have to forward a port for a Raspberry Pi or whether I have to have a DNS record for it. As I'm most likely on IPv4 when out and about (public hotspots etc) I'd need to do both for a while anyway (that's hypothetical, I actually use ZeroTier)

---

In all fairness, a "smart" bulb relaying information would probably work regardless of it being Ipv4 or Ipv6.

The bigger problem will come with us now needing a more robust firewall design, plus something that's easy to deal with.  If we ignore UPnP then right now users need to set a port forward rule for IPv4 to a specific IP.  Under the new system a user would need to Open a ports (as you mention) for transit to IPv6.  So will the end user see the same thing in terms of complexity?

In terms of .local, I don't think that will be too much of an issue.  There SHOULD come a point where people learn to start naming their devices.  Amazon and Apple come to mind as two providers who hate letting users do that (Amazon is worse)... With Amazon you need to rename the devices through the website as you add them as it doesn't even provide MAC addresses, ugh...

But here's the thing.  IPv6 issues are going to happen.  So that's (yet another reason) why we should get it as soon as we can.  When will these issues be easier to fix, when there's 2 devices per house with little IoT traffic, or 200 that has constant IoT traffic?

We have the same sort of device count as you. 15~20 active every day and 4 people.  Right now we are fine without IPv6, and as long as there's no CGNat I will probably be fine without IPv6.  It surprises me that we haven't seen an additional protocol added to IPv4 NAT to extend the usefulness of it for a while yet.  Websites have the GET URI that allows a lot of sites to use the same IP, but nothing like that really exist where CGNAT is used (to my knowledge at least).  I do find NAT a headache, and I understand the basics of it just fine.  It's overdue for retirement, and too complicated for most people these days to understand.

chicken and egg and all that.

My VoIP service is not IPv6, nor does my phone support IPv6 (probably never will, but there are unofficial patches that change it from 4 to 6, not dual stack).

My Solar Inverter is also not IPv6 capable either, but it also uses outdated embedded java and requires a java enabled browser to log into it (time to unplug it perhaps).

My Roku box doesn't support Ipv6 either.

But eh, My 17 year old WRT54G supports IPv6 ;P....

[Timwilky]

I still want IPv6, I currently run with a HE tunnel to my firewall  and all capable devices on the LAN are assigned IPv6,

But it is a mishmash. My smart devices i.e power/light switches are IPv4, but as I do not access them directly remotely, that is not an issue. I can access the OpenHAB control on both stacks. I know there is experimental IPv6 at this stage for the underlying core, but it would require support building into the "Smart" layer. I haven't got the time/enthusiasm to do this so would need the development within the firmware of choice (Tasmota)

My Asterisk appliance is IPv4 only as is my SIP phones. my trunk supplier does support IPv6, so a new Asterisk device required. I could probably build on a Pi.

My NAS is OK and I access already from my external servers on IPv6, Those devices I currently expose as web interfaces go through a reverse proxy.

My real remote access is always through  VPN. So I need an endpoint I can reach when away from home. So that means until telecom providers globally provide IPv6, I need IPv4. I work globally, this year I have been in China, Taiwan, India, Philippines and have a cruise planned. All so far have been IPv4 only at the remote locations.

The one good thing with IPv6, my firewall rules are a not cleaner. far less wildcard sources, no seperate NAT rules. real source/targets. But it still needs managing/auditing. Without a decent firewall I think this will turn into a potential security nightmare for the none security savvy. 

[ksim]

1) NAT != SECURITY !!!! it is a **bleep**ty workaround for the addresses shortage. You still need proper firewall rules!!!! UPnP is a security nightmare.

2) IoT requires access from outside world as devices are managed from cloud services, they register themselves in cloud and after the cloud makes calls to them. Surprise they do not need DNS for this. There is no security issue also, port forwarding and IPv4 has no advantage in this, even port scanning on IPv4 is easier.

3) You do not need complex firewall rules, as connectivity and authentication is managed on the device itself.

4) Stop show examples of **bleep**ty implementations and workarounds done for IPv4, all this is not needed on IPv6. SIP phones with STUN is IPv4 nightmare!

5) Ads are not using IPs to track users, most of consumer IPs are dynamic and not reliable (laptops/ mobile phones), they are using browser fingerprinting, IPv6 won't stop then and won't help them.

[matthewsteeples]

---

@ksim wrote:

1) NAT != SECURITY !!!! it is a **bleep**ty workaround for the addresses shortage. You still need proper firewall rules!!!! UPnP is a security nightmare.

2) IoT requires access from outside world as devices are managed from cloud services, they register themselves in cloud and after the cloud makes calls to them. Surprise they do not need DNS for this. There is no security issue also, port forwarding and IPv4 has no advantage in this, even port scanning on IPv4 is easier.

3) You do not need complex firewall rules, as connectivity and authentication is managed on the device itself.

4) Stop show examples of **bleep**ty implementations and workarounds done for IPv4, all this is not needed on IPv6. SIP phones with STUN is IPv4 nightmare!

5) Ads are not using IPs to track users, most of consumer IPs are dynamic and not reliable (laptops/ mobile phones), they are using browser fingerprinting, IPv6 won't stop then and won't help them.

---

1) Partially agree. NAT is not equal to security but in its default configuration it blocks all incoming TCP connections (and only allows UDP connections in if one has been made out) which is how you want things to be configured

2) They don't need DNS because this is the other way around. Devices open the connection to the cloud service and keep it open for 2 way communication, rather than the cloud service opening the connection. Granted IoT covers a broad array of devices, but the vast majority of consumer products work this way (and are more secure because they do so). I'm willing to accept that I'm wrong if you have some examples, but this is how my devices work

3) "Managed on the device itself" is a security risk. There are countless flaws in software (that are sometimes patched) that allow you to either DoS a device or gain access to it by sending it data that it's not prepared for. If you have devices that could accept connections, you want these stopped at the perimeter (even on a home network) which means you're going to want to configure ports on a "whitelist" basis (which configuration equivalent to port forwarding for the average user), otherwise you've got exactly the same functionality (and flaws) as uPNP!

4) These devices aren't going to change when IPv6 is widespread. Nest/Hive are still going to have the hub talk to their system, and the app on your phone talk to their system. This allows them to diagnose issues easier, gather metrics, deal with latency issues, reduce the security footprint etc. It's not a workaround for IPv4. Yes, SIP phones will work better, and anything else that requires a direct connection, but that's not the vast majority of devices. Even IM and non-SIP calls run on centralised architectures now, more to guarantee network connection quality than for any "direct connection" issues (Skype had P2P pretty much solved)

5) I can't specifically speak for ads, but Google/YouTube certainly do. If my step-daughter browses stuff on YouTube (not signed in) then recommendations based on those videos appear on other (also not signed in) devices on our network. 

[ksim]

---

@matthewsteeples wrote:

---

1) Partially agree. NAT is not equal to security but in its default configuration it blocks all incoming TCP connections (and only allows UDP connections in if one has been made out) which is how you want things to be configured

2) They don't need DNS because this is the other way around. Devices open the connection to the cloud service and keep it open for 2 way communication, rather than the cloud service opening the connection. Granted IoT covers a broad array of devices, but the vast majority of consumer products work this way (and are more secure because they do so). I'm willing to accept that I'm wrong if you have some examples, but this is how my devices work

3) "Managed on the device itself" is a security risk. There are countless flaws in software (that are sometimes patched) that allow you to either DoS a device or gain access to it by sending it data that it's not prepared for. If you have devices that could accept connections, you want these stopped at the perimeter (even on a home network) which means you're going to want to configure ports on a "whitelist" basis (which configuration equivalent to port forwarding for the average user), otherwise you've got exactly the same functionality (and flaws) as uPNP!

4) These devices aren't going to change when IPv6 is widespread. Nest/Hive are still going to have the hub talk to their system, and the app on your phone talk to their system. This allows them to diagnose issues easier, gather metrics, deal with latency issues, reduce the security footprint etc. It's not a workaround for IPv4. Yes, SIP phones will work better, and anything else that requires a direct connection, but that's not the vast majority of devices. Even IM and non-SIP calls run on centralised architectures now, more to guarantee network connection quality than for any "direct connection" issues (Skype had P2P pretty much solved)

5) I can't specifically speak for ads, but Google/YouTube certainly do. If my step-daughter browses stuff on YouTube (not signed in) then recommendations based on those videos appear on other (also not signed in) devices on our network. 

---

1) Nope, this is not how I want things to be configured

2) I do not think you understand IoT if you are saying that every device will open and maintain a connection to a cloud, that means the cloud have to maintain trillions of open and non-active connections, a total waste of resources and unscalable. This is not how it is working.

3) strange view on security and firewall, makes no sense to comment.

4) the reason skype abandoned the P2P is NAT, making uPNP reliable was much harder than just sending traffic through "supernodes," gathering metrics doesn't require to send the main traffic through a server, most of modern RTC protocols contain p2p part as the preferred if possible to establish a direct connection.

5) I do not see any ads served for my wife and daughter from google/youtube or anyone else.

[matthewsteeples]

---

@ksim wrote:

2) I do not think you understand IoT if you are saying that every device will open and maintain a connection to a cloud, that means the cloud have to maintain trillions of open and non-active connections, a total waste of resources and unscalable. This is not how it is working.

You might want to let Microsoft know that they don't understand it as well then: https://docs.microsoft.com/en-us/azure/iot-fundamentals/iot-security-ground-up

Additional connection security features include:

In order to protect devices from unsolicited inbound connections, Azure IoT Hub does not open any connection to the device. The device initiates all connections.

On a serious note, I think we're going to have to respectfully disagree with each other. There isn't a single right method to do everything that we're talking about, and I don't think it's worth going backwards and forwards over the same points. We all want IPv6, and that's enough really 🙂

[ksim]

---

@matthewsteeples wrote:

You might want to let Microsoft know that they don't understand it as well then: https://docs.microsoft.com/en-us/azure/iot-fundamentals/iot-security-ground-up

Additional connection security features include:

In order to protect devices from unsolicited inbound connections, Azure IoT Hub does not open any connection to the device. The device initiates all connections.

On a serious note, I think we're going to have to respectfully disagree with each other. There isn't a single right method to do everything that we're talking about, and I don't think it's worth going backwards and forwards over the same points. We all want IPv6, and that's enough really 🙂

---

I told you, "the security" is always an excuse for not implementing IPv6, you will hear the same from VM in 10 years, IPv6 is "not secure" because it doesn't have NAT. I have no idea why everyone is saying this, IPv6 miles more secure. Your local network is open to any javascript from your browser, that's why I have authentication enabled on any service even accessed locally;

and try to build a system which handles around 5million simultaneous connections and tell me how you will scale to billions of devices and then to trillions.

[matthewsteeples]

---

@ksim wrote:I told you, "the security" is always an excuse for not implementing IPv6, you will hear the same from VM in 10 years, IPv6 is "not secure" because it doesn't have NAT. I have no idea why everyone is saying this, IPv6 miles more secure. Your local network is open to any javascript from your browser, that's why I have authentication enabled on any service even accessed locally;

and try to build a system which handles around 5million simultaneous connections and tell me how you will scale to billions of devices and then to trillions.

---

The fact that your local network is open to any javascript from your browser is exactly why you don't want devices accepting incoming connections unless there is no alternative, and why IoT devices should always make connections out instead. It's not because of IPv4 or IPv6. You've proved Microsoft's point there!

You're going to have exactly the same scalability problems whether your trillion simultaneous connections are inbound or outbound. However you can handle the load better with outbound connections (from the device to the cloud service) because you can use DNS or AnyCast to make sure that the connections are spread out geographically and handled "at the edge". You can then scale based on region, and this works exactly the same on IPv4 as it does on IPv6.

[ksim]

> You're going to have exactly the same scalability problems whether your trillion simultaneous connections are inbound or outbound

and why you think inbound connection should be always established? why not make a call from cloud to the device or from the device to the cloud when it's needed and close the connection after? that will reduce the number of connections drastically. if you allow only outbound connections then you have to have the connection be "always-on" as otherwise, the cloud won't be able to send commands to the device, or you have to do polling and introduce latency and not help much really.

> You can then scale based on region, and this works exactly the same on IPv4 as it does on IPv6.

try your calculator and count how many edge servers you need just to handle connections.