"the world is out of IPv4 addresses" should really be written "the world if out of FREE IPv4 addresses".
I wish the IPv6 promotion pieces would include that because when I read news articles about this (or someone tells me there are no more IPv4 addresses) they always include this statement that you can't get IPv4 addresses anymore and so things like new services can only use IPv6.
One could replace "the world is out of IPv4 addresses" with "Internet Assigned Numbers Authority that oversees global IP address allocations is out of IPv4 addresses and is not giving out any more". The question is how many would know the difference between those two statements. Is the distinction between an independent ipv4 address allocation and an ipv4 address allocation something which news articles should highlight in this kind of articles in order the explain that one can buy independent ipv4 address from IPv4 brokers but it has nothing to do with IANA (mostly, further details need to be used in order to correctly make that statement).
> "the world is out of IPv4 addresses" should really be written "the world if out of FREE IPv4 addresses".
That is true of almost everything. Endangered species could be brought back by a trillionaire willing to invest in cloning technology and large land reserves. We can make more helium if we had a do-or-die mandate and sufficient fusion tech. We won't run out of oil as long as we have the ability to manufacture more.
Nothing ever really goes away. But very often, scarcity increases the amount of resources (typically of the monetary sort) required to acquire more of it.
Annoyingly the support for IPv6 isn’t everywhere yet. One of my remote colleagues got assigned one and GCP doesn’t support whitelisting of IPv6 addresses in their VPC network firewall so we had to resort to using our flaky VPN connection in the meantime.
Large cloud vendors can absorb cost of the IPv4 on the secondary market, and thus aren't i rush to deploy IPv6. In fact that creates kind of vendor lock-in.
maybe most facebook visits are from mobile and that mobile providers are more likely to have IP scracity issues (my speculation based on the fact that mobile providers tend to do CGNAT more than residential providers).
The article mentions several factors that seem relevant. Mobile carriers are moving to 100% IPv6 quite rapidly. Facebook doesn't see as much Enterprise traffic, which does seem to be where the biggest lag is (and also why every IPv6 chart has a nights and weekends sawtooth pattern).
"Enterprise" seems to have really embraced the "it's not broken it's compliant" mentality, it's much easier to tell employees "Company policy doesn't allow that" than make any improvements.
We have been here before, it's how the PC got started. Company policy said you couldn't have $14 of mainframe time to save six of your team working it out on calculators over several hours, so you bought a PC with 1-2-3 instead.
It's a version of Newton's First Law of Motion, as much as anything. "A corporation at rest will remain at rest unless acted upon by some outside unbalanced force."
Apple adopted the policy to force all developers to keep in mind IPv6-only networks, because Apple was given a mandate by several mobile carriers (ISPs) that they needed to support IPv6-only networks.
Facebook's article here even mentions that mobile carriers are well on their way to their planned 100% IPv6-only networks. (T-Mobile is at 90% IPv6 traffic.)
I messed around with IPv6 on Comcast for a while. They claim very high levels of residential deployment, yet when you head to their forums to troubleshoot it, their top IPv6 agent--who seems to know his stuff--generally comes back with things like "yes, that is broken," or "we're still working on a fix for that."
I'm using IPv6 on Centurylink who don't even deploy IPv6 by default (they have a 6RD server but their default modem/router config doesn't use it and you have to dig on their site to find it) and IME after configuring 6RD on my modem IPv6 "just works" for both incoming and outgoing connections. I'd be surprised if Comcast weren't at least as good as Centurylink.
I had problems with Ubuntu updates hanging and the fix was to do something that (I think) caused networking to prefer IPV4. I'm on Comcast but don't know if the problem was theirs. If networking preferred IPV6 prior to the change and only one site gave trouble, I'd be inclined to blame something specific to that site or the route involved.
I've had Comcasst IPv6 for the last few years, none of the issues I've encountered with IPv6 were Comcast's fault. What sort of problems did you encounter?
I have a Comcast business account. I've had an IPv6 address for a few years, and generally, it has worked exactly as expected. I've had two outages that are notable:
1. an outage where v6 traffic was just dropped, period. It took a service call, but was fixed within a day, IIRC. It was no more or less painful than any other service call.
2. an outage where v4 TCP SYNs were dropped, mostly; once a connection was established, the connection was fine. AFAICT, this was some issue, perhaps HW failure, with their modem/router combo. Once the router was replaced, the issue was fixed. This took several days to correct, mostly because it was difficult to convince Comcast's techs that the physical copper cable is probably not discriminating against IPv4 traffic.
My experience w/ their business division is that the support agents have some light experience. My experience w/ their residential side is that the support agents have never seen a computer.
The rollout to business was after the rollout to residential; I also filled out a form requesting one way back in the day when they were essentially polling for interest.
> This took several days to correct, mostly because it was difficult to convince Comcast's techs that the physical copper cable is probably not discriminating against IPv4 traffic.
I'm torn between laughter and intense anguish. I'm afraid to even estimate how many days of my life have been spent honing my rhetorical skills to convince a support agent of similar points.
Right. Last I checked (business), with a static IPv4...
IPv6 worked with one of the four available modems. If you had that one modem, you got dynamic IPv6, static wasn't supported.
With your dynamic IPv6, you then had to modify your SLAAC(?) / DHCPv6 because of an incongruity between what the modem was saying, and what would work (I believe it said you had a /56, but you could only advertise a /64 internally).
I really wish IPv6 had a better argument than you can't get IPv4 addresses needed to build a complex application.
The majority of complex applications being built today are being built to be IPv4 accessible and may even be using IPv4.
You can use 17 million private addresses + buy plenty of public IPv4 addresses.
AWS and Google are both building major clouds that are both complex and STILL heavily IPv4 oriented (I and others pinging them to add IPv6 for a long time).
They throw in an IPv4 for every running instance and even their elastic IPv4's are cheap if attached to an instance.
That decision should be taken by filtering (or just preventing it altogether) in each specific case. With dynamic IPs, it's already a no from the start.
We actually do want that especially for the internet of things, so that your lights and garage door keep functioning during an AWS outage that takes out the relay servers (used to work around NAT) or if the manufacturer goes out of business.
Every six months, I enable dualstack on my laptop and router. The last time was maybe a month ago.
It's still not there. The experience of my daily use of the internet is vastly better with ipv6 off. There are just too many sites that answer with an ipv6 address and then fail to work, and I have to wait for the system to fall back to ipv4. At the same time, I've yet to find a single site I want to get to that isn't available on ipv4, nor any site that offers a noticeably better experience over ipv6.
Edit: Amusingly I was down voted for stating my opinion on my own ipv6 experience. No one likes the truth I guess?
People downvote for all kinds of stupid reasons here. I think one of my comments was literally just describing how some technology worked, and that got downvoted.
It would make much more sense to provide some sort of useful feedback with a vote, such as Needs Citation, Uncivil, Not Relevant, etc. Once a commenter knew why others are apparently mad at them or disagree with them, they could actually modify their comment or behavior appropriately, rather than just be shamed with gray text. I've been asking for this feature for like 5 years.
Possibly because 'too many sites that answer with an ipv6 address and then fail to work, and I have to wait for the system to fall back to ipv4' is a complaint from 2012 or so? rfc 6555 is hardly new.
and i've seen an ipv6-supporting webapp work substantially better for video chatting (no STUN/TURN/relaying), although to be fair i was working on it.
My home network runs all of the /64 from my ISP behind a stateful firewall, and I expect this is true of others; just because you have a publicly routeable address doesn't mean you will receive packets.
Do you have an example site? I use dualstack everywhere and I haven't seen the behavior you describe.
The only problem I've hit is sites with broken PMTU detection, but that's a problem that exists in v4 too and which needs to be worked around there in exactly the same manner, so it's not exactly a v6 problem.
Perhaps, but it turns out not to be possible to extend v4 without producing something that looks like v6. You can only fit 32 bits into the dest address field in the v4 header, and any attempt at working around that problem ends up looking like v6 plus one of the existing transition methods (NAT64/6to4/Teredo/etc).
If the biggest problem in v6 is one that fundamentally can't be fixed, then I think we did pretty good.
For the most common purposes, IPv6 is IPv4 modified with a bigger address space. It turns out that deploying anything other than IPv4 is a major PITA, and a stripped down IPv4++ that changed nothing but the address length would be pretty much just as hard to start up as IPv6 has been.
There are far more similarities than there are differences though, and many of the differences are simply direct consequences of expanding the address space.
Uhm no. Look at that chart in the article I linked. That is a lot of changes that are functional and not just the address size changed. NAT comes up a lot and that is a major change.
My question is pretty simple. Why the heck did someone think all the changes were a good idea?
I did. A good chunk of that chart (addresses, DNS, autoconfig, ARP/NDP, IGMP/MLD) is a result of changing the address size. Some parts of it are incorrect (IPsec) or aren't a difference (multicast). Many of the parts that are left don't seem like a big deal (minimum MTU increase from 576 bytes to 1280 bytes should be trivial, especially since 99.9% of people use 1500 bytes via PMTUD anyway).
NAT isn't even a part of v4 in the first place, it's an additional thing that you bolt onto the side to try and deal with not having sufficient address space for your network. Since in v6 you generally do have enough space, you simply don't need to do that -- which is good, because NAT complicates your network and makes it harder to reason about the behavior.
Erm ... you are aware that NAT is not a function of IPv4, right? That IPv4 worked completely without NAT for the first one and a half decades or so? That NAT was invented later as a workaround for the lack of addresses?
IPv6 works exactly like IPv4 in this regard, it's just that you have enough addresses, so you obviously don't continue the workaround for a problem that you don't have anymore, but operate IPv6 networks exactly the same way you would operate IPv4 networks if it weren't for the lack of adresses.
It is probably a good an example of the "second system effect" [1] where developers were given an opportunity to go back and fix the problems they saw in IPv4. Some obvious examples:
- IPv4 options are too inflexible, lets provide IPv6 with extension headers instead.
- IPv4 ARP broadcasts are inefficient, lets use multicasts for IPv6 neighbor discovery instead.
I've been working with IPv6 off and on since 2004. It's great to see progress, but I'm ready for a bigger momentum shift in the US. Even with the major ISPs onboard and support appearing in the cloud, it's hard to imagine widespread adoption when consumer and SOHO network device makers are doing so little to bring the necessary tools to end-users.
Part of my business is focused on providing privacy and security consulting to small businesses and self-employed professionals. I've spent a good chunk of time researching suitable network devices for this audience, and it seems that IPv6 isn't even on the minds of many device makers (can't resist calling out Cisco, who has been nearly silent on their plans for IPv6 in their Meraki line).
As a side note, I am a bit concerned about the day that these same device makers start to enable support. Given the role of NAT as the gatekeeper of so many small network devices, I expect we'll see more than a couple stories about inadequate firewall rules exposing home networks via IPv6.
54 comments
[ 3.1 ms ] story [ 111 ms ] threadI wish the IPv6 promotion pieces would include that because when I read news articles about this (or someone tells me there are no more IPv4 addresses) they always include this statement that you can't get IPv4 addresses anymore and so things like new services can only use IPv6.
Fixed that for you.
That is true of almost everything. Endangered species could be brought back by a trillionaire willing to invest in cloning technology and large land reserves. We can make more helium if we had a do-or-die mandate and sufficient fusion tech. We won't run out of oil as long as we have the ability to manufacture more.
Nothing ever really goes away. But very often, scarcity increases the amount of resources (typically of the monetary sort) required to acquire more of it.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Maybe the Facebook app is more aggressive in steering towards IPv6 than browsers.
We have been here before, it's how the PC got started. Company policy said you couldn't have $14 of mainframe time to save six of your team working it out on calculators over several hours, so you bought a PC with 1-2-3 instead.
https://developer.apple.com/support/ipv6/
Apple adopted the policy to force all developers to keep in mind IPv6-only networks, because Apple was given a mandate by several mobile carriers (ISPs) that they needed to support IPv6-only networks.
Facebook's article here even mentions that mobile carriers are well on their way to their planned 100% IPv6-only networks. (T-Mobile is at 90% IPv6 traffic.)
Years later, still no fix.
1. an outage where v6 traffic was just dropped, period. It took a service call, but was fixed within a day, IIRC. It was no more or less painful than any other service call.
2. an outage where v4 TCP SYNs were dropped, mostly; once a connection was established, the connection was fine. AFAICT, this was some issue, perhaps HW failure, with their modem/router combo. Once the router was replaced, the issue was fixed. This took several days to correct, mostly because it was difficult to convince Comcast's techs that the physical copper cable is probably not discriminating against IPv4 traffic.
My experience w/ their business division is that the support agents have some light experience. My experience w/ their residential side is that the support agents have never seen a computer.
The rollout to business was after the rollout to residential; I also filled out a form requesting one way back in the day when they were essentially polling for interest.
I'm torn between laughter and intense anguish. I'm afraid to even estimate how many days of my life have been spent honing my rhetorical skills to convince a support agent of similar points.
IPv6 worked with one of the four available modems. If you had that one modem, you got dynamic IPv6, static wasn't supported.
With your dynamic IPv6, you then had to modify your SLAAC(?) / DHCPv6 because of an incongruity between what the modem was saying, and what would work (I believe it said you had a /56, but you could only advertise a /64 internally).
And so on.
It is amazingly sad how little works with IPv6 only. Today, in 2018. (Hello, Microsoft/GitHub, here is a low hanging fruit to appeal to developers)
Also why would ipv6 appeal to developers? What do I care if GitHub supports ipv6 or not?
You care because you may need various IPs when doing complex applications; which you can't have right now because of IPv4 exhaustion
The majority of complex applications being built today are being built to be IPv4 accessible and may even be using IPv4.
You can use 17 million private addresses + buy plenty of public IPv4 addresses.
AWS and Google are both building major clouds that are both complex and STILL heavily IPv4 oriented (I and others pinging them to add IPv6 for a long time).
They throw in an IPv4 for every running instance and even their elastic IPv4's are cheap if attached to an instance.
My Chrome extension lets you see IPv6 usage in a bit more detail: https://github.com/pmarks-net/ipvfoo
It's still not there. The experience of my daily use of the internet is vastly better with ipv6 off. There are just too many sites that answer with an ipv6 address and then fail to work, and I have to wait for the system to fall back to ipv4. At the same time, I've yet to find a single site I want to get to that isn't available on ipv4, nor any site that offers a noticeably better experience over ipv6.
Edit: Amusingly I was down voted for stating my opinion on my own ipv6 experience. No one likes the truth I guess?
It would make much more sense to provide some sort of useful feedback with a vote, such as Needs Citation, Uncivil, Not Relevant, etc. Once a commenter knew why others are apparently mad at them or disagree with them, they could actually modify their comment or behavior appropriately, rather than just be shamed with gray text. I've been asking for this feature for like 5 years.
and i've seen an ipv6-supporting webapp work substantially better for video chatting (no STUN/TURN/relaying), although to be fair i was working on it.
The only problem I've hit is sites with broken PMTU detection, but that's a problem that exists in v4 too and which needs to be worked around there in exactly the same manner, so it's not exactly a v6 problem.
If the biggest problem in v6 is one that fundamentally can't be fixed, then I think we did pretty good.
My question is pretty simple. Why the heck did someone think all the changes were a good idea?
NAT isn't even a part of v4 in the first place, it's an additional thing that you bolt onto the side to try and deal with not having sufficient address space for your network. Since in v6 you generally do have enough space, you simply don't need to do that -- which is good, because NAT complicates your network and makes it harder to reason about the behavior.
Erm ... you are aware that NAT is not a function of IPv4, right? That IPv4 worked completely without NAT for the first one and a half decades or so? That NAT was invented later as a workaround for the lack of addresses?
IPv6 works exactly like IPv4 in this regard, it's just that you have enough addresses, so you obviously don't continue the workaround for a problem that you don't have anymore, but operate IPv6 networks exactly the same way you would operate IPv4 networks if it weren't for the lack of adresses.
- IPv4 options are too inflexible, lets provide IPv6 with extension headers instead.
- IPv4 ARP broadcasts are inefficient, lets use multicasts for IPv6 neighbor discovery instead.
1: https://en.wikipedia.org/wiki/Second-system_effect
Part of my business is focused on providing privacy and security consulting to small businesses and self-employed professionals. I've spent a good chunk of time researching suitable network devices for this audience, and it seems that IPv6 isn't even on the minds of many device makers (can't resist calling out Cisco, who has been nearly silent on their plans for IPv6 in their Meraki line).
As a side note, I am a bit concerned about the day that these same device makers start to enable support. Given the role of NAT as the gatekeeper of so many small network devices, I expect we'll see more than a couple stories about inadequate firewall rules exposing home networks via IPv6.