No they don't. Classfull addressing was deprecated over 20 years ago. They may have a /16. (Obligatory wikipedia link https://en.wikipedia.org/wiki/...)

Excellent! This is the way it should be done (firewall part aside). A globally routable IP address per machine is the dream!

Reclaiming address space just isn't worth the time. At its peak, ARIN (the RIR for North America) was going through a /8 in a few months. These days there is a lot of buzz about 'The Internet of Things'. Whether you buy into all that or not, its just not possible to address every machine they are talking about out of the IPv4 address space.

They have contemplated doing things like making 240/4 routable, but it wouldn't last a year if allocations were allowed to run at the rate they would with no limitations. Reclaiming address space (even if they could) from organisations that 'don't need it' would give the Internet a year of growth at best.

There probably is a lot of waste in IPv4 address space, but we shouldn't be citing that as a reason not to change. At some point - even if we put in the effort to reclaim all the 'waste' - we are going to run out. Why spend all that energy reclaiming instead of just deploying v6?

I would not agree with you here. The motivation is a larger address pool.

This is a lot of rage. I'm clearly pro-IPv6. I'm aware of the limitations in address space in IPv4. I'm aware that IPv6 adds 96 more bits, and makes the space ridiculously large. My point was merely an observation on why the uptake has been slow. The ISP I work for is in the habit of making any new purchase or deploying anything new IPv6 capable. I think a lot of operators with clue are doing the same.

I don't think that you can disagree my point though? If IPv4 and IPv6 were able to interop, then uptake would have been much quicker.

Oh, and a lot of decisions made when IPv6 was being developed was around complexity. Routers were really starting to struggle around then. This was basically the reason that MPLS was created for. Hardware got quicker first though. Had IPv6 been developed 10 years later then a very different beast would have emerged. Hindsight is a wonderful thing though.

Exactly this.

The problem occurs when you have an IPv4 VPN tunnel, and IPv6 native connectivity. The IPv6 connectivity will be preferred over the IPv4 tunnel, and you will connect natively.

The fix? There are two

1) Add IPv6 support to the VPN, and default route traffic over that.
2) Drop the IPv6 connection while connected to the VPN.

The first solution is obviously best.

This sounds like you don't know what you are talking about. To start with, in IPv6 there is no broadcasting at all. Anywhere broadcast was used (eg ARP) this has been replaced with multicast. Announcing and autorouting? Not sure what you mean by this, but if its the router advertisements when using SLAAC then how is this different from IPv4 and DHCP? FYI this doesn't have to be turned on. From a pure routing point of view (I work for ISPs) it works no different than to IPv4. Address length aside of course.

As for empty colons... Are you writing addresses like 2001:db8::::::6? Sounds like you need to read an RFC. That can be written as 2001:db8::6. (Of course you can only truncate one set of colons, but there is only 7 maximum in total.

What is hard to secure about it? I would like some genuine details on this. I don't see where it is harder than IPv4 (address length aside)

The reason that it isn't widely deployed is simple. It is not backwards compatible. If the spec had been written so an IPv4 addressed machine could communicate with an IPv6 addressed machine without any of the hackery we are now looking at, we wouldn't be having this conversation. Unfortunately when the spec was written over 20 years ago routers were not that powerful, and they were trying to limit the amount of work they had to do.

True, SLAAC does require a /64 boundary. I would not recommend deploying anything other than that on a network. Android currently does have a problem. One of two things will happen.

1) Google will implement dhcpv6. There are 2 versions stateful, which works much the same as the v4 variant, and stateless, which is used to provide extra information like a DNS server when configuring via SLAAC.

2) everyone standardises on something else like RDNSS.

I predict that the first option will occur.

As for 'neat routing tables' there is no such thing. One aim was to reduce fragmentation, which it may do. People owning their own address space is not a big problem though.

Also IP addresses and AS numbers are not tied to a location. ISPs are already crossing international borders without any complaints. Move your prefix where you want to.

Please stop calling them 'private AS numbers'. They are a thing, but not what you are referring to. They are not routable on the internet. You just want a normal AS number. Same as everyone else.

