0

Tell HN: IPv6-only still pretty much unusable

 1 year ago
source link: https://news.ycombinator.com/item?id=33894933
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Tell HN: IPv6-only still pretty much unusable

Tell HN: IPv6-only still pretty much unusable
327 points by 9dev 5 hours ago | hide | past | favorite | 302 comments
Our Hosting provider, Hetzner, has recently started charging for public IPv4 addresses - as they should! Those numbers started getting expensive. This prompted me to try and set up a new server cluster using IPv6 exclusively, and see how far I could get before having to give in and purchase an additional v4 address.

The experiment ended much sooner than I had anticipated. Some of the road blocks I hit along the way:

  - The GitHub API and its code load endpoints are not reachable via IPv6, making it impossible to download release artefacts from many projects, lots of which distribute their software via GitHub exclusively (Prometheus for instance).
  - The default Ubuntu key servers aren't reachable via IPv6, making it difficult to install packages from third-party registries, such as Docker or Grafana. While debugging, I noticed huge swaths of the GPG infrastructure are defunct: There aren't many key servers left at all, and the only one I found actually working via IPv6 was pgpkeys.eu.
  - BitBucket cannot deploy to IPv6 hosts, as pipelines don't support IPv6 at all. You can self-host a pipeline runner and connect to it via v6, BUT it needs to have a dual stack - otherwise the runner won't start.
  - Hetzner itself doesn't even provide their own API via IPv6 (which we talk to for in-cluster service discovery. Oh, the irony.
It seems IPv6 is still not viable, more than a decade after launch. Do you use it in production? If so, how? What issues did you hit?
IPv6 has been one of the biggest failures in the last couple of decades.

And I don't mean adoption, I mean the standard itself.

If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade.

Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.1.2.3.4).

Not having two sets of firewall rules and two sets of everything. I always disable IPv6 because it can bite you so hard when you don't realize that you are wide open to IPv6 connections because of different firewalls.

Edit: To make everything a bit clearer, the idea with this "ipv4+" is that you don't need the complexity of running both ipv4 and ipv6 as you do now.

And regarding compatibility, with ipv4+ if you have a 0.0.0.0.x.x.x.x ip address you would be able to talk to both ipv4+ aware and legacy ipv4 devices natively without any tunneling (because you also own the legacy, non quad 0 ip address). If you don't have such "quad 0 ip" (you are 1.1.1.1.x.x.x.x), only ipv4+ aware devices would be able to to connect to you, and for you to connect to non ipv4+ aware devices you would need either tunneling, or having a secondary, cgnat, "quad 0 ip".

s.gif
> And regarding compatibility, with ipv4+ if you have a 0.0.0.0.x.x.x.x ip address you would be able to talk to both ipv4+ aware and legacy ipv4 devices natively without any tunneling (because you also own the legacy, non quad 0 ip address).

This exists:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5

You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", and this (lack of) upgrading and enabling is what is hampering deployment.

What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

s.gif
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

I'm pretty sure that those who built new protocol were aware of this and were like "anyway we are gonna have to upgrade network devices. Why don't we build a new protocol while avoiding pitfalls of older one"

Any comittee that sat down to solve IPv4 issue would have thought of compatibility first.

I am shocked that so many people agree with OP's armchair solution here.

s.gif
Mayne RFC exists, but it os not used in teal world anywhere. In all servers, I configure IPv4 and IPv6 separately. Network setup is separate. DHCP daemons are separate. Firewall rules are separate. Network monitoring is separate.

I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is too much for me.

s.gif
> I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is too much for me.

And exactly would you accomplish this switch to a larger address space? Please explain the steps exactly how they would be done.

Because IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How exactly do you fit in >32b in a data structure that is only 32b? You cannot.

So you have to go and replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.

s.gif
Ok. How do you increase address space without breaking the protocol? IPv4 just doesn't have the space in the header. Something like "v4+" can't happen for this reason.

You could argue that pervasive use of NAT beginning in the late 90's was "v4+". It bought us decades of Internet growth, at the expense of true end-to-end connectivity.

s.gif
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

Way less resistance from tech teams. Ultimately companies are made of people, and ipv6 is partly a failure because working with it requires a wholly new skillset

s.gif
Maybe it’s different on the software side but coming from a network VAR it’s the same skill set. You still have subnets and routes and netmasks and DHCP or automatic assignments the difference is the size. If you know IPv4 all you need to learn is “the subnets are all /64 in size, addresses are 128 bits, and you don’t need DHCP if you don’t want”.
s.gif
Let's not forget about the idea that ISPs would distribute a /56 range to residential users. You could split it in /64 ranges according to your requirements and everything would work fine.

There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan.

That makes IPv6 not only useless but also a huge security issue.

1) I can't use my Mikrotik as a firewall. Trying to split a /64 range breaks things and some devices ( specially IOT ones ) will simply not work.

2) Routers provided by the ISPs here are very limited, specially for things like firewall rules. Some of them will only provide a On/Off switch, with Off option between the default one.

Although IPV4 + NAT had some issues, it ( accidentally? ) created a safe/sane default config for non-technical users. In order to open a port and expose a device, you have to explicitly add a rule on the firewall.

IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.

In the last 3 years I've noticed criminals focusing more and more on IPv6 scans to compromise devices and create botnets since it's much easier to find exposed/unpatched devices as most users don't understand how to correctly configure a firewall.

Most of the time, the only viable solution is to disable IPv6.

s.gif
RouterOS v7 supports DHCPv6 prefix delegation. You can request a delegated /64 per downstream interface and announce itself as router using these prefixes. You can still use your MikroTik device as router, stateful firewall, proxy. You don't have to mess with smaller than /64 allocations on links unless your provider forces a broken CPE on you that doesn't support DHCPv6 prefix delegation.

Have you actually seen any large scale deployments of CPEs without an active IPv6 firewall blocking incoming connections by default?

s.gif
Fritz!OS also does, it's used by many consumer routers in Germany. There is of course also OpenWRT.
s.gif
Same situation, I use IPv6 NAT and VPN, huge letdown but c'est la vie.
s.gif
One of the ideas of ipv6 was to reduce routing tables, those tables that backbone providers have to keep in memory and look up for incoming traffic. With ipv4's fragmented allocation scheme, these routing tables are huge. With ipv6, even huge companies like amazon only have a couple of global allocations. A "ipv4 with more octets" scheme would have kept that fragmentation around.

That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/

Also, there are definitely some horrible ipv6 warts, like that the only standard for local ipv6 addresses forces you to adopt a scheme where your local address is horribly long, for the sake of global uniqueness, which is something that most people don't really need.

s.gif
> where your local address is horribly long, for the sake of global uniqueness, which is something that most people don't really need

Apart from debugging where you can copy-paste anyway, does it matter? I've got a few services on the local network and over zerotier that all talk IPv6. In the last 3 years or so I've never used an ipv6 address directly. There's enough DNS and discovery protocols that I never needed to.

s.gif
I'm not up to date, but when I knew about this stuff the cost of memory for routing tables was only a tiny, tiny fraction of the cost of a network. Most of the cost is burying and maintaining fiber.

So unless something big has changed, it seems like a terrible choice to twist the whole system into uselessness to try to save a small amount of RAM cost.

s.gif
> Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess?

Whole IPv4 address space is 4294967296 addresses.

A single /48 is 1,208,925,819,614,629,174,706,176.

And 2804:800::/32 is 79,228,162,514,264,337,593,543,950,336.

s.gif
Gp comment refers to the number of routing table entries, not total number of addressable ips.

Ideally the number of ipv6 allocations should be close to 1 rather than close to 1000.

s.gif
It's already more or less how IPv4 addresses are embedded in IPv4 (except its 128bits and they use an FFFF prefix between the 0 and the IPv4 address).

IPv6 doesn't solve anything for the sake of it. Anyone who had to debug ARP caused issue on a network knows it's complete garbage for example.

Providers who explain that they are dragging their feet because of the complexity would have said exactly the same thing even it was only IPv4++. They just don't want to invest any money in something which is working for them.

s.gif
> Not having two sets of firewall rules and two sets of everything. I always disable IPv6 because it can bite you so hard when you don't realize that you are wide open to IPv6 connections because of different firewalls.

nftables gives us a dualstack firewall, and it's so far the only one I've seen. It's not that bad, but I have occupational damage so I don't mind :D

https://wiki.nftables.org/wiki-nftables/index.php/Nftables_f...

s.gif
It’s the firewall rules that always creep me out. The nice thing about NAT is open ports on your internal network are hidden to the outside world by default. You have to think about which ports you want the NAT gateway to forward.

With IPv6 the entire network is reachable outside by default. Granted I assume you can probably create a default DENY rule for inbound traffic and selectively open ports up as exceptions. Right?

s.gif
> With IPv6 the entire network is reachable outside by default.

The entire network might be routable, but it often isn't reachable. My router had a default deny rule, so everything in my network for sure wasn't reachable by default despite having IPv6 addressing.

If anything, I like firewalling in IPv6 far better than dealing with NATs. Just imagine having multiple boxes you'd like to reach by SSH or HTTPS from the outside. With NAT, you can only run one on a standard port. With IPv6, there's no need to NAT, everything can just use one of their many public IPv6 addresses, and then I can firewall to allow traffic to each of those boxes at the standard ports.

In fact, this gets even cooler. I can then have multiple services all bound to different IP addresses and have different firewall rules related to each of those services. There's so much more possible using IPv6 that you just practically can't do in IPv4, unless you just happened to have a /8 assigned to you back in the day.

Think about this: every device in my home network gets more IP addresses assigned to it than there are IP addresses in IPv4. I can have every container on my cluster have its own publicly routable IPv6 address, every application I run could theoretically have its own address and have its own network rules applied. And then I can look at my network edge and immediately identify any and all traffic flowing through that edge.

I can't wait until IPv4 is dead and I never have to deal with NAT issues again.

s.gif
No.... Absolutely no...

NAT is absolutely not in any way a substitute for an actual firewall, despite the side effect of 'blocking' ports.

And how is "You have to think about which ports you want the NAT gateway to forward." any different from thinking about firewall rules?

