The Ripe NCC Has Run Out of IPv4 Addresses
ripe.net
ripe.net
1. My home has Verizon fiber. No native IPv6. I have a tunnel for this, but such solutions aren’t going to work for the masses. The other in-region residential provider, Comcast, has great native IPv6 service, but had layer 2 performance issues versus price.
2. At $dayjob I just ordered a circuit from Level3/Centurylink for a branch site. No IP justification form was required if I needed only IPv4 /30. But for dual IPv4 /30 + IPv6 /126, I was required to provide written justification. Shouldn’t this be the other way around? Unencumbered IPv6 for all, with paperwork for IPv4?
EDIT: these are not site allocations, just point-to-point link addresses, hence the /126. Still, I’m being asked to justify IPv6 but not IPv4.
Uh, unless you're running BGP over this or getting a larger subnet statically routed to you, get a larger prefix. A /48 or /56 is the current recommendation [1] for business end site allocations.
That said, I think the original intent was that such “point-to-point Ethernets” should have been issued /64, but seems /126 is common practice.
* https://www.ripe.net/publications/docs/ripe-690#4-1-2--unnum...
Also another fyi: if you're rolling commodity hw (bcm tridents etc) after a /64 up to /128 you are dipping into another constrained forwarding table - can't fill your box with too many of those.
I can get a /56 even at my apartment just by setting my router to request it.
Putting multiple customers on the same /24 introduces all kinds of issues. Either you leave it open leaving IP's vulnerable to hijacking, or you have to create static ARP and/or MAC entries, and deal with all the hassle of managing that. Presumably, you're describing consumer service where they don't really have to care about your security unlike a business/enterprise level service.
I'm all for IPv6 but it's not widespread enough to ditch the need for static IPv4 addresses.
Doing this means all IPv4 network addressing headaches vanish internally. Oh there are going to be 260 remote offices instead of 100 like you said at the kick off meeting? No problem, my subnets are easily big enough either way.
And with this approach your budget for the edge reduces over time as more of the network supports IPv6, whereas with a NAT gateway your budget increases as throughput rises.
You do need to be really firm during purchases, if the "IPv6 support" in that shiny new product is actually more of a wishlist item than an actual feature, you're getting a full refund, no second chances. That goes for desk phone (if your outfit still has those), printer/ copiers, IoT devices, and everything.
I've heard this pretty often. One day it gets rolled out without any notice, and surprise, you're on V6. Plays havoc.
Only server administrators need to care, and there they have a problem. If you run real IPv4 only: then IPv6 only users can talk to your server no problem and won't even realize anything is happening. If you run IPv6 only there are a lot of IPv4 only users who cannot connect to you. Thus if you run a server it is critical to have a real IPv4 address.
Did you notice the "real" qualifier to IPv4 in that last paragraph? many (most?) IPv4 only users are behind a NAT system such that they cannot run a server anyway. If you are running a IPv4 Server you need an address of the type that RIPE just ran out of. If you are a user you can use a fake IPv4 address and keep on working.
If you are a server administrator you should ensure that all your servers have IPv6 addresses. You should then collect statistics on use. There may be a date in the future where you can suggest to your management that you can cut off [small number]% of your users by going IPv6 only and selling your existing IPv4 address to the highest bidder for $$$. That is a business decision, but once it starts happening it will make headlines, but I wouldn't want to be first. (if you wait too long enough others will have gone IPv6 only that there isn't a real customer cost to being IPv6 only and then the market for IPv4 will disappear - and interesting value maximization problem if you want to play that game)
NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-IPv4 NATs, that is to say pretty poorly: but we've long since adjusted the architecture of Internet-enabled software to cope with the flaws, so practically speaking they work just fine.
We've been down a road for a while now of funnelling all of the Internet's services into something-over-HTTP, so running a server might need a public IPv4 address, but as the supplies already assigned to LIRs by the RIPE NCC (and other RIRs) start to dwindle I expect we'll see more services offered whereby you can share an HTTP front end with a bunch of other people, proxied to an IPv6 (or private space) server you run.
A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly.
Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.
Does this mean we've finally run out of new allocatable IPv4 addresses with the RIRs?
[0]: https://en.wikipedia.org/wiki/Regional_Internet_registry#/me...
Game over IPv4.
Theoretically we could have transitioned to IPv6 instead and avoided this hassle, but too many incumbents are dragging their feet on the whole IPv6 issue.
One thing you don't see enough of yet is providers charging for the IPv4 address their customers probably don't need. Those have a real cost, and economics 101 tells us if something has a cost, even a small cost, and you surface that cost to your customers, suddenly they're a lot more interested in helping avoid that cost than they were when you just ate it as part of the service. Plastic carrier bags weren't free back when grocery stories didn't charge for them -- they just absorbed the financial cost and externalised the environmental cost. Charge for the bags and suddenly customers remember they already have a bag, they don't need a bag. Same with IPv4.
Do other cloud providers (Azure, Google Cloud, Digital Ocean) do this?
All they needed to do was expand the address space, but it looks like the kitchen sink got thrown in.
65536.65536.65536.65536.65536.65536.65536.65536
I feel like the adoption problem is now firmly on "us". Last time I was setting up an internal network, I was afraid of the consequences of using IPv6 internally, so I just didn't. I imagine a lot of people are in the same boat, and they are the stragglers preventing us from turning off IPv4. The big players are ready.
(I will say that jrock.us has worked over IPv6 for almost as long as Google, though. When you only have one computer on the network, IPv6 is not much work.)
Fingers crossed they don't lol.
If every single incumbent and every single newcomer is dragging their feet on IPv6, maybe, just maybe, the problem isn't every single engineer in the industry, the problem is IPv6.
Theoretically we could have had a straightforward extension of IPv4 to a longer address length and the exact same design, but some architecture astronauts took over the IETF and they think it's more valuable to push their weird redesign of the internet than to actually solve IPv4 address exhaustion.
The situation feels like chicken-and-egg to me. If I had the option to use IPv6 at home, I'd be on it 100%... as-is, there's little motivation to move off of v4 internally since I'd have to NAT/tunnel to get to the v6 internet over Fios. That said, most of my link-local intranet traffic is on the fe80:: network, because that's what avahi and mDNS prefer as answers.
There's still a lot of waste that can be reclaimed before it's game over for IPv4. For just two examples - both Ford Motor Company and Prudential Securities are currently assigned over 16.7 million public IPv4 addresses each.
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
So do Apple, AT&T, the U.S. Postal Service and others.
https://neverthenetwork.com/notes/lisp/
Full disclosure, the second link is my blog.
I believe Cisco is the only large vendor that's implemented it, but there are Linux and BSD implementations, which should make it easy for any Linux or BSD based NOS to implement it in the future.
Honestly this problem will probably be mostly solved in hardware with larger FIBs/TCAMs
Edit - I should clarify the problem I'm referring to here is fragmentation, not exhaustion.
https://en.wikipedia.org/wiki/IPv4_address_exhaustion#Addres...
Entire networks of computers can share a single public IP address so the 33.5 million public IP addresses supplied by two /8s could last quite a long time. Or we can let Ford sit on them.
https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...
with some 1M ips given out PER DAY, how long would two /8s last? 4 weeks, or 33 days. That is not "quite a bit longer", it is literally what I suggested.
It is only now, long after the crunch that thinking entire networks would share a single ip (hopefully never running any SIP,bittorrent or something that needs more than one port simultaneously) or the entire network would quickly run out of the 64k ports usable...
So, if Ford and whoever had that second net did give it back when it started to get scarce, all of 33 days is what we would have "won". Good margin for writing up that ipv6 migration plan I guess.
EDIT: just found it https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
I could see most others doing it though.
I'm wondering how much justification validation they are actually doing, or if something worse is going on.
given the recent corruption allegations with PIR/ICANN, I wouldn't be surprised if it was corruption.
- APNIC ran out
- ARIN ran out
- RIPE NCC just ran out
- AfriNIC is expected to run out in 2020
- LACNIC is expected to run out in May 2020 https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases
They're pretty low too though
>AFRINIC has no more than one /11 of non-reserved IPv4
Until something forces the transition nothing is going to change.
And before now, there were still some unused addresses available. We've just begun the phase where we have to scrounge for loose change in the couch cushions. Previously there was money in the wallet. (Only a little, but that's what you use first.)
My guess is scrounging will initially be easy. Then it will get gradually harder, until eventually it becomes easier to just use IPv6, and then people will switch over.
(And apparently the police are not big fans either, as it makes it more difficult to track down miscreants).
From a consumer standpoint the problems I've run into and heard about are:
1. Can't use port-forwarding anymore since you can't configure the ISPs router doing the NAT
2. A bad neighbor sharing your IP can get you IP banned on sites that still think IP address is a good way to block/throttle bad players
3. Connections can be unstable if there's a lot of connections going on, so prime-time can often run into issues.
In Finland 2 out of 3 mobile operators give you IPv6 by default (and mobile data usage is very high).
This is the chicken-and-egg problem that all new networks are facing with regard to IPv6 adoption. In order to have a usable network, you have to support IPv4 to all endpoints. But once you have v4 at all endpoints, the incentive to run v6 is greatly diminished.
As always, v6 needs a "killer app" that Grandma wants to use that is unavailable over the v4 internet, and then network administrators could use the actual demand from their customers as a justification for moving to v6. Unfortunately, at the moment, the list of v4-only must-have apps is still greater than the list of v6-only must-have apps.
Maybe we've done too early (it was about five years ago maybe, I don't really remember exactly) and now tooling is better, idk
Unfortunately Virgin Media (my ISP) are still dragging their heels but have decided to go with DS-Lite.
Many large cable ISPs in the USA have been running IPv6 internally for years now. They likely have some of the largest deployments if you account for all their IP managed gear.
Of course, these are the same ISPs that already provide a dual-stack gateway to their customers.
CableOne/Sparklight says hi, because they have zero intention on deploying v6 for the foreseeable future.
At least in Poland, you must provide law enforcement with information about your subscriber for any given 5-tuple at a given time (timestamp, {src,dest}{ip,port} and protocol). If you're CGNATing everyone, you have to either:
- log all outgoing connections (which is a GDPR hazard)
- design your CGNAT to use static outgoing ports for a given customer (but then you're running out of ports pretty fast, if you're doing anything close to >=500 subscribers)
With IPv6, you can just immediately tell who the subscriber is based on the IP address, and as such don't have to log anything.
Most of the stuff regular people care about performance for is on CDNs that support IPv6 (or is YouTube, Netflix etc)
https://www.aussiebroadband.com.au/help-centre/nbn/tech-supp...
The adoption rate has been really slow.
If everyone is routable it cuts the gordian knot in the "What kind of content should be allowed on our platform?" question by allowing everyone to simply be their own platform. If ipv6 gets adopted fast enough it might just save the 'net from being just a more privacy invasive form of television.
This is such a great analogy.
The Internet has become a dopamine fix. Platforms are generic and inflexible. (Remember when you could change the HTML?) Content is watered down or demonetized for the sake of ad money (Youtube, Tumblr). You can't read the news without getting a video ad shoved down your throat. Commercial video is DRM'd. Browsers (read: Chrome) enables websites to prevent you from copying text or viewing source images. Your every move is tracked to better target ads and sell your profile.
* {
-webkit-user-select: text !important;
user-select: text !important;
}
It is incredible how much more palatable the web becomes with uBlock Origin + uMatrix + Stylus. Not optimistic for the web in the long term, though.
Example: https://www.ghacks.net/2016/05/24/chrome-copy-text-manipulat...
Your comment brings a whole new angle to IPv6 I hadn't before considered. Having each packet routable straight to a TCP/UDP port number eliminates the complexities of NAT. Since the {hard,soft}ware that handles NAT wouldn't be needed, perhaps a shift to IPv6 could also give throughput gains.
It does, although barely noticeable. More noticeable is the cost to ISPs for carrier-grade NAT equipment.
Ultimately, technologies are less important than public opinion, politics and commerce in dictating how the net goes.
* Or a single trackable address range, no matter. Yes, ISPs could do differently. Why would they? All the incentives are on the other side.
Sorry, but this is incorrect. No matter how you connect to the internet, someone has to agree to route your traffic. Just having an allocation of "public" address space doesn't mean you are free to do whatever you want. Other people have to actually pick up your traffic.
If you don't have an ASN and a core router on a backbone to announce and carry your traffic, and instead are just using what an ISP gave you, you really have almost no control over whether that address is routable, what protocols you can use with it, etc. They can impose the same limits on IPv6 as IPv4 - and in order to reduce overt abuses of their network resources, they almost certainly will.
Remember: passing packets requires real money. The larger the number of packets, the larger the bandwidth used, the larger the concurrent connections, the more money it costs. Any segment in the network that takes up significantly more traffic than another, will end up costing a disproportionate amount of dollars and maintenance to support. So unless you're paying for all of it, you will have limits. And just like every other resource on the planet, some people will have more resources than others.
IPv6 is identical to IPv4 in terms of what "freedom" you have on the internet.
It is easier to offer services on IPv6 IMHO. If you want to have some boxes at home to SSH into, you need to provide port forwarding after the first.
So for the first system in IPv4 you would have pubip:22 -> inta:22, but then you have to do pubip:23 -> intb:22, pubip:24 -> intc:22, etc.
With IPv6 you can just use the hosts' IPv6 addresses and punch holes for :22 for each individual system as desired: no port tomfoolery needed.
The ISP can decide to impose exactly the same limit on allocated IPv6 as IPv4, and charge you for more hosts. Your freedom hasn't changed, only your billing has.
Do you think the adoption of IPv6 would lead ISPs to drop their ban on running servers from non-business accounts?
I don't think that even given widespread IPv6 adoption, we'll ever go back to a model where residential or mobile internet connections will allow for public reachability by default.
Of course, NATs and firewalls are not the same thing (you just effectively happen to get the latter when deploying the former). But I firmly believe that the bulk of technologies that give us dynamic endpoint lookup and coordinated firewall traversal will outlive IPv4 and NAT.
As an anecdotal example, I used to have a mobile data plan that assigned a public IPv4 address to my phone, including inbound TCP/UDP reachability! That's neither good for battery life, nor for data consumption (on a metered plan). By contrast, my current one puts me behind a carrier grade NAT, but I have no problems whatsoever making peer to peer VoIP calls to friends behind the same type of NAT.
Given how sht the security on IoTs is I'm not convinced giving everything a routable IP is a good idea frankly. At least not until the IoT players up their game significantly
Also NAT is not a firewall, but that’s a story for another day.
Home devices are always going to be deployed with an allow outgoing, deny incoming firewall, regardless if they have IPv6 or not. They are identical in terms of security.
It most certainly does. If you have an insecure device behind a nat, say something with telnet sitting open, a port scanner from the outside won't be able to find it (unless you've gone to great efforts to allow inbound connections without an established outbound connection). This is objectively better than if that device were directly addressable.
> Home devices are always going to be deployed with an allow outgoing, deny incoming firewall, regardless if they have IPv6 or not.
Not always. My last router came with the firewall off and that was just a few years ago. A lot of consumer ISPs don't bother with the firewall because they don't want to field customer service calls about things not working.
https://www.fourmilab.ch/documents/digital-imprimatur/
by John Walker, of Autodesk fame.
The router has a public IP and everything behind it has a local one. That you can do NAT in different contexts and that technically you could have NAT without the firewall functionality doesn't change that this is 99.9% of all NAT applications.
A bit more text about this concept:
https://security.stackexchange.com/questions/176744/why-is-n...
This is just arguing semantics. It's not "NAT itself", but a side effect of using it is that it requires deliberate effort to allow inbound connections to get to devices behind the router. This has many of the same effective security benefits as a firewall blocking inbound connections does.
Another way of saying this: the companies that make cheap, crappy routers can do the absolute bare minimum and not end up exposing internal devices to inbound internet traffic. So NAT provides security against the cheap, crappy router manufacturers.
With IPv6, the opposite is true: The router manufacturer has to do deliberate extra effort to block inbound connections, beyond just making the router "work". Will most router manufacturers do this extra effort and include a properly-configured firewall? Probably yes, especially if they don't want to get a terrible reputation for being insecure, which would (hopefully) eventually drive them out of business.
Will absolutely 100% of them always do this properly and never make a mistake? I wouldn't bet on it.
The way common household NAT works is you have hosts on a private IP space behind a NAT device with an ephemeral internal IP/port table. When an internal device initiates a connection outward the NAT device takes a note of the IP address and port it is connecting to and writes them to the table, along with its own port mapping.
When a packet arrives addressed to the NAT device it checks the table and if it finds a matching entry it rewrites the packet and forwards it back to the original host.
So someone attempting to make a new connection to an internal host is effectively firewalled off by the lack of a mapping table.
Now most people who say "NAT isn't a firewall" are referring to the case where you have for some reason turned off the default firewall rules on the NAT device and have somehow routed a packet with a destination address that is on your internal network. In this case, the NAT will just forward the packet onto your internal host and provide no protection as they say. However, it ignores the difficulty of getting your ISP to route an RFC 1918 address to your NAT device in the first place. The very fact that your internal hosts are on non-routeable addresses is a form of protection provided by NAT.
A bit incorrect. There are IPv6 protocol changes (ex. ICMP vs ICMPv6) where the newer protocols are more secure. But actually having a private IP behind a NAT gateway is more secure in general, because nobody can directly route to a host behind your NAT, without exploiting reverse NAT traversal. IPv6 will allow easier exploitation of default host configurations due to being able to route to them easier.
NAT itself does have the security benefit of masking more bits of client identity though. If I had a bunch of machines on an ip6 prefix, I would still want their outgoing connections to be NATted, to avoid address-based tracking.
Not saying that you’re incorrect, but the problem might not be as big as you think.
Were it not for home routers supporting NAT because they need to with IPv4, the same routers would have a basic firewall with that default block rule in place.
No, it really doesn't. It makes easier one aspect of developing peer to peer software. Which sure is a good thing, but it's not some panacea. Our regressive software landscape didn't come about because end users simply didn't have easy access to routeable IP addresses. But rather because tinkering with software can be tedious, developing easy to use software takes resources, and the most straightforward way of recouping that investment through surveillance and control.
Right now, you can get a VPS with perfectly routable addresses for $5/mo. And if you're not interested in or able to afford that, you're certainly not going to leave your own machine up 24/7 as a server. In reality, IP/DNS is a namespace that's terrible for user-facing systems - it itself causes centralization by necessitating that singular authoritative servers answer requests for a named object. What we actually need for a non-corporate net is higher level addressing such as content concentric networking (IPFS et al).
(I've gotten some downvotes, and I would be really interested in hearing the actual disagreement. I know we're all biased to think this paradigm of IP4/6 could do everything we want, if only it were used "correctly". But after a few decades of watching things evolve I just don't see how it's sufficient for de-centralization).
The public commercial platforms offer far more than just a routable IP. You get reach, reliability, resilience, and security (the kind you don't get to build yourself).
Being your own YouTube/FB/Twitter/someChan/etc. platform means almost nobody will ever hear about you, the ones that do can easily wipe you off the internet, coming back is a real hassle, and that your data will leak is basically a forgone conclusion. Being your own Dropbox/GDrive may not need the reach but still relies the other three to provide value. And the list can go on for almost anything you can think of for "being your own platform".
The overwhelmingly vast majority of people have little to no interest in building and maintaining any such platform. It's why so few people actually do it today even when having a routable address. It's inconvenient even for skilled people, let alone regular ones.
I'll wait for a counterargument.
(It's fine to assert things, but make sure you're right first. Asserting things you don't know to be true is disingenuous, and a bad habit.)
Look at the speed with which WhatsApp was adopted (talking about before the FB acquisition), and compare to Mastodon or Diaspora - there is no contest.
If you somehow use them only for yourself so they run effectively as "your own" (assuming you can and want to isolate them) you run into the same issues I mentioned above.
Your comment in brackets applies very much now ;).
We'd have doused Zuck's dorm room sever in gasoline if we'd known what was to happen.
Having said that, it's still possible to hear about independent websites, nobody can "easily wipe me off the internet," and I'm pretty sure my data is far more likely to leak from actual YouTube/FB/Twitter/someChan/etc. than it is from a non-monetized, advertising-free Mastodon instance, let alone my static website. But it's also absolutely true that the best way for me to drive traffic to my web site is getting linked from Twitter or Reddit; discovery is one of the big problems for federated, decentralized networks.
It only causes problems for me with absolutely no gain. There isn't a single website I can't reach, and no website that I've found runs any quicker when using IPv6.
But at the same time, if I have v6 on, it causes delays in name resolution and sometimes I just can't connect to a site until I disable v6.
I still have an addressable v4 address, so I can still run a home server.
I don't know how to fix this. I know that v6 is good for the planet, and I know these problems won't get better until more people are using v6, but it's definitely a chicken/egg problem.
That sounds like your ISP does not actually support IPv6, eg. doesn't have the full Internet routing table for v6. I've seen this happen.
DNS v4/v6 resolutions can also hang with glibc because of a well known bug with Happy Eyeballs when ISPs that fuck up outgoing DNS packets (eg. messed up stateful NAT/DPI). "options single-request-reopen" in /etc/resolv.conf is a workaround. See https://bugzilla.redhat.com/show_bug.cgi?id=505105.
I would contact your ISP, or at least publically shame them. This is not how IPv6 Internet should work (source: we provide IPv4/v6 as an ISP and take care to prevent issues like this).
- Serving different content on IPv4 vs. IPv6, e.g. just showing Apache2's "It Works" page
- Serving some subresources behind a reverse proxy on IPv4 only (and 404ing on IPv6)
- Forgetting IPv6 AAAA Records after a server change
Trying to debug this as a user is annoying and even if I identified the issue before leaving the site, working with sites to get it fixed has been an issue. I quickly ran into the "Works for me" issue, when the administrators (and a majority of their users) ran on IPv4 only networks.
Ultimately I just disabled IPv6 on all my systems because it ends being more trouble than it's worth.
Also, I don't even use my ISPs name servers, I use Cloudflare or Google, so I don't think it's that unless the ISP is somehow munging the packet in transit, which I suppose is possible.
Honestly I think it is all due to issues with the v6 stack in MacOS.
But my point is, I shouldn't have to be a network engineer to make v6 work. I should be able to turn on my computer and just have it work.
That's exactly the problem. You send out two v4 DNS UDP packets one after another (one for A, another for AAAA), both go via your ISPs CGNAT, the CGNAT gets confused, one of the packets gets dropped. I've seen this exact behavior when talking to 8.8.8.8 on Orange in Poland (and they do DS-Lite). It didn't occur with the ISP's DNS, because a) they were also on v6 b) they weren't getting CGNATed.
> But my point is, I shouldn't have to be a network engineer to make v6 work. I should be able to turn on my computer and just have it work.
By disabling IPv6 you're letting shit ISPs get away with this. Your ability to debug this and to figure out it's the ISP's issue should be used to voice your concerns, and not just let this slide.
Maybe this is true. But as the other guy said. There is zero benefit in moving to v6 so there isn't any point in taking the time to investigate.
With RIRs running out of addresses, that's about to change (well, realistically, maybe in 1-2 years).
As techs, I think it's our responsibility to push this forward and keep the Internet free and decentralized.
I doubt it. Websites that want to be reachable will find a way to be reachable.
> As techs, I think it's our responsibility to push this forward and keep the Internet free and decentralized
I agree, but there is only so much I'm willing to sacrifice for that effort. I've tried to use v6 for at least two weeks on three separate occasions. I do that about once a year. That's the level of sacrifice I'm willing to make for this effort.
My hope is that one year it goes so smoothly I forget to switch back.
Edit: I should point out that I had no idea my machine was using IPv6 until I wondered why I was able to use Gmail and not other sites (such as HN).
I haven't seen a consumer CPE that both supports v6 and doesn't firewall off incoming v6 connections, and I haven't seen any operating system in years that doesn't enable RFC4941 by default.
If they supported IPv6, and gave me a globally routable address that was unfiltered except at my gateway, I'd be happier.
>Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.
(It's still obviously less direct, and inferior to your ISP supplying native IPv6, but it may improve your situation.)
There's a list of brokers at https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
https://6project.org/ looks viable (OpenVPN) and cheap.
IPv6 was always about maintaining the status quo. It doesn't become "better" than IPv4 until CGNAT makes IPv4 worse. (Or if your internal network reaches the scaling limits of RFC1918.)
So as long as I connect to the EC2 instance over IPv6, I get a free static IP address on my server.
a) for one as a response against CGN, thankfully my ISP isn't using one right now but I have a hunch they're going to start becoming a lot more common in the future. and b) as a hacker I'm interested to finally set it up and play around with it.
Also IMO even if it doesn't bring any improvements to the general consumer given all the pressure to start switching to IPv6 it is a good thing to be interested about it, pressuring more ISPs to start supporting it.
the isp could also provide dynamic dns as part of their package for users who do want to access their devices at home. why remember a 4-octet ip when you can get your own subdomain from your internet provider?
Maybe you could elaborate on why you assume these things are bad?
Honestly stupid that USDoD controls at least 13/256 of all IPv4 addresses.
It seems some entities, e.g. IBM and MIT, have returned (sold?) their /8s to their RIRs though.
Good on GEC, IBM, HP or Xerox for having relinquished their(s).
I figured IBM would eventually sell it off and I wasn't looking forward to the day I'd have to reIP all those systems. Glad I missed that party.
--Edit I just did a whois on some the IPs that I remember. Looks like IBM still has big chunks of the 9.0.0.0/8. Likely only sold off what they hadn't already used. Honestly I'm surprised they sold off any of them. With their cloud ambitions I'd think they want to keep them for use there.
When pressure is zero and effort is high, things will go unchanged. I'm sure once pressure exists then some movement will occur. It seems most of the industry is doing everything they can to put off incurring pressure, though.
Ipv6 really only serves to shed load off CGNAT since we rely on the continued use of v4 addresses since v6 is not interoperable with v4.
But why should Reddit support v6? For the greater good of v4 by reducing pressure of CGNAT for dual homed users. But wait, who are the dual homed users you may ask? Mobile users. And it will only be mobile users since autoconfiguring residental networks to dual home is not going to happen. But Mobile carriers have full control of addressing and TCP/IP configuration of handsets, and so they can easily deploy usable v6.
So the smaller sites shouldn't bother with v6 because they're not an essential part of the Internet with large traffic. But a site like Reddit can reduce enormous pressure for mobile carriers to deliver use of the Internet.
https://news.ycombinator.com/item?id=2174992 9y
https://news.ycombinator.com/item?id=4480532 7y
Looking forward to the next time we run out of IPv4 addresses.
First link: Last ICANN (global) RIR-reserved block assigned allocated to a RIR. End of the line for blocks that were globally reserved for, but yet unused by RIRs.
Second link: RIPE (a RIR) has one month until it starts distributing its last /8 block (185.0.0.0/8) to LIRs.
Now: 185.0.0.0/8 and small bits and bobs that RIPE still had for LIRs (ISPs) is gone. No more IPv4 for European/ME ISPs from RIPE, only gray market available.
The previous posts were the writing on the wall. Now we're actually fucked.
I checked, and IPv4 address price is somewhere between $20 and $30[0]. It's not so bad given it's a one-time buy - and using cloud services de facto creates a situation where the buying is in bulk.
The real shortage will start be when prices reach $170 I guess? Should take a few years...
Not only will no shortage occur, but the upgrades will be performed for the least cost possible. This is the kind of resource allocation problem that markets solve optimally.
There won't be a situation where a business will not put up a site due to lack of IPs, they'll switch if/when they have to.
Are there any guides for how to properly secure a home network so that I can re-enable IPv6 with a clear conscience?
For most home IPv6 networks, blocking all incoming traffic from the egress port will achieve the same level of security as a NAT'd IPv4. Different router/fw manufacturers would need their own guides on how to do that, but IMO any sane consumer product should be configured like that by default.
Here's a guide for OpenBSD, for instance. Note how it includes "block all" which means it blocks everything not specifically allowed. https://www.openbsd.org/faq/pf/example1.html#pf
ip6tables -P FORWARD REJECT
ip6tables -F FORWARD
ip6tables -A FORWARD -o wan -s 2a42:.../64 -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -p icmpv6 -j ACCEPTThis makes sense, considering ISPs might not want to deal with a ton of pwned devices that are now part of botnets.
You can always enable v6, then see if you can reach internal machines from a machine on the internet (like a VPS or over a cell connection)
They don't know what you're going to use it for and in real networks, the sensible home default of "allow outcoming deny incoming" doesn't usually make much sense. You're probably going to have dedicated firewall devices somewhere else in your network.
If you have a Asus/Dlink/whatever there's nothing special to be done.
Who cares about cookies, 1st party or 3rd party, when you have a unique ~60 bit per customer identifier?
My ISP gives un-natted IPv4, but I get a different one each time I reboot the modem, which I do every now and then.
1) ping6 ff02::1%eth0
2) Advertise the device and it's services (such as ssh) via avahi.
3) Set a static address such as fe80::1 (link local), fd00::1 (ULA), or 2001::1 (your prefix).
Most systems (maybe 70% today) couldn't reach it, it's harder to estimate how many _people_ because people may have many options to access the Network and some are more likely than others to be IPv6 enabled.
It also varies geographically, in some places (e.g. Germany) it may be about half of people who have IPv6 access, in say Australia it might be more like a quarter and so 75% could not reach that site.
As we see above in this HN thread some users intentionally disable IPv6.
If I were to remove cloudflare, more than 30% of users can connect to the site via IPv6. Problem is that other 70% will consider the site dead and move on.
But I can't send anything to such a user directly if they don't support IPv6 and I don't have an IPv4 address.
Perhaps we need some community-run webservice with an explanatory page saying "Website [something.com] requires IPv6, here's lots of documentation on how to try and fix this" and everyone could point their domain name IPv4 address to that webservice, and the IPv6 address to the real server.
For hobby projects hosted on a Raspberry Pi in someone’s bedroom, I can imagine a static IPv4 being prohibitively expensive, but that’s about it.
What you're probably going to see is increasing cost to keep a dedicated public IPv4 address. If you don't, you will probably either have to have IPv6 or NAT.
Residential will probably lose public IPv4 addresses faster than for hosting services.
Eventually maybe a premium for an ipv4 static IP on some cloud provider but that’s about it. The big players have plenty of CIDR.
They already have high-performance domain-aware routers, so you can still basically run a million websites via a single ipv4 address.
...if not residential ISPs then certainly mobile-phone/wireless providers.
Home providers will start tunnelling ipv4 traffic over v6 (this is already the case here, termed "Dual-Stack Lite"), computers will start start doing 4->6 translation locally according to instructions given over Route Advertisements, hosters will start providing ipv4 load balancers to make their VMs v4-reachable, etc.
It looks to me like we are heading to world where ipv4 will work forever, but be turned into ipv6 at the first possible opportunity.
One way to accelerate their adoption, though, could be throttling IPv4 transfers: have, say, youtube or Netflix faster at an ISP that enabled it. Or less lag for online games.
This is not 1995 when you needed to connect to other users of the Internet to get stuff done.
Fundamentally, TCP won't allow more than 64K connections from one IP to a single port on another IP. That's a hard limit on the number of users behind a NAT of any kind who can simultaneously connect to a given service on a fixed port. Right now my ISP's resolvers are returning exactly two IPs for google.com. If it were infected with CGNAT, at most 128K of my ISP's customers could use Google at the same time. The real number is much smaller as fetching a web page typically opens lots of connections.
No, I stand by it: CGNAT is dead tech that only has a short window of feasibility. It breaks way more than a migration to IPv6 would, and it's a short-sighted solution for the previous century.
With all these elastic search instances running open to the public I have the feeling that with IPv6 this will get worse as NAT no longer protects you.
Their requirement is probably for their addresses to be globally unique.
Historical addressing plans being what they are, they probably have sparse assignments across all blocks. Re-numbering existing systems is a non-trivial exercise with high costs. There is no benefit to them to doing this, and we have known this exhaustion is coming for literally decades now.
Just because they're not in use on the Internet, doesn't mean they're not in use.
> With all these elastic search instances running open to the public I have the feeling that with IPv6 this will get worse as NAT no longer protects you.
Stateful firewalls protect you. NAT does not.
You're not the first person to ask this, and the answer is: not nearly enough.
Demand for IPv4 is orders of magnitude larger than the current address space. There is no level of freeing up addresses that can make this problem go away. At most we're buying us a few months until we run out again.
I'd wager most home networks are protected only by the fact that they use NAT. ISPs are getting better about shipping routers with firewalls on by default, but it's still not there.
(Have you ever seen even an old IPv4-only home router that didn't include a firewall? I haven't.)
On a real firewall, generally you don't reroute a port to a different IP, you just pass or fail the packet.
Other large holders include Apple, Ford, Prudential Insurance and the USPS.
More easy answers to similar questions here: https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
But, now that it's happened … it shoots to the top story.
For anyone interested, the blog post from RIPE that I submitted is still up, here: https://www.ripe.net/publications/news/about-ripe-ncc-and-ri...
So why are IPv4 addresses so valuable? Mostly because IPv6 is overly-complicated and a pain to work with. We should have first added a new range where 5 of the 8 hextets were 0000. And found a simple way to write it without ::
Why wasn't that done?
The road to hell is paved with good intentions so I guess I will see you all in hell.
For client use, carrier-grade NATs allows to have 1000 IPs per customer, giving 6 million addresses.
For server use, TLS SNI allows to have one IP per datacenter, which are estimated to be around 10 million in the world.
Non-TLS inbound usage is probably relatively rare, so overall around 100 million addresses should be fundamentally enough even accounting growth.
Of course there's a lot of inefficiencies, but the fundamentals seem to say that the IPv4 address space is enough.
TLS SNI is awesome, but no plausible implementation is going to let you put an entire datacenter worth of addresses behind a single address. That's not going to happen.
IPv4's time is soon to be past. Google is nearly hitting 30% IPv6 usage already, and it's still growing. This is the way forward, not junk tech like CGN or millions of hosts on a single TLS SNI address.