32 Bit Real Estate
fly.io
fly.io
$ dig fly.io AAAA
fly.io. 590 IN AAAA 2a09:8280:1::a:791
The reality is, pretty much anyone who uses a major ISP in the US has IPv6 (Comcast, Spectrum, etc. hand them out without customers even asking), and it's even more likely in other countries.
The big blocker right now is cloud providers. I lost IPv6 on my personal website when I switched from Linode to Digital Ocean (with a load balancer instead of putting them VM directly on the network). At this point, it sounds a lot like "we paid a lot for 3.0.0.0/9 so we're going to drag our feet on IPv6 to hurt competing cloud providers".
Cloud customers are somewhat to blame as well -- enabling IPv6 doesn't get you new users today, so nobody does the work to configure things twice. But the ISPs and the users are ready. It's just us, the tech elite, that's slowing everyone down. And it makes sense, because we burned a lot of money on IPv4 addresses and we don't want our imaginary money to become worthless.
> It's just a lot of work for honestly not a lot of gain just yet. Things like HTTPS and HTTP/2 are far more impactful for users. We'll get to IPv6 eventually, but it's unlikely to happen any time soon. There are simply far more impactful things we can do with our time on the sysadmin front for the foreseeable future.
> This is something everyone on our SRE team would like to do. We just don't have the time yet, even more important things are in queue.
https://meta.stackoverflow.com/a/348224
Other services sit on giant heaps of ipv4 space and see it appreciate. For them, price increases are wonderful, because it means they can charge higher rents for the ipv4 space.
Taking action as a group to speed adoption of a technology that makes the kind of innovation and autonomy we had in the first thirty years of the Internet accessible to the next thirty years of the Internet is impactful for users. The gigantic companies who have bought /8s and /9s of IPv4 space are not going to undermine their investments. It will take companies and network operators who are big enough to decide but small enough to still be idealistic who say "yes, IPv6 is worth it and we are going to spend the time and people and money and resources on doing it."
This is the same problem we have with housing; it can't be an investment and a thing everyone needs. At least the difference here is probably no one winds up hungry under a bridge taking ill-advised substances to handle daily life simply because they don't have a /24 to call their own.
On the bright side, IPv6 adoption is increasing constantly, and if you fit the curves we'll have 100% adoption (or close) in the 2030s.
The US is ahead of most other countries with ipv6 adoption.
Here in Australia I email my ISP once a year or so asking about ipv6 support. They have "no plans at this stage". And have had no plans for years.
You can see the per-country IPv6 support here:
https://stats.labs.apnic.net/ipv6
Apparently here in Australia (like much of the rest of the world) we still only have ~25% of our population on ipv6 networks. Africa is almost entirely dark.
Weirdly India is the world leader here, with 73% of devices being ipv6 capable.
1: https://gadgets.ndtv.com/telecom/news/reliance-jio-adds-5-47...
Your browser, however, may also be circumventing all of this and may be using DoH to a public DNS server, and therefore may have a completely different DNS querying experience than what you're seeing with dig...so you should also take a look at what your browser's network inspector tells you about the host you're getting the fly.io content from.
Unfortunately, there are still major ISPs in the US that don’t support IPv6. For example, Verizon (not Verizon Wireless) has been promising IPv6 for about a decade and has so far failed to deliver.
But Verizon FIOS does not, long after they should have.
To answer the authors question: lower number ASNs are seen as older more established networks when negotiating peering. It's the equivalent of doing a WHOIS on someone's personal domain and seeing when they started seriously internetting.
Obviously shorter numbers are more memorable and easier to type frequently, which is a desirable trait for network operators.
You probably spent a few bucks on "fly.io" and applied a mental value to the outward perception of a short memorable domain.
We have a moderately-sized regional network at my employer (that's not an ISP) and I've seen a snide version of this. Our previous Director of IT who also made day-to-day decisions on things like peering would refer to 32-bit ASN holders as "six-digit trash." In his view, anyone who didn't have a 16-bit ASN was virtually not worth talking to. Not for technical reasons like our equipment didn't support the newer ASNs, just that they were Johnny-come-latelys.
He was quite proud of the fact that our employer had and still held a sizeable quantity of legacy, as in pre-RIR, IPv4 address space. I'm fairly sure one of the reasons he quit was because of the decision the board of trustees made to transfer chunks of this space to other entities in our same line of work.
Still waiting for AAAA records on news.ycombinator.com. IPv6-only SIP trunking would also be nice, since an IPv4 address is the main cost of hosting a small PBX.
I'm starting to think the RIR's should just start charging increasing YoY maintenance fees on v4 address space for companies that haven't rolled out v6. Those companies, who already have an allocation, are really benefiting from a negative externality. Maybe it's time they start paying for the privilege.
This situation is the result of poor design and roll-out decisions, not the fault of everyone else.
Impossible. You can't communicate between two hosts without both hosts being able to address the other -- and there's no way for an IPv4-only host to pack 128 bits of address into a 32-bit host field.
Many of those can be used even if your own ISP has no support for IPv6 at all. Many of the require manual configuration (as in the case of tunnel brokers) however, which makes it less likely for non-technical users to use them.
But the issue is that some ISPs (and cloud providers) simply don't care or even actively drag their feet (since it may be in their business interest to do so for now).
I think better design could have avoided that issue to begin with by facilitating smooth roll over.
Still, I'd start with translating ipv4 addresses into a reserved range of ipv6 addresses. ...and if ipv4-only clients can't initiate new connections to ipv6 addresses outside that range, OH WELL. (There's probably wiggle room to NAT your way through anyway) More importantly, if there's a default in-built way for ipv6-only machines to initiate connections to ipv4-only machines, and the ipv4 machines can return traffic via some type of NAT, there's a lot more incentive to switch to support ipv6 since more machines would be using it.
This is generally referred to as CGN, or Carrier Grade NAT. Article on CGN from 2011, as an example [0].
[0] https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ip...
That's already a part of IPv6: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
(In fact, when I store IPv4 addresses in memory/files, I just use the IPv6 encoding, which saves having a separate IP version field.)
[0] 10.10.10.10 == ::ffff:0a0a:0a0a
It suffers from a lot of practical problems, which are described at length in RFC 4966. For example, without careful special handling it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets; it breaks IPsec; it can't handle fragmentation; and it suffers from scalability issues.
Well it doesn't break them exactly. An ipv6 capable application would connect to the embedded ipv6 address and not be natted. But it fails to make a legacy application work, so you are no worse off at least.
IPv6 should just have been a superset and 0..1.xxx.yyy.zzz.ttt should have been the legacy IPv4 space. I really don't get the point of all the bizarre block assignments, hexadecimal fetish, and general "why is this seemingly purposefully such a pain in the ass" feeling I get whenever I look at it.
I'd love to just have a firewall between my SIP device and the internet with IPv6 and none of the games routers play these days.
The IPv4 packet structure looks like it has a lot of leeway to evolve/handle/crossmap to ipv6. especially with the version and "option" sections.
So ipv6 came out almost 24 years ago. And its adoption is a disaster. It's adoption rate was a disaster at the decade mark.
I don't understand why ipv4 wasn't evolved to interoperate with ipv6 at whatever level was necessary (servers, OS, routers).
I don't understand why there isn't an evolved ipv4 that can route ipv6 and ipv4 traffic to the same application endpoints.
I don't understand why there isn't a section of ipv6 address space that is "special" that contains all of ipv4 + possible ports for NAT.
I'm sure there are reasons, but I've also seen a lot of dogma from ipv6 people over the years that comes off as my way or the highway.
But why you can't get the big boys in the room in the modern corporate-consolidated internet (AWS, MS, FAANG, US government, europeans, mobile carriers etc) and work out how to get ipv6 transitioned.
To me, ipv6 was always a lot like the security group at large companies: they dictated a policy, tried to enforce compliance, but never offered solutions. And solutions is what gets your policy or protocol adopted.
Why not charge a premium for even one distinct public IPv4 address? Most applications are HTTP(S)-based and could share a reverse proxy with a thousand other apps, right? You could even spin the lack of distinct public IPs as a positive: zero IPv4 footprint.
1. We don't want to do anything to discourage people from building non-HTTP applications on Fly.io, because we're fans of weird applications.
2. Just giving every app a routable address simplifies our own deployment logic (at the expense of acquiring blocks of IP addresses).
Really, the reason we were moved to write about this is (2); specifically: so long as IPv4 addresses are appreciating assets (as current buyers, we can report: they remain appreciating assets), then there is a sense in which holding IPv4 blocks is really just holding money in a different, somewhat less liquid (but potentially profitable) form.
We're not saying that's a good thing, just that it's interesting that you can essentially take out a mortgage on a large block of addresses and live in it while it appreciates.
Try running your SaaS app on an IP address shared with a porn site and you'll quickly discover all the strange ways older middle-boxes try to police network traffic.
If you want to talk more about getting additional IPs, Mark at your provider is a super smart dude, or you can ping me offline.
This is a hard market to time. Nobody
believes the Internet will be IPv6-only
within the next few years. There are
credible people who believe IPv4 addresses
will be scarce and useful indefinitely.
We might put money on you getting away
with an IPv6-only app 20 years from now.
But we'd have said that 20 years ago, too.
In 5 years (2016-2021) it went from 9% to 35%.
Source: https://www.google.com/intl/en/ipv6/statistics.html
TL;DR: it's being adopted at 5% of internet traffic per year, over the past 5+ years.
Once it gets to 80% or so, some number, there plausibly could be a flood of "we don't support IE6" behavior where adoption accelerate.
But that would still be 9 years, if the rate of adoption didn't accelerate at all.
SNI is nothing but a PITA for users who don't want to send Host headers in plaintext over the wire.
It may be a small number of users who are aware of the SNI leak, but it doesn't mean they are being unreasonable for wanting to plug it.
https://curvecp.org/addressing.html
"An ISP or site administrator can easily run a huge number of CurveCP servers on a single global IPv4 address, even if the servers are independently operated with separate long-term public keys. This feature is provided by a simple extension mechanism in CurveCP addresses.
CurveCP servers are inherently anti-aliased, providing automatic virtual hosting and fixing some of the deficiencies in the "same-origin" policy in web browsers. This feature is provided by a simple domain-name mechanism in CurveCP addresses.
If a site has two server addresses, and one server is down, a CurveCP client will quickly connect to the other address.
A CurveCP connection remains fully functional even if the client changes IP address.
CurveCP is fully compatible with existing NAT (network address translation) mechanisms; none of the above features require clients or servers to know the global addresses of their gateways."
I will keep using CurveCP forwarders on the home LAN because I like it and just in case it ever sees interest from a wider audience, like Curve25519 eventually did. No expectations.
Popular graphical browsers send a servername in the ClienHello even when SNI is not required! (Most HTTPS site submitted to HN do not require SNI.)
To see how SNI leaks host names,
https://github.com/kontaxis/snidump
# example.com - with no SNI
echo -e "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n"|openssl s_client -connect example.com:443 -ign_eof -noservername
# example.org - with SNI
echo -e "GET / HTTP/1.1\r\nHost: example.org\r\nConnection: close\r\n\r\n"|openssl s_client -connect example.org:443 -ign_eof -servername example.org