Slashdot Mirror
IPv6 Turns 20, Reaches 10 Percent Deployment (arstechnica.com)
An anonymous reader writes: Ars notes that the RFC for IPv6 was published just over 20 years ago, and the protocol has finally reached the 10% deployment milestone. This is an increase from ~6% a year ago. (The percentage of users varies over time, peaking on the weekends when most people are at home instead of work.) "If a 67 percent increase per year is the new normal, it'll take until summer 2020 until the entire world has IPv6 and we can all stop slicing and dicing our diminishing stashes of IPv4 addresses."
"A decade or so ago, it was still quite common for people to complain about certain IPv6 features, and proclaim the protocol would never catch on. Although part of that can be blamed on the conservative nature of network administrators, it's true that adopting IPv6 requires abandoning some long standing IPv4 practices. For instance, with IPv4, it's common to use Network Address Translation (NAT) so multiple devices can share the use on an IPv4 address. IPv6 has more than enough addresses to give each device its own, so there's no NAT in IPv6. The Internet is probably better off without NAT and the complications that it adds, but without NAT as a first but relatively porous line of defense against random packets coming in from the open Internet, it's necessary to be much more deliberate about which types of packets to accept and which to reject."
"A decade or so ago, it was still quite common for people to complain about certain IPv6 features, and proclaim the protocol would never catch on. Although part of that can be blamed on the conservative nature of network administrators, it's true that adopting IPv6 requires abandoning some long standing IPv4 practices. For instance, with IPv4, it's common to use Network Address Translation (NAT) so multiple devices can share the use on an IPv4 address. IPv6 has more than enough addresses to give each device its own, so there's no NAT in IPv6. The Internet is probably better off without NAT and the complications that it adds, but without NAT as a first but relatively porous line of defense against random packets coming in from the open Internet, it's necessary to be much more deliberate about which types of packets to accept and which to reject."
without NAT as a first but relatively porous line of defense against random packets coming in from the open Internet, it's necessary to be much more deliberate about which types of packets to accept and which to reject.
What? If you want the same 'security' as NAT, can't you just set the firewall to reject all incoming connections?
"First they came for the slanderers and i said nothing."
ah, turning 20 and enjoying 10% recognition. reminds me of my youth. but seriously guys. theres no excuse other than laziness at this point. home docsis3 routers are dual stack, and hurricanes 6-2-4 gateways have done heavy lifting for a decade now. lets make 15% a 2016 resolution.
Good people go to bed earlier.
The chief infection vector these days is the web browser and add-ons. If a machine can connect to the Internet, even if behind seven layers of NAT, it can get infected. Second to that are Trojans and dancing bunny attacks.
Internet based attacks to compromise hosts are relatively few, and they tend to be brute force attempts, looking for older/patched bugs, or a DDoS. Good firewalls are a solved problem.
https://xkcd.com/865/
Most home users would be perfectly fine with a IPX connecting to a HTTP proxy. That doesn't mean it's a good idea.
IPv6 is a very different beast from IPv4. One of its strengths is also a weakness - NATless wide open host to host routing of traffic. This is great as long as everyone adequately protects their internal network from outside access. However, the vast majority of home and small business networks are hidden behind a consumer-grade NAT router. Given the low level of understanding of what's actually under the hood, IT people (and consumers) have been conditioned for years to believe anything plugged into the inside of their router is safe from outside access or discovery. It would seem to me that the safest thing would be to continue using IPv6's NAT feature for networks like this. Not many people understand what actually makes IP routing work at a nuts-and-bolts level, so this would be a safe default. 20 years ago, when IPv6 was new, I would have more faith that the average IT person would have a better grasp of details like this. These days, it's abstracted away for the most part. I doubt non-network focused IT people learn the stack to the same depth they had to in the past.
Even large enterprise networks I've seen implicitly trust traffic on the inside. Obviously that's not the best way to go, but re-architecting the network for trust-nothing operation is a slow process the larger the entity.
Trying to not support two things, is why cell phone companies are planning on going IPv6 with NAT64/DNS64. It is also why all iOS 9 apps must support IPv6. Thus approach allows them to optimise their infrastructure for IPv6 and only deal with IPv4 on the border.
Nothing is stopping anyone from staying IPv4 internally, but if you can't speak to that IPv6 service outside your network, then you'll look pretty stupid. At least get a web proxy, that deals with IPv6 externally, if you don't want to deal with the setup internally.
Jumpstart the tartan drive.
Also, while IPv4 is structured in a way that one can determine the netmasks and determine how it is structured, and easily deduce the number (or at least maximum number) of boxes on the subnet, that's not even possible in IPv6. Like if you have a network that has a subnet mask of 255.255.255.240, you know that there can be a max of 14 boxes on that subnet. In IPv6, all that is irrelevant: any subnet can have anywhere b/w 1 and 2^64 boxes: it's impossible to find out w/o port scans.
Also, unless someone uses some structure in assigning IPv6 addresses using DHCPv6, it is impossible to figure out individual addresses. And if they have privacy extensions, which is the equivalent of IPv4's dynamic addresses, that makes it even more impossible.
This makes me wonder how long until ISPs start wanting to phase out nat so they can better see the patterns of usage behind the router. If they can tell that you use your TV and iPad more than your laptop... well, there's gotta be someone who'd pay for that info.
Is that the metric that keeps IPv6 adaption capped?
I asked the owner of an ISP how he was going to deal with IPv6. His answer was, "Buy a lot of expensive hardware." That is the metric that keeps IPv6 adoption capped: people don't want to pay for new hardware.
"First they came for the slanderers and i said nothing."
NSA here. We want everyone to use IPV6 because it makes tracking everything down to your dog's internet enabled nipple piercing that much easier. So stop this nonsense about sticking with IPv4. Were watching you.
Restoring end to end for everyone is worth way more to continued freedom of Internet use than any NSA boogieman.
IPv6 privacy addresses are widely supported. Big data stalking firms currently have no problems discovering individual devices behind IPv4 NATs.
That's the reason that I've always believed that the /64 was a stupid boundary where to demarcate the Global Prefix and the Interface ID. It should have been at /96. The reason for the /64 was for easy autoconfiguration w/ SLAAC. But even w/ SLAAC, uniqueness is not guaranteed, and therefore, a lot of flexibility in IPv6 is sacrificed at the alter of autoconfiguration, resulting in an overkill when it comes to subnet sizes.
Instead, having a /96 would have enabled the internet to have had a hierarchical routing system, thereby lessening the need for things like RIPng, OSPG, EIGRP, et al. Also, RIRs, national Internet registries and ISPs could then have allotted Global prefixes up to /64 or /80, and we could have had either 16 bits of subnetting - allowing for 65,536 subnets or a full 32 bits of subnetting - allowing for a hierarchical subnet set-up.
Even w/ all this, 32 bits would have been adequate for autoconfiguration mechanisms. Yeah, it wouldn't be completely unique, but nothing is. Port scans would still be as slow as scanning the entire internet, but on top of that, privacy extensions, or allowing an address to change very frequently would make it even more impossible for port scans to determine internal network topologies. I do think something like this would have to be deployed to avoid runnning into address depletion issues even in IPv6 later.
Those are all excuses. None of that stuff needs to be touched to deploy v6. Deploying v6 won't make any of it work worse than it currently is. You don't need to upgrade all your DOCSIS1/2 modems to get v6 to the DOCSIS3 modems.
Also if you're an ISP that's been buying hardware in the past half a decade that's not v6 capable, then you screwed up -- or if your hardware is much older than that, then you're probably looking towards a replacement soon anyway.
Ignoring the (quite literal) network effects. When the tipping point comes, it'll go to 100% IPv6 very quickly. Everybody will be on IPv6 because that's where everybody else is. Nobody will want to be cut off by being on an IPv4-only address.
What's really sobering is when you look at relatively new but very successful FOSS ecosystems like that surrounding Docker, you'll see poor considerations for IPv6. If you're working on new bleeding edge stuff and you're still developing for an IPv4 world, you're needlessly wasting a huge opportunity to help the world move beyond IPv4. I really want to call out CoreOS's fleet project for using IPv4 private networks for cross-container communications where IPv6 would have been a much better fit.
My cell phone traffic has been IPv6 for years. Every time I watch a youtube video, piles of IPv6 traffic flow. A large amount of network traffic is now handheld related.
Is that the metric that keeps IPv6 adaption capped?
I asked the owner of an ISP how he was going to deal with IPv6. His answer was, "Buy a lot of expensive hardware." That is the metric that keeps IPv6 adoption capped: people don't want to pay for new hardware.
As someone who works for ISPs for a living, that is nonsense. Equipment generally has a lifetime that it is useful for. We typically buy kit with 5 years in mind, but may stretch it further if there is still life in it. Equipment that is 10 years old is probably worthless (This likely is the same for most other areas of IT)
Any equipment you buy today will support IPv6, with all the latest standards. Equipment generally gets firmware upgrades for the duration of its life that adds new features as they come along.
All Cisco and Juniper kit (2 big vendors in the ISP space) have had full feature sets for v6 in the service provider routed world for quite some time now. So long that some of their kit has gone end of life that have v6 support. There may be some enterprise grade products where this doesn't hold true, but it shouldn't be far off.
If your friend claims that the way he is going to deal with v6 is to buy more kit, he is either running outdated equipment, stupid, or lying.
The CPE is the only major space where there is issues. This is getting better now, and the same 5 year rule generally applies here to ageing equipment. You have the luxury of a phased replacement plan in this space too, which makes things a bit simpler.
Not giving everyone a /48 is a daft argument. From someone who is a lot smarter than me source
"Let’s assume that ISPs come in essentially 3 flavors. MEGA (The Verizons, AT&Ts, Comcasts, etc. of the world) having more than 5 million customers, LARGE (having between 100,000and 5 million customers) and SMALL (having fewer than 100,000 customers).
Let’s assume the worst possible splits and add 1 nibble to the minimum needed for each ISP and another nibble for overhead.
Further, let’s assume that 7 billion people on earth all live in individual households and that each of them runs their own small business bringing the total customer base worldwide to 14 billion.
If everyone subscribes to a MEGA and each MEGA serves 5 million customers, we need 2,800 MEGA ISPs. Each of those will need 5,000,000 /48s which would require a /24. Let’s give each of those an additional 8 bits for overhead and bad splits and say each of them gets a /16. That’s 2,800 out of /16s and we’ve served every customer on the planet with a lot of extra overhead, using approximately 4% of the address space.
65,536
Now, let’s make another copy of earth and serve everyone on a LARGE ISP with only 100,000 customers each. This requires 140,000 LARGE ISPs each of whom will need a /28 (100,000 /48s doesn’t fit in a /32, so we bump them up to /28). Adding in bad splits and overhead at a nibble each, we give each of them a /20. 140,000 /20s out of 1,048,576 total of which we used 44,800 for the MEGA ISPS leaves us with 863,776 /20s still available. We’ve now managed to burn approximately 18% of the total address space and we’ve served the entire world twice.
Finally, let us serve every customer in the world using a small ISP. Let’s assume that each small ISP only serves about 5,000 customers. For 5,000 customers, we would need a /32. Backing that off two nibbles for bad splits and overhead, we give each one a /24.
This will require 2,800,000 /24s. (I realize lots of ISPs server fewer than 5,000 customers, but those ISPs also don’t serve a total of 14 billion end sites,
so I think in terms of averages, this is not an unreasonable place to throw the dart).
There are 16,777,216 /24s in total, but we’ve already used 2,956,800 for the MEGA and LARGE ISPs, bringing our total utilization to 5,756,800 /24s.
We have now built three complete copies of the internet with some really huge assumptions about number of households and businesses added in and we still have only used roughly 34% of the total address space, including nibble boundary round-ups and everything else."
They can already see that information with DPI (Deep packet inspection) and many already do monetize it.
In the very worst case, the ISP gives you a /64 which is enough to support every possible ethernet address 64K times over.