Skimmed through the article to understand how IPv6 will improve battery life and I get following:
* 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...
One area where IPv6 will have "fewer hops" is in cases where carrier grade NAT is being used in mobile networks. With IPv4 and CGN all traffic must be routed from cell sites to central offices with CGN hardware. With IPv6 traffic can be routed directly from cell sites to its destination without having to first travel to a central aggregation point with special hardware.
I think the 'hop' argument is silly. The other points about not maintaining keep-alive made more sense.
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.
Indeed. The 'hop' argument is only "true" with IPv6-over-IPv4 tunneling, where the real hops are concealed. Of course, the effect is actually the opposite: you have less efficient routing from source to destination because you have to go through tunnel PoPs, plus processing overhead.
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.
While I somewhat agree about the tracking (if every device gets a /64, then, while the device can chose the host part, the network part is fixed, so site owners would just track the network part to uniquely identify a device or subscriber), I don't see the argument about illegal contents.
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
There are currently several schemes for obtaining a full /128 address from a /64. One appends your device's MAC address and some other stuff to the network prefix. This obviously has some privacy implications.
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.
Honestly, I can't help but hate you when your first thought with "privacy issues" is illegal downloads. Even if you thought that was the main reason for 'net privacy, why would you say it?
This is pure speculation and cherry-picking. There are significant differences between IPv4 and IPv6. If you want to prove that IPv6 will boost performance and preserve battery life, run 2 identical devices limited to each and report the results.
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?
> 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.
Things will be simpler without NAT for sure, but the article assumes that carriers won't still have stateful firewalls with IPv6 that also require battery-draining keepalives. If IPv6 mobile networks don't have stateful firewalls, then the battery-draining keepalives could be replaced by battery-draining port scans and other probing/DoS attempts by attackers.
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.
It seems incredibly unlikely that anyone is going to be able to do a active network scan of an address block to find devices with IPv6. Each end-user is granted a /64 network which has over 4 billion times the number of IPs than exist on the entire IPv4 internet.
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).
If a mobile phone is given a /64 that means that entire /64 is routed to the phone, so any attempt to scan it (even if it doesn't find the actual address in use by the device) will cause battery drain.
I am not convinced about the polling argument to save battery life.
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.
If carrier NAT devices increase their timeouts, they're going to have to keep more stale connection information in memory, which means they'll need more memory to handle the same number of users, which will cost carriers money. They're not affected by their users getting less battery life because most customers won't realise it's the carrier's fault, so why should they change anything?
Compared to the costs to carriers in implementing IPv6? That's nothing.
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?
well, ipv6 defines periodic router-advertisement messages that results in ipv6-hosts recomputing currently active parameters e.g. mtu, lifetime for link-prefixes etc. in the worst case, say when the ue is idle, this might result in paging, which in turn causes establishment of radio-bearers, moving ue from idle to active state etc. etc. which most definitely cannot be good for battery life.
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...
* 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...