So you want Microsoft to be able to find your phone without being able to know where your phone is.
The issue is users are denied the option of preventing their phones location to be periodically uploaded to Microsoft. I don't want Microsoft anyone at Microsoft or anyone who may compel Microsoft to produce the information to track me.
Perhaps it is, but AFAIK both iOS and Android do the same thing. Google even killed Skyhook and is facing a lawsuit in order to get hold of location data. Why is such a stink raised over Microsoft doing it?
Hello officer, why such a stink over robbing the blind mans collection of wind chimes? My neighbors did it too!
That doesn't make any sense. You can turn off find my phone even if you have a MS and dev account and dev unlock your device.
There is no way to turn off the find my phone option on the device. This is part of the problem the way the UI is constructed people think they can turn it off when they really can't. Get ahold of a windows phone, turn off "find my phone" and then see if your location is still not reported on the web site.
Once you associate an account there is no way to unassociated it without wiping the device. Wiping the device also resets the unlocked status of the device.
Source, please? I very much doubt this is true. There are a number of options which will cause your location to be sent to MS (for example, the Find My Phone feature, or the "Send information
I know because I've seen it in action myself. If it is not using the GPS it is uploading tower data to get a rough position for the find my phone option.
about WiFi networks near me to Microsoft to improve location services" feature) but each one of them explicitly calls out that they will send your location. Turning off Location Services is supposed to completely disable the GPS and WiFi-hotspot-based location features as well (hypothetically the latter could be re-implemented in other code, but I've seen no sign of this).
How do you use your devices GPS for a local mapping application without also participating in Microsoft's crowdsourcing? It seems to be all or nothing which is unacceptable.
Oh, and for the record, sideloading is possible on WP as well as on Android. It's definitely more restrictive (you need a PC) but it's possible.
You need to developer unlock your device to sideload... this requires a Microsoft account and a developer account.. which means find my phone is then not optional.
Sorry I don't know anything about iOS. Google is optional on Android, you can load applications on your device without google play and even use a number of alternate stores.
Turning off "location services" does not resolve the problem.
Atleast they don't seem to be spying on which physical stores you visit
At least.... at least Microsoft is not run by Hitler.. so there is that...
1. Find my phone option can't be opted out of there is no way to not have the device send location to Microsoft and still be able to use the device in even a remotely meaningful way.
2. It is not possible to not be complicit in Microsofts skyhook WiFi location mapping system.
3. When your device connects to a WiFi network it sends unique device identifiers in the clear over the network there is no way to stop it.
4. Wireless security 100% completely utterly insecure by design due to total failure of device to validate certificate chain.
5. Impossible for mortals to perform basic functions available as standard features on decades old "feature phones" such as contact synchronization without having to upload all of your contact information to Microsoft. My contacts are none of Microsoft's goddamn business.
Windows phone 8 is designed to violate your privacy at every turn while locking you into their curated app store.
Can we all just fucking accept that companies get rich at your cost and there is no large company that does not do shit they should not do!
Never, they care when nobody buys their shit. It is the users responsibility to reign in corporations when they get too greedy by forcing change.
All of these technology companies are banking on not enough people caring.. while it is increasingly clear there actually is a non-trivial chorus of people who actually give a shit.
I wonder whether it's FUD around the option (probably defaulted to opt-in) to participate in Microsoft's "feedback" program.
I don't think there is anything that is overblown.
If you associate your Windows phone with an account (Required to load software from the only source permissible the windows app store) the phone also periodically and on demand of Microsoft uploads your location to a Microsoft server and there is **NOTHING** you can do about it and no way you can turn it off short of wiping the device and never associating an account which means not using the app store paying a hefty premium to use what is then essentially a "feature phone"
Microsoft's WP does not respect your privacy by default and there is no lever you can pull that changes this.
Why? If the connection is being MITMd, then both sides need to be able to figure this out.
You answer your own question in the next paragraph.
You have a compromised communication channel and you are making decisions based on content of data communicated over that channel. It's broken so lets use it anyway and hope for the best.
There was a long discussion on this (regrettably rejected by the browser vendor) to allow the SSL fingerprint to be obtained in JS. That would make it reasonably easy for the site operator to verify that the SSL cert hadn't been tampered with. (Of course, a really evil proxy can scan for the JS, but that game of whack-a-mole is usually easier for the good guys to win, at least sometimes).
If you want servers to validate clients use client certificates or TLS-SRP to log-on to a site. All MITM countermeasures need to be cryptographically bound to session encryption or they are useless. "whack-a-mole" scenarios do not prove security and security without meaningful trust is an illusion.
Go look at the laundry list of CAs your browser trusts. It's a mile long, and any one of those companies can insert itself between you and the website you are visiting and get your login credentials, bank account numbers, personally identifiable information, and whatever other information you THINK is secure.
Not to mention SHA1 signature algorithm all CAs currently using has been known to be broke for years. Would be amusing if a cluster of PS4's were used this time to demonstrate that which had apparently not already been learned five years ago.
SSL is defective by design.
Please join my campaign of pushing browser support for TLS-SRP. Tell all of your friends, have them spread the word, bug the sh1t out of browser vendors to commit the SRP patches already in many of their ticket systems. While it is no panacea it is a useful option where CA's and their planet scale trust anchors are completely optional.
If there was a caching proxy closer to the edge that made your wget of an ubuntu ISO 10* times faster, wouldn't you want that?
There are a million ways to do this already.. CDN's, anycast, redirects... how is operating a proxy at scale a viable alternative to all the other shit that stays out of the data path?
No, you don't want your HTTPS Gmail to be cached and snooped - but that's perfectly ok, because that's NOT what is being proposed here.
No it is just ISO of your new operating system that will be used to access your gmail account. Oh yea those **MD5** checksums on Ubuntu's.. I give up.
As a website operator, I want to know if my content is being MITMd en route to the user. I know about the SSL fingerprint trick that lets a really technical user discover proxying, but I want to automate this process server-side, and stick up a big banner to say "Your employer is snooping on this connection, please log in from a trusted machine" (and then I'll prevent the user from logging in).
What you just wrote makes about as much sense as: "My Internet is currently down so I'm sending a nasty e-mail to my ISP demanding they fix the problem."
Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.
Except the consumer of this ID would be anyone with a browser which is potentially billions of people. The only question that matters in my opinion is can you explain the concept of "trusted proxy of untrustworthy content" to an average person (e.g. cookie baking oracle)... if not essentially you are asking the user to provide an answer to a question they don't understand. A stupid and pointless question I might add.
If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.
Providing legal cover for illegitimate behavior I suspect is the whole point. See the user said it was ok (Even though they have no fucking clue) so now we have legal cover to continue with our bullshit without fear of retribution.
It is not the fault of those who originally wrote the SMTP, HTTP W3C standards that their shit is constantly abused to screw over and scam millions. This was all done in an era of implicit trust and technical sophistication.
It is however our fault for decades later continuing to allow this shit that passes for basic communications today to be so easily coopted by scum. This ID does nothing to fix anything... It just pours more fuel on the fire by asking users TOTALLY USELESS questions they are incapable of answering.
But as I read it, the issue seems to arise from the fact that HTTP2 will permit TLS to be used with both http: and https: URLs. If it is used for http: URLs, then existing proxy and caching mechanisms will simply break. I think this is a
My understanding using TLS for HTTP via "HTTP2" is accomplished via *untrusted* opportunistic encryption. Nothing breaks if your operating a proxy supporting HTTP2. Proxy would simply terminate the encryption from the client and setup a separate equally useless "encrypted" channel to the server. The proxy would act as a middle man.
proposal for "trused proxies" to be permitted where an http: URL is in use and TLS is also employed, I don't think it's proposed that this should apply to https: URLs.
Basically what they are proposing is to provide a "trusted proxy" for completely untrustworthy http transactions. How is this not an oxymoron? What is the security value? Value to the user? Who benefits?
It seems all this does is add more complexity while accomplishing nothing. And about consent good luck explaining "secure proxy of insecure data" doublespeak to an average human being who has better things to do with their time than read IETF ID's... more likely this will only confuse the hell out of people causing them to assume things about the content they are consuming which are false.
Wherever there are finite bandwidth connections, there will always be throttling. Whether the throttling occurs based on type of traffic, end user limits, or "naturally" sort itself out via TCP or other protocols, throttling will occur as the bottlenecks fill up. If the carriers will not be allowed to do any throttling based on traffic type/source/etc, then the guy that decides to run a p2p file server will have his 500 connections open while your measly 1 netflix connection will get drowned out, as the "natural TCP throttling" tends to divide the bandwidth equally per connection (not per user).
Give policy peeps some credit they are well aware of the difference between network management and throttling shenanigans. Simply put application of "network management" preferentially is the issue rather than management itself.
If content wants to play games by nerfing congestion algorithms for competitive advantage this is separate issue from the typical eyeball network which will simply forward whatever it gets subject to local constraints/queue management.
I agree with the sentiment people get sad when their streaming service lags and tend to automatically jump on conspiracy bandwagons both real and imagined as explanation. Thankfully while hearsay may act to promote change in regulatory environment it has no place with respect to enforcement.
Now suppose I start my own company that competes against Netflix's streaming service. Is the ISP "throttling" if they accept Netflix's cache server in their network nodes, but won't accept mine?
Nope.
Or what if there are 10,000 would-be Netflix competitors - do all ISP's have to host 10,000 cache servers, all on the same terms?
ISPs want CDN servers because it lowers their costs. The same way mutually beneficial peering arrangements lowers costs. If you operate a service nobody uses no ISP will want your servers. The space they take up is not cost effective.
It has nothing to do with "blocking" or preferential treatment of packets from sources your in cahoots with.
but in a data center, server 2012 would likely be a headless server-core instance with no GUI at all.
Having connected to many hundreds of windows servers throughout the world not a single one was ever running "server core"
To address your question, I would imagine that developers who choose to develop on a server SKU may want to target Metro/Modern apps so it is available, if required.
I'm sure this happened...once... in the history of mankind.
If you look in a DNS cache all you know is name request was made you don't have any evidence of what was done with that name.
Any web site you visit could cause entries for any DNS name it chooses to be loaded into the cache. It is not hard to imagine competing clans, those who dislike you or just want to create chaos operate a site which causes incriminating entries to be loaded into DNS caches.
I want to see Valve held criminally liable for rummaging thru computers and conducting investigations.
Wide and easy adoption of any new technology requires backward compatibility.
Unless of course there is no other operationally viable solution.
Wide and easy adoption of any new technology requires backward compatibility. IPv6 is not even slightly backwards compatible.
When I browse to YouTube I connect via IPv6 and it works fine. When I go to that same website and I don't have IPv6 I reach it via IPv4 and it still works.
I know every v6 hater thinks there just **MUST** be some clever way to solve the pigeonhole problem or construct some magical overlay network that is better than deploying IPv6. Must have heard them all by now. Meanwhile in the real world IPv6 adoption is following exponential growth curve.
If you have one IPv4 application on the entire network, then you pretty much have to keep IPv4.
Who is saying get rid of IPv4? Just add IPv6 and call it a day.
I just want to play I don't want all of your bullshit. Between anti-piracy hoops, spying, forcing Internet connectivity and removing LAN functionality it just isn't worth it.
There are millions of devices with IPv4 baked in that will never get another firmware update. These devices cannot run tunnel software. They talk ipv4 and thats it. It is unreasonable to expect people to ditch their hardware to support new protocol that missed its window of opportunity for adoption.
That's just fine. These devices will eventually break or become obsolete for some other reason and will be eventually replaced. While some might last a million years in aggregate the yearly churn rate is enough to fuel healthy IPv6 growth curves.
It is not like cable operators have not routinely forced stragglers to upgrade to the latest and greatest cable labs concoction. At some point it becomes cost effective to draw a line in the sand for the few outliers who want to hang on to their 50 year old Interface Message Processors for sentimental reasons.
My networking knowledge is rusty, but does NAT actually add any substantial security beyond what would be provided by a router with an aggressive firewall that rejects all incoming connections that haven't been specifically white-listed?
NAT is LESS secure than a SPI firewall due slightly to extra code in mangling packets and mainly in assumptions made managing MANY:1 state machines that can be gamed by adversaries.
In order to make a device that is IPv4 only able to run IPv6 is software changes. Carrier grade hardware will have firmware updates that add this functionality.
The big routing toys all have specialized hardware (ASICs) tied to IPv4 packet structures and addressing which needs to be physically replaced to support new structures of IPv6. Assumptions about structure is literally burnt into the hardware.
However most of this gear will still pass IPv6 on the slow path allowing some deployment of IPv6 until the gear can be replaced/upgraded over time.
In 2014 I have little sympathy for the ISP who is just now realizing "OMG we need to buy all new shit" simply because they failed to be proactive and didn't plan ahead...they should have been sourcing hardware with IPv6 support for years already.
Slashdot Mirror
That analogy would make more sense if
There is no defense for asserting "but they did it too" .. two wrongs don't make a right. Stop digging.
You refuse to let utility company access a piece of in-home equipment.
Utility goes thru legal hoops to compel access.
While utility is on-premise police ask utility workers if it is ok to search your home without a warrant.
So you want Microsoft to be able to find your phone without being able to know where your phone is.
The issue is users are denied the option of preventing their phones location to be
periodically uploaded to Microsoft. I don't want Microsoft anyone at Microsoft or anyone who may compel Microsoft to produce the information to track me.
Perhaps it is, but AFAIK both iOS and Android do the same thing. Google even killed Skyhook and is facing a lawsuit in order to get hold of location data. Why is such a stink raised over Microsoft doing it?
Hello officer, why such a stink over robbing the blind mans collection of wind chimes? My neighbors did it too!
That doesn't make any sense. You can turn off find my phone even if you have a MS and dev account and dev unlock your device.
There is no way to turn off the find my phone option on the device. This is part of the problem the way the UI is constructed people think they can turn it off when they really can't. Get ahold of a windows phone, turn off "find my phone" and then see if your location is still not reported on the web site.
Once you associate an account there is no way to unassociated it without wiping the device. Wiping the device also resets the unlocked status of the device.
Source, please? I very much doubt this is true. There are a number of options which will cause your location to be sent to MS (for example, the Find My Phone feature, or the "Send information
I know because I've seen it in action myself. If it is not using the GPS it is uploading tower data to get a rough position for the find my phone option.
about WiFi networks near me to Microsoft to improve location services" feature) but each one of them explicitly calls out that they will send your location. Turning off Location Services is supposed to completely disable the GPS and WiFi-hotspot-based location features as well (hypothetically the latter could be re-implemented in other code, but I've seen no sign of this).
How do you use your devices GPS for a local mapping application without also participating in Microsoft's crowdsourcing? It seems to be all or nothing which is unacceptable.
Oh, and for the record, sideloading is possible on WP as well as on Android. It's definitely more restrictive (you need a PC) but it's possible.
You need to developer unlock your device to sideload... this requires a Microsoft account and a developer account.. which means find my phone is then not optional.
And how is that different from iOS or Android?
Sorry I don't know anything about iOS. Google is optional on Android, you can load applications on your device without google play and even use a number of alternate stores.
Turning off "location services" does not resolve the problem.
Atleast they don't seem to be spying on which physical stores you visit
At least .... at least Microsoft is not run by Hitler.. so there is that...
1. Find my phone option can't be opted out of there is no way to not have the device send location to Microsoft and still be able to use the device in even a remotely meaningful way.
2. It is not possible to not be complicit in Microsofts skyhook WiFi location mapping system.
3. When your device connects to a WiFi network it sends unique device identifiers in the clear over the network there is no way to stop it.
4. Wireless security 100% completely utterly insecure by design due to total failure of device to validate certificate chain.
5. Impossible for mortals to perform basic functions available as standard features on decades old "feature phones" such as contact synchronization without having to upload all of your contact information to Microsoft. My contacts are none of Microsoft's goddamn business.
Windows phone 8 is designed to violate your privacy at every turn while locking you into their curated app store.
Can we all just fucking accept that companies get rich at your cost and there is no large company that does not do shit they should not do!
Never, they care when nobody buys their shit. It is the users responsibility to reign in corporations when they get too greedy by forcing change.
All of these technology companies are banking on not enough people caring.. while it is increasingly clear there actually is a non-trivial chorus of people who actually give a shit.
I wonder whether it's FUD around the option (probably defaulted to opt-in) to participate in Microsoft's "feedback" program.
I don't think there is anything that is overblown.
If you associate your Windows phone with an account (Required to load software from the only source permissible the windows app store) the phone also periodically and on demand of Microsoft uploads your location to a Microsoft server and there is **NOTHING** you can do about it and no way you can turn it off short of wiping the device and never associating an account which means not using the app store paying a hefty premium to use what is then essentially a "feature phone"
Microsoft's WP does not respect your privacy by default and there is no lever you can pull that changes this.
Why? If the connection is being MITMd, then both sides need to be able to figure this out.
You answer your own question in the next paragraph.
You have a compromised communication channel and you are making decisions based on content of data communicated over that channel. It's broken so lets use it anyway and hope for the best.
There was a long discussion on this (regrettably rejected by the browser vendor) to allow the SSL fingerprint to be obtained in JS. That would make it reasonably easy for the site operator to verify that the SSL cert hadn't been tampered with. (Of course, a really evil proxy can scan for the JS, but that game of whack-a-mole is usually easier for the good guys to win, at least sometimes).
If you want servers to validate clients use client certificates or TLS-SRP to log-on to a site. All MITM countermeasures need to be cryptographically bound to session encryption or they are useless. "whack-a-mole" scenarios do not prove security and security without meaningful trust is an illusion.
Go look at the laundry list of CAs your browser trusts. It's a mile long, and any one of those companies can insert itself between you and the website you are visiting and get your login credentials, bank account numbers, personally identifiable information, and whatever other information you THINK is secure.
Not to mention SHA1 signature algorithm all CAs currently using has been known to be broke for years. Would be amusing if a cluster of PS4's were used this time to demonstrate that which had apparently not already been learned five years ago.
SSL is defective by design.
Please join my campaign of pushing browser support for TLS-SRP. Tell all of your friends, have them spread the word, bug the sh1t out of browser vendors to commit the SRP patches already in many of their ticket systems. While it is no panacea it is a useful option where CA's and their planet scale trust anchors are completely optional.
If there was a caching proxy closer to the edge that made your wget of an ubuntu ISO 10* times faster, wouldn't you want that?
There are a million ways to do this already.. CDN's, anycast, redirects... how is operating a proxy at scale a viable alternative to all the other shit that stays out of the data path?
No, you don't want your HTTPS Gmail to be cached and snooped - but that's perfectly ok, because that's NOT what is being proposed here.
No it is just ISO of your new operating system that will be used to access your gmail account. Oh yea those **MD5** checksums on Ubuntu's.. I give up.
As a website operator, I want to know if my content is being MITMd en route to the user. I know about the SSL fingerprint trick that lets a really technical user discover proxying, but I want to automate this process server-side, and stick up a big banner to say "Your employer is snooping on this connection, please log in from a trusted machine" (and then I'll prevent the user from logging in).
What you just wrote makes about as much sense as: "My Internet is currently down so I'm sending a nasty e-mail to my ISP demanding they fix the problem."
Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.
Except the consumer of this ID would be anyone with a browser which is potentially billions of people. The only question that matters in my opinion is can you explain the concept of "trusted proxy of untrustworthy content" to an average person (e.g. cookie baking oracle) ... if not essentially you are asking the user to provide an answer to a question they don't understand. A stupid and pointless question I might add.
If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.
Providing legal cover for illegitimate behavior I suspect is the whole point. See the user said it was ok (Even though they have no fucking clue) so now we have legal cover to continue with our bullshit without fear of retribution.
It is not the fault of those who originally wrote the SMTP, HTTP W3C standards that their shit is constantly abused to screw over and scam millions. This was all done in an era of implicit trust and technical sophistication.
It is however our fault for decades later continuing to allow this shit that passes for basic communications today to be so easily coopted by scum. This ID does nothing to fix anything... It just pours more fuel on the fire by asking users TOTALLY USELESS questions they are incapable of answering.
But as I read it, the issue seems to arise from the fact that HTTP2 will permit TLS to be used with both http: and https: URLs. If it is used for http: URLs, then existing proxy and caching mechanisms will simply break. I think this is a
My understanding using TLS for HTTP via "HTTP2" is accomplished via *untrusted* opportunistic encryption. Nothing breaks if your operating a proxy supporting HTTP2. Proxy would simply terminate the encryption from the client and setup a separate equally useless "encrypted" channel to the server. The proxy would act as a middle man.
proposal for "trused proxies" to be permitted where an http: URL is in use and TLS is also employed, I don't think it's proposed that this should apply to https: URLs.
Basically what they are proposing is to provide a "trusted proxy" for completely untrustworthy http transactions. How is this not an oxymoron? What is the security value? Value to the user? Who benefits?
It seems all this does is add more complexity while accomplishing nothing. And about consent good luck explaining "secure proxy of insecure data" doublespeak to an average human being who has better things to do with their time than read IETF ID's... more likely this will only confuse the hell out of people causing them to assume things about the content they are consuming which are false.
I'm wearing a goofy visor worth 15 franklins.
Wherever there are finite bandwidth connections, there will always be throttling. Whether the throttling occurs based on type of traffic, end user limits, or "naturally" sort itself out via TCP or other protocols, throttling will occur as the bottlenecks fill up. If the carriers will not be allowed to do any throttling based on traffic type/source/etc, then the guy that decides to run a p2p file server will have his 500 connections open while your measly 1 netflix connection will get drowned out, as the "natural TCP throttling" tends to divide the bandwidth equally per connection (not per user).
Give policy peeps some credit they are well aware of the difference between network management and throttling shenanigans. Simply put application of "network management" preferentially is the issue rather than management itself.
If content wants to play games by nerfing congestion algorithms for competitive advantage this is separate issue from the typical eyeball network which will simply forward whatever it gets subject to local constraints/queue management.
I agree with the sentiment people get sad when their streaming service lags and tend to automatically jump on conspiracy bandwagons both real and imagined as explanation. Thankfully while hearsay may act to promote change in regulatory environment it has no place with respect to enforcement.
Now suppose I start my own company that competes against Netflix's streaming service. Is the ISP "throttling" if they accept Netflix's cache server in their network nodes, but won't accept mine?
Nope.
Or what if there are 10,000 would-be Netflix competitors - do all ISP's have to host 10,000 cache servers, all on the same terms?
ISPs want CDN servers because it lowers their costs. The same way mutually beneficial peering arrangements lowers costs. If you operate a service nobody uses no ISP will want your servers. The space they take up is not cost effective.
It has nothing to do with "blocking" or preferential treatment of packets from sources your in cahoots with.
Don't use it.
Not a bad attempt at trolling,
Serious?
but in a data center, server 2012 would likely be a headless server-core instance with no GUI at all.
Having connected to many hundreds of windows servers throughout the world not a single one was ever running "server core"
To address your question, I would imagine that developers who choose to develop on a server SKU may want to target Metro/Modern apps so it is available, if required.
I'm sure this happened...once... in the history of mankind.
If you look in a DNS cache all you know is name request was made you don't have any evidence of what was done with that name.
Any web site you visit could cause entries for any DNS name it chooses to be loaded into the cache. It is not hard to imagine competing clans, those who dislike you or just want to create chaos operate a site which causes incriminating entries to be loaded into DNS caches.
I want to see Valve held criminally liable for rummaging thru computers and conducting investigations.
What I have never understood is: why has no one redesigned IPv6 in such a way as to be backwards compatible as possible with IPv4?
The key to solving IPv4 exhaustion is rooted in deeper understanding of ternary logic :)
http://tools.ietf.org/html/dra...
http://tools.ietf.org/html/dra...
Wide and easy adoption of any new technology requires backward compatibility.
Unless of course there is no other operationally viable solution.
Wide and easy adoption of any new technology requires backward compatibility. IPv6 is not even slightly backwards compatible.
When I browse to YouTube I connect via IPv6 and it works fine. When I go to that same website and I don't have IPv6 I reach it via IPv4 and it still works.
I know every v6 hater thinks there just **MUST** be some clever way to solve the pigeonhole problem or construct some magical overlay network that is better than deploying IPv6. Must have heard them all by now. Meanwhile in the real world IPv6 adoption is following exponential growth curve.
If you have one IPv4 application on the entire network, then you pretty much have to keep IPv4.
Who is saying get rid of IPv4? Just add IPv6 and call it a day.
I just want to play I don't want all of your bullshit. Between anti-piracy hoops, spying, forcing Internet connectivity and removing LAN functionality it just isn't worth it.
There are millions of devices with IPv4 baked in that will never get another firmware update. These devices cannot run tunnel software. They talk ipv4 and thats it. It is unreasonable to expect people to ditch their hardware to support new protocol that missed its window of opportunity for adoption.
That's just fine. These devices will eventually break or become obsolete for some other reason and will be eventually replaced. While some might last a million years in aggregate the yearly churn rate is enough to fuel healthy IPv6 growth curves.
It is not like cable operators have not routinely forced stragglers to upgrade to the latest and greatest cable labs concoction. At some point it becomes cost effective to draw a line in the sand for the few outliers who want to hang on to their 50 year old Interface Message Processors for sentimental reasons.
My networking knowledge is rusty, but does NAT actually add any substantial security beyond what would be provided by a router with an aggressive firewall that rejects all incoming connections that haven't been specifically white-listed?
NAT is LESS secure than a SPI firewall due slightly to extra code in mangling packets and mainly in assumptions made managing MANY:1 state machines that can be gamed by adversaries.
IP is a protocol. It is software, not hardware.
In order to make a device that is IPv4 only able to run IPv6 is software changes. Carrier grade hardware will have firmware updates that add this functionality.
The big routing toys all have specialized hardware (ASICs) tied to IPv4 packet structures and addressing which needs to be physically replaced to support new structures of IPv6. Assumptions about structure is literally burnt into the hardware.
However most of this gear will still pass IPv6 on the slow path allowing some deployment of IPv6 until the gear can be replaced/upgraded over time.
In 2014 I have little sympathy for the ISP who is just now realizing "OMG we need to buy all new shit" simply because they failed to be proactive and didn't plan ahead...they should have been sourcing hardware with IPv6 support for years already.