IPv6 can boost mobile performance, battery life
itworld.com
itworld.com
* Because NAT is not necessary with IPv6 every device can be directly reached by services like Twitter. In contrast today the device has initiate the connection to the services on a regular basis, which drains the battery. * "Accessing sites and content over the Internet is usually faster with IPv6 than with IPv4 because with the new protocol it requires fewer "hops" between network nodes": I cannot comment on this but I would like to know why IPv6 will use fewer "hops"?
The article goes as well on to say that communication providers will offer static IP addresses to their customers. We will see, but I am a little bit worried what this can mean for security if everybody in the InterNet can easily reach every mobile phone. Imagine new exploits in the TCP/IP implementation. It would open the door to infect a huge number of devices...
To track a downloader of illegal content, you'd still have to go through the users provider and the provider can easily determine who actually downloaded that content at a time.
So as long as providers cooperate, it's not easier or harder to track down a pirate with IPv6 than it was with IPv4
You're not doing anyone any favors.
The second appends a random number to the /64. This was added specifically to address the privacy concerns of the previous scheme, and does so as well as any easily routable scheme can. While it's obvious under this scheme what network traffic is headed to, it isn't easy to determine which device on that network is going to receive that traffic. Or that device's past network history, if it routinely switches IP addresses.
A /64 isn't a person any more than a IPv4 address is a person. It could identify you on your wifi, your phone, your friends phone, your friends laptop, the kind lady downstairs who you lent your wifi password... all it specifies is the destination subnet for communication.
If you're the least bit privacy aware, it's not any easier to track your device using IPv6 vs IPv4.
edit: IPv6 is arguably harder to track, because autoconfiguration proceeds without a central DHCP server. In order to log IP <=> client mappings, a router would need to listen for all Neighbor Solicitations to outgoing devices, not just add a couple printfs to the DHCP server.
I think devices have been built assuming there was a firewall around them. If the designers started to envisage security from the start, things would have to change. I think it is probably the way things will move.
Regarding security, it is still possible to provide the same "security" as NATed private addresses on the network gateway level. However, with some carriers it was (still is?) possible for a long time to communicate with other private IPs without any firewalling, making the argument moot. This also had the bonus feature of bypassing traffic accouning, allowing to have free unlimited traffic via a VPN between two customers.
Anyway, I doubt it will have a significant impact on battery life.
Well, where there used to be NAT there should now be a carrier-grade firewall. So it probably won't be as bad as a bare connection to the internet.
Also, how does a device keep an address when it switches between cellular data and WiFi? How does IPv6 make this and similar issues go away?
It doesn't (unless people use Mobile IPv6, which seems unlikely). However, changing IP address is a small potato problem compared to the problems caused by keepalives and NATs. A device will know when its IPv6 address changes and can re-initiate its TCP connections. Right now, a device doesn't know when a NAT/stateful firewall has timed out one of its connections or decided to start NAT'ing to a new public IP address, which is why constant battery-draining keepalives are needed.
On the other hand, perhaps if the carriers sparsely assign IPv6 addresses from their vast address space, it won't be feasible for attackers to scan for nodes as they do now.
I think the article is premature in suggesting anything about how IPv6 will be implemented in mobile networks in practice.
Even with MAC-based IPv6 autoconfiguration to reduce the number of IPs you have to scan using tables of assigned vendor prefixes, you still have a truly massive number of IPs to scan before you find anyone.
Put another way, it would take over 500,000 years to just send an ICMPv6 packet to a /64 block (assuming you could even narrow it down to a /64 which itself seems just as unlikely) with a 1 Gbps connection (over ethernet).
But maybe attackers just won't even try.
Yes, IPv6 could do that, but so can IPv4. Google have already demonstrated how to detect and adapt to the NAT device's timeout. Devices can just as easily hold a TCP connection open with minimal keepalives. All that is needed is for carrier NAT devices to increase their timeouts, and Android will detect this and start using less frequent keepalive intervals. 30 seconds (as from the article) can become 30 minutes. I'm sure the other smartphone OSes can either do the same thing or already do.
No IPv6 is needed. As much as I'd like to see IPv6 adopted, specious claims do not help.
I'm not convinced there will be that many extra stale connections, either. Do a significant number of phones switch IPs so often that there will really be a problem, or do they tend to get the same ones back?
also, the claim about "With a static address, it's easier to keep a data session alive while a smartphone or tablet travels with the user from one cell to another" is slightly disingenuous. typically address allocation in cellular networks is via an end node like ggsn or the pgw (lte). cell-to-cell movement doesn't constitute a "rat" (radio-access-tech) change. only when you move from lte coverage area to say a cdma area, handover procedures kick in, and then too, for session continuity reasons, end-node-address doesn't change...