It's already happening. It's not completed, and it will take time for publicly available services.
At some point having IP4 on your public gateways will be seen like FAX in your office. You can't turn it off because a small minority is still using it. The importance is dwindling and at some point you will turn it off and nobody will notice.
IPv6's share of traffic has been increasing at about 0.5% per month for the past year. If IPv4 has 80% and IPv6 20% this month, next month it'll be 79.5 vs 20.5. So in your opinion... what? The change will stop? When? Why?
Sure, I am a RIPE member and am leasing out IPv4 (and IPv6) address space, ASN registrations, etc.
Everyone is able to sign up with RIPE and get a /22, thats around 1000 IP addresses. For years the RIRs want to tell us that IP addresses run out but I am still able, today, to pay some bucks and get IPv4 addresses without issues. The issue was that exactly those RIRs handed out IPv4 addresses years ago like there is no tomorrow and now they want us to switch to a broken protocol because they made a huge mistake. I won't deny that we are months (around 2 years) away from the RIPE actually running out of IPs.
Part of my job leasing out IPv4 space is also monitoring different sources, like Spamhaus, if my client or client of clients send spam with my IPs. What I can tell you is that with IPv4 already this is messy but if I think about IPv6 this is impossible to track or control and a complete nightmare. Also, for example if you operate a mail server that only runs IPv6 and send emails to gmail they will outright block you or just send it to the spam folder. Please note that this is only one of many examples.
Apart from that, if I look at the implementation of cloud providers like DO, Linode, OVH, Scaleway, etc. this is all a big joke. Also, IPv6 routes from some tier 1 upstream to others are down for days without anyone noticing it, because most people want IPv6, but no one is actually using it. It's like having a todo list and IPv6 is done but how it's been implemented doesn't matter at all.
You should also be careful with statistics, as a lot of scammers switched to IPv6 so I would not be surprised if a lot of the "IPv6 market share" is from scammers.
1) Not everyone can sign up with RIPE. We have tried multiple times and been rejected despite being connected to backbone and having peering agreements and AS number.
2) Why track IP addresses instead of mandating DKIM? Gmail eats valid IPv6 sourced mail with good DKIM keys no problem.
3) Same can be said about IPv4 routes. Remember nobody really uses IP directly to route nowadays...
I think some hosting providers are wasting a bit of the address space. For an example I have 15 linodes each with their own public IP, but I actually only need one or two of the IPs to be accessed publicly for the loadbalancers, the rest I actually prefer not to be routable from the public.
I feel like AWS and the Cloud in general have to be helping with this issue, because people no longer need to lock down individual IPs or ranges of IPs to get work done. Without the need to lock down an IP that you may or may not need to use, and with load-balancers that are able to expose boxes on a private subnet, the demand for IPv4 should be going down.
I actually disagree on this point. The rapid deployment and horizontal scaling that cloud recommends implicitly (failure domains, microservices as small isolated single purpose units et al.) also promote the consumption of IPv4 address space.
The other thing is Docker and Kubernetes are not supporting IPv6 today so that definitely locks a lot of the more modern cloud deployments to IPv4, even if it's S2S communication which could have been IPv6 only (since you would control both ends) otherwise... so that's another thing.
However, new network layer technologies like "Layer-3 all the way to the server" are allowing providers to use their entire IPv4 allocation by having BGP pushing /32 routes internally and this has been the biggest helper in my opinion, no longer do you have a static /24 allocation and a bunch of dead space that can't be freed easily.
Of course people who are new to OPs/Dev haven't really seen this much- but I would probably venture more than 50% of ipv4 space is locked into allocations that are mostly empty.
-- I also think there is still an increasing population of internet users and VPS/Cloud providers give a cheap and easy way to be online too.. $5 for a VPS in most cases.
You just get given some 10.x space anyway. It only really bites you on the ass when you need to exchange traffic between hosting providers and that can generally be done although you may have to find a middle man in some cases.
> I actually disagree on this point. The rapid deployment and horizontal scaling that cloud recommends implicitly (failure domains, microservices as small isolated single purpose units et al.) also promote the consumption of IPv4 address space.
Nothing but the external entry points in a cloud need to be publicly accessible IPv4.
That is if the number of Internet users don't grow and since it is so easy to spin up an instance even for just $5 a month these days, many people are rather willing to spin up more than they would have physically to use more IPv4 addresses.
But seeing how attaching an extra IP to an instance is so cheap everywhere, it seems there's no immediate threat to lack of address spaces but I'd like to know about a proper research.
new techniques such as SNI [0] enable more websites to be hosted behind the same IP. I do not know what it means for security or if there are any major trade offs, but I am acutely aware that it is widely used.
I don't see an answer to 'how bad' in the article. I thought I'll get some recent numbers but instead i got... some generic text that was valid even 3 years ago?
There has been an answer to your question in this thread for 14 minutes. However only users with showdead on can see it, because Arc has erroneously flagged it as evil. Screenshot/proof of what I currently see: https://i.imgur.com/Y7iM30E.png
HN does get spam, but the text and links don't look like the currently-buried comment does. I can't see it being /that/ hard to train an RNN, what with this being a comp-sci discussion forum...
--
Oh, about the bar being brown/black in my screenshot - I set the bar color to that of the upvote/karma text, as I don't care to see that information (I start commenting for points, not to contribute meaningfully - it's true). Unfortunately Arc doesn't realize it should make the color of the links lighter so I can see them, so I've had to work hard to learn where the "threads" link is sitting so I can access comment replies.
Bit inconsistent letting me change the background color but not the text color. I can understand it, but still. Getting to the root cause, it would be nice to have an option to completely disable karma score display.
Depends on the karma you have, but if you click on the time stamp, there is a vouch link there. I just did, and it does not show as dead any more on my end, so hopefully people can see it now.
Don't you have enough karma to vouch/favorite that comment? I just did. Usually there's a reason why the comment is automatically flagged so don't agree with your assessment.
My ISP doesn't support IPv6 and it's been complicated to get IPv6 running properly at my hosting providers too. My hosting provider uses DHCP to propagate routing information, and I had a lot of issue with it going down, thus losing IPv6 connectivity. In the end I just disabled IPv6 on all the node I manage, it has no benefit except increased complexity.
The problem is the lack of insensitive to do the conversion.
This sounds more like poor DHCP configuration on your side? DHCP going down doesn't remove anything unless your client decides to time out it's current address configuration - of which there's no incentive to do on a server.
Moreover if routing was being propagated by DHCP, why was that not the case for IPv4 as well which would presumably be using it ?
DHCPv4 and DHCPv6 are different (they even run on different ports) and probably they have more experience with monitoring and operating DHCPv4.
Honestly I think the fundamental mistake of IPv6 was trying to fix everything else along the way. Certainly there are things that can be fixed in DHCPv4. But there isn't a way to put off that operational work until you're ready to get good at it; there is no way to just get more addresses and not also sign up to run a new version of DHCP, to decide if you even want DHCPv6 or you want RAs and SLAAC, to give up ARP, etc. It's a big lesson in the second system effect.
As I understand it, ARP is abstraction-breaking and hard-codes that IP is running on top of Ethernet or something Ethernet-compatible - you're sending Ethernet packets (with a non-IP EtherType) that reference IP and an IP address, initially over Ethernet broadcast. NDP runs over ICMPv6, which is an IP protocol, and the way it works is that it's sent to well-known IPv6 multicast addresses, ff02::1 for all nodes or ff02::2 for all routers. If you're a node and/or a router, you join those multicast groups. So there's no assumption of Ethernet; that just depends on some link layer with a working multicast. (And broadcast is a perfectly legal implementation of multicast, although if your layer 2 protocol makes it easy to do a better implementation, great.)
Also, there's some multicast fanciness so you join a multicast group based on some hash of your IP address so that NDP packets don't even go to all machines, but just some hash bucket that contains that IP address.
(I think these are good reasons to make a successor to ARP, but I don't think these are good reasons to require that you use the successor protocol if you don't want to NAT, especially given the extent to which deployed networking gear does ARP snooping and IGMP snooping - and does not expect a pile of multicast groups.)
That's what I thought too, I really tried a lot of configuration client side, on different OS (linux, bsd...), but none was working reliably, even the provider preconfigured linux image. It might be client that are all broken or something else, to be honest I didn't investigate it further, as I don't need IPv6, I just wanted to be "ready" for the future.
I actually tell my ISP when they call me to upgrade that I will not upgrade to a higher package unless that package has IPv6 enabled. I am probably the only person who does this.
What I did instead was set up a HE.net tunnel so I can actually have IPv6 (albeit with a smaller MTU, but you're unlikely to notice). What I gain is the ability to run my own little services at home again, no NAT punching! no complicated rules.. I have a salt master that connects to my IPV6 enabled VPS' (which is all of them, thankfully), I have all my mail listening on VPS's with IPv4 and IPv6 which take in my mail and deliver it to a harddisk at my house essentially. Anything S2S can happen directly.. and it's nicer even on IPv6 enabled networks that I happen to be on when travelling (Mobile operators are increasingly IPv6)..
But it's unreliable to be IPv6 only, I can only access my home from other wifi networks at a ratio of about 1:20..
But I long for the day where it's ubiquitous and I can shit on wifi operators for not supporting it.. that day will come.
I mean last year IPv6 adoption more than doubled and is sitting at around 22%~ of all traffic.. so that's something.
This is off topic, but I make heavy use of “Reader Mode” in mobile Safari, as well as the embedded “Mercury Reader” in the “Reeder” app. These both do a great job of cutting out the junk on annoying sites, and I’d recommend investigating whether similar utilities exist for your platform of choice.
We should add another 4 bytes to IPv4 which is the internal IP, then AWS f.ex. would only have one public IP per region and the rest would be internal IPs.
If I understand what you're suggesting, this is basically how NAT64 [0] works to provide backwards compatibility to IPv6 (tunneling IPv4 over IPv6). It uses the first 32 bytes of the IPv6 address to store the IPv4 value.
Pedantic comment here, but NAT64 doesn’t involve any tunneling - it’s pure address translation handled by an edge box, whereas tunneling involves encapsulation.
Although there is technically no packet-level encapsulation, from a mathematical perspective you may consider the IPv4 bits "encapsulated" within the IPv6 bits.
Every time there's a discussion about IPv6, a suggestion like that appears, without fail. Paraphrasing the classic spamsolutions.txt, "Your idea will not work. Here is why it won't work."
"Requires immediate total cooperation from everybody at once": every single system which wanted to talk to an AWS host would have to implement that IPv4 extension.
"Many server administrators cannot afford to lose business or alienate potential clients": for anyone with a non-upgraded system, the server would be unreachable.
Specifically, your plan fails to account for:
- Lack of centrally controlling authority for networking
- Huge existing software investment in IPv4
- Popularity of NAT and other middleboxes
- Users who don't update their operating system ever
and the following philosophical objections may also apply:
- Ideas similar to yours are easy to come up with, yet none have ever been shown practical
- It will work for a while and then we'll get stuck with it
- It's an ugly hack
"Sorry dude, but I don't think it would work."
(I apologize for choosing your comment for this, but this idea of applying the spamsolutions.txt format to the inevitable "extended IPv4" proposals has been in my head for a long time. Someone with more networking experience should be able to present an even more complete list of "extended IPv4 objections".)
Nothing is going to change unless there is a real issue by not having ip v6 which will force users to jump to the ISPs which do support it and abandon the ones who don't.
My understanding is that there is a real cost for ISPs to make IP v6 available, but zero need to (upgrade of thousands of pieces of hardware equipment - is that still true?). There is no consequences for not doing so.
I had read that cellular carriers were pushing to be able to just use IPv6. I know Apple has really emphasized IPv6 compatibility with App Store apps for at least a few years now.
That's one of the things I've been watching. Theoretically, the easiest switchover should be consumer iPhones on cellular data networks, because any app released in the last few years should work on them.
Google was incorporated in September 1998. RFC 2640 was published in December 1998. Google's IPv6 tracker [1] has ~20% of their traffic coming in as IPv6. In the time that it's taken for Google to become one of the largest companies in the world, IPv6 is still uncommon.
Hypothesis: Mass adoption of IPv6 is blocked by the ugliness/inconvenience of the IPv6 address format, hence "end-users" (developers) don't like adopting IPv6. As long as this UX issue does not get solved, IPv6 adoption is only going to happen on an individual level when any given business' significant income stream is at immediate risk of being disrupted. Depending on how many of these individually affected businesses represent major infrastructure providers (such as public clouds), the individual moves to IPv6 might together bring about a globally noticeable effect.
---
Who here actually feels any sort of pain, as an internet technologist, or as business owner, from "still" being on IPv4? I know that I do not.
I work for an ISP so I have some perspective on this issue. We do offer static IPv6 addresses to our customers, but only upon request (by default they get one static IPv4).
If we had demand for it, I'm pretty sure we'd start including an IPv6 subnet by default. It doesn't cost us much, it's just more bookkeeping really. If anything, it could be a turn-off to our customers who might not be used to configuring their router with an IPv6 subnet (the 'ugliness' problem you're talking about, but also just unfamiliarity).
I think IPv6 adoption will happen when cloud providers start running out of IPv4 space. If AWS has to drastically raise its prices for IPs, or simply announces they're running out, then AWS customers will have to start evangelizing IPv6 to their own customer bases.
Eventually an IT guy in an office says, "I heard Slack is only going to support IPv6 soon, we need it!". So the ISPs start doing it.
the 'dotted quad' format was 'good enough' from a UI perspective (and... fitting in peoples' brains for short term). had we added one or two more spaces - and default all existing addresses to 0.0.x.x.x.x, we'd have had 65000 more blocks of 4 gig spaces. That should have been enough for most countries to have allocated enough space, while making the transition and UI upgrades pretty painless. If there's only a x.x.x.x address, assume leading zeros, and so on.
it's "failing" for a number of reasons - the UI and mental map model is certainly a stumbling block, but it's also something which requires coordinated effort between multiple parties to happen more or less at the same time. If it doesn't (and it didn't), it'll take years more for all players to get in sync, which is what we're seeing.
Residential ISP companies didn't have much incentive to upgrade when everyone's OS didn't include IPv6 stack. Not much push to try to upgrade your OS when your modem and ISP don't support it. Not much use to try to support it on your websites and email servers when no one is using it or asking for it.... and so on.
As all the pieces fall in to place - hardware, ISP, OS, web/mail/services - it'll still be a gradual move, unless some major players announce IPv6 only service. If Office365 was "IPv6 only in 2020", that might motivate a lot of orgs to push their IT/ISP to upgrade and migrate.
> As all the pieces fall in to place - hardware, ISP, OS, web/mail/services - it'll still be a gradual move, unless some major players announce IPv6 only service. If Office365 was "IPv6 only in 2020", that might motivate a lot of orgs to push their IT/ISP to upgrade and migrate.
It doesn't even need to be that drastic. Apple, Google, and Microsoft could just check for IPv6 when connecting to a network. If it's missing, display some kind of alert saying, "This internet connection is malfunctioning, please contact (lookup service number based on the IP address.)"
Constantly showing that nag will put a lot of pressure on major ISPs like Comcast.
Yes, Comcast has made, relatively speaking, amazing progress on deploying IPv6 across their network. It works very well (well, except if you have one of their business "routers" required if you need a static IPv4 address). This is a stark contrast of, say, Verizon Fios, who has yet to deploy ANY IPv6 across their network.
I don't know. IPv6 is ugly, yeah, but not any more ugly than other long random strings that we just copy-paste all the time, like API keys. For me, not adopting IPv6 has these reasons:
* My home and small business Internet provider does not support IPv6, despite them talking about deploying it for about 10 years now. Actually here in the Netherlands I have never encountered a mainstream consumer ISP that supports IPv6.
* I don't have any users that are on exclusively on IPv6. All my users have access to IPv4.
* IPv6 does not bring me any visible benefits, like faster performance.
Sure, the IPv6 address of my server (vsza.hu) is 2a01:270:2016::1, which is 2-A-0-1-colon-2-7-0-colon-2-0-1-6-double-colon-1 over the phone. Many people seem to forget that leading zeroes within 16-bit groups and one contiguous block of zeroes can be omitted.
"Sir, please type this into your browser to get to the router web interface: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. I repeat 2001:0db8:85a3:0000:0000:8a2e:0370:7334."
"Server IP address could not be found."
5 minutes later...
"Now could you please tell me the IPs of all connected devices?"
Wasn't a similar problem solved by services like URL shorteners? I had to work occasional technical service for products where I was one of the embedded engineers and I leaned heavily on bit.ly at the time to get URLs back and forth from customers and it worked exceedingly well.
So, with that in mind, what would be the major drawbacks to IPv6 address shorteners? You'll always have a certain class of issues such as transcription errors, of course.
Problem with URL shorteners is ones that use characters, especially of varying cases. Relaying letters across a telephone sucks, I often resort to NATO codes, and now you'll have to distinguish capitalization.
Yeah, actually I guess that I was spoiled in that regard. I worked for an RF company when I had that experience and, also having a military background myself, the NATO phonetics were used naturally when communicating with our customers.
Here, the linux routers are way ahead of you. Odhcpd used to handle ipv6 delegations for normal users can coordinate with dnsmasq (often used for ipv4 assignments and dns proxying) or unbound - to assign nice local names.
Three trouble begins at internet scale where mDNS just does not work due to collisions. And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.
Yes. The thing is, this would be super easy for the ISPs as they already have to maintain reverse DNS for dynamic IPv4 most of the time, so modifying it to also allow delegating to an authenticated DNS secret should be trivial. Eslecially now that ISPs are so fond of giving you big routers.
>: Mass adoption of IPv6 is blocked by the ugliness/inconvenience of the IPv6 address format, hence "end-users" (developers) don't like adopting IPv6. As long as this UX issue does not get solved, IPv6 adoption is only going to happen on an individual level when any given business' significant income stream is at immediate risk of being disrupted.
it's a 128 bit number. no matter how you encode it, the ux is going to suck.
I don't think the UX necessarily has to suck. Three observations:
1. Just because we have 128 bits doesn't mean we have to use them all right now.
2. As anyone who's familiar with data compression knows, there are ways to represent some values in convenient forms and other values in less convenient forms.
3. There is a trade-off between ease of allocation and ease of use. Maybe we shift the focus toward ease of use if we want wide adoption.
With the benefit of hindsight, one way the IPv6 rollout could have been done differently is to have initially restricted ourselves to 40 bits of the address space. Thus we'd have started with addresses that look like (say) A.B.C.D.E instead of the current A.B.C.D.
Such a (hypothetical) system would be easy for an end user to handle, and most importantly that could be enough to get us over the hump to IPv6 adoption. Longer addresses would be valid, but they just wouldn't be assigned until later.
Of course, this is not quite how IPv6 works. But they do have a syntax that allows omitting zero values, and if addresses were assigned so that more of them were zero, it would make the UX better.
Your comment spawned the following (minor?) idea for me: A lot of the devices (and hence IP addresses) we basically know are never going to be accessed directly by a human being, only through some combination of tools and automated processes, if at all. Make a distinction, where possible and appropriate, between these and the actually-UX-relevant addresses and reserve the shorter/nicer ones for human use.
(This may not be a great idea, or may be impractical, but I still wanted to put it here, because there's benefit in mapping out any amount of the potential solution space.)
Also, thinking about it in this way, "end user" for IPv6 does not only translate to the developers working with IPv6 as consumers (think someone getting an IP from AWS for deploying their app), but, for maximum effectiveness, should also include the developers working on the implementation as well as distribution end of the technology. As always, these two (or more) groups have different levels of motivation to adopt and use the technology, and as such it is likely that the usual tradeoffs can be made (making something a bit harder to implement, for the sake of much increased "consumer" experience).
Ideally there would be a spec and an implementation that would appeal to both allocators as well as consumers of the address space.
At home, I get IPv6, but I get assigned a different network every 24 hours, so it not that useful to, say, access my home server remotely. It works smoothly, though.
At work, we had some problems with Windows' Network Location Awareness where a domain controller thought it was on a public/non-trusted network unless IPv6 was turned off in the network settings. So we actually had at least a little pressure not to enable v6. :-|
Well, that is not exactly news. The forced disconnect every 24 hours has been around as long as DSL (in Germany at least), so you would need to pay extra for a static line.
From a principal point of view, it is very annoying, practically it has not been sufficiently annoying for me to do anything about it.
Long address in not the only problem of IPv6. Mass adoption is also slowed by complexity of IPv6. There is rationale for this complexity (more features, more flexibility), but in most networks this complexity comes with little or no practical benefits.
> The ultimate solution to IPv4 exhaustion is, of course, the complete transition of the Internet to IPv6, however, this will take time and until then there will be (by definition) networks and sites which only support IPv4. This requires other networks and sites, even if they support IPv6, to maintain IPv4 connectivity, which in turn requires some number of IPv4 addresses. For that reason, IPv4 exhaustion certainly is an issue to be understood and dealt with, especially by those who are building new networks and services.
I had IPv6 setup at one point, but a lot of things using it are broken. Some sites/services/software repos will just refuse to connect- and after a few minutes of debugging I realize it's probably v6. Turning off IPv6 usually fixes the problem.
I'd like to use IPv6, but since turning it on by default breaks a lot of things- I'm leaving it off for now.
When I set up IPv6 I learned that you have to let some things through your firewall, like ICMP, because the IPv6 protocol relies on it. When I blocked everything like I did with ipv4, it eventually stopped working.
If you block everything with IPv4, things stop working too: you have to allow at least some ICMP (for "packet too big" path MTU discovery), otherwise you will have hard-to-diagnose issues.
I agree with people blaming whole situation on ugly format of IPv6. I also believe that increase to 128bit address was unnecessary and harmful. We could have just added another two segments, have 48 bits total and it would probably be enough. It would also be much easier for people to switch from 127.0.0.1 to 0.0.127.0.0.1 than to ::1.
We've done so much learning about good UX, backwards compatibility and smooth upgrade paths in the years since IPv6 was first thought of and specified that I suggest there is a group of people out there (or on here) who can sensibly come up with an "IPv4.1" draft that can represent a smooth upgrade path from where we are right now, towards an extensible internet addressing format/protocol. It would have at least the following properties:
- IPv4-formatted addresses would continue to work as today
- address space can be extended by adding bits to the existing IPv4 format, and 0 bits do not need to be typed out etc (in mathematical notation there's also no need to write 0001.200 if we just mean 1.2)
(It feels like there should be a couple more fundamental properties to be stated here, but I can't think of any more right now.)
> The ultimate solution to IPv4 exhaustion is, of course, the complete transition of the Internet to IPv6, however, this will take time and until then there will be (by definition) networks and sites which only support IPv4.
Off-topic: I've always wondered why English speakers (or perhaps just Americans?) use "by definition" arguments so much (also just saying that things are by definition so and so).
People never seem to use "by definition" arguments and such in Finnish for example.
Definitions of mathematical objects aside, things in concept space are not eternal and can shift around.
Is the usage a cultural thing? A quirk of language? Just some random trivial thing that just is and doesn't have any particular reason to it? :p
I think search engines are very well positioned to massively help IPv6 addoption. For example, they could limit the number of search hits to an IPv4 only site. A mom an pop page without IPv6 is fine, a top 1000 site is inexcusable in 2018 and contributing to the vicious circle.
On the user facing side, they could inform consumers when they are connecting from IPv4 only networks, to realy drive home the point that they are receiving a sub-par service. It might not be true today, but in the long run it's true for the internet as a whole, stuck in IPv4. And if people perceive IPv6 as desirable, they will prefer it given the choice even if they don't understand exactly what it is, just like they prefer a 4G service to a 3G one.
What incentive would Google and Microsoft have to do this? IPv4 exhaustion costs them too, in routing performance and manpower to manage a scarce resource. Also, reliable end to end connectivity is an enabler for the type of technologies they push, limiting telco control over their users. Massive growth markets are trumped by lack of IP space, the whole of Afrinic only has a few /8. That means African carriers will do massive NAT.
I've been dreaming of a small-scale "cloud" hosting startup, and one of the biggest concerns is actually IPv4 availability.
I was hoping that this article would shed some light on the feasibility for a new company to grab a /20 or so. Does anyone around here have some insight?
Come on. Firewall rules is one sed call. IDS are dinosaurs and junk that are generally worthless (feel free to show me otherwise).
Since all major OS support ipv6 there's nothing to educate about other than perhaps new IP address form.
Software upgrades? Like what software, OS to support NAT64? Which every major OS supports? (Including Windows 7. The holdouts are ancient telephones and tiny embedded trash.)
Toolchain updates are important... if you use IP addresses directly, bypass the OS network stack and so not support names. This likely means that software is junk that should've been replaced years ago and likely some internal cookery.
Not so fast. With over 60.000 clients (yes with all known OSes and versions known to man), 10.000 servers (yes with all known OSes and versions known to man), 50 network firewalls, firewall on nearly all hosts (clients & servers), it might be just a little more then a sed call.
> IDS are dinosaurs and junk that are generally worthless.
They're part of the infrastructure, partly "just a compliancy thingy" but also part of the layered security model. Hell, there is even antivirus software for that exact same reason.
> [...] there's nothing to educate about other than perhaps new IP address form.
That is a joke right? I am sure you know a little bit more about v6 then "it's just a longer address"
> Like what software
Like software that touches IP addresses. DHCP (if that's your choice for v6), monitoring tools (yes there is loads of that which does not support v6 (mainly home made crapola) etc.
You might live in a greenfield environment, homogene and clean. Loads of older organisations run everything ever invented within the last 20 years.
IPv4 exhaustion is going to get really bad if we don't move to IPv6 soon.
IPv4 exhaustion means no more personal server boxes at home. The US has huge chunks of IPv4 allocation. In Vietnam, it's not as fun. IPv4 addresses have really exhausted. I just learned by accident that the ISP there they do a thing called the "carrier grade NAT" to get around that.
I was baffled I couldn't open a port on my router to seed some Linux images despite setting up the NAT correctly (remotely). After scratching my head for a while I noticed the IP address that the router reported was not the public IP when I Googled "what is my IP address." Then I sent an email to FPT, the ISP - one of the biggest ISPs in Vietnam saying "Hey guys - I believe I'm behind a NAT... I can't open a port to do stuff. Can you assist me?" To my surprise, after 15 minutes they sent an email back, saying "Oh yeah, we know that, we have given you a public IP. Thanks for trusting our service." I was double baffled by their service. Then because of that, I also asked for IPv6. 10 minutes later - "IPv6 has been enabled on your account. Thanks for using our service." What the hell?
While my ISP in the US (Spectrum/TW) has just given me a hell of a hard time because they sent me a buggy modem that would restart 3+ times a day. And in 4 months with a countless number of calls, 10 tech people sent to my house, no one knew what TF was going on. Now suddenly, it doesn't crash anymore, but they disabled IPv6 altogether, no words given. No one in their tech support knew that IPv6 was disabled because it crashes their router and they just gave me bullshit answers. I just found out about the "Puma chipset IPv6 crash" ordeal by Googling. Again, Spectrum was as helpful as a rock. I don't know how do they have so many people sending me mail spams weekly and calling and harassing me to sign up for their TV service, yet the service sucks so much.
Could IPv4 address exhaustion be staved by opening some of the currently unused /8 blocks? For instance, Apple has the entire 17.0.0.0/8 block. If IPv4 addresses are really becoming scarce and demand is going up, seems like Apple could dole out /24 or /16 bit blocks to RIRs and make some money - which they obviously like to do. So why aren't they doing it? Maybe someone more familiar with the economics of IP has an idea.
There’s dozens of cases of this besides just Apple. Frustratingly, if you scan the legacy allocation /8 blocks (not done personally, but know someone who has), most of the ranges have no open ports on a majority of the range. So they literally are serving no justifiable (in my opinion) purpose.
I did IT support at a car dealership where some ancient line-of-business software needed a public IP for every Windows desktop it ran on to function properly.
No justifiable purpose, sure, but I can only imagine the tons and tons of legacy line-of-business crap out there with assumptions like this.
You nailed why I threw in the word justified intentionally. There’s plenty of reasons a public IP could be needed, but not justifiably (to me, your example perfectly illustrates that).
In the organisation I work for we had IPv4/IPv6 dual stack. Due to IPv4 exhaustion my whole department was shoved behind an NAT, which given the circumstances I find it normal as there is no need for 400+ workstations to have public IPs. The weird thing is that after the switch to NAT IPv6 connectivity was lost. When asking why IPv6 was lost I was told "what do you need it for?".
In the meantime I have residential IPv6 since 2011. I really believe corporate networks are one of the main causes of delay in massive IPv6 adoption. And given the inertia I'm not really expecting them to change soon.
The most important slowdown on IPv6 adoption is vat replacement of small local services and servers in lieu of centralized ones provided by ISPs amd a few Fortune 500 companies.
One problem to moving to IPv6 is that most of the firewalls I've looked at either don't support it at all or the support is very weak. I know that IPFire doesn't support it and I couldn't find any information on Smoothwall IPv6 support. I think that pfSense supports it but I don't know how well.
Come on people, it's 2018 and your building a network application. I'm thinking a top priority would be IPv6 capabilities. Apparently, I'm wrong.
An embarrassing admission, but one that is potentially useful for this conversation: I have a Cisco CCNA cert that I got in 2009 but never used. (Got a job that didn’t put most of the knowledge to use, and the cert collected dust.) IPv6 was on the exam. I’ve forgotten all about how to use it.
For me it is just not as intuitive. Maybe others think the same, slowing adoption? I didn’t find it intuitive when studying for the exam, but I got it enough to pass.
Basic networking knowledge I still have. I can tell you how to set up a DHCP and DNS server, and how NAT works on your router. I can tell you about ARP tables, VPNs, VLANs, firewalls, and subnets. I can’t begin to tell you about the equivalents on v6.
Maybe I’m just getting old. Maybe it would come to me once I started using it again. Or maybe it’s just not as intuitive.
93 comments
[ 3.3 ms ] story [ 192 ms ] threadAt some point having IP4 on your public gateways will be seen like FAX in your office. You can't turn it off because a small minority is still using it. The importance is dwindling and at some point you will turn it off and nobody will notice.
IPv6's share of traffic has been increasing at about 0.5% per month for the past year. If IPv4 has 80% and IPv6 20% this month, next month it'll be 79.5 vs 20.5. So in your opinion... what? The change will stop? When? Why?
Everyone is able to sign up with RIPE and get a /22, thats around 1000 IP addresses. For years the RIRs want to tell us that IP addresses run out but I am still able, today, to pay some bucks and get IPv4 addresses without issues. The issue was that exactly those RIRs handed out IPv4 addresses years ago like there is no tomorrow and now they want us to switch to a broken protocol because they made a huge mistake. I won't deny that we are months (around 2 years) away from the RIPE actually running out of IPs.
Part of my job leasing out IPv4 space is also monitoring different sources, like Spamhaus, if my client or client of clients send spam with my IPs. What I can tell you is that with IPv4 already this is messy but if I think about IPv6 this is impossible to track or control and a complete nightmare. Also, for example if you operate a mail server that only runs IPv6 and send emails to gmail they will outright block you or just send it to the spam folder. Please note that this is only one of many examples.
Apart from that, if I look at the implementation of cloud providers like DO, Linode, OVH, Scaleway, etc. this is all a big joke. Also, IPv6 routes from some tier 1 upstream to others are down for days without anyone noticing it, because most people want IPv6, but no one is actually using it. It's like having a todo list and IPv6 is done but how it's been implemented doesn't matter at all.
You should also be careful with statistics, as a lot of scammers switched to IPv6 so I would not be surprised if a lot of the "IPv6 market share" is from scammers.
2) Why track IP addresses instead of mandating DKIM? Gmail eats valid IPv6 sourced mail with good DKIM keys no problem.
3) Same can be said about IPv4 routes. Remember nobody really uses IP directly to route nowadays...
Looks like it's growing rather steadily.
(and not crawlers of all those SEO tools that need to crawl with different IPs because they hit rate limits very fast)
IPs are still cheap enough to "waste" - the only real motivator is going to be ipv4 price being too high which we're quite far off of
The other thing is Docker and Kubernetes are not supporting IPv6 today so that definitely locks a lot of the more modern cloud deployments to IPv4, even if it's S2S communication which could have been IPv6 only (since you would control both ends) otherwise... so that's another thing.
However, new network layer technologies like "Layer-3 all the way to the server" are allowing providers to use their entire IPv4 allocation by having BGP pushing /32 routes internally and this has been the biggest helper in my opinion, no longer do you have a static /24 allocation and a bunch of dead space that can't be freed easily.
Of course people who are new to OPs/Dev haven't really seen this much- but I would probably venture more than 50% of ipv4 space is locked into allocations that are mostly empty.
-- I also think there is still an increasing population of internet users and VPS/Cloud providers give a cheap and easy way to be online too.. $5 for a VPS in most cases.
Nothing but the external entry points in a cloud need to be publicly accessible IPv4.
That is if the number of Internet users don't grow and since it is so easy to spin up an instance even for just $5 a month these days, many people are rather willing to spin up more than they would have physically to use more IPv4 addresses.
But seeing how attaching an extra IP to an instance is so cheap everywhere, it seems there's no immediate threat to lack of address spaces but I'd like to know about a proper research.
[0] https://en.wikipedia.org/wiki/Server_Name_Indication
There has been an answer to your question in this thread for 14 minutes. However only users with showdead on can see it, because Arc has erroneously flagged it as evil. Screenshot/proof of what I currently see: https://i.imgur.com/Y7iM30E.png
HN does get spam, but the text and links don't look like the currently-buried comment does. I can't see it being /that/ hard to train an RNN, what with this being a comp-sci discussion forum...
--
Oh, about the bar being brown/black in my screenshot - I set the bar color to that of the upvote/karma text, as I don't care to see that information (I start commenting for points, not to contribute meaningfully - it's true). Unfortunately Arc doesn't realize it should make the color of the links lighter so I can see them, so I've had to work hard to learn where the "threads" link is sitting so I can access comment replies.
Bit inconsistent letting me change the background color but not the text color. I can understand it, but still. Getting to the root cause, it would be nice to have an option to completely disable karma score display.
</Irritated but ultimately harmless 1:30AM rant>
The problem is the lack of insensitive to do the conversion.
Moreover if routing was being propagated by DHCP, why was that not the case for IPv4 as well which would presumably be using it ?
Honestly I think the fundamental mistake of IPv6 was trying to fix everything else along the way. Certainly there are things that can be fixed in DHCPv4. But there isn't a way to put off that operational work until you're ready to get good at it; there is no way to just get more addresses and not also sign up to run a new version of DHCP, to decide if you even want DHCPv6 or you want RAs and SLAAC, to give up ARP, etc. It's a big lesson in the second system effect.
Also, there's some multicast fanciness so you join a multicast group based on some hash of your IP address so that NDP packets don't even go to all machines, but just some hash bucket that contains that IP address.
(I think these are good reasons to make a successor to ARP, but I don't think these are good reasons to require that you use the successor protocol if you don't want to NAT, especially given the extent to which deployed networking gear does ARP snooping and IGMP snooping - and does not expect a pile of multicast groups.)
I actually tell my ISP when they call me to upgrade that I will not upgrade to a higher package unless that package has IPv6 enabled. I am probably the only person who does this.
What I did instead was set up a HE.net tunnel so I can actually have IPv6 (albeit with a smaller MTU, but you're unlikely to notice). What I gain is the ability to run my own little services at home again, no NAT punching! no complicated rules.. I have a salt master that connects to my IPV6 enabled VPS' (which is all of them, thankfully), I have all my mail listening on VPS's with IPv4 and IPv6 which take in my mail and deliver it to a harddisk at my house essentially. Anything S2S can happen directly.. and it's nicer even on IPv6 enabled networks that I happen to be on when travelling (Mobile operators are increasingly IPv6)..
But it's unreliable to be IPv6 only, I can only access my home from other wifi networks at a ratio of about 1:20..
But I long for the day where it's ubiquitous and I can shit on wifi operators for not supporting it.. that day will come.
I mean last year IPv6 adoption more than doubled and is sitting at around 22%~ of all traffic.. so that's something.
IPv6 is too big and incompatible!
[0] https://en.wikipedia.org/wiki/NAT64
Although there is technically no packet-level encapsulation, from a mathematical perspective you may consider the IPv4 bits "encapsulated" within the IPv6 bits.
"Requires immediate total cooperation from everybody at once": every single system which wanted to talk to an AWS host would have to implement that IPv4 extension.
"Many server administrators cannot afford to lose business or alienate potential clients": for anyone with a non-upgraded system, the server would be unreachable.
Specifically, your plan fails to account for:
- Lack of centrally controlling authority for networking
- Huge existing software investment in IPv4
- Popularity of NAT and other middleboxes
- Users who don't update their operating system ever
and the following philosophical objections may also apply:
- Ideas similar to yours are easy to come up with, yet none have ever been shown practical
- It will work for a while and then we'll get stuck with it
- It's an ugly hack
"Sorry dude, but I don't think it would work."
(I apologize for choosing your comment for this, but this idea of applying the spamsolutions.txt format to the inevitable "extended IPv4" proposals has been in my head for a long time. Someone with more networking experience should be able to present an even more complete list of "extended IPv4 objections".)
My understanding is that there is a real cost for ISPs to make IP v6 available, but zero need to (upgrade of thousands of pieces of hardware equipment - is that still true?). There is no consequences for not doing so.
That's one of the things I've been watching. Theoretically, the easiest switchover should be consumer iPhones on cellular data networks, because any app released in the last few years should work on them.
[1] https://www.google.com/intl/en/ipv6/statistics.html
---
Who here actually feels any sort of pain, as an internet technologist, or as business owner, from "still" being on IPv4? I know that I do not.
If we had demand for it, I'm pretty sure we'd start including an IPv6 subnet by default. It doesn't cost us much, it's just more bookkeeping really. If anything, it could be a turn-off to our customers who might not be used to configuring their router with an IPv6 subnet (the 'ugliness' problem you're talking about, but also just unfamiliarity).
I think IPv6 adoption will happen when cloud providers start running out of IPv4 space. If AWS has to drastically raise its prices for IPs, or simply announces they're running out, then AWS customers will have to start evangelizing IPv6 to their own customer bases.
Eventually an IT guy in an office says, "I heard Slack is only going to support IPv6 soon, we need it!". So the ISPs start doing it.
But, you're right about IPv6 being extremely complicated. Back when I first heard about IPv6, I suspected it was going to fail in the marketplace.
it's "failing" for a number of reasons - the UI and mental map model is certainly a stumbling block, but it's also something which requires coordinated effort between multiple parties to happen more or less at the same time. If it doesn't (and it didn't), it'll take years more for all players to get in sync, which is what we're seeing.
Residential ISP companies didn't have much incentive to upgrade when everyone's OS didn't include IPv6 stack. Not much push to try to upgrade your OS when your modem and ISP don't support it. Not much use to try to support it on your websites and email servers when no one is using it or asking for it.... and so on.
As all the pieces fall in to place - hardware, ISP, OS, web/mail/services - it'll still be a gradual move, unless some major players announce IPv6 only service. If Office365 was "IPv6 only in 2020", that might motivate a lot of orgs to push their IT/ISP to upgrade and migrate.
It doesn't even need to be that drastic. Apple, Google, and Microsoft could just check for IPv6 when connecting to a network. If it's missing, display some kind of alert saying, "This internet connection is malfunctioning, please contact (lookup service number based on the IP address.)"
Constantly showing that nag will put a lot of pressure on major ISPs like Comcast.
Comcast is making good progress: http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...
For others, see: http://www.worldipv6launch.org/measurements/
* My home and small business Internet provider does not support IPv6, despite them talking about deploying it for about 10 years now. Actually here in the Netherlands I have never encountered a mainstream consumer ISP that supports IPv6.
* I don't have any users that are on exclusively on IPv6. All my users have access to IPv4.
* IPv6 does not bring me any visible benefits, like faster performance.
"Server IP address could not be found."
5 minutes later...
"Now could you please tell me the IPs of all connected devices?"
Customer hangs up and cancels his subscription.
So, with that in mind, what would be the major drawbacks to IPv6 address shorteners? You'll always have a certain class of issues such as transcription errors, of course.
Instead of the numbers you type in the hostname of a device. IPv6 encourages to improve on the current lackluster DNS solutions some routers have.
Three trouble begins at internet scale where mDNS just does not work due to collisions. And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.
>And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.
Probably not but for internal resolution a .local or similar TLD is sufficient.
it's a 128 bit number. no matter how you encode it, the ux is going to suck.
1. Just because we have 128 bits doesn't mean we have to use them all right now.
2. As anyone who's familiar with data compression knows, there are ways to represent some values in convenient forms and other values in less convenient forms.
3. There is a trade-off between ease of allocation and ease of use. Maybe we shift the focus toward ease of use if we want wide adoption.
With the benefit of hindsight, one way the IPv6 rollout could have been done differently is to have initially restricted ourselves to 40 bits of the address space. Thus we'd have started with addresses that look like (say) A.B.C.D.E instead of the current A.B.C.D.
Such a (hypothetical) system would be easy for an end user to handle, and most importantly that could be enough to get us over the hump to IPv6 adoption. Longer addresses would be valid, but they just wouldn't be assigned until later.
Of course, this is not quite how IPv6 works. But they do have a syntax that allows omitting zero values, and if addresses were assigned so that more of them were zero, it would make the UX better.
Also, thinking about it in this way, "end user" for IPv6 does not only translate to the developers working with IPv6 as consumers (think someone getting an IP from AWS for deploying their app), but, for maximum effectiveness, should also include the developers working on the implementation as well as distribution end of the technology. As always, these two (or more) groups have different levels of motivation to adopt and use the technology, and as such it is likely that the usual tradeoffs can be made (making something a bit harder to implement, for the sake of much increased "consumer" experience).
Ideally there would be a spec and an implementation that would appeal to both allocators as well as consumers of the address space.
At work, we had some problems with Windows' Network Location Awareness where a domain controller thought it was on a public/non-trusted network unless IPv6 was turned off in the network settings. So we actually had at least a little pressure not to enable v6. :-|
From a principal point of view, it is very annoying, practically it has not been sufficiently annoying for me to do anything about it.
That's what I heard in college in 1999.
I'd like to use IPv6, but since turning it on by default breaks a lot of things- I'm leaving it off for now.
- IPv4-formatted addresses would continue to work as today - address space can be extended by adding bits to the existing IPv4 format, and 0 bits do not need to be typed out etc (in mathematical notation there's also no need to write 0001.200 if we just mean 1.2)
(It feels like there should be a couple more fundamental properties to be stated here, but I can't think of any more right now.)
Off-topic: I've always wondered why English speakers (or perhaps just Americans?) use "by definition" arguments so much (also just saying that things are by definition so and so).
People never seem to use "by definition" arguments and such in Finnish for example.
Definitions of mathematical objects aside, things in concept space are not eternal and can shift around. Is the usage a cultural thing? A quirk of language? Just some random trivial thing that just is and doesn't have any particular reason to it? :p
He's defining a particular scenario, and then using a tautology to clarify that scenario.
On the user facing side, they could inform consumers when they are connecting from IPv4 only networks, to realy drive home the point that they are receiving a sub-par service. It might not be true today, but in the long run it's true for the internet as a whole, stuck in IPv4. And if people perceive IPv6 as desirable, they will prefer it given the choice even if they don't understand exactly what it is, just like they prefer a 4G service to a 3G one.
What incentive would Google and Microsoft have to do this? IPv4 exhaustion costs them too, in routing performance and manpower to manage a scarce resource. Also, reliable end to end connectivity is an enabler for the type of technologies they push, limiting telco control over their users. Massive growth markets are trumped by lack of IP space, the whole of Afrinic only has a few /8. That means African carriers will do massive NAT.
I was hoping that this article would shed some light on the feasibility for a new company to grab a /20 or so. Does anyone around here have some insight?
Keeping (private) v4 working is hard enough.
Even drafting a project budget for v6 makes management go balistic. - firewall & IDS upgrades
- firewalls rules
- accountablity
- dynamic DNS
- employee education
- toolchain updates
- upgrades of software
- functionality tests
Not all companies employ NY or Google level engineers who "just roll out v6" on a Sunday afternoon.
Since all major OS support ipv6 there's nothing to educate about other than perhaps new IP address form.
Software upgrades? Like what software, OS to support NAT64? Which every major OS supports? (Including Windows 7. The holdouts are ancient telephones and tiny embedded trash.)
Toolchain updates are important... if you use IP addresses directly, bypass the OS network stack and so not support names. This likely means that software is junk that should've been replaced years ago and likely some internal cookery.
This leaves tests and dynamic DNS.
Not so fast. With over 60.000 clients (yes with all known OSes and versions known to man), 10.000 servers (yes with all known OSes and versions known to man), 50 network firewalls, firewall on nearly all hosts (clients & servers), it might be just a little more then a sed call.
> IDS are dinosaurs and junk that are generally worthless.
They're part of the infrastructure, partly "just a compliancy thingy" but also part of the layered security model. Hell, there is even antivirus software for that exact same reason.
> [...] there's nothing to educate about other than perhaps new IP address form.
That is a joke right? I am sure you know a little bit more about v6 then "it's just a longer address"
> Like what software
Like software that touches IP addresses. DHCP (if that's your choice for v6), monitoring tools (yes there is loads of that which does not support v6 (mainly home made crapola) etc.
You might live in a greenfield environment, homogene and clean. Loads of older organisations run everything ever invented within the last 20 years.
IPv4 exhaustion means no more personal server boxes at home. The US has huge chunks of IPv4 allocation. In Vietnam, it's not as fun. IPv4 addresses have really exhausted. I just learned by accident that the ISP there they do a thing called the "carrier grade NAT" to get around that.
I was baffled I couldn't open a port on my router to seed some Linux images despite setting up the NAT correctly (remotely). After scratching my head for a while I noticed the IP address that the router reported was not the public IP when I Googled "what is my IP address." Then I sent an email to FPT, the ISP - one of the biggest ISPs in Vietnam saying "Hey guys - I believe I'm behind a NAT... I can't open a port to do stuff. Can you assist me?" To my surprise, after 15 minutes they sent an email back, saying "Oh yeah, we know that, we have given you a public IP. Thanks for trusting our service." I was double baffled by their service. Then because of that, I also asked for IPv6. 10 minutes later - "IPv6 has been enabled on your account. Thanks for using our service." What the hell?
While my ISP in the US (Spectrum/TW) has just given me a hell of a hard time because they sent me a buggy modem that would restart 3+ times a day. And in 4 months with a countless number of calls, 10 tech people sent to my house, no one knew what TF was going on. Now suddenly, it doesn't crash anymore, but they disabled IPv6 altogether, no words given. No one in their tech support knew that IPv6 was disabled because it crashes their router and they just gave me bullshit answers. I just found out about the "Puma chipset IPv6 crash" ordeal by Googling. Again, Spectrum was as helpful as a rock. I don't know how do they have so many people sending me mail spams weekly and calling and harassing me to sign up for their TV service, yet the service sucks so much.
No justifiable purpose, sure, but I can only imagine the tons and tons of legacy line-of-business crap out there with assumptions like this.
In the meantime I have residential IPv6 since 2011. I really believe corporate networks are one of the main causes of delay in massive IPv6 adoption. And given the inertia I'm not really expecting them to change soon.
Come on people, it's 2018 and your building a network application. I'm thinking a top priority would be IPv6 capabilities. Apparently, I'm wrong.
For me it is just not as intuitive. Maybe others think the same, slowing adoption? I didn’t find it intuitive when studying for the exam, but I got it enough to pass.
Basic networking knowledge I still have. I can tell you how to set up a DHCP and DNS server, and how NAT works on your router. I can tell you about ARP tables, VPNs, VLANs, firewalls, and subnets. I can’t begin to tell you about the equivalents on v6.
Maybe I’m just getting old. Maybe it would come to me once I started using it again. Or maybe it’s just not as intuitive.