And most consumer CPE devices (i.e. 'router' etc) are perfectly capable of running a firewall, and often do.

And any firewall that doesn't drop inbound traffic by default is not really much use at all.

And lastly, if you want you can still do NAT66 if you really must, or IPv6 network prefix translation, which is a slightly improved version.

s.gif
>NAT is absolutely not in any way a substitute for an actual firewall, despite the side effect of 'blocking' ports.

This is one of those infosec tenets that is technically true but functionally unhelpful. Like correct-horse-battery-stable debates.

The claim is that IPv4 + NAT + bad firewall is better than IPv6 + bad firewall.

Yes, both are insufficient and inferior to a good firewall - but how confident are you that you never interact with a bad firewall?

s.gif
What makes you think that, for critical systems, "IPv4 + NAT + bad firewall" is the default IPv4 deployment paradigm, rather than "IPV4 + bad firewall"?

Sure, big IaaS providers like AWS put you in a VPC by default. But most servers on the net are not hosted in an IaaS; they're hosted using a VPS or bare-metal hosting provider, or just coloed in a DC by their owner. And in all those cases, what that kind of deployment gets you, is a public IPv4 per VM/machine, that anyone on the Internet can march right up and talk to, where it's the responsibility of the machine itself to reject incoming packets (i.e. at the OS level with a kernel firewall.)

NAT on IPv4 is only really a default assumption for residential networks. Anywhere else, it's pretty much like the movie WarGames: even the mainframe has a phone number you can call. Staying on IPv4 isn't making anyone safe.

s.gif
While I don't have any factual proof to refute your statements, in my personal experience almost every organization uses NAT & RFC1918 address space. The only client I can think of in my 20 years of experience that used a public IPv4 per VM/machine was the DoD, specifically, the U.S. Army.

From your very last statement, I think you've confused self hosting (like buying a VPS from Digital Ocean and hosting your own blag) and how the real world works (like going to Dell.com and ordering a new laptop). "The mainframe" these days is almost always behind a L4/L7 load balancer or other network device and very rarely directly addressable.

s.gif
I use an old Parallax Propeller server as my DMZ, with instructions to log everything and answer "OK" to everything. It's funny what people try to do to it.
s.gif
Why don't you write a blog post about this? I'm interested to see what will go on
s.gif
It is a substitute to an actual firewall because I don't need a firewall since NAT makes all of my listening ports unavailable to my WAN.
s.gif
Depending on the NAT implementation this can be incredibly naive. Many home routers will send ANY traffic incoming on a port to the NAT'd IP address, even if the sources don't line up.

So say Alice is behind a crappy NAT and wants to talk to Bob. Alice's router opens a port on its edge, lets say 1234, and sends traffic to Bob on port 80.

Let's say Charles knows Alice's IP address. Charles starts spamming Alice's router, eventually hitting port 1234 with bad data.

Alice's router is dumb. It sees traffic on port 1234, checks its NAT table, and sees that data is supposed to go to Alice. It happily rewrites that packet and passes it along to Alice. Now Alice is getting traffic from Bob *and* Charles. Uh oh!

Many game consoles are explicitly designed around this bad, broken behavior. You'll open a port to the matchmaking server and then the matchmaking server will tell people to connect to that IP address and port combination. Crappy home routers will happily route that data through its NAT configuration to the console despite the console never explicitly opening up traffic to those other parties. This is why some game consoles will complain about closed NAT versus open NAT.

s.gif
That's like saying that a bad firewall implementation leaks like a sieve. This is not what I was talking about.
s.gif
Any router running a poor NAT implementation (aka most of them) essentially has a built in firewall bypass for the right attacker.

A naive NAT implementation can allow an attacker to bypass the firewall.

s.gif
I gave an example just a few comments above this. Alice never wanted Charles' traffic, the firewall should not have let it through. But because the NAT is dumb, and the firewall rules are often tied to the NAT on these crappy home routers, it's allowed. So now because Alice wanted to talk to Bob, she opened a port to the world that she never wanted opened as wide.
s.gif
those of us who want to have the same port on different computers available to the internet might see that as a bad thing
s.gif
Oh you don't need a firewall then? I guess accessing a routers web interface from the WAN is a-okay
s.gif
My shitty cable modem which is also a router does not expose its web interface to the world by default.

I don't understand why you'd need a firewall if

- you trust devices on your network (yes, big if, but even then: the only reachable ports of a machine from the outside are those explicitly open to the outside, most stuff listens to 127.0.0.1 anyway)

- you only configure your NAT to forward ports you would open on your firewall

s.gif
My shitty router also firewalls incoming IPv6 connections by default, unless I manually allow them per-device, so I don't get your point.
s.gif
My point is lzaaz's one https://news.ycombinator.com/item?id=33897568

I didn't think of my cable modem as a firewall. Maybe technically it has one to provide the feature of blocking access to its web interface from the world, or maybe it just listens to the right network. I don't know, but for all intent and purposes, setting up a firewall myself does not seem necessary.

To be fair, I was also a bit annoyed by staringback's phrasing.

s.gif
My router's httpd listens on the LAN not the WAN unless I tell it to. This is unrelated to what I said.
s.gif
> It’s the firewall rules that always creep me out. The nice thing about NAT is open ports on your internal network are hidden to the outside world by default. You have to think about which ports you want the NAT gateway to forward.

Have you never had more than a handful of IPv4 addresses? IPv6 works the same in this regard as a router IPv4 network e.g. universities, large/old enterprises etc. NAT started as a workaround to make the available public address space last longer.

The address (and port) translation wasn't intended as a security feature on its own. These days lots of protocols automatically deal with NAT and mostly manage to establish bidirectional communication over UDP or TCP through NATs. I rather deal with stateful firewalls and public IPv6 addresses end to end instead of gluing the segments of flows between IPv4 translators back together.

s.gif
> Granted I assume you can probably create a default DENY rule for inbound traffic and selectively open ports up as exceptions. Right?

Sure, of course. That’s how firewalls work for IPv4 as well— you have an implicit deny rule at the end, and then allow rules come before it.

s.gif
Every consumer and professional router I've seen comes with a deny rule for incoming traffic by default, unless the device is configured as a "router router", like inside an ISP.

NAT has many problems because people rely on it for security. For example, many shitty IoT devices and even consoles (looking at you, Nintendo Switch) tell you to put their device in the DMZ to make them work.

The norm for IPv6 in practice is that you've got your firewall on and need to make exceptions for ports you want open, just like on IPv4, except that with IPv6 you don't need some kind of interactive state machine attackers can confuse and abuse running inside your router's kernel (ALG).

s.gif
> Granted I assume you can probably create a default DENY rule for inbound traffic and selectively open ports up as exceptions. Right?

That's what reasonable people would do for a V4 network too.

s.gif
> The nice thing about NAT is open ports on your internal network are hidden to the outside world by default.

That is usually not true. NAT punching is a thing for decades now.

s.gif
- NAT punching does require cooperation of programs on the protected machines, though, no? How is it different from them inviting traffic in any other way (like, requesting a page via https from an infected server could hijack the client on the protected machine if the client has security holes in the right places; the https client is willing to get traffic here, just as some VoIP program is willing to receive a call)?

- And is it any different from a stateful firewall on IPv6?

s.gif
I just started University, and as a result I have had my first experience of Internet without NAT. The firewall rules provided are simply On or Off, which has been very strange to me, and it doesn’t seem all that secure.
s.gif
My own ISP provided router is by default setup to deny all inbound traffic on IPv6. I'm surprised it's not the default everywhere.
s.gif
My ISP doesn’t support IPv6 at all, unless I want to voluntarily go behind a CGNAT.
s.gif
it's the default behaviour by most cpe, correct

any exceptions to this should be roasted (my twitter dm's are open)

s.gif
> With IPv6 the entire network is reachable outside by default

Only, and only, if you configured your router that way.

In both cases, it's absolutely the same:

    IPv4 -> allowed NAT ports -> NAT network -> Everything else is dropped/denied
    
    IPv4 -> allowed ports -> directly routed IPv4 network -> Everything else is dropped/denied
    
    IPv6 -> allowed ports -> directly routed IPv6 network -> Everything else is dropped/denied
See?

Of course if you are on someone's else network (typical for hosting when you aren't provided with your own v6 subnet, instead you have a bunch of addresses) then you should configure firewall on each your machine... which is what you need to do anyway?

s.gif
> If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade.

I don't really think so: it woulds still be completely backward incompatible and still require replacing a lot of costly network equipment. I think that's the main reason why large ISPs and enterprises have been postponing the upgrade since forever but operating systems, smartphones and other new devices didn't really have a problem with it.

s.gif
It's been decades. The vast majority of network equipment already has been replaced multiple times since IPv6 became a thing that people "understood" we would switch in the future.

The difference is that instead of their ipv6 being broken, partial, or correct but non functioning because it needs additional configuration, it would properly work and support with the much simpler "ipv4+"

s.gif
But IPv4+ is incompatible, so it requires to maintain two network stacks until reasonably everything has moved over to it. You need to duplicate the configuration for DNS, routing, firewalls etc., exactly as for dual stack IPv6. I don't really see a difference.
s.gif
Imagine I own a company and I already have a bunch of IP4. I upgrade my network equipment to IP4+, and then keep all my routing and firewall configs. Everything just works the same as before. Now I want to access IP4+, so I add a route entry for all the IPs above 255.255.255.255. In fact, if that entry is just "send everything to my upstream" it might already work!

Now I want to add some new resources but I'm out of IPv4 space. So I get some IP4+ space and a new host with a new firewall rule for the new octet and a DNS entry. Of course only other people on IP4+ can reach it, so I use it for my internal tools since I know all of my clients support IP4+.

Then I want to use it for a public service, so I add a dual DNS entry of 0.0.0.0.1.2.3.4 and 1.2.3.4. IPv4 clients get 1.2.3.4 and IP4+ clients get 0.0.0.0.1.2.3.4. Now I can start collecting data on how many people support IP4+. When it gets high enough, I can shut off the v4 address and move it to IP4+ only.

It would make the transition just soooo much easier, because the changes are much more incremental. I don't have to set up a whole new dual stack. I can just make a few dual entries.

s.gif
The evidence at this point I think refutes your argument. It's been the case for a while now that basically all the hardware, all the networking stacks, all the major libraries and software supports IPv6. So the reason people haven't switched to IPv6 as quickly is because there's all sorts of hidden IPv4 assumptions that take significant effort and energy to get rid of--and there's relatively little resources being devoted to rooting those out.

The kinds of things I'm talking about are places where an IP address is stored in a uint32_t in the middle of your core business app somewhere. Or maybe you've got some log sniffing that only looks for four dotted octets and can't pick an IPv6 address. Those are the sorts of things that if you move to any system that's not IPv4, it's just not going to work period. And you're often not going to discover that you have these issues until you try forcing things to use not-IPv4.

A migration I've been working on--admittedly not in networking--has been LLVM's opaque pointer migration, and the vast majority of the time has been spent not figuring out how to get rid of every "pointer_type->getPointerElementType()" call, but in quashing all of the assumptions like "this input operand has to be a bitcast of a global variable" that is violated by the pointer migration. I have no reason to expect that the IPv4-to-IPv6 migration is not similar, in that most of the effort is going to be spent on code that you didn't think would assume it is using IPv4.

s.gif
> Imagine I own a company and I already have a bunch of IP4. I upgrade my network equipment to IP4+, and then keep all my routing and firewall configs. Everything just works the same as before. Now I want to access IP4+, so I add a route entry for all the IPs above 255.255.255.255.

It does not. Because 255.255.255.255 only covers 32 bits and "IP4+" is >32 bits. You'd still have to touch every rule to to tweak the mask.

Oh, and your IP4+ idea already exists:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5

You still need to upgrade bit of networking kit between the source and destination to understand "IP4+", and this (lack of) upgrading and enabling is what is hampering deployment.

What makes you think that companies would have been willing to make the effort to deploy "IP4+" any more than IPv6?

s.gif
> You'd still have to touch every rule to to tweak the mask.

No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing. If the rule says 1.0.0.0/8 then the router converts it to 0.0.0.0.1.0.0.0/40. If you happen to have 1/8 as your rule, then an easy fix is to say ip4+ translates shorthand rules at ipv4 if the mask is under /32.

> What makes you think that companies would have been willing to make the effort to deploy "IP4+" any more than IPv6?

Because when they went to upgrade their router, as they often do every decade, it would just support IP4+ with no config changes on their end. They would pull their config from their old router and it would just work.

Then they would discover they had IP4+ support and maybe start using it.

The reason it is easier is because it's a small incremental change.

s.gif
> No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the same thing.

I don't see why the CIDR would make a direct difference. Whether it's converting 1.0.0.0/8 to 0.0.0.0.1.0.0.0/40 or 2002:c000:0204::1.0.0.0/96 doesn't seem to matter to me. The only difference I can think of is local networks (10/8, 192.168/16, 172.16/12) but your suggestion would fail in the same way.

Several compatibility systems for IPv6 exist. 6to4 is the most common one I've seen. It all works on a technical level until DNS gets involved.

> Then they would discover they had IP4+ support and maybe start using it.

If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional.

s.gif
> If your business network is managed by "hey, this feature exists, let's see what happens if we turn it on" then your network admin needs to be more professional.

I think this is why you don't understand how IP4+ would be easier. 99% of companies make their "IT guy" manage the network. They aren't network professionals. They are mostly desktop professionals who also get forced to manage the network and firewall. Same with most schools -- they can't afford to hire network professionals. Sometimes they get lucky and someone is excited about learning networking, but that's not true in most cases.

If they already have a bunch of IPv4 rules that some contractor wrote once, and they have a vague understand of how those rules work and why, they don't want to learn a new scheme or run 6to4 or anything else. They just want it to work by copying the old config and then maybe if they have time they can explore the new features of their new equipment.

s.gif
If it's just "The IT guy", then IPv6 will work out of the box for outgoing traffic and will block all incoming traffic. This is why almost half of the USA is using IPv6 right now, it's just turned on by default.

Hosting stuff is harder, but it's also that different. Theoretically, you can NAT IPv6 traffic to an IPv4 server inside your network no problem, but it's a pain and nobody really needs it anyway, so it's not widely used.

s.gif
I think you're missing the point. You're a network engineer and know what you are doing. Most people aren't.

IP4+ would be easier because it's more incremental and less change than IPv6.

Yes, there exists solutions to all the problems that IP4+ would solve, but the point is backwards compatibility and incremental change is always easier than doing something new.

s.gif
But, correct me if I'm wrong, IP+ doesn't do anything differently from IPv6, except that it changed the 6to4 prefix?

Host 1.2.3.4.5.6.7.8 still can't communicate with a "legacy" host 4.5.6.7 without some kind of bidirectional translation mechanism. Just prepending 0.0.0.0 to an address (or 2002:c000:0204, for that matter) doesn't fix the problem.

s.gif
Do addresses have a variable length in your IPv4+ header?
s.gif
I still don't understand why they shifted from 0:: to ffff::

but point stands, ipv6 is exactly ipv4+, except yes, they did redo arp. I don't think its really that much better...but really? that's what turns something from great into awful?

s.gif
If you really wanted you to could keep you old addressing scheme in IPv6 (arbitrary IPv4 addresses can be embedded into IPv6), you can disregard all best IPv6 practices about subnetting and do everything like you did for IPv4, DHCP and all, heck even NAT. The problem is that as soon as you're turning it on you need to maintain two sets of routing and firewall configs, even if they were identical.

Also you need proper support from all those lazy vendors (both hardware and software) that did the absolutely minimal amount of work to advertise their products as IPv6 ready when it fact the support ranges from subpar to practical unusable.

As soon as you make a one bit incompatible change to the protocol routers aren't able to communicate anymore: it's the same situation again. It doesn't matter how similar the two protocols are, they're incompatible.

s.gif
It provides a lot of improvements actually. Stating the obvious, NAT isn't needed anymore. Also with modern Firewalls rules need to be written only once. At this point I'm just surprised why it's not adopted
s.gif
> NAT isn't needed anymore.

False.

The most obvious case is multi-homing (for redundancy, fail-over, and policy-routing reasons) without an AS available and thus without BGP. In other words, a typical case when a user has a fiber connection and LTE as a backup. Then it is the router who should pick the correct source address, according to the link which is up.

Another reason is to deal with dynamic addressing from the ISP. Let's suppose we have an ADSL PPPoE connection, with prefix delegation. The modem connects, gets a prefix, devices grab IPs from it. Then a rat chews upon the line, causing a disconnection and a reconnection - but the ISP now delegates a different prefix. Or worse - the modem crashes and reboots, also picking up a different prefix. Devices are still not picking up such unexpected renumberings well. So they continue using old addresses, which don't work. Using a layer of network prefix translation solves the problem, as now only the router needs to be aware of the renumbering that has just happened due to the rat.

s.gif
>> * NAT isn't needed anymore.*

> False.

"IPv6 Multihoming without Network Address Translation"

   Network Address and Port Translation (NAPT) works well for conserving
   global addresses and addressing multihoming requirements because an
   IPv4 NAPT router implements three functions: source address
   selection, next-hop resolution, and (optionally) DNS resolution.  For
   IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network
   Prefix Translation (NPTv6).  However, NAT and NPTv6 should be
   avoided, if at all possible, to permit transparent end-to-end
   connectivity.  In this document, we analyze the use cases of
   multihoming.  We also describe functional requirements and possible
   solutions for multihoming without the use of NAT in IPv6 for hosts
   and small IPv6 networks that would otherwise be unable to meet
   minimum IPv6-allocation criteria.  We conclude that DHCPv6-based
   solutions are suitable to solve the multihoming issues described in
   this document, but NPTv6 may be required as an intermediate solution.
* https://datatracker.ietf.org/doc/html/rfc7157
s.gif
The correct way to do this is to advertise the fiber connection's prefix to devices on LAN as long as that connection is available. When it fails, the router should send RA with zero as the expiry time for that prefix, and include the LTE prefix. This way, all devices will immediately start using the new prefix. You can use ULA in addition so local connections don't fail.
s.gif
This can work with the fiber + LTE example, and with the rat example, but does not cover the "modem crash" example. The ADSL modem does not know its old prefix, and thus cannot send zero-expiry-time announcements for it.

Also consider a case where there is an ADSL modem (with the ISP giving out /56 via prefix delegation) and a home lab with virtual machines, that are behind a virtualization host, which grabs a subprefix (let's say a /64, separate from the main home LAN /64 prefix) for its VMs from the modem via DHCPv6. While there is indeed a mechanism for flash renumbering over SLAAC, which may work for devices in the home LAN, there is also a need to invalidate the subprefix delegated for virtual machines via DHCPv6 through the virtualization host. Last time I checked, this is not implemented anywhere.

s.gif
ISPs love NAT because it is an artificial distinction between producers and consumers, which means they can call the producers ‘pro’ of ‘enterprise’ and charge them through the nose while the consumers can’t cause trouble and just pay for download speed.
s.gif
Going by my current experience of managing an ISP, the number of people that care at all about producing anything is almost zero. Out of thousands of accounts I can count on two hands the number of people that want anything outside of the standard ipv4 symmetric 1gb we offer.
s.gif
When infrastructure makes it really hard for people to produce things, then there's no ecosystem for it and very few people get interested in producing things.

At-home hosting would open up tons of applications. You could have at home video cameras that are actually private (no third party connection). You could share photos with family and friends from a home photo frame - directly. There could be tons of applications that normal people would be interested in.

s.gif
Perhaps the don’t say they care about producing content but surely they care about accepting (voip) phone calls, being able to torrent twice as fast (because they would be able to connect to twice as much peers) and they’d also like all these services that just don’t exist anymore because too many people are behind NATs they can’t control.

The popularity of uPnP for automatic port forwarding should be a clue, anything that uses that is blocked by cgnat.

s.gif
Inertia on the part of large services, providers, and infrastructure isn't much of a surprise.
s.gif
> (1.2.3.4 can be referred as 0.0.0.0.1.2.3.4).

Which would need translation support at the edges between devices speaking only old-IPv4 and the superset-IPv4. Just as is done with IPv6.

s.gif
Obviously hardware would need to be upgraded. But it is much much simpler, and you don't have separate configurations for Ipv4+ and ipv4.
s.gif
Except that it would be a small incremental change instead of a whole second stack.
s.gif
I always joke with "We figured out how to move from Python 2 to 3 but we still cannot figure out how to do IPv6" :). What a catastrophic failure it has been. Should we just stop using it altogether and retire or are there people still advocating ?
s.gif
Yes, people are using ipv6 for real deployments. See any large scale mobile network deployment. Funny thing is most people never realize because it all just works…
s.gif
How is a host with a 32-bit address supposed to communicate with a host with a 128-bit address when it can only send packets with a 32-bit address?
s.gif
That's a solved problem whose solution is called ipv4 over ipv6 tunneling.
s.gif
that will cause state and can hurt performance since it needs extra memory. one of the main selling point of IPv6 is try to be stateless as much as possible to ease up on routers and switches
s.gif
Where's the need for state? Please excuse the abuse of terms below, but you can probably figure out what I mean.

A v6 only host would send a v6 packet from it's full address to the v4+ address. A router on the path that has access to v4 internet would pull the v4 destination out, and reframe as a v4 packet (source ?, dest the v4 address), that's got the v6 packet, or maybe just the addresses, I dunno. This router would burn a lot of CPU doing this, but doesn't need any state.

The v4+ host has a little harder job, it needs to know a v4 address to send the tunneled packets to. But again, it's sending a tunneled packet, and whatever is processing that doesn't need state, it just needs cpu to inspect and untunnel. Of course, if the v4+ address is rfc1918 (or otherwise unroutable), then that's problematic. You _could_ do NAT at the router, but I'd say don't do that.

It might be useful for the v4 host to keep the v4 tunnel sender IP from incoming addresses to reframe on the back end.

You might also do something special with routing to the v4+ prefix... if you advertise the v4+ address, it indicates you want v6 -> v4+ traffic to go to your network as v6 and you'll encapsulate it, otherwise it would go a (hopefully local) router that advertised the /96 prefix. If this encap/decap turned out to be popular, you might see router ASICs accelerate it, but likely it's expensive, so the work should be distributed to end points as much as possible.

Of course, there was Teredo that kind of tried to do something like, but it didn't really work out, did it?

s.gif
It’s mostly a solved problem as most mobile network operators are ipv6 only now. My iPhone only has an ipv6 address for example.
s.gif
If it's not "Ipv4+" aware, it wouldn't be able. Otherwise it would understand new packet formats.
s.gif
So exactly like current situation, with content providers forever stuck at providing old version for old clients.
s.gif
The difference is that this ipv4+ would be easier more gradual and less scary to adopt. I edited my original comment to explain a bit more.
s.gif
IPv6 is the Python 3 of networking, although adoption is taking far longer than Python 3. Hopefully the lesson has been learned and this won't happen again.
s.gif
I feel the same way.

Clearly ipv6 is very flawed and by now the community should consider it a failure and work on a viable replacement.

We need an internet protocol that is backwards compatible with ipv4 and does not require deploying and maintaining entirely parallel networks, interfaces, firewalls, routing, etc.

If ipv6 actually was viable, the internet would have cut over. Instead we’re on a path to support ipv4 and ipv6 in parallel essentially forever.

s.gif
There is no “backwards compatible with IPv4”. If you have to modify the existing packet headers, you no longer have backward compatibility. If you change anything involving how a flow is identified (like the source/address destinations and ports) then you have broken backward compatibility. Firewalls need to understand new address formats, routers need to understand new address formats, end systems need to understand new address formats, BGP needs to be extended to support new address formats.

IPv6 is perfectly viable and it is in many ways cleaner than IPv4 is. It’s just that transition is expensive and apathy is easy.

s.gif
> It’s just that transition is expensive

It’s impossible to finish a transition when the old version has no end of life in sight.

s.gif
>It’s impossible to finish a transition when the old version has no end of life in sight.

The end of life is gonna happen when ipv4 addresses end up being cost prohibitive. They are already some $50 an ip address.

That is gonna be cost prohibitive in developing Countries, who already are making a transition to ipv6.

s.gif
"::ffff:1.2.3.4" is a valid IPv6 address; "IPv4-mapped IPv6"
s.gif
I generally agree, but I'm pretty sure ::1.2.3.4 is a valid IPv6 address because it does have the idea of v4 compatibility built in.
s.gif
Everyone on this thread is dumber for having read this.
It's been a quarter of a century since IPv6 launch.

There's some really good lessons learned here. IPv6 requires everyone, everywhere, needs to change their configuration to add IPv6 addresses and network connectivity to every node/endpoint. The madness of course is that all the underlying infrastructure software (routers, OS, standard libraries) all support IPv6. It would seem, at a large enough scale, that software is the easy part, configuration is the hard part.

DJB wrote this up two decades ago[0] and it remains relevant. In particular the comparison between IPv6 and MX records. It took me a little while to wrap my brain around just extending existing software to support sometimes 32bit and sometimes 128. Ultimately it wasn't hard to dream up a few solutions for how that would work.

The other thing, FWIW, which has been slowing IPv6 adoption is business owners not asking for it as a high priority item from their providers. I've seen this happen way more often that I would like where provider asks a customer what they want and the customer never mentions IPv6, and when prompted shrugs it off because they don't see it as a business critical (and in fairness, it hasn't been). Yes provider isn't asking the 'nerds' at their customer's businesses, but those folks also aren't the ones paying the bills so...

0: https://cr.yp.to/djbdns/ipv6mess.html

s.gif
I got a brand new router recently, IPv6 was still disabled by default! I honestly can't understand the reasoning, I don't even buy the internet visibility argument because the default incoming connection rules for IPv6 after I enabled it were deny-all. We really have a long way to go still in getting equipment everywhere enabled on it.
s.gif
If we take a chapter on fixing broken implementations from the USB Forum, the clear solution is to come up with an IPv6 Rev. e^76.
s.gif
anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.

part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008

part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depletion. at this juncture ipv6-only (w/ nat64) is becoming a more preferable approach, since you only need to maintain a single protocol in the majority of your environment (as evidenced by org's like tmobile us, facebook, etc).

part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.

"no one is asking for ipv6" is a lie writ large in the provider space; i've seen plenty of examples where a provider has told multiple customers "you're the first person to ask for ipv6 support!" - the problem being is that most org's don't actually keep track of such requests in a unified place, & so every customer is pushing for it alone, so far as the provider is concerned.

s.gif
> anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.

It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now.

Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken as the cost of sticking with IPv4 rose. Also, a significant period of time was always going to be necessary for software and tooling to catch up -- perhaps there wasn't much to be done about improving the transition 20 years ago. Yet DJB's rant isn't wrong or devoid of value -- it's mostly right and entertaining (still!), even if there just wasn't enough IETF and dev oomph to do better at the time.

s.gif
I'm not sure it was ever relevant. All it does is describe the problem, which was already well-known at the time by the people working on v6. It doesn't give a fix for it.

It doesn't give a fix because no fix is possible. Because the problem comes from the design of v4, not from v6.

For some reason djb wasn't able to get his head around that, and people have been pointing to that damn page as if it's some big gotcha ever since. No, it's just the situation we're stuck with, thanks to the people that designed v4.

s.gif
If it describes problems we're still struggling with, it's still relevant.
s.gif
It talks quite a bit about how to tackle migrations. It doesn't specify specific solutions for IPv6, no, but it does talk about what doesn't work and what should be looked into. It's a blog, not an Internet-Draft.
s.gif
I mean, v6 is still mostly a failure, so (rightly or not) the situation is going to be blamed on the people that have been pushing v6. That's just the cost of trying to push the entire world towards a new standard.

(I know that v6 has been a success within datacenters and such.)

s.gif
by what definition would you call ipv6 "mostly a failure"? 30-40% global eyeball network (to the end user) adoption after ~10 years of active deployment, against very vocal opposition seems commendable enough to me.
s.gif
> It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now.

it's irrelevant now because there are smoother approaches to migrating to future-proofed networks than existed at the time. the fact that it persists on the internet, unamended, to be regularly presented (two decades later) as some semblance of current realities of the challenges to ipv6 deployment is a disservice to the internet.

> Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken as the cost of sticking with IPv4 rose.

i would maintain that "ipv6mess" had a NEGATIVE impact on ipv6 adoption overall, as people who saw djb as a tech god accepted his word as gospel, despite it fundamentally being a crybaby rant, & proliferated the misconceptions & opposition therein.

the fact that he explicitly rejected ipv6 patches to qmail & djbdns (resulting in a fork to at least qmail) should not be understated - he didn't just complain about ipv6, he actively sought to undermine its adoption.

s.gif
> part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008

Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?

> part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened).

Perhaps they didn't listen because dual stack means investing in building another incompatible internet on ipv6 in parallel with the ALREADY WORKING ipv4 internet. Reminds me of a great quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S Raymond

> part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.

Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.

s.gif
> Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?

Oh, you mean like this:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5

You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", and this (lack of) upgrading and enabling is what is hampering deployment.

What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

> Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.

Backwards compatibile IPv6 was impossible.

IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How do you fit in >32b in a data structure that is 32b? You cannot.

So you have to go an replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.

s.gif
> Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?

Because it does not help. djb's “idea” was to change everybody's setup _first_ and then have a flag day where the entire world were moved from IPv4 to IPv6 in one big change. Good luck with that. (And only after that flag day, we could start actually using a larger address space to try to get rid of NATs.)

The ipv6mess essay is confused because it somehow thinks _getting addresses_ is the hard problem. It does not solve _any_ other configuration or coding part. You still need to upgrade DNS. You still need to have a different wire protocol. You still need every hop on the path from me to you to understand and route IPv6.

At least now with gradual rollout and dual stack, we're at 40% of endpoints and AFAIK a majority of traffic. With djb's plan, we'd still be at zero.

I was thinking about ipv6 the other day. I concluded in my head that adoption was just around 5-10%. Luckily I went to verify that with statistics.

https://www.google.com/intl/en/ipv6/statistics.html

While price of ipv4 addresses are increasing, the world has slowly been adopting ipv6. From the graph above, I'd say we cross over 50% in about 2-3 years time. At some point the "dash" to adopt ipv6 starts, and brave folks will drop support for ipv4. Then it'll probably evaporate between 2030-2035.

s.gif
> At some point the "dash" to adopt ipv6 starts, and brave folks will drop support for ipv4.

I wouldn't be sure about that. I don't see any "dash" to support v6 in our future, when the option to just keep working around issues with v4 is so much easier and cheaper in the moment. Really, what does anyone have to gain by switching to v6?

s.gif
> I don't see any "dash" to support v6 in our future, when the option to just keep working around issues with v4 is so much easier and cheaper in the moment.

30-40% global adoption in ~10 years may or may not be a "dash", but it's also not nothing.

"easier and cheaper" is very much not the case at larger scale. legacy ip space is only growing more expensive, & cgnat platforms are not cheap. even if a carrier HAS TO deploy cgnat, deploying ipv6 first means you don't need to buy cgnat capacity for any v6-native traffic (which is a non trivial volume)

> Really, what does anyone have to gain by switching to v6?

the above, & also a future-proofed, infinitely scalable network. any org's that do alot of m&a don't have to play as many stupid rfc1918 integration games.

if you don't deal w/ scale, yea, hard to see the benefits. fair.

s.gif
> 30-40% global adoption in ~10 years may or may not be a "dash", but it's also not nothing.

Still nowhere close to being remotely unusable after soon 30 years is very very close to nothing.

Regarding benefits: Amazon, Azure and all the other major VPS companies has a lot to gain from IP addresses being expensive, since it makes it almost impossible for new players to enter the market. ISPs may pay for CGNAT in terms of infrastructure and complexity, but they save in support and abuse mitigation cost by making it impossible for normal people to host their own stuff, they save in support cost by not dealing with customers' broken products which get confused by IPv6, and they gain financially from charging a ton for "pro"/"enterprise" non-CGNAT connections.

And for any kind of web service, supporting IPv6 is obviously just a net negative, since you have to deal with both v4 and v6 rather than just v4.

So I suppose I'm saying, sure, there are minor things to gain from v6, but it's not clear that they outweigh the (opportunity) cost of v6 for anyone, and for large sectors it's simply a cost with no upside.

I don't see a rush to support v6... ever. We'll keep growing steadily but slowly for a while, then adoption will taper off.

But hey, I may be wrong! I'd certainly be happy if you were right. The minuscule amount of progress across almost 30 years doesn't instill confidence though.

s.gif
That is a very one-sided view of adoption. It ties directly with the rise of mobile and internet in areas that wasn't able to grab IPv4 addresses in time. Such as India. Not sure what France is doing though, maybe something right.

So, from my perspective (which obviously is tied to my location) is that all computers have IPv4 (haven't heard (and I've asked) of a single consumer ISP that offers IPv6) but all mobile phones have IPv6. Whether people in general do most searches on mobile or PC is gonna change that graph dramatically, but won't explain what I would be interested in regarding ipv6 adoption. That is, how much of the world would be broken without IPv4?

And for that, that graph isn't completely useless - but not too far off.

s.gif
Comcast added IPv6 ages ago. Time Warner and AT&T (FTTH, not just mobile internet) support it now as well.
s.gif
All the big cable and fiber internet providers I've worked with in the US support IPv6, even evil nasty ones like Comcast have supported it for a decade now.
s.gif
okay - how about a few other angles?

https://stats.labs.apnic.net/ipv6/ - per-country, and within a country, per-asn eyeball statistics, collected from online ads - not just mobile!

https://www.facebook.com/ipv6/?tab=ipv6_country - per-country, albeit with a mobile-heavier bias (as you hint)

https://www.akamai.com/internet-station/cyber-attacks/state-... - collected from their content delivery network - tends to show lower adoption than the other metrics

i would point out that "all mobile phones have IPv6" isn't true globally, but it is the reality in some countries, yes.

s.gif
Neat, very different results. But still looking at it from the wrong direction?

That is, ipv6 for clients. But I'm more interested in servers, because that is what would affect me if I don't have IPv4. Such as the experiences described by OP in this thread.

s.gif
ipv6-only web sites are borderline nonexistant, because no one who needs to maintain a profit dares to cut off a revenue stream from legacy ip only users (yet).

the most exhaustive list thus far is https://sites.ip-update.net/ afaik

s.gif
I'm not asking for ipv6-only, but ipv4-only.

Those are the ones blocking adoption for me, as an end user.

s.gif
I'd love for some way to measure how much of my network's traffic outbound and inbound is IPv6. I assume there's some way to "count" it on the router, but Mikrotik doesn't seem to expose it directly.
s.gif
PiHole is actually pretty great for this. I set up some firewall rules in OpnSense to force all devices to use PiHole as a DNS server. Then log all queries.

You can see which clients are using ipv6 and how many queries there are. I would estimate that about 60% of iPhone traffic in my household (by far the busiest devices) is ipv6. We usually use big sites though like Reddit, twitter, google, etc.

And then there’s the Rokus that don’t support ipv6 at all. Considering how cheap they were it doesn’t really surprise me.

s.gif
I don’t know if this corresponds to traffic, but my local DNS server shows that it’s returning more AAAA results that A results (_just_) nowadays.

This is a home cable connection in the Bay Area.

s.gif
iirc mikrotik supports netflow. that's how i account for proto balance. FWIW, owing to the nature of residential traffic, I've typically seen high (60-70% of traffic) as v6.
s.gif
Yeah, if the stream platform CDNs support IPv6 (Do they? is there a site that lists it?) then the vast majority of residential traffic will be IPv6.
s.gif
This is exactly why this isn't a good way to measure ipv6 adoption. For example, youtube supports ipv6; if you spend all day watching youtube, 80%+ of your traffic will be ipv6.
s.gif
In addition to NextDNS I have been running a firewall app on my android phone (which also points to NextDNS) and shows all this. Good easy way to get started. ReThinkDNS is the app I am currently using because it integrates some block lists well but there is also a more serious Android firewall app I may switch to.
Having "grown up" with IPv4, I'm slow to learn everything necessary to set up an IPv6 infrastructure. The times I did look into it, IPv6 seemed so much more complicated than IPv4, but maybe that's just because I'm just not familiar with it.

Are there any good resources on setting up IPv6 support from first principles?

I still get confused as to the "right" way to set up internal networks for IPv6, especially when DHCPv6 isn't universally supported (I'm looking at you Android).

s.gif
A confusing aspect of IPv6 is that it's actually a much simpler protocol than IPv4, you often end up assuming you need to configure a bunch of stuff that you really don't have to.

The most common example would be NAT, despite the complexity it adds to IPv4, people often get comfortable with idea of setting up complex subnet hierarchies and feel lost when that all just disappears with IPv6.

The key things to remember when working with IPv6 are:

- IPv6 is very unidirectional, it's not a giant one way waterfall like IPv4/NAT

- Routers don't assign addresses, they advertise "prefixes", usually multiple

- Routers will usually have a prefix for: Internet, WAN, Link-Local (last one being advertised only to nodes directly connected to it)

- Nodes use prefixes to auto-generate an address

- Auto generated addresses are usually in the form of "prefix - device_id" so even if a node has a lot of addresses, they are all mostly the same

- Usually nodes can easily communicate back and forth across multiple local routers with little configuration or hierarchy

- Internet/non-local IPv6 addresses break the rules a bit and don't use a device_id in their addresses in order to protect user privacy

- Even if every node has an external address now, you can still configure your firewall to ensure they are isolated from external connections (which is usually the default anyway). You don't need NAT to securely isolate things.

- Once you get the hang of it you will realize how easy it makes everything and despair that support for it sucks and everyone makes it harder than they need to

Finally for learning resources I honestly recommend just reading the RFCs, I personally learned this way and believe they provide the most direct understanding of the rational behind everything.

s.gif
I have the technical ability to set up a well structured VPC in AWS with private/public subnets, but I wouldn't know where to start if asked to set up an ipv6-only network.

Is the general model of public/private subnet still valid? Or are you saying in a ipv6-only world, there's no need for separate subnets?

There's something about a server not being assigned an IP address at all that makes me sleep easy at night (in ipv4 world, you know that server is truly unreachable via public internet)

s.gif
I generally see IPv6 being a better reflection of reality vs the illusion presented by IPv4/NAT. To put it another way, even if your server has no public IP address, if someone punches through your firewall it's not like that matters anymore right? If they have the keys to the kingdom they can change your network to be however they like.

If your network is a house, and your firewall is the front door, then all NAT does is force you to have a weird fractal room layout where rooms are inside rooms, inside rooms. But if a dude breaks in through your front door, it doesn't matter how many rooms you have, he will find what he wants.

IPv6 lets you have as much rooms as your want and lets you optionally send mail to specific ones. If someone breaks in they still have access to everything, but instead of having to navigate a fractal house, they have to navigate a house with a nicer layout and a trillion doors.

The metaphor is falling a part a bit here but my point is that if your server has some form of physical network connection that eventually leads to the internet, it's address scheme isn't going to help you much, even if it makes you sleep better.

s.gif
Ok, i'll bite.

> Auto generated addresses are usually in the form of "prefix - device_id" so even if a node has a lot of addresses, they are all mostly the same

> Internet/non-local IPv6 addresses break the rules a bit and don't use a device_id in their addresses in order to protect user privacy

So a device needs to have both an internal address and an "Internet/non-local" address in IPv6?

Plus one for WAN and Link-Local?

4-5 addresses per device?

s.gif
Actually there can be an arbitrary number of addresses per device, thanks to the privacy extensions. Since your “device id” is a simple derivation of your MAC address, technically you could be tracked across ipv6 networks through that.

Therefore most modern oses will create a time limited random address (within the prefix) to use. When the connections using that address have died, the address is retired. New addresses are generated on a periodic basis. So if you have long lived connections you could have several active privacy addresses at the same time.

s.gif
The internal address is optional, it's only useful if you want to have a known address if your uplink is down so you can do maintainance.

You only need two addresses:

- a global address

- a link-local address

s.gif
Thanks, that helps a lot.

This got me reading about IPv6 again. I'm trying to figure out how we'd set up an IPv6 network in the case where we have 1) Two upstream ISPs, mostly for failover, but could be loadbalanced too. 2) Internal servers with assigned DNS

My initial thoughts were that for each of the two ISPs, each host (e.g. personal desktop or laptop) would use the IPv6 prefix and end up with two addresses. But in the interest of having an internal address for internal servers, we'd need yet another IPv6 prefix for internal use. That makes 3 IPv6 addresses per host.

Does that make sense? I read about getting Provider Independent (PI) address prefixes, which would allow use to consolidate to a single IPv6 prefix, but from what I read, that costs money and should generally be used for large organizations. Ugh.

s.gif
Everything should get its IPv6 configuration via SLAAC. DHCPv6 is only useful when you plan to provide prefix delegation for extra routers or network boot information.
s.gif
So how do you do DNS then?

Not sure if this is a good source but it had some history to recap, and it doesn't look pretty... https://www.reddit.com/r/networking/comments/ajb2ec/comment/...

[...] To be honest because of this hot mess if you want to reliably support any possible client you'll need to do both DHCPv6 and RDNSS for DNS information. [...]

s.gif
SLAAC can configure DNS automatically (via RDNSS).

Or you can run DHCPv6 just to hand out DNS settings (or anything else you want more control over), even if it's not handling addressing. But this isn't necessary for small deployments.

Personally, I've never had any problems with pure SLAAC (no DHCPv6) on my home network.

s.gif
That source is, at best, dated.

Sending DNS info is one of the options in SLAAC (just like how it is an option for DHCPv4).

You just configure your router to advertise DNS servers via SLAAC Router Advertisements (RAs) the same way you would via DHCP.

One of the benefits is that any configuration changes propagate almost immediately—you don’t have to wait for DHCP clients to renew their lease to get new DNS servers.

Also, you can (if you want) have the DNS server advertise itself using the same mechanism.

The only common clients that can’t use SLAAC-based DNS configuration are older (unsupported) versions of windows. Even then, setting up DHCPv6 (in unmanaged mode) to send DNS servers is easy.

s.gif
The SLAAC should not change after the host has generated it during installation / first connection, as long as you don't reinstall the OS etc.

It's basically no problem.

Even better: I can set my own ::/64 so personal servers at home can be ::d3ad:b33f and accessible from outside without NAT. It's beautiful. Firewall configuration is not hard either these days is it?

s.gif
So I have to manually configure every device to be able to use internet?

Every friends phone that wants to connect to my wifi needs manual setup?

That is a problem. To which the solution is IPv4?

s.gif
What? No. You connect a device, and SLAAC (and optionally DHCPv6, on enterprise networks) configures everything. It just works.

SLAAC is more than capable of sending DNS settings to devices. There's no manual configuration involved.

s.gif
My post said to use DHCPv6 and RDNSS. Follow up claimed to use SLAAC instead.

SLAAC does not do DNS. Clear as day?

s.gif
I run dual stack at home and every device I have connected to my home network runs ipv6 with no manual configuration whatsoever. It’s easier than ipv4 when you consider providing inbound access to resources (no nat configuration)
s.gif
SLAAC does DNS, with the RDNSS extension enabled. (RDNSS is a feature that was added to SLAAC.)

Some older devices [1] do not support RDNSS. I haven't run into them, but if you're at all worried about it, you can run DHCPv6 in parallel just to hand out DNS settings.

Personally, I just use SLAAC (with RDNSS) and it just works.

[1]: https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...

s.gif
Why do you think this? What led you to assuming these things?

You would only need to configure any of this if you want to allow external connections, which isn't much different than setting up port forwarding with IPv4 + NAT, except with IPv6 it's less complicated.

s.gif
Literally the post I answered.

Fact: SLAAC does not do DNS. So, my question then is: how do you do DNS?

Answer: "The SLAAC should not change after the host has generated it during installation / first connection, as long as you don't reinstall the OS etc."

Since SLAAC does not do DNS that answer implies that you'd enter it during connection/installation to complete the config.

s.gif
SLAAC installations can use RDNSS to configure DNS.

