Forum Discussion
I'm also interested in buying a new router for home, but I can't do that until I know how this will all work so I can make sure my new router will work... I don't even know if my current router will work (this is all with modem mode of course)
CG NAT is coming because of the shortage of IPv4 addresses, not because of IPv6. DS-lite is a sensible solution, because they are rolling out a network stack that will be in use for many years to come, and the shortage gets ever worse.
If they cancelled the IPv6 project tomorrow, it would be immediately replaced with another project implementing some form of CG NAT.
- ksim6 years agoUp to speed
thelem wrote:If they cancelled the IPv6 project tomorrow, it would be immediately replaced with another project implementing some form of CG NAT.
yep, I am more than sure, they canceled IPv6 project and will replace just with ipv4 nat when will feel the shortage with an option to buy a public IP. they will even advertise that as a "secure network".
- ApprovedAnonymous6 years ago
ksim wrote:
yep, I am more than sure, they canceled IPv6 project and will replace just with ipv4 nat when will feel the shortage with an option to buy a public IP. they will even advertise that as a "secure network".This daft. They've not cancelled the IPv6 project. The trial deployment is on-going with only a small but seemly permanent dip a few months ago.
Deployment of DS-Lite is in a holding pattern. To the best of my knowledge VM aren't in a tight spot for IPv4. They have indicated that deployment is dependent on content providers moving to IPv6. This isn't happening very quickly outside of the big content providers. For example the IPv6 traffic through LINX is tiny even with the huge deployment of IPv6 clients on BT and Sky. There's no compelling business case for them to rush.
If and when VM feel the pinch on IPv4 they can start the deployment for new customers (as suggested on here some months ago). It's a low risk way to start the ball rolling with new customers tied into 12 month contracts and not knowing any better. They'll know from large scale Liberty Global deployments in the rest of the EU what the impact is going to be.
- ksim6 years agoUp to speed
Anonymous wrote:This daft. They've not cancelled the IPv6 project.
okey, they are just moving backward or they stuck in 2017 ;-)
Anonymous wrote:The trial deployment is on-going with only a small but seemly permanent dip a few months ago.
Deployment of DS-Lite is in a holding pattern. To the best of my knowledge VM aren't in a tight spot for IPv4. They have indicated that deployment is dependent on content providers moving to IPv6.
Every major content provider implemented IPv6 years ago. Main internet provider did the same. Even this forum is using IPv6 ;-), VM is the biggest who promised to deliver but wasn't able to, the only things they were able to do is configure a cap for clients who are using tunnels.
Anonymous wrote:If and when VM feel the pinch on IPv4 they can start the deployment for new customers (as suggested on here some months ago). It's a low risk way to start the ball rolling with new customers tied into 12 month contracts and not knowing any better. They'll know from large scale Liberty Global deployments in the rest of the EU what the impact is going to be.
The main mistake is thinking is that IPv6 is only needed when a provider has a limited pool of IPv4 addresses, NO, I need it as a client to get rig of NAT for my IoT devices at home. IPv6 brings much more than just addresses, it is faster routing and other things.
Just want to finish with one thing, transition to IPv6 is not noticable for endusers if you do it right, VM as part of LG just can't do it right, and this is why VM is not doing it.
Anonymous wrote:
They'll know from large scale Liberty Global deployments in the rest of the EU what the impact is going to be. - fyonn6 years agoDialled in
thelem wrote:CG NAT is coming because of the shortage of IPv4 addresses, not because of IPv6. .
VM can't be short of IPv4 addresses, they've been telling us for the 8+ years that I've been following this thread that they weren't implementing IPv6 because they had no shortage of IPv4 addresses... *ahem*
- VMCopperUser6 years agoWise owl
Anonymous wrote:Spoilerksim wrote:
yep, I am more than sure, they canceled IPv6 project and will replace just with ipv4 nat when will feel the shortage with an option to buy a public IP. they will even advertise that as a "secure network".This daft. They've not cancelled the IPv6 project. The trial deployment is on-going with only a small but seemly permanent dip a few months ago.
Deployment of DS-Lite is in a holding pattern. To the best of my knowledge VM aren't in a tight spot for IPv4. They have indicated that deployment is dependent on content providers moving to IPv6. This isn't happening very quickly outside of the big content providers. For example the IPv6 traffic through LINX is tiny even with the huge deployment of IPv6 clients on BT and Sky. There's no compelling business case for them to rush.
If and when VM feel the pinch on IPv4 they can start the deployment for new customers (as suggested on here some months ago). It's a low risk way to start the ball rolling with new customers tied into 12 month contracts and not knowing any better. They'll know from large scale Liberty Global deployments in the rest of the EU what the impact is going to be.
Over a year ago Liberty Global was talking about full customer rollout "soon". I think (could be wrong), out of the whole of the EU, 10 of the Countries they operate in are IPv6 enabled, the UK is not. Not sure how many separate companies they have in the EU/how many countries in total they operate in. I am also counting the UK as 1, not 4.
VM has said that their core network is IPv6, that their voice services all run over IPv6. No mention of their Video on Demand services.
https://benunetworks.com/product-2/dual-stack-lite/ is the DS-Lite provider they have chosen (if they haven't changed it).
A neat little fact is that Liberty Global (who now owns Virgin Media) has been praised highly over the years because they seem to push for IPv6 deployment. For some reason, the UK arm (and, it is now an Arm of Liberty Global) seems to go the other way.
Now.... I know that their IPv6 deployment is not standard. In Ireland if you complain about DS-Lite then they can give you a IPv4 only Config. In Germany I think those who complain about DS-Lite can get full DS services. Some areas seem to complain about using 3rd party routers too.
In regards to the post by ksim... I think they forgot to put in the word "IF", I do not think it intentional of them saying VM had cancelled the IPv6 deployment. (could be wrong).
It shouldn't be about a IPv4 "Pinch"... I think they argued that early on too... This shouldn't be an idea that has to be monetized, and that is sadly what I think is happening. I seen the same thing with Modem cloning in the past, for years and years people were not-not-allowed to clone modems and steal service - sometimes literally killing others sharing the same area connections. There was never a large enough monetary reason for them to combat theft of service. Until customers leave due to this then they'll never care.
And I still see no reason why everyone cant have a IPv4 from Virgin Media...9.5 million IPv4 addresses and 5.9 million home broadband customers.
- ApprovedAnonymous6 years ago
@VMCopperUser: Great post.
I think we've covered this before but I believe that the UK VM customer base is approx the same as all the other EU LG networks put together. With an adequate supply of IPv4 it's in their interest to approach things here with a greater sense of caution. Don't think they'll be seeking to monetise. That seems like a fools errand costing more to administer than it would bring in (for the time being).
ksim wrote:
Every major content provider implemented IPv6 years ago.Hmm. Not really. Many like Google, Facebook, LinkedIn and CDNs like Cloudflare, Akamai surely have and reaped the benefits. A great many have not. Twitter, the BBC and many newspapers (Mirror, Sun, Guardian, Telegraph) being easy examples that have yet to make the switch. According to https://whynoipv6.com/ only 350 of the Alexa top 1000 sites are IPv6 enabled.
On my own network my mostly pedestrian web browsing is showing 21% of downstream traffic as IPv6 and 12.9% of upstream. If you exclude my YouTube addiction it's probably the 12.9% number that's more typical.
ksim wrote:
Even this forum is using IPv6 ;-),This is a good spot! They must have turned this on fairly recently. A quick survey of other VM services shows they're still on IPv4-only unfortunately.
- ksim6 years agoUp to speed
Anonymous wrote:Hmm. Not really. Many like Google, Facebook, LinkedIn and CDNs like Cloudflare, Akamai surely have and reaped the benefits. A great many have not. Twitter, the BBC and many newspapers (Mirror, Sun, Guardian, Telegraph) being easy examples that have yet to make the switch. According to https://whynoipv6.com/ only 350 of the Alexa top 1000 sites are IPv6 enabled.
On my own network my mostly pedestrian web browsing is showing 21% of downstream traffic as IPv6 and 12.9% of upstream. If you exclude my YouTube addiction it's probably the 12.9% number that's more typical.
It is not about web traffic, it is about devices from local network with public IPs, without IPv6 I can't access CCTV cameras directly, I can't access doorbell/home-assistant/monitoring system/media player/fridge/washing machine, I have to implement NAT translation/nginx proxy/use Cloudflare/DNS override, the traffic from this devices is about 2-3%, but this is not why IPv6 can be ignored, newspapers are not working with my devices, google assistant does, that is why Google has IPv6 and Mirror is not (BTW BBC has IPv6 enabled API).
Anonymous wrote:
ksim wrote:
Even this forum is using IPv6 ;-),This is a good spot! They must have turned this on fairly recently. A quick survey of other VM services shows they're still on IPv4-only unfortunately.
this forum is not made or hosted by VM, they are just paying third-party, and the third-party is using AWS where IPv6 comes with a click of a button
- ApprovedAnonymous6 years ago
I'm struggling to follow your argument. We're discussing/advocating that VM deploy IPv6 not the generic benefits of IPv6 [1].
For a consumer ISP like VM traffic and customer experience is everything. VM have made few pronouncements w.r.t. IPv6 but those they have made indicate that they are waiting for the content providers to make a greater move to IPv6. Given their desire to use DS-Lite [2] this makes complete sense. The more native IPv6 traffic (by bandwidth and/or connections) the better as this will reduce the load on their AFTR CG-NAT boxes which in turn reduces Cap-Ex. Also, more native IPv6 traffic will reduce the likelihood of AFTR CG-NAT induced breakage of network applications so better customer experience and fewer support calls.
This surely validates (from VMs point of view) the wait-and-see approach to deployment that they would appear to be holding to however much it may frustrate (or delight) the enthusiasts on this forum.
[1] I fully agree with your assertions on the benefits of IPv6. I was an engineer and latterly an engineering manager for a large CCTV manufacturer for over 13 years. A world without NAT would open up many opportunities in that arena. Never enough to influence ISPs deployment plans however.
[2] The merits and demerits of DS-Lite have been done to death on this thread. I don't think we need to re-open that can of worms. It's clearly Liberty Global's preferred technology for better or worse.
- ksim6 years agoUp to speed
It is wrong to think that IPv6 migration should follow content providers, content providers will support IPv4 for years, while they even have 1% of IPv4 traffic. This thinking (and VM follows it) leads to "why implement IPv6 at all if everything is accessible through IPv4", surprise!! that is what is exactly what they are saying: "But what could you be downloading over 6in4 tunnel that you can't get over IPv4?"! https://community.virginmedia.com/t5/Speed/traffic-shaping-for-protocol-41/m-p/4023900/highlight/true#M211102 For a user who is opening youtube/facebook/netflix IPv6 makes no difference, moving BBC, twitter or anyone else to IPv6 will not make any difference for VM, as the services will be available on IPv4 also.
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 to play a game with friends? -> learn port forwarding, more fun when you the only one who can't connect and you have to teach your friend (who is on IPv6) to configure port forwarding for IPv4. 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.
I've sent my complaint to obdusmen as VM is capping me and other users against own policy https://assets.virginmedia.com/help/assets/documents/Virgin_Fibre_Traffic_Management_Key_Facts_Indicator_Unlimited.pdf.
- matthewsteeples6 years agoDialled in
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)
- VMCopperUser6 years agoWise owl
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....
- Timwilky6 years agoFibre optic
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.
- ksim6 years agoUp to speed
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.
- matthewsteeples6 years agoDialled in
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.
- ksim6 years agoUp to speed
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.
- matthewsteeples6 years agoDialled in
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 :)
- ksim6 years agoUp to speed
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.
- matthewsteeples6 years agoDialled in
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.
- ksim6 years agoUp to speed> 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. - VMCopperUser6 years agoWise owl
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.
- jonathanm6 years agoUp to speed
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.
- ApprovedAnonymous6 years ago
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?
- TonyJr6 years agoUp to speed
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.
- andrewducker6 years agoOn our wavelength
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
Related Content
- 5 months ago
- 1 year ago
- 1 year ago