IPv6 support on Virgin media
Does anyone know whether (and if so when) Virgin plan to implement IPv6 on its network?
Forum Discussion
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.
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.
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.
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 :)
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.
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.
- > 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. Yea, Connection count is the same either way.
I don't have any "Smart" devices so haven't looked in detail at how some of them work, but with the world still stuck on IPv4 then yes being stuck connected to a central sever (like most messaging apps work) is probably the best way.
IPv6 will and should change that. The Central server will probably stay even after migration, but your devices would probably be allowed direct communication instead of passing through a proxy. Some "connected" devices are not connected through central severs for their main task, so in a way both of you are correct. But those not using a central type of server might not be contactable.
I will go back to what I said earlier, chicken and egg. Will the design work or be a problem in the future, we wont know until we try. But I know waiting until the last moment to do something rarely works well (Look at UK politics at the moment!).
The Game Consoles, VoIP, and VPN/Remote file access are really three of the most simple things that NAT gets the way of, to me just those three things are enough to say we need IPv6 now. There's other benefits to IPv6 that we don't even touch on that much. Basically it's time to start, not time to keep thinking about it.
I guess the only upshot of VM taking so long, is that by the time they finally get ready to deploy DS-Lite, the world will have moved to IPv6 and they can just shelve the whole thing.
Pretty much all of the main consumer "IoT" devices will register with a server (more likely a set of services running in someones cloud that can handle load balancing for you). I don't think this will change whether running on IPv4 or IPv6, primarilary because it makes it easy for device supplier to provide a consistent experience for non-technical and technical users alike (most don't care about the specifics they just want it to work when the open the app on their phone!). This probably covers off the most common [IoT] devices that most people will come across.
Very simply, other categories might be industrial (sensors, etc.) and enthusiast (who will know what they are doing, but in terms of numbers I guess will be a minority). For machine to machine there has to be some form of discover, I'd expect this to be over local networks rather than just directly to the internet, otherwise they will probably need to register themselves. Directly addressable devices will exist, but how are they discovered? You either need DNS or to know the v6 address (not likely), and as already mentioned here that DNS would need to be registered for direct connectivity. I can see an application for this, but for most consumer routers the firewall blocks incoming connections as this is best practice so like with IPv4 and port forwarding, you will likely have to configure IPv6 pinholes on the router or turn off the firewall.
Since we are talking about consumer services with VM (and since this is the same on newer BT HomeHub routers which are already IPv6), I don't see that VM would change the default router configurations from manufacturers to make them less secure?
Just my 2p.
Hate to bring this up again but I'm seeing really bad performance of my Hurricane Electric IPv6 tunnel. It seems to have started when VM upgraded the uplink of my 100M connection from 6Mbps to 10Mbps a few days ago. I thought that it might be the weird routing that was discussed here a few months back. Looking at the traceroute it seems that the routing anomaly has been fixed and both forward and reverse paths to Hurricane Electric in London is now direct through LINX.
I've run a raw Wireshark on my connection while running speed tests (Thinkbroadband and ipv6-test.com). There's nothing jumping out as being odd, no MTU issues, packet drops or retransmissions. It's just slow.
Anybody have any suggestions on how to debug further?
Anonymous wrote:Hate to bring this up again but I'm seeing really bad performance of my Hurricane Electric IPv6 tunnel. It seems to have started when VM upgraded the uplink of my 100M connection from 6Mbps to 10Mbps a few days ago. I thought that it might be the weird routing that was discussed here a few months back. Looking at the traceroute it seems that the routing anomaly has been fixed and both forward and reverse paths to Hurricane Electric in London is now direct through LINX.
I've run a raw Wireshark on my connection while running speed tests (Thinkbroadband and ipv6-test.com). There's nothing jumping out as being odd, no MTU issues, packet drops or retransmissions. It's just slow.
Anybody have any suggestions on how to debug further?
I would contact HE directly.
Not much of an update. But a statement from Virgin here https://www.ispreview.co.uk/index.php/2019/10/update-on-ipv6-plans-for-virgin-media-talktalk-and-vodafone.html
From the Article..
A Virgin Media spokesperson told ISPreview.co.uk:
“We are currently setting out our IPV6 deployment plans and will provide an update at the appropriate time.”
Wonder if it was just a basic PR reply - It sounds like one. Tho the "rumor" that they might go full dual-stack rocks... If it's true. They should just CGNAT the public roaming WiFi stuff and nothing else (but that's just me).
I hope the article is correct and they're not going to use DS Lite.
Virgin Media Ireland use DS Lite and they can't use Modem Mode without switching back to IPv4.
cje85 wrote:I hope the article is correct and they're not going to use DS Lite.
Virgin Media Ireland use DS Lite and they can't use Modem Mode without switching back to IPv4.
https://www.boards.ie/ttfthread/2057868651/1
the most useful answer I got from all IPv6 topics is to switch to another provider, the only thing that solved the issue really well :-).