Windows, according to Wikipedia, doesn't support it, but if you want to please Microsoft there's stateless DHCPv6 (which does not maintain leases, configure addresses, or do anything else that SLAAC doesn't do already; it can be simple piece of software in comparison).

On the other hand, Android and ChromeOS don't support DHCPv6 for DNS server provisioning because of Google's opinion about all matters related to DHCPv6. A pain, but not impossible to overcome either.

As for unchanging addresses, SLAAC is bound to the device MAC address so a reinstall should give you the same IP. However, you are/should be running privacy extensions, which means your outgoing IP will rotate to prevent tracking (as your IP is based on your MAC address and using that would make tracking way too easy). You'll still have the same primary IP, though, unless you add a second device to the network with the same MAC address.

s.gif
Windows supports SLAAC+RDNSS, as long as you're running Windows 10 or newer.
s.gif
just a funny joke: what about using IBGP/OSPF for prefix delegation?
s.gif
How does that work you have more than one ISP giving you an IPv6 prefix?
s.gif
Growing up implementing IPv4, then moving to a different part of IT, I never found a reason to learn IPv6; it is something that is out there, but not relevant for me. I cannot tell if this good or bad.
s.gif
Bookmarking for future. I want to fill this out but don't have the info in front of me at the moment.
All ipv6 shortcomings discussion aside; What I think is the more vital problem to focus on is that the governments clearly don't want us mere mortals to expose our own servers running on our own hardware to the outside world (most often justifying that with "it's for your own security" mantra, for we're all deemed too dumb to figure that out for ourselves).

ISP-imposed ipv4 double NAT (imposed on ISPs by the governments, I am pretty sure about that) reduces our devices to all but dumb receivers which are scarcely superior to TV sets. And no amount of STUNning and TURNing, or buying VPSes can realistically fix this situation, when we can't simply connect our devices directly without resorting to some service provided by some Men in the Middle. And it gets worse, 10 years ago I could buy a static public IP from my ISP for some affordable extra - all ports open unless blocked manually in my firewall - nowadays there remain no ISP around to sell those to the general public. Just no such option anymore. Too much freedom it gave, I guess.

So this begs the question: can ipv6 fix that? Will ipv6 fix that? I'm afraid not.

s.gif
This seems like a poorly-researched conspiracy theory. Nobody is forced to use double-NAT, and if there was some secret policy which somehow has avoided leaking for a couple of decades, you'd think they'd have blocked IPv6 deployments, too.
s.gif
CGNAT isn't imposed by governments, it's imposed by address space exhaustion in v4. v6 fixes it by having enough address space that NAT isn't needed.

Governments share some responsibility here for not mandating a move to v6, leaving everybody in "wait for other people to go first" mode, and one might ask why they've done that but the answer is mostly that governments don't usually get involved in the Internet at that level.

I've not seen an ISP do CGNAT on v6, even when they're doing CGNAT on v4. This makes sense because CGNAT is expensive and doesn't have any benefits for the ISP except for dealing with address space exhaustion. If they wanted to prevent inbound connections then all they would need to do is firewall them.

s.gif
Can you provide a source for that government claim?
Setting a website to be available over IPv6 is relatively easy, yet we see:
    ;; QUESTION SECTION:
    ;news.ycombinator.com.  IN AAAA
Why? Because it's not quite as simple as making Apache respond over IPv6; any website of any size has various protections in place to prevent DDoS, spam, etc, and those tools are almost universally basic and at the root is the "ban by IPv4 address". Without that tooling supporting IPv6, it remains a side note not worth supporting.

Solutions? You can make an IPv6 version available that is read-only; or requires you to login via an IPv4-only gateway first (and protect that) and then ban by username as necessary.

And outbound? You have to IPv4 NAT which maybe Hetzner offers? If not there are things like https://nat64.net

s.gif
> Why? Because it's not quite as simple as making Apache respond over IPv6; any website of any size has various protections in place to prevent DDoS, spam, etc, and those tools are almost universally basic and at the root is the "ban by IPv4 address". Without that tooling supporting IPv6, it remains a side note not worth supporting.

The consensus I've seen is to treat IPv6 /56s or /48s (depending on preferred strictness) as an IPv4 address. From there, it's quite simple to port the security mechanisms.

Of course the chicken/egg problem comes back, because many of these "solutions" don't support IPv6 because nobody asked them to support IPv6 because they don't use IPv6 because their solutions don't support IPv6.

As for HN, good question. Adding a simple line to your DNS server or hosts file to make HN resolve on IPv6 is enough to get it to work.

Edit: emailed dang, it's on the roadmap!

s.gif
Actually HN is available via IPv6 over Cloudflare. You have to add a CF IPv6 it to the hosts file.

In fact I am posting this comment over IPv6.

s.gif
> You have to add a CF IPv6 it to the hosts file.

That's worse, yeah? You do see how that's worse?

s.gif
The fact anyone should think this is somehow acceptable state of art is obscene to me.
s.gif
I actually run a separate DNS proxy that does it automatically for me. (HN and lot of other sites)

I only mentioned hosts file because it is the easiest way to spoof the domain.

s.gif
That's still the same thing: you're manually adding a mapping where you shouldn't have to. HN should just publish the AAAA RRs and be done.
This problem led us to self-hosting Gitlab four years ago, I can't believe it's still an issue in 2022.

It's appalling that a "developer product" like Github remains such a blocker to IPv6 adoption, especially for highly Github-reliant communities like the Golang ecosystem.

Launch an IPv6-only VM and try to build a mainstream Go project.

20 years ago it was the lack of IPv6 support on the CPE holding IPv6 on the server side back, nowadays it's a lack of IPv6 at major SaaS providers causing issues. In most of the scenarios I was involved in we made sure that the CDN in front of the product was able to terminate IPv6 and left everything behind it v4 only. About 1/3 to 1/2 of the traffic received was sent via IPv6 on those setups. Maybe time to turn that around and use the CDN to make the product also available via v4? Leaves you with maintaining a NAT gateway for your own infrastructure.

BTW also only one of the office networks I had to deal with in the past 20 years hat experimental IPv6 support, and that was at a small local hosting company. Everything bigger than that also sticks to IPv4 only for now. :(

Strange how things change but still stay the same.

We are IPv6-only on our institute-internal CPU compute cluster based on slurm. Only the head node has an IPv4 address, so that it can be reached from IPv4 only clients (sadly, there are still quite a lot). All nodes inside the cluster talk over IPv6. And all other computers with IPv6 access use that to communicate to the head node. We are transitioning to IPv6-only for internal services and try to avoid using IPv4 addresses, only going back to it when something needs to be accessed from the outside.

Sadly, our local ISP is still IPv4-only, meaning we cannot even access our IPv6 hosts while at home, so we need to fall-back to IPv4 quite a lot. Also, the Cisco VPN is still IPv4 only (because of lacking resources to add IPv6 support), so not even the VPN helps. We need to jump over some dual-stack host then.

When speaking to the local ISP, they just reply that it's not planned soon, they don't have resources for it, and "they evaluated IPv6 and don't have a reason to support it". Me/us giving them reasons was not enough it seems.

s.gif
> Sadly, our local ISP is still IPv4-only, meaning we cannot even access our IPv6 hosts while at home, so we need to fall-back to IPv4 quite a lot.

Have you perhaps looked into using tunnels to fix this? he.net can add IPv6 support to any routable IPv4 address that can respond to ICMP. If you need to stick to your internal ULA, something like NPTv6 can translate the /48 subnet HE provides to your own /48 subnet transparently.

Requires some setting up, but so does maintaining VPNs.

s.gif
Yes, I did this on my personal network. I'm in Linz (Austria), the nearest tunnel to a german speaking country that's listed on tunnelbroker.net was Berlin (if I remember right). Everything worked rather well, but I then decided against it, because of the GeoIP implications (with one IP being in Austria and one in Germany) and the added latency. It's noticable when SSHing somewhere whether I'm Linz-Linz or Linz-Berlin-Linz, especially when a small lag spike happens, which is rather frequent with the cable-based network our ISP is offering. It wasn't worth it to half-slowdown our network just to not rely on jumping through some dual-stack node in the university.

If anybody from Liwest (our local ISP) reads this - IPv6 would be really nice! :)

s.gif
He.net needs a fixed non-CGNAT IPv4 address, with protocol 41 open, and this is quite difficult to get.
s.gif
That really depends on where you live. Every ISP I've ever had has fit this bill.

I know IPv4 availability in developing countries is a problem and there's no fix for that other than "wait until IPv6 is available", but in those countries IPv6 is actually part of the solution to not have to rely on "communal" IPv4 CG-NAT.

s.gif
With all these limitations, why did you prefer IPv6 over IPv4?
s.gif
Because we don't want to use 20 IPv4 addresses for the cluster of 20 nodes, when we only have so much addresses assigned to our institute. We could have gone the NAT route, but then we'd need to have some router. And if we designate the head node as router, all traffic would not go through the switch directly, but first through the head node and then out. This would mean that the nodes are less independent, as they have this one additional choke-point. Our university gave us a /64 for this network, so we just used that and it worked flawlessly, also for university-internal distro-package fetching and host-cluster connections.

Also, research software is usually working nicely with IPv6. If we encounter something that would really need IPv4, we could update the thing and give it some local subnet - but currently we were lucky.

> Our Hosting provider, Hetzner, has recently started charging for public IPv4 addresses

Well actually, they were charging for IPv4 addresses for a while, but just changed pricing... to outrageous pricing. The setup fees are actually insane!

And yeah IPv6-only is quite a terrible experience, I tried out a few days ago. I suggest just using nat64.net if you want to access IPv4 sites over IPv6.

One quite funny thing, I recently asked my ISP if they were ever going to add IPv6, they told me no, there's "not enough demand"... well there's "not enough demand" because there's barely any IPv6 websites, and then websites refuse to add support for IPv6 because... you guessed it, "not enough demand".

s.gif
That's not insane, that's pretty cheap. If you buy IPv4 addresses in bulk (e.g. an entire /18 or so), they're ~$40 a piece these days.

When you buy cloud services from AWS or GCE, you're still paying for those IPv4 addresses, it's just baked into the price. Hetzner makes paying for it optional, which makes it so much more visible.

s.gif
It is an insane price for renting an IP address. It's not like you get to keep the IP address when you move elsewhere.
s.gif
This isn't buying, this is renting. You are paying that setup fee + the monthly fee.

As a comparison, I pay ~$1.60/ip/mo (no setup fee) for my IPs.

s.gif
My guess would be that you need to let used IPv4 addresses age out for a while before you can reassign them to a new customer, and they need to reduce churn - and avoid people intentionally burning IPv4 addresses by rotating through new, clean addresses.
s.gif
> The rental costs for the current hosting is quite affordable for me. If that becomes insufficient I will look for partnerships with transit providers who are able to make a little profit from carrying parts of the traffic.

Well, that's ominous. Basically a promise that they will sell your data.

IPv6 is a case study in the second sytem effect [1]. Realizing you need to make breaking changes and it being rare that you get to do so you decide to make all the changes.

The truth is IPv4 only had 2 real problems:

1. Lack of address space due to 32 bit addresses; and

2. Lack of a solution for roaming since your IP address is a core part of connection identity (between the source and destination address and port).

IPv6 managed to only solve one of these problems and it did so in a way that removed functionality. Yes there are more addresses but now address blocks are non-portable. I guess 25 years ago they thought that routing protocols like BGP4 were considered a problem and decided to remove that with hierarchical address spaces and massively expanded those address spaces to do it.

Somehow ports were also considered a problem so we got /64 addresses. Part of the motivation for this was to use (mostly) unique MAC addresses (48 bits) as your identifier and that fits in 64 bits. Of course this became a massive PII leak and a tracker's dream so it never happened but we're still stuck with /64 blocks that we absoultely do not need.

It's an object lesson in solving actual problems and not solving imagined problems.

[1]: https://en.wikipedia.org/wiki/Second-system_effect

s.gif
Finally, a great comment in this thread.

Arguably lack of IP address block portability is not that big a deal [now that we're well used to it]. But IPv6 did not solve the CIDR route table size issues, and that's a big failure.

I have long thought that IP packets should have a source and destination ASNs as well as actual addresses. That would mean that we'd need more DNS (or similar) lookups, and a bootstrapping system for that. A scheme like this would greatly reduce router table sizes and would allow for IP address block portability.

s.gif
You can get PI v6 space, and if you are somewhere where a RIR won't give it to you, that's not the protocol's fault.

Also ports weren't removed, they work just like in v4.

The long addresses with subnettable space for everyone is very valuable and useful and doesn't remove any functionality.

s.gif
> Part of the motivation for this was to use (mostly) unique MAC addresses (48 bits) as your identifier and that fits in 64 bits. Of course this became a massive PII leak and a tracker's dream so it never happened but we're still stuck with /64 blocks that we absoultely do not need.

please read about rfc4941 privacy extensions & how prevalent their use is before continuing to regurgitate decade-old, outdated privacy alarmism about MaC aDdReSsEs.

Yes, I use IPv6 in production, alongside IPv4 (dual-stack). I've got an IPv6 only EKS cluster that has IPv4 on the local instance that NAT's any IPv4 outgoing connections, but the entire cluster and all communications inside the cluster/between pods is IPv6 only.

IPv6 stand-alone without IPv4 dual stack is not yet an option, but it is getting closer. If you can mirror content and deploy from your mirrors it is entirely possible to do everything over IPv6 alone.

About 30% of my production traffic is IPv6, referring to outside traffic coming in to the systems. Internally almost 90% of the traffic is IPv6 due to the k8s cluster being IPv6 only, and preferring that over IPv4.

Interestingly enough at home on my home connection about 60% of my traffic is IPv6, which has been increasing steadily over the years as other companies have started bringing on-line IPv6 for their services.

In Norway, it's required[0] for all public sectors to have IPv6. We are not there yet, but I believe the push will only increase with time.

Especially all new internal networks must be IPv6, and IPv4 is optional.

[0]: https://lovdata.no/dokument/SF/forskrift/2013-04-05-959?q=ip... (Sorry that it's in Norwegian.)

s.gif
There is a current effort to fully transition the US government internal networks to IPv6 only: https://www.gsa.gov/technology/technology-products-services/...

Considering how many old, IPv4 based management and security tools are probably in use, it will be an exciting time.

s.gif
Norway is not big enough on Internet scale to make a difference. Equipment and software companies will put in balance the cost vs the benefit and may decide to ignore that market.
To use GitHub on an IPv6-only Hetzner instance, you'll need to use a NAT64 gateway. There's a list of public ones here: https://nat64.xyz/

This can just go into your /etc/hosts:

    2a01:4f8:c2c:123f:64::140.82.121.3 github.com www.github.com
s.gif
Huh, so I can effectively use a NAT64 gateway as an unauthenticated open proxy? Let's try it. First look up the IPv4 for a site that reads back your IP address:
    $ dig +short a icanhazip.com
    104.18.115.97
    104.18.114.97
(Those are Cloudflare IP; icanhazip.com is hosted on CF.) Next, try connecting to the IP-readback site via a NAT64 gateway, but presenting the correct Host header so that Cloudflare knows what to do with the request:
    $ curl -6 -k -H 'Host: icanhazip.com' https://[2001:67c:2960:6464::104.18.115.97]/
    141.98.136.43
OK, it reads back an IPv4...
    $ dig +short -x 141.98.136.43
    de-fra2-nat641.level66.network.
...with a PTR record associated with level66.network, which was the NAT64 gateway we chose.

How does this not see more abuse by bad actors? I guess it probably does, which is why there are so few of these public gateways?

s.gif
> How does this not see more abuse by bad actors?

Because this tech goes unused in almost all cases. Also doesn't work if your DNS client is secure against tampering (i.e. uses DNSSEC) without more configuration.

To make this work, you need to intercept and modify the victim's DNS traffic or reconfigure the victim's DNS server somehow. With that amount of control, IPv6 or IPv4 no longer matter; you apparently have full network or configuration access already.

There are protocols to automatically configure such workarounds intended for ISPs, but I don't think they see much use.

> which is why there are so few of these public gateways?

I think a bigger problem is that you're piping a lot of people's internet traffic through your own network for... fun, I guess? To make this sustainable you need a business model and I don't see why anyone would pay for such a service until IPv6-only hosts start becoming more common.

s.gif
That’s what I ended up doing, but it’s a major turn-off to learn this by trial and error, after setup scripts fail with seemingly unrelated messages.
s.gif
Yeah, if any Hetzner reps are reading this thread, it would be great to put up a support page talking about NAT64, and link to it from the dashboard when creating IPv6-only instances.
s.gif
And if any Github reps are reading this thread, put together a presence on IPv6. If Google can do it, so can Microsoft.
And this is where government regulation would have helped. It's a shame nobody listened to me back in the 90's: (it's a joke. I'm a nobody, there is nobody listening.)

All cell-phones should have been ipv6 from the get-go.

Now if we could just go back in time and warn everybody about IPv4 address space being exhausted. And maybe the climate too while we are at it.

Seriously though, cell-phone adoption would make that a game changer. Hey Apple, sell it as an exclusive feature!

s.gif
It’s not that ipv4 space is exhausted, there’s plenty of it available. It’s that early on it was mismanaged to the point that people / companies were able to buy entire /8’s for basically nothing and hold them forever.
s.gif
Given the top rate* for handing out ipv4 some 10 years ago, every such "wasted" /8 would give you days to weeks before being used up again. What do you intend to do when those 2 weeks are up?

*) https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...

s.gif
the global burn rate was 4-6 weeks for a /8, iirc

but there are waitlists to fulfill, so...you're probably still right.

(tl;dr: "repatriate the poorly allocated legacy ip space" is a losing proposition)

s.gif
Single-purpose accounts aren't allowed on HN (they're too predictable and predictability is the antithesis of curiosity) - so I've banned this account. If you don't want it to be banned, you're welcome to email [email protected] and we can figure something out.
s.gif
Related anecdote, my (small) school had acquired a /16 way back and so today, every single device on the network gets its own public ipv4. It was an absolute mess for security (imagine a small army of first year CS majors setting up each a Raspberry Pi) but it was kinda fun being able to experiment with servers without having to worry about NAT.
s.gif
A long, long time ago my (large) school had 2 /16s and a bunch of /24s and every device--including those in the medical center--got a public, internet accessible IP address. https://itconnect.uw.edu/tools-services-support/networks-con...
s.gif
they could just firewall inbound connections and have some sort of request/interface to allow certain/all ports whilst keeping everything lovely about public v4 though, yeah?
s.gif
Cellphones are the main driver of IPv6 adoption as it is; many countries you're behind CGNAT if you hit an IPv4 endpoint, but you go direct if they support IPv6.
> Our Hosting provider, Hetzner, has recently started charging for public IPv4 addresses - as they should! Those numbers started getting expensive. This prompted me to try and set up a new server cluster using IPv6 exclusively...