Nonsense. Privacy extensions are enabled by default on all modern operating systems. And I'm even including windows XP in this! The general accepted policy is to provide a /56 or /48 per site. This should give you more than enough networks to stick to the recommended /64 boundary. Oh, also if you are a bit of a hippy, breaking a /64 down smaller is possible.

If you MUST have IP addresses that don't change, you can use NAPT. This is a 1:1 mapping of IPv6 addresses from global scope to local scope. If you don't want to do this, then tools will come along (or already exist!) to assist managing things like DNS, firewalls etc. At the end of the day, its only the first 64 bits that change. The last 4 stay the same, so worst case s/// would do the trick for most things.

I'm not sure where you heard this? Private ASs (private isn't even the correct term here. There is a range of 'private' AS numbers that are for use within a network) are not discouraged at all. If anything they are encouraged. (I'm in the RIPE region, my viewpoint is based on their policies)

If you want an AS number. Just apply.

You also don't require an AS number to have your own address space. There is a thing called Provider Independent space. Address space, but no AS number (I believe this is the route ARIN require you to take to get an AS number) Contact your local ISP, and ask them to help you out with that. You can then multihome with it, and even take it with you to a different ISP.

You are confusing a NAT with a firewall.

Today people buy, or get sent from their ISP a router with NAT and a firewall enabled. The NAT does the bodge for addresses. The firewall protects you. The default settings are a default deny inbound, and a reflective default accept outbound.

There is no reason why this couldn't be enabled on IPv6 by default also. This part works pretty much the same.

Jitter isn't caused by cables. Its caused by the devices either side.

Typically on switches or routers, where packets are received on two different interfaces, and need to be transmitted out a third. If two packets are received at the same time on the two ports, one of them must be queued while the other is being sent. This will introduce a small amount of jitter. This is magnified with a busier network, and is one of the things QoS tries to eliminate for certain traffic types (typically voice on enterprise/ISP networks).

The most a cable could really do is cause a packet to get mangled, and retransmitted. I suppose this could be viewed as introducing jitter, but its at a higher point up the stack at the application layer, rather than the network.

I find it amusing that the guy in this article completely glosses over the importance of the switches in his network. If he had any other traffic running over his network when performing his tests, they are pretty much invalid.

That's the kind of problem that would be easier to be fixed if the full source code was available to you. Cameras (among other things) tend to be a binary blob. Reading the associated bug, it actually appears to be the GPU driver that is out of date there.

The fact there are very few complaints is testament to it being able to run 4.4+.
(https://jira.cyanogenmod.org/browse/CYAN-1651?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22In%20Review%22%2C%20QA)%20AND%20text%20~%20%22maguro%22)

Typically in porting a device that hasn't been officially upgraded a replacement driver must be found that supports the new API calls. Often drivers from phones with similar hardware is pulled in, which obviously will never work quite too well. This was a big thing when going from 2.x->4,x as the camera interface changed massively.

Looking at the bug report, they expect that to be fixed when they move to CM12.

Why does it need to be in the 4.3 code base?

As previously mentioned, Android versions are not like Windows versions - ie a massively different OS. They are incremental, and especially with the recent versions don't require massive additional resources. The fix is to upgrade from 4.3 -> 4.4. The Galaxy Nexus is capable of running 4.4.

Your argument here should be 'Why is Google not releasing 4.4 for the Galaxy Nexus'. I could support that statement.

It is fixed. The fixed version just hasn't been released for the Galaxy Nexus...

My current phone has got updates from Kit Kat to Lollipop without a wipe and reinstallation. As have all my previous android phones from one version to another. I'm unsure what you are getting at here...

Not true. Google has a way to patch parts of the operating system on older versions using play services:

http://arstechnica.com/gadgets...

This seems a bit of an extreme reaction. They have released an update for your tablet (https://dl.google.com/dl/android/aosp/nakasi-lrx22g-factory-2291c36b.tgz) Have you contacted google for support about why the update it isn't working for you?

Except that google do support older devices in the form of Google Play Services. This provides the latest and greatest APIs as far back as gingerbread:
http://arstechnica.com/gadgets...

In fact many of Google's own apps are updated to use the material designs etc on Gingerbread devices:
http://arstechnica.com/gadgets...

All this should make it easier for the developer community to keep up with the newer API versions, and support the older ones.