

IPv6 can boost mobile performance, battery life - danyork
http://www.itworld.com/internet/335395/ipv6-can-boost-mobile-performance-battery-life-proponents-say

======
reirob
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...

~~~
macalicious
I'm actually more concerend about privacy. Now tracking a device is even
easier than before. No more downloading of illegal contents!

~~~
pilif
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

------
jackalope
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?

~~~
agwa
> 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.

------
agwa
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.

~~~
Aloisius
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).

~~~
agwa
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.

But maybe attackers just won't even try.

------
rlpb
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.

~~~
makomk
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?

~~~
rlpb
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?

------
signa11
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...