I think what OP went thru is what will make the transition happen. Market forces are ultimately going to be the thing that drives wider adoption: IPv4 addresses getting so expensive that it drives people to try IPv6, and when that fails they complain in posts like this and directly to their service providers. The fact that OP names names of services failing to offer IPv6 is a good thing. Ideally it will start creating pressure on those services/corporations to fully support IPv6. If complaining doesn't work to motivate them, users moving away from their services to providers who do offer IPv6 support will motivate them.

I was rather dissuaded from trying to keep it working on any of my servers when, after much head-scratching and wrangling, I eventually traced a bunch of weird network issues on my desktop system to IPv6. Seems that any web requests to sites that supported v6 natively were randomly flaky and slow, causing terrible video streaming performance. Only fixed when I shut off v6 at the network adapter level.

Guess I'll try and turn it back on in a year or two and see if it's still terrible. If it's not, maybe I'll think about turning it on for some of my servers again.

> The GitHub API and its code load endpoints are not reachable via IPv6

This is quite strange given the period around 2010 where there were government edicts that IPv6 must be supported. Perhaps GitHub wasn't mission critical back then.

s.gif
There are a number of companies (not naming names) that do NOT support IPv6 for commoners but if you are on a government account/contract you have different government endpoints that ... work over IPv6.

Infuriating, but perhaps understandable; they're willing to support the government over IPv6 because it's required and they pay more. But I wish there was a "I know what I'm doing and understand you'll make fun of me if I ask for support on this" option.

Still no ipv6 support with WSL2 in windows. So, if you’re a Microsoft Windows dev in an ipv6 environment, you won’t make it too far.
s.gif
Quite a strange limitation in my opinion. I understand that dealing with subnetting/host network rebinding to allow full IPv6 can be a challenge (especially if you're on DHCPv6 or some other manually managed thing instead of normal SLAAC) but surely Microsoft could use whatever NAT solution they use for IPv4 to work on IPv6 as well?

Apparently support for the protocol can already be enabled (https://github.com/nathanchance/WSL2-Linux-Kernel/issues/25). This makes it technically possible to use a WireGuard tunnel for IPv6 support, at least...

s.gif
Heh, yeah, I opened that issue. Nathan is awesome for maintaining that kernel.
s.gif
Haha, I didn't even notice. I should clean my glasses!
Hetzner should provide free CGNAT IPv4 Addresses (IPv4 Gateway) for IPv6-Only VMs
s.gif
Communal ipv4 is very problematic for certain services due to bad neighbors causing it to be blacklisted.
s.gif
Not for hosting services, but for things like accessing Github.
s.gif
That's GP's point. Service providers will block the IPs of abusive clients. If those clients are your cg-nat neighbours, you're blocked with them.
s.gif
Try accessing the web through TOR and you see why public, shared IP addresses are quite a hassle in practice. Exit nodes don't host anything either, after all.

Actually, that's not even that bad a way to get IPv4 on any IPv6-only host: route it all through TOR!

s.gif
this sounds like a valid argument for deploying ipv6 wherever you can, tbqh

cgnat is only going to get MORE common, globally

s.gif
A whole lot of ISPs are doing CGNAT for IPv4 now, mostly in Asia. Starlink does it. It's mostly OK but has a lot of drawbacks, particularly IP-based geolocation. (Starlink does not support IPv6 although they seem to be rolling it out this month.)
s.gif
Being behind CGNAT has downsides yes, for example being unable to ever host anything; you become relegated to a consumer who's dependent on the big hosting companies to ever have an Internet presence. But geolocation? I don't want everyone to be able to get my location! Breaking IP-based geolocation is a benefit of CGNAT, not a drawback.
s.gif
It's a huge PITA though. I'm near Sacramento but my IP looks like it's in Los Angeles. It screws up a surprising number of things, particularly local TV streaming services.

IP geolocation is a bad idea for lots of reasons. Unfortunately it's also a reality of how services work.

s.gif
IP-based geolocation is fundamentally broken. Making it visibly broken in more cases is good.
s.gif
My ISP (Metronet, Ohio, US) uses CGNAT. I’ve had their service for about 15 months now, and it has been pretty much uneventful. Maybe a handful of times I’ve gotten a captcha on something, but for the most part, it’s just fine. I also don’t see thousands of blocked connection attempts a day either, so there is a plus side. I just use Tailscale should I need to access anything at home while I’m away.
s.gif
47.57% of observed requests coming out of as14593 is ipv6, as of two days ago: https://twitter.com/noIPv6/status/1600527249282895879

& to be clear, that is CRAZY growth!

edit: that's traffic to monitoring resources, not in general, sorry /facepalm

s.gif
Just to specify the kind of "should": But they don't, do they? Same with vultr, their ipv6 boxes have no outgoing IPv4 connection route.
Yearly reminder that Hacker News still is IPv4 only.
I have not seen a practical way to go IPv6-Only. If I made my DNS, Web, Chat, Time and other servers IPv6-Only I would only be able to access them from a few mobile networks, most VPS providers and a handful of ISP's. One might be tricked into thinking adoption is high, but the VPS and mobile providers really throw off the statistics. Mobile providers due to sheer numbers of clients and being late to the allocation game did not have much choice but to go IPv6 and set up IPv4 gateways/tunnels.

I could see doing IPv6+IPv4 in a corporation and terminate everything on load balancers, allowing anything behind the LB to be any combination of IPv4/IPv6. But IPv6 only? I don't see any big companies doing that in my lifetime.

My ISP obtained some IPv6 space but have not deployed it yet as they are still trying to decide how to subnet and bill for it so I currently have some static IPv4 addresses. I am on a tiny ISP, so tiny all their C-Levels phone numbers and email addresses are still in whois. Most of the US ISP's doing IPv6 also do IPv4 even if sometimes it is CG-Nat.

s.gif
> I could see doing IPv6+IPv4 in a corporation and terminate everything on load balancers, allowing anything behind the LB to be any combination of IPv4/IPv6. But IPv6 only? I don't see any big companies doing that in my lifetime.

facebook started migrating to ipv6-only datacenters in 2014 or so. i think all of them are converted at this point. they only support legacy ip at their network edge, & use siit (iirc) to facilitate access.

I propose a real simple solution:

Major providers pledge to take this seriously. They toss a rule in their routers that just drops all ipv4, for 1 minute, starting at noon UTC. At 12:01 UTC, revert the change and ipv4 works again. Do this every day.

The following week, up it to 2 minutes.

The incentive will happen.

s.gif
Of course it’s simple if you have the capability to compel coordinated action across a globally-distributed disparate-and-not-easily-definable group of stakeholders whose incentives typically do not align.
s.gif
Or as a friend of mine suggested, more than ten years ago and only half in jest, I think: just block all porn sites on IPv4 (but not on IPv6). The demand for IPv6 will soon be overwhelming.
s.gif
While I think this would effectively move the needle, as soon as they announce that this is going to happen, I am guessing heart monitors, ankle brace companies (people in home jail) and a slew of weird other use cases will pop up as major problems and the effort will fail.
s.gif
All of those things should be able to cope with a 1-minute loss of connectivity already. To do otherwise would be astonishingly negligent.
We are running a lot of IPv6 only clusters and don't have any issues. The key solution is to have a NAT64 gateway somewhere at the edge.
s.gif 52 more comments...
s.gif
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK