Tell HN: IPv6-only still pretty much unusable
647 comments
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".
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".
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?
That's a solved problem whose solution is called ipv4 over ipv6 tunneling.
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
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?
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?
You're more or less describing 6to4. It's already a thing in v6.
It’s mostly a solved problem as most mobile network operators are ipv6 only now. My iPhone only has an ipv6 address for example.
If it's not "Ipv4+" aware, it wouldn't be able. Otherwise it would understand new packet formats.
> (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.
Which would need translation support at the edges between devices speaking only old-IPv4 and the superset-IPv4. Just as is done with IPv6.
> 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.
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.
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+"
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+"
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.
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.
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.
[deleted]
> 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?
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?
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
Do addresses have a variable length in your IPv4+ header?
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?
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?
> I still don't understand why they shifted from 0:: to ffff::
I think the most reasonable explanation is probably because they thought ::1 being loopback (otherwise it would have to go above 255.255.255.255) was more important (since it would exist as long as IPv6 does) than the transition encoding that presumably would die off over time.
I think the most reasonable explanation is probably because they thought ::1 being loopback (otherwise it would have to go above 255.255.255.255) was more important (since it would exist as long as IPv6 does) than the transition encoding that presumably would die off over time.
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.
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.
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.
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.
This comes up every few years. I remember there was even a link about it, but I can't remember what to search for :)
Naive approaches all assume that there is some incremental step, and IETF was just too idealistic to go with a completely new second system. But as others mentioned, it's a coordination problem. Since IPv4 does not have any signaling mechanism for upgrade, or for somehow encapsulating variable/longer length addresses ... adding that is the minimal change size.
Of course if your argument is that the RFCs and the whole v6 world is just a big unfriendly abstract wall of text, not "accidental IT guy" friendly, then of course you are right. But that can be remediated by writing better docs, providing better UX via better tools. (All the usual linux tools are horribly user hostile, and then they have an additional stinking pile of v6 tools, or the occasional -6 parameter.... but that's not exactly the IETF's fault.)
Naive approaches all assume that there is some incremental step, and IETF was just too idealistic to go with a completely new second system. But as others mentioned, it's a coordination problem. Since IPv4 does not have any signaling mechanism for upgrade, or for somehow encapsulating variable/longer length addresses ... adding that is the minimal change size.
Of course if your argument is that the RFCs and the whole v6 world is just a big unfriendly abstract wall of text, not "accidental IT guy" friendly, then of course you are right. But that can be remediated by writing better docs, providing better UX via better tools. (All the usual linux tools are horribly user hostile, and then they have an additional stinking pile of v6 tools, or the occasional -6 parameter.... but that's not exactly the IETF's fault.)
IPv6 is a slightly different model, different enough that you can't just copy the configuration from IPv4, and that adds a significant implementation burden. If IPv4+ had been created instead, we'd probably all be already using it.
That said, it's obviously way too late to go that direction. The only successor to IPv4 is IPv6. Choosing the wrong model just made sure we'd have to go dual-stack for a loong time.
That said, it's obviously way too late to go that direction. The only successor to IPv4 is IPv6. Choosing the wrong model just made sure we'd have to go dual-stack for a loong time.
IPv4+ would be backwards compatible as long as the first 4 bytes are zero. So you could just replace the existing ipv4 stack.
Ipv6 is not backwards compatible at all.
Ipv6 is not backwards compatible at all.
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.
it's ::ffff:1.2.3.4, so that loopback can be ::1. But yeah same idea.
"::ffff:1.2.3.4" is a valid IPv6 address; "IPv4-mapped IPv6"
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?
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?
> 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.
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.
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.
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.
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.
those of us who want to have the same port on different computers available to the internet might see that as a bad thing
Oh you don't need a firewall then? I guess accessing a routers web interface from the WAN is a-okay
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
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
staringback(1)
My shitty router also firewalls incoming IPv6 connections by default, unless I manually allow them per-device, so I don't get your point.
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.
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.
My router's httpd listens on the LAN not the WAN unless I tell it to. This is unrelated to what I said.
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.
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.
That's like saying that a bad firewall implementation leaks like a sieve. This is not what I was talking about.
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.
A naive NAT implementation can allow an attacker to bypass the firewall.
Curious, could you expand on this?
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.
Thanks! (you added this afterwards, right? Or it's just me being tired and skipping this)
> 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.
While in principle that is possible, in practice almost all home routers are based on Linux, and Linux netfilter NAT implementation distinguish connections based on port and IP, not just port, so this would not work.
While in principle that is possible, in practice almost all home routers are based on Linux, and Linux netfilter NAT implementation distinguish connections based on port and IP, not just port, so this would not work.
Home routers often greatly simplify the interface.
BT, one of the largest ISP's in the UK, only allow the configuration of destination IP and external/internal ports[0].
I've never expected my NAT to do anything other than map ports. I can see why the ability to map source IPs to different ports would be useful but relying on that as a security feature feels like a foot-gun. I wouldn't feel comfortable exposing an application that doesn't have some form of authentication and/or blacklisting.
[0] https://portforward.com/bt/home-hub-6/Port%20Forwarding.jpg
BT, one of the largest ISP's in the UK, only allow the configuration of destination IP and external/internal ports[0].
I've never expected my NAT to do anything other than map ports. I can see why the ability to map source IPs to different ports would be useful but relying on that as a security feature feels like a foot-gun. I wouldn't feel comfortable exposing an application that doesn't have some form of authentication and/or blacklisting.
[0] https://portforward.com/bt/home-hub-6/Port%20Forwarding.jpg
I think you would enjoy this article from Tailscale: https://tailscale.com/blog/how-nat-traversal-works/
The poke a hole to outside world to a random server, log the port allocated to you by your router and have someone else use this to connect to you is the basis of STUN protocol.
The poke a hole to outside world to a random server, log the port allocated to you by your router and have someone else use this to connect to you is the basis of STUN protocol.
This is straight up untrue. The only thing NAT does is change the apparent source address of outbound connections. Inbound connections aren't outbound connections, so it does nothing to them.
NAT is not a substitute for a firewall.
NAT is not a substitute for a firewall.
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.
Why don't you write a blog post about this? I'm interested to see what will go on
>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?
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?
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.
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.
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.
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.
Big universities (at least in my experience in the USA) are the other ones that would have a public IP address for every device, at least until rather recently. They were online very early and got allocated huge blocks of addresses, before anyone really imagined future scarcity.
In the mid-90's, every system at my university had a public IP address, including those on the campus residential networks. There were no firewalls. It was also a flat address space (/16, 255.255.0.0) for the whole campus! The 90's were certainly a different time.
My company runs an API SaaS; my impressions come from a hobby I have of looking up the hosting providers behind our customer IPs as seen in our request logs (to find out what people think is a good idea for hosting a production web- or mobile-app service backend these days.)
By and large, our very-much "real world" customers are "self hosting" — usually on bare metal rather than a VPS, and usually with providers you've probably never heard of (ColoCrossing and ServerMania seem to come up fairly often among our US-based customers.) These hosting providers are all very much in the style of "you lease each machine as a separate contract; each machine gets one public IPv4 address included in the cost; private networking [i.e. an explicit VLAN] is an extra optional feature you can enable after the fact, and only works between higher-end machine types, rather than being a given, because our lower-end machines only have a single NIC in them [besides the one that's part of the BMC used for IPMI]."
What I assume is happening here isn't literal "self hosting" — these random non-IT-oriented customers wouldn't know the first thing about it — but rather that a given customer of ours has paid some "vertically-integrated IT consultancy" to both build and host their service for them; and said consultancy has chosen to use bare-metal hosting to host the resulting service, to minimize their own OpEx, and therefore maximize their margins. (In fact, I bet they're often packing several such customers onto a single box.)
---
Also, in a more professional capacity, I investigate the hosts behind IP addresses behind bulk-registration / DDoS attacks against our platform, in order to create signatures for them. Given the way some of these attacks seem to work, a large number of machines on the Internet — especially in Russia and [some parts of] Africa — seemingly aren't only un-NATed, but in fact have a public /24 or even /22 directly attached to a single box! (If traffic was originating from a random subset of a /24, it could just be someone spinning up a hundred VMs on top of some small colo's OpenStack deployment, sure. But tandem traffic from every IP in a /24, and only exactly said /24? That looks pretty much exactly like the sort of tandem IPv6 traffic that is generated when a box has a /48 or /56 assigned to it.)
By and large, our very-much "real world" customers are "self hosting" — usually on bare metal rather than a VPS, and usually with providers you've probably never heard of (ColoCrossing and ServerMania seem to come up fairly often among our US-based customers.) These hosting providers are all very much in the style of "you lease each machine as a separate contract; each machine gets one public IPv4 address included in the cost; private networking [i.e. an explicit VLAN] is an extra optional feature you can enable after the fact, and only works between higher-end machine types, rather than being a given, because our lower-end machines only have a single NIC in them [besides the one that's part of the BMC used for IPMI]."
What I assume is happening here isn't literal "self hosting" — these random non-IT-oriented customers wouldn't know the first thing about it — but rather that a given customer of ours has paid some "vertically-integrated IT consultancy" to both build and host their service for them; and said consultancy has chosen to use bare-metal hosting to host the resulting service, to minimize their own OpEx, and therefore maximize their margins. (In fact, I bet they're often packing several such customers onto a single box.)
---
Also, in a more professional capacity, I investigate the hosts behind IP addresses behind bulk-registration / DDoS attacks against our platform, in order to create signatures for them. Given the way some of these attacks seem to work, a large number of machines on the Internet — especially in Russia and [some parts of] Africa — seemingly aren't only un-NATed, but in fact have a public /24 or even /22 directly attached to a single box! (If traffic was originating from a random subset of a /24, it could just be someone spinning up a hundred VMs on top of some small colo's OpenStack deployment, sure. But tandem traffic from every IP in a /24, and only exactly said /24? That looks pretty much exactly like the sort of tandem IPv6 traffic that is generated when a box has a /48 or /56 assigned to it.)
People assume that RFC1918 is not routable, but that's not the case... It's fully routable, but there is no global route.
Have you ever tested routing to your RFC1918 address space from the ISP, or from a customer in the same neighborhood?
On some ISPs, all the customer routers in a given area are placed in a large legacy subnet, so if another customer adds a manual route to RFC1918 space using your router as next hop - the traffic will arrive on the WAN interface of your router. Some routers will actually route this traffic inside.
Have you ever tested this and verified that your router doesn't do this? Probably not, because most people haven't. They just assume that it can't, and get a nasty surprise if someone demonstrates that it can.
On some ISPs, all the customer routers in a given area are placed in a large legacy subnet, so if another customer adds a manual route to RFC1918 space using your router as next hop - the traffic will arrive on the WAN interface of your router. Some routers will actually route this traffic inside.
Have you ever tested this and verified that your router doesn't do this? Probably not, because most people haven't. They just assume that it can't, and get a nasty surprise if someone demonstrates that it can.
> The claim is that IPv4 + NAT + bad firewall is better than IPv6 + bad firewall.
Even that is not true:
- It takes half-minute to scan an IPv4 public IP (NAT) for vulnerabilities.
- Good luck and have fun to scan a /64 for a potentially vulnerable machine. See you next century.
- And if it is not enough: most internet box support UPnP/NAT-PMP that allow any malware to get your NAT wild opened.
Even that is not true:
- It takes half-minute to scan an IPv4 public IP (NAT) for vulnerabilities.
- Good luck and have fun to scan a /64 for a potentially vulnerable machine. See you next century.
- And if it is not enough: most internet box support UPnP/NAT-PMP that allow any malware to get your NAT wild opened.
Who's the monster that created NAT for IPv6 D:
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.
> 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:
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?
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
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?
> 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.
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.
> 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.
That is usually not true. NAT punching is a thing for decades now.
- 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?
- And is it any different from a stateful firewall on IPv6?
> NAT punching does require cooperation of programs on the protected machines
As does listening to a port.
> And is it any different from a stateful firewall on IPv6?
Hum, not much. And that's the point, all of those are basically the same. NAT doesn't give you much security, and NAT without a firewall usually gives you less security than a firewall, since NAT usually is configured for connectivity, and a firewall for protection.
As does listening to a port.
> And is it any different from a stateful firewall on IPv6?
Hum, not much. And that's the point, all of those are basically the same. NAT doesn't give you much security, and NAT without a firewall usually gives you less security than a firewall, since NAT usually is configured for connectivity, and a firewall for protection.
> > NAT punching does require cooperation of programs on the protected machines
> As does listening to a port.
Listening on a port is for incoming connections, exactly the kind that we're blocking with either a (stateful) firewall or NAT. Listening on a port is a declaration of a program (a server) to communicate with whichever counter party can connect to this port (until the server program decides to close the connection), and limiting that reach is the topic here.
NAT hole punching is more like an outgoing connection in that the client agrees to communicate with a particular single counter party for each punch. That's why I made the comparison to opening an https connection to a server. The risks look basically the same to me (the client has to trust the server in the https case, and the client has to trust the intermediating server in the NAT hole punching case to intermediate with the right client; admittedly it additionally has to trust the other peer (e.g. that its compressed data doesn't try to break decoders), but in cases where it communicates with another party via a server the situation may be the same again (unless the server re-encodes the data and does that securely)).
> And that's the point, all of those are basically the same.
That's a relief for me to hear, as I started to doubt myself whether I am missing something ("why is it not OK to use NAT to block incoming connections?").
> since NAT usually is configured for connectivity, and a firewall for protection.
Sure, a firewall can add additional restrictions. I have always understood NAT's protection to be limited to prohibiting incoming connections (unless when adding port forwarding), while allowing outgoing connections including NAT hole punching.
I'm also talking in the context of configuring a Linux machine via iptables (where you configure both NAT and other firewalling rules). Maybe you're thinking more in terms of consumer "NAT" vs. consumer "firewalling" devices and their respective capabilities. Or maybe this whole "don't consider NAT to be a security feature" movement is just to pull people towards IPv6 by saying they don't need NAT to be as secure (or better if they configure additional restrictions)?
> As does listening to a port.
Listening on a port is for incoming connections, exactly the kind that we're blocking with either a (stateful) firewall or NAT. Listening on a port is a declaration of a program (a server) to communicate with whichever counter party can connect to this port (until the server program decides to close the connection), and limiting that reach is the topic here.
NAT hole punching is more like an outgoing connection in that the client agrees to communicate with a particular single counter party for each punch. That's why I made the comparison to opening an https connection to a server. The risks look basically the same to me (the client has to trust the server in the https case, and the client has to trust the intermediating server in the NAT hole punching case to intermediate with the right client; admittedly it additionally has to trust the other peer (e.g. that its compressed data doesn't try to break decoders), but in cases where it communicates with another party via a server the situation may be the same again (unless the server re-encodes the data and does that securely)).
> And that's the point, all of those are basically the same.
That's a relief for me to hear, as I started to doubt myself whether I am missing something ("why is it not OK to use NAT to block incoming connections?").
> since NAT usually is configured for connectivity, and a firewall for protection.
Sure, a firewall can add additional restrictions. I have always understood NAT's protection to be limited to prohibiting incoming connections (unless when adding port forwarding), while allowing outgoing connections including NAT hole punching.
I'm also talking in the context of configuring a Linux machine via iptables (where you configure both NAT and other firewalling rules). Maybe you're thinking more in terms of consumer "NAT" vs. consumer "firewalling" devices and their respective capabilities. Or maybe this whole "don't consider NAT to be a security feature" movement is just to pull people towards IPv6 by saying they don't need NAT to be as secure (or better if they configure additional restrictions)?
The point here is that the movement against IPv6 for security reasons is disingenuous or even outright dishonest. Those security reasons don't exist.
Personally, I have never seen any argument for IPv6 based on security (except for some very fringe ones about address enumeration). But if anybody makes one to you, well, it would be disingenuous, or maybe even dishonest too. There is no security-based argument either way.
Personally, I have never seen any argument for IPv6 based on security (except for some very fringe ones about address enumeration). But if anybody makes one to you, well, it would be disingenuous, or maybe even dishonest too. There is no security-based argument either way.
> I have always understood NAT's protection to be limited to prohibiting incoming connections
It doesn't actually do this. NAT rewrites the source address of outbound connections. Inbound connections aren't outbound connections so it does nothing to them, which means it doesn't prohibit them.
That is why you don't need NAT for security: it doesn't give any in the first place.
It doesn't actually do this. NAT rewrites the source address of outbound connections. Inbound connections aren't outbound connections so it does nothing to them, which means it doesn't prohibit them.
That is why you don't need NAT for security: it doesn't give any in the first place.
> which means it doesn't prohibit them
OK. I want to dig down into this. Let's say I have a router `R`, which I'm running NAT and optionally other iptables rules on. I've got a client machine `C` sitting in a private network "behind" `R`. `R` is connected to the internet via a gateway `G`. `A` is some machine out there owned by an attacker. There's a vulnerable TCP service running on `C` listening on *:1313.
The only issue I can see is that if `A` can hack `G`, because `G` doesn't have to depend on routing to reach `R`, it can send traffic to `R` with a target address of 10.0.0.2, which `R` then forwards to `C`. I haven't verified that this works (don't have enough devices with me). Is this what you're after? Fair point.
If I'd add the following rule to `G`, `C` would be safe even if `G` is hacked[*]:
Am I missing anything?
Edit: simplified the rule
PS. I'd welcome a good pointer (book or other) on network security and also IPv6; I'm a software developer, and only occasionally dealing with networks.
OK. I want to dig down into this. Let's say I have a router `R`, which I'm running NAT and optionally other iptables rules on. I've got a client machine `C` sitting in a private network "behind" `R`. `R` is connected to the internet via a gateway `G`. `A` is some machine out there owned by an attacker. There's a vulnerable TCP service running on `C` listening on *:1313.
A
|
internet
|
G
| 4.3.2.1
|
| eth_public 4.3.2.77
R
| eth_private 10.0.0.1
|
| 10.0.0.2
C
The only issue I can see is that if `A` can hack `G`, because `G` doesn't have to depend on routing to reach `R`, it can send traffic to `R` with a target address of 10.0.0.2, which `R` then forwards to `C`. I haven't verified that this works (don't have enough devices with me). Is this what you're after? Fair point.
If I'd add the following rule to `G`, `C` would be safe even if `G` is hacked[*]:
iptables -A FORWARD -i eth_public -d 10.0.0.0/16 -j REJECT
Am I missing anything?
Edit: simplified the rule
PS. I'd welcome a good pointer (book or other) on network security and also IPv6; I'm a software developer, and only occasionally dealing with networks.
That's basically it. In that network, G can connect to C just fine. You need the firewall rule to block inbound connections, because NAT just does nothing to them.
I don't have any good learning resources for this stuff, sorry. I mostly picked it all up by running it on my home network and Googling for stuff when I hit something I didn't get.
I don't have any good learning resources for this stuff, sorry. I mostly picked it all up by running it on my home network and Googling for stuff when I hit something I didn't get.
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).
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).
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.
> 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.
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.
NAT wasn’t started as a way to make the address space last longer. A few decades ago you could get hundreds of thousands of IP’s by filling out a form with ARIN without any serious justification if you wanted them. I worked at an ISP and IP’s weren’t a scarce resource.
NAT started because having a network didn’t mean you were necessarily participating in the Internet. Globally unique addresses weren’t that important. At some point you had this decentralized situation where local networks wanted to bridge their users address space to the Internet without renumbering everything and thus NAT was born.
NAT started because having a network didn’t mean you were necessarily participating in the Internet. Globally unique addresses weren’t that important. At some point you had this decentralized situation where local networks wanted to bridge their users address space to the Internet without renumbering everything and thus NAT was born.
> 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.
That's what reasonable people would do for a V4 network too.
RFC7084 says a NAT-like stateful firewall mechanism should be enabled by default on customer IPv6 routers.
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
Inertia on the part of large services, providers, and infrastructure isn't much of a surprise.
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.
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.
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.
The popularity of uPnP for automatic port forwarding should be a clue, anything that uses that is blocked by cgnat.
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.
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.
> 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.
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.
>> * NAT isn't needed anymore.*
> False.
"IPv6 Multihoming without Network Address Translation"
> 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.
I just did a quick read but I don't understand how this would help the case of your Gateway ethernet link going down temporarily and switching to Cellular WAN?
The client would still need some smart steering to select the correct route no? Does the gateway invalidate the ethernet address somehow? But with NAT you don't need to worry about it.
The client would still need some smart steering to select the correct route no? Does the gateway invalidate the ethernet address somehow? But with NAT you don't need to worry about it.
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.
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.
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.
Elad Cohen?
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.
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.
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.
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.
> 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.
It’s impossible to finish a transition when the old version has no end of life in sight.
>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.
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.
Increased demand will drive the price up, but that's not end of life.
Developed countries will pay obscene amounts for ipv4 space. Just as they do for shorthand .com domains.
Developed countries will pay obscene amounts for ipv4 space. Just as they do for shorthand .com domains.
That cost will continuously rise up until migration to ipv6 comes out cheaper and enables access to the developing market as well. At which point it is a business no brainer.
Short .com domains actually have an intrinsic value to their prospective owners though, since the domain is the human-readable address, and a shorter address is more memorable to customers. The version of the underlying network protocol is just an implementation detail that the vast majority of companies (basically everyone besides possibly 1.1.1.1 and 8.8.8.8) would happily drop if it became totally unnecessary.
IPv4 will never disappear, it will just fade into obscurity. (We'll probably be dead and buried long before that time.)
Just like IPX. It's still necessary and in use for some things -- so it hasn't reached its end of life -- but when was the last time you ever thought about it?
By this metric, we still haven't finished migrating to v4.
By this metric, we still haven't finished migrating to v4.
True. I could see a world where IPv4 is only for legacy, internal systems and it is not routed externally, but that feels like decades away. There would need to be a coordinated effort of major ISPs to turn it off, but why would that happen if people are willing to pay for it?
I'm curious: what still uses IPX in 2022?
I have no doubt there's an internal application running on a Novell server somewhere that we'll never hear about. It's still running on a machine in a closet just like it was in 1997, or possibly imaged and migrated to a VM because nobody wanted to touch it.
Red Alert 2! They never added IP-based LAN play to it.
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.
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.
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.
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.
> 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.
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.
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.
Ideally the number of ipv6 allocations should be close to 1 rather than close to 1000.
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.
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.
According to this Stack Exchange post from last year a full IPv4 routing table requires on the order of a few hundred MBs of RAM. This is indeed a tiny fraction of the cost of maintaining the global internet infrastructure.
https://networkengineering.stackexchange.com/questions/76562...
https://networkengineering.stackexchange.com/questions/76562...
The problem is that the routers that have to hold the routing table can only handle a limited number of routes. There is a good article from APNIC about the topic.
https://blog.apnic.net/2021/03/03/what-will-happen-when-the-...
https://blog.apnic.net/2021/03/03/what-will-happen-when-the-...
Said routers could be redesigned...
And besides, there is no need to keep the whole routing table in RAM. Instead all that's necessary is a single integer per route representing which port packets to each route needs to be sent down. So even for a large router with 64 ports, the whole routing table fits inside 1 megabyte.
And besides, there is no need to keep the whole routing table in RAM. Instead all that's necessary is a single integer per route representing which port packets to each route needs to be sent down. So even for a large router with 64 ports, the whole routing table fits inside 1 megabyte.
Sure they can create routers with more space for the routing table but you still have to replace all the old ones which isn't cheap.
A single port of a router at an internet exchange can reach more than 1000 different routers. A router has to decide to which IP it should forward a packet not just the port.
A single port of a router at an internet exchange can reach more than 1000 different routers. A router has to decide to which IP it should forward a packet not just the port.
It's not "twisted into uselessness"... the reduction in routing table size comes from the large address space. No twisting was needed.
Also, the routing tables we're talking about here need to be stored in TCAM. Content-addressed memory is a lot more expensive than regular DRAM.
Also, the routing tables we're talking about here need to be stored in TCAM. Content-addressed memory is a lot more expensive than regular DRAM.
> 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.
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.
Plus if you're using enough IPv4 addresses it is going to be the same problem anyway. I can barely keep track of what I've assigned everything to in just a /24 so I have local DNS and I don't need to.
Any sysadmin for a medium sized company with their own servers are likely to end up having to type in IP address or get them off shitty management consoles that don't support copy paste in any way.
Using IP addresses directly is a bad practice in general, it introduced security risks in many scenarios.
SSL - usually cannot verify the cert, defeating the point of SSL SMB - windows will fail over to less secure ntlm auth instead of kerberos
If your using IP addresses instead of hostnames to reference machines, you're doing it wrong.
Also IPv6 is easier to remember in general... We have a single large IPv6 allocation (eg 2001:db8::/32), and everything sits under that in a logical layout. For legacy IP, we have several different allocations in different class A blocks (104.x, 66.x, 62.x etc) plus all the RFC1918 space used internally
SSL - usually cannot verify the cert, defeating the point of SSL SMB - windows will fail over to less secure ntlm auth instead of kerberos
If your using IP addresses instead of hostnames to reference machines, you're doing it wrong.
Also IPv6 is easier to remember in general... We have a single large IPv6 allocation (eg 2001:db8::/32), and everything sits under that in a logical layout. For legacy IP, we have several different allocations in different class A blocks (104.x, 66.x, 62.x etc) plus all the RFC1918 space used internally
Sure, but most places are not setup to using DHCP on servers or automated installs. So you will be typing in IP addresses through some kind of console to configure the machine in the first place and you will be typing in that IP address in the DNS system and when someone remotely fucks up the routing or IP config then you will be manually typing in lots of IP addresses to fix it.
If you have enough nodes to care and manually assign and at the same time don't automate deployment that sounds like an issue in general... and not with IPv6. You're likely to typo IPv4 just as well with enough entries.
Yep, but in my experience you have to manage about 2000+ machines before management will allow you to spend time on setting up deployment automation. So around the time you are setting multiple new machines a week.
I've done automatic deployment for 16. It was still totally worth it.
Of course it is, automation is very nice, I use it for the handful of machines I have my personal stuff on. I am just saying that from my days as a sysadmin it was usually a years long uphill battle to get approval for automating even minor things.
> One of the ideas of ipv6 was to reduce routing tables
That idea was abandoned about 20 years ago. One fairly quickly discovered that hierarchical routing does not work well in the real Internet, where redundancy is done on the IP level with everybody and their dog having provider-indepent IP space.
> like that the only standard for local ipv6 addresses
Which one is the only standard? Link-local, site-local, ULA, or using a non-routed netblock with or without DHCPv6 (or RA)?
That idea was abandoned about 20 years ago. One fairly quickly discovered that hierarchical routing does not work well in the real Internet, where redundancy is done on the IP level with everybody and their dog having provider-indepent IP space.
> like that the only standard for local ipv6 addresses
Which one is the only standard? Link-local, site-local, ULA, or using a non-routed netblock with or without DHCPv6 (or RA)?
site-local addresses are deprecated since RFC 3879. Link-local addresses are indeed another standard, but have the very same length problem. You have these horribly long ipv6 addresses... those can't reasonably be parsed by humans...
There is no 192.168.* equivalent in ipv6. Why don't we have something like fd00::1 being the router and fd00::2, fd00::3, etc being the devices in the local network, assigned by DHCP. You can absolutely configure your router that way but it is violating a MUST requirement of RFC 4193. That's my point. There is no non-routed netblock where you can just use it for local purposes, outside of the one for SLAAC and the one for ULA, both creating these horribly long monsters of addresses. All the others have purposes attached that are not meant to be used for local networks.
Why do you care how long the addresses are? That's what DNS is for. Within a link - most home networks are only one, and those are the ones that need to be simplest - there's even mDNS.
DNS is great but it is not available in all settings. Eventually you need to type in ip addresses, there are gazillions of workflows where you have to do that.
There's only a very few places where typing IP addresses actually makes sense. Configuring DNS is the main one. Trying to isolate problems is another - if you can ping 8.8.8.8 but not google.com you can reasonably infer that the problem is DNS. I really can't think of any others.
That latter one is admittedly kind of a pain, but a wallet-sized cheat sheet can solve it for you. Might be a good idea to try to convince vendors to include a reliable entry or two in the hosts file for that purpose? You can always add it yourself for now, when you're on your own workstation.
That latter one is admittedly kind of a pain, but a wallet-sized cheat sheet can solve it for you. Might be a good idea to try to convince vendors to include a reliable entry or two in the hosts file for that purpose? You can always add it yourself for now, when you're on your own workstation.
Amazon is really not a great example, I don't think. The giant cloud providers are outliers with respect to DFZ announcements, as they have many, many POPs and also allow their customers to announce address space. They're more like transit networks at this point than what could be reasonably considered a representative end user.
More reasonable to look at announcements per AS, where it's currently about half of IPv4, but trending upwards at a faster pace.
v6: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata... v4: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata...
More reasonable to look at announcements per AS, where it's currently about half of IPv4, but trending upwards at a faster pace.
v6: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata... v4: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata...
So Amazon with its 3-fold ratio is in fact giving a better argument for ipv6 than the average, nice. Generally a factor of two doesn't say much about ipv6 creating less allocations at all, given how ipv6 is roughly within a factor of two in terms of adoption in general.
> That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/
I remember the line being "the IPv4 routing table is 3x as big as it needs to be due to fragmentation", so that seems pretty in line with that.
I remember the line being "the IPv4 routing table is 3x as big as it needs to be due to fragmentation", so that seems pretty in line with that.
> That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/
How many clients can those IPv4 allocations serve? How many clients can those 946 serve?
If Amazon had 2880 IPv6 allocations, how many clients could they serve?
I'd say a lot was gained. Someone asking for a random PI IPv6 allocation gets, at minimum, a /48 for a "site". That's the equivalent of a Class A (16 bits for subnets).
Are you saying everyone being able to get their own Class A equivalent is 'nothing gained'?
How many clients can those IPv4 allocations serve? How many clients can those 946 serve?
If Amazon had 2880 IPv6 allocations, how many clients could they serve?
I'd say a lot was gained. Someone asking for a random PI IPv6 allocation gets, at minimum, a /48 for a "site". That's the equivalent of a Class A (16 bits for subnets).
Are you saying everyone being able to get their own Class A equivalent is 'nothing gained'?
> 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?
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?
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.
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.
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.
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.
> 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 how 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.
And exactly how 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.
In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan.
OR
Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine.
There’s no useful and backward compatible way of extending IPv4.
OR
Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine.
There’s no useful and backward compatible way of extending IPv4.
Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem.
I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.
On Windows firewall matches ip4 and ip6 with the same rule. The address field there isn't numeric, but text, and can be ip4 address, ip4 network, ip6 address, ip6 network, address range, gateway or "any". Most rules specify "any" for addresses and focus more on ports, application paths and subprotocols like TCP/UDP.
Couple things:
1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets.
2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.
1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets.
2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.
Devices with no clue of IPv6 also just drop those packets. What have we gained?
The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.
The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.
Even better, instead of using a reserved unrouted address, use the "IP version" header field, which literally exists for this exact purpose.
I'm struggling to see how this would improve anything over what v6 did though.
I'm struggling to see how this would improve anything over what v6 did though.
[deleted]
OK:
Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface.
Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in4plus" and AF_INET->AF_INET4PLUS. That's it -- since backward compatibility guaranteed, my software still works on IPv4 system, and hostname parsing is not broken. There might be some minor breakage (unexpected dependencies on struct size or ipv4+ address string length), but it would be way, way smaller than the mess IPv6 is in too.
Right now, I have to set up my firewall twice for ipv4 and ipv6. But with ipv4+? I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both.
Right now, all the network monitoring tools have to have separate "ipv4" and "ipv6" codepaths. But with ipv4+, there could be only one codepath. Yes, packet parsing will have to handle two different IP header format, but once it's parsed, old and new are treated identically.
Sure, the network layer will be more complex. The IP stack in kernel would need to determine if the address is "short" or "long", and format packets differently (either old or new format). The high-performance routers would need to be rewritten. The TCP/IP network card offload will need to accommodate new format.
But this would be way, way less intrusive than current IPv4->IPv6 transitions, because for each line of low-level network code there are millions of lines of application-level code, and for some totally stupid reason the app code transition was made way harder than needed.
Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface.
Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in4plus" and AF_INET->AF_INET4PLUS. That's it -- since backward compatibility guaranteed, my software still works on IPv4 system, and hostname parsing is not broken. There might be some minor breakage (unexpected dependencies on struct size or ipv4+ address string length), but it would be way, way smaller than the mess IPv6 is in too.
Right now, I have to set up my firewall twice for ipv4 and ipv6. But with ipv4+? I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both.
Right now, all the network monitoring tools have to have separate "ipv4" and "ipv6" codepaths. But with ipv4+, there could be only one codepath. Yes, packet parsing will have to handle two different IP header format, but once it's parsed, old and new are treated identically.
Sure, the network layer will be more complex. The IP stack in kernel would need to determine if the address is "short" or "long", and format packets differently (either old or new format). The high-performance routers would need to be rewritten. The TCP/IP network card offload will need to accommodate new format.
But this would be way, way less intrusive than current IPv4->IPv6 transitions, because for each line of low-level network code there are millions of lines of application-level code, and for some totally stupid reason the app code transition was made way harder than needed.
I am not sure why you are downvoted, since you do make some valid points. I myself am not sure whether the very fundamental changes that IPv6 brings did not hamper its adoption than if it was just extended IPv4.
From a network administration perspective, sure, "you need to replace every piece of equipment". But from a software modification perspective (thinking more about the software on network infrastructure equipment than endpoints like applications), you have two very different stacks.
On the other hand, if there was ever a time to make (assumedly so) highly desirable compatibility-breaking changes, that was it.
From a network administration perspective, sure, "you need to replace every piece of equipment". But from a software modification perspective (thinking more about the software on network infrastructure equipment than endpoints like applications), you have two very different stacks.
On the other hand, if there was ever a time to make (assumedly so) highly desirable compatibility-breaking changes, that was it.
> I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both.
Kind of like how PF does it?
If an address family ("af") is not specified, the rule applies to both:
Perhaps the protocol isn't the problem and you're just using firewall software that doesn't have very good syntax?
Kind of like how PF does it?
tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
udp_services = "{ domain }"
block all
pass out proto tcp to any port $tcp_services keep state
pass proto udp to any port $udp_services keep state
If an address family ("af") is not specified, the rule applies to both:
[…]
pf-rule = action [ ( "in" | "out" ) ]
[ "log" [ "(" logopts ")"] ] [ "quick" ]
[ "on" ifspec ] [ route ] [ af ] [ protospec ]
hosts [ filteropt-list ]
[…]
af = "inet" | "inet6"
[…]
action [direction] [log] [quick] [on interface] [af] [proto protocol]
[from src_addr [port src_port]] [to dst_addr [port dst_port]]
[flags tcp_flags] [state]
Perhaps the protocol isn't the problem and you're just using firewall software that doesn't have very good syntax?
Similar functionality is provided in nftables for linux ('inet' filter applies to both ipv4 and ipv6). But, outside of the most trivial use cases of just block/allow a port, it doesn't really work out to be that useful because of other restrictions. E.g., if you are collecting IPs that have e.g., created new connections to some set of ports greater than n times within a time period to rate limit them, you are out of luck and will need separate rules for ipv4 and ipv6 since you cannot save a mix of ipv4 and ipv6 addresses to the same list.
> Right now, most application software need non-trivial rewrite to add ipv6 support:
That's not right.
If you've been using the platform network libraries for things then IPv6 will just work with anything more recent than Windows XP. Unless you've been hardcoding IP length expectations then there is basically nothing to do.
Seriously, use the platform libraries. They handle all the edge cases and stop storing IP address in a uint32.
That's not right.
If you've been using the platform network libraries for things then IPv6 will just work with anything more recent than Windows XP. Unless you've been hardcoding IP length expectations then there is basically nothing to do.
Seriously, use the platform libraries. They handle all the edge cases and stop storing IP address in a uint32.
Unless you are doing something super trivial, like making http/https requests to pre-defined URLs, your platform libraries will not help you.
Your network servers need two explicit bind() calls for two different protocols, and some logic to select which ones to call, and your main accept() code needs to be able to handle two listening sockets... Theoretically you could create IPv6 socket only and accept both addresses but.. (1) apparently it is disabled on many BSD's by default and (2) even on Linux bind() will fail if you have no IPv6 addresses assigned at all.
Your network client would be better, as there are some libraries which let you connect to ipv4 or ipv6 address, but then IPv6 colon-separated format will trip you. How many clients split on ":" to get port number? Or concatenate (IP, ":", PORT) in the logs / settings? All of those would break.
The really annoying part is that all of these problems were 100% predictable from day 1, and yet someone decided to go ahead with this implementation.
Your network servers need two explicit bind() calls for two different protocols, and some logic to select which ones to call, and your main accept() code needs to be able to handle two listening sockets... Theoretically you could create IPv6 socket only and accept both addresses but.. (1) apparently it is disabled on many BSD's by default and (2) even on Linux bind() will fail if you have no IPv6 addresses assigned at all.
Your network client would be better, as there are some libraries which let you connect to ipv4 or ipv6 address, but then IPv6 colon-separated format will trip you. How many clients split on ":" to get port number? Or concatenate (IP, ":", PORT) in the logs / settings? All of those would break.
The really annoying part is that all of these problems were 100% predictable from day 1, and yet someone decided to go ahead with this implementation.
Sorry. What? You’re claiming that the hard part is the parsing of textual ipv6 addresses to binary representation but these same algorithms would work on a hypothetical hand-wavy ipv4+ how? It’s extended so you’ve either got numbers > 255 (breaks parsing routines) or more dots (again breaks parsing routines). Either way you slice it you have to upgrade the parsing routines. And the hard part has not been the parsing routines. And you’d need to justify that what you describe about bound addresses doesn’t apply to a non-existent ipv4+.
It’s getting all the middleware routers, services, and websites to support both that’s been the challenge because it was a chicken and egg. ISPs didn’t want to do it. Websites wouldn’t do it because there were no customers. Carrier grade NATs bought another decade or two. Manufacturers didn’t bother prioritizing the ipv6 stack because carriers weren’t demanding it so HW had very immature and buggy ipv6 stacks which further prohibited ISPs from turning it on because it was another 1-3 purchase cycles before the stack actually worked correctly. And none of that solves the chicken/egg problem of the lack of eyeball supply / customer demand.
The complexity of IPv6 contributed to some of it. Carrier grade NAT did most of the harm though and that would have been a thing regardless.
It’s getting all the middleware routers, services, and websites to support both that’s been the challenge because it was a chicken and egg. ISPs didn’t want to do it. Websites wouldn’t do it because there were no customers. Carrier grade NATs bought another decade or two. Manufacturers didn’t bother prioritizing the ipv6 stack because carriers weren’t demanding it so HW had very immature and buggy ipv6 stacks which further prohibited ISPs from turning it on because it was another 1-3 purchase cycles before the stack actually worked correctly. And none of that solves the chicken/egg problem of the lack of eyeball supply / customer demand.
The complexity of IPv6 contributed to some of it. Carrier grade NAT did most of the harm though and that would have been a thing regardless.
How you represent the address is arbitrary, using a colon instead of a dot matters little as underneath it's just an integer with the only difference being 32 or 128bit.
Using a dot causes its own problems, because it conflicts with DNS. DNS allows fully numeric domain names, but they conflict with legacy ip so are not used on a the public DNS. Using hex would make the problem worse as it's perfectly valid to have an ipv6 address ending "de" for example, which is the TLD for germany.
Legacy addresses can be represented via hex too - try ping 0xdeadbeef.
The socket apis between v6 and legacy ip are largely as compatible as they can be, you need to use sockaddr_in6 and AF_INET6 which is the same as you propose. You can open an AF_INET6 socket and still connect to legacy addresses with it.
For higher level languages that don't deal with fixed size memory structures directly it's pretty much fully compatible, you can just say "connect www.google.com tcp/443" or equivalent, and the system takes care of resolving what protocol and address to connect to.
Using a dot causes its own problems, because it conflicts with DNS. DNS allows fully numeric domain names, but they conflict with legacy ip so are not used on a the public DNS. Using hex would make the problem worse as it's perfectly valid to have an ipv6 address ending "de" for example, which is the TLD for germany.
Legacy addresses can be represented via hex too - try ping 0xdeadbeef.
The socket apis between v6 and legacy ip are largely as compatible as they can be, you need to use sockaddr_in6 and AF_INET6 which is the same as you propose. You can open an AF_INET6 socket and still connect to legacy addresses with it.
For higher level languages that don't deal with fixed size memory structures directly it's pretty much fully compatible, you can just say "connect www.google.com tcp/443" or equivalent, and the system takes care of resolving what protocol and address to connect to.
You just need to do what the world did - NAT.
IPv6 is more than just address space extension. There’s all sorts of stuff packed in there that complicates the process.
All mobile clients are behind CG-NAT. We should have built standards around that instead of worrying about extending IP space to Mars or whatever.
IPv6 is more than just address space extension. There’s all sorts of stuff packed in there that complicates the process.
All mobile clients are behind CG-NAT. We should have built standards around that instead of worrying about extending IP space to Mars or whatever.
> All mobile clients are behind CG-NAT.
Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
* https://www.youtube.com/watch?v=nNMNglk_CvE
NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers:
* https://www.statista.com/statistics/219577/total-customers-o...
One-third of the US population is connecting via IPv6-only on a day-to-day, hour-to-hour basis every time their smartphone reaches out over the radio.
Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
* https://www.youtube.com/watch?v=nNMNglk_CvE
NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers:
* https://www.statista.com/statistics/219577/total-customers-o...
One-third of the US population is connecting via IPv6-only on a day-to-day, hour-to-hour basis every time their smartphone reaches out over the radio.
I also have IPv6 on Verizon Wireless. (I don’t know the details of how it connects to IPv4-only hosts.)
Even my smalltime telco in Australia uses ipv6.
My fiber-based residential ISP here in Japan uses IPv6, and from what I can tell, they're all like that here.
A lot of mobile telcos use IPv6, but there are virtually no telcos around the world that don't force the use of some form of NAT (CGNAT, NAT64) for connecting to legacy sites. NAT64 is effectively another form of CGNAT, you only have a proper end to end connection if you're using IPv6 directly.
TMO US has 110 million customers, but they don't have 110 million legacy IP addresses, and most other telcos are in the same boat.
TMO US has 110 million customers, but they don't have 110 million legacy IP addresses, and most other telcos are in the same boat.
Mea culpa. I'm away right now, but I'm like 95% sure that T-Mobile Home Internet is NATing, or at least was awhile back when I had trouble. Googling around it sounds like it may operate differently than the mobile phones do.
There's a huge difference in the effort required of maintainers (both actual work and cognitive) from just upping the integer size vs what IPv6 is.
It's like no protocol has ever been extended or revised. Ever.
Let's pretend there isn't an Options and Padding section in the IP header:
"Options and Padding - A field that varies in length from 0 to a multiple of 32-bits. If the option values are not a multiple of 32-bits, 0s are added or padded to ensure this field contains a multiple of 32 bits."
Wow, like I CANNOT think of how that would be used to add more bits. More 32 bit sections? No use for that for ipv4+ or ++ or +++.
Let's pretend there isn't an Options and Padding section in the IP header:
"Options and Padding - A field that varies in length from 0 to a multiple of 32-bits. If the option values are not a multiple of 32-bits, 0s are added or padded to ensure this field contains a multiple of 32 bits."
Wow, like I CANNOT think of how that would be used to add more bits. More 32 bit sections? No use for that for ipv4+ or ++ or +++.
Lets call the ip4 the area code and serve the Rick Astley video if no further bits are provided.
There is in fact an options section in v4, and I think it's pretty obvious how it could be used: you could put extra address bits there.
The problem is... how do you get those extra address bits to work?
If you think through that question and produce a working answer, your working answer is going to be roughly the same as v6 -- and have the same issues v6 does. Almost as if the people that designed v6 weren't completely clueless.
The problem is... how do you get those extra address bits to work?
If you think through that question and produce a working answer, your working answer is going to be roughly the same as v6 -- and have the same issues v6 does. Almost as if the people that designed v6 weren't completely clueless.
There are viable transition mechanisms other than dual stack, that put some kind of translation layer between protocols, rather than expect native IPv4 connectivity on all hosts.
This is perfectly viable, and is how many mobile networks handle IPv4 (ie. there is no native IPv4 on the handset at all), and how many cloud providers are handling it these days too. You have to do NAT at the border anyway, why not NAT to/from an IPv6 address?
The adoption problem doesn't have that much to do with the technology, it's simply that it provides little value to most individual entities participating in the network, even if the benefit in aggregate is clear, so it's difficult to achieve the critical mass to make it valuable. It's the same thing behind climate change and so many other societal issues.
This is perfectly viable, and is how many mobile networks handle IPv4 (ie. there is no native IPv4 on the handset at all), and how many cloud providers are handling it these days too. You have to do NAT at the border anyway, why not NAT to/from an IPv6 address?
The adoption problem doesn't have that much to do with the technology, it's simply that it provides little value to most individual entities participating in the network, even if the benefit in aggregate is clear, so it's difficult to achieve the critical mass to make it valuable. It's the same thing behind climate change and so many other societal issues.
You might appreciate this. Basically, it leverages Babel routing to bridge IPv4 with IPv6.
https://datatracker.ietf.org/doc/rfc9229/
https://datatracker.ietf.org/doc/rfc9229/
> 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.
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.
They took much more on with IPv6 than IPv4 replacement. The spec goes much deeper than IPv4 did, replacing ARP, DHCP, etc. It's a product of its time, including a lot of over-engineering by committee. Many of the problems they tried to address didn't pan out to be real issues. You can read the RFCs and compare.
IPv4 w/ more bits is a lot more simple. Yes, older network gear wouldn't deal with it well, but that's not a real issue today because that same network gear supports IPv6.
Buuut, one of the biggest problems with app-level issues is just that the app doesn't bother dealing with IPv6 addresses and AAAA records. It would be the same issue with an imaginary IPv4*2.
IPv4 w/ more bits is a lot more simple. Yes, older network gear wouldn't deal with it well, but that's not a real issue today because that same network gear supports IPv6.
Buuut, one of the biggest problems with app-level issues is just that the app doesn't bother dealing with IPv6 addresses and AAAA records. It would be the same issue with an imaginary IPv4*2.
Agree. Second system effect in action -- https://en.wikipedia.org/wiki/Second-system_effect.
No kidding - they got rid of dhcp and more but it’s a nightmare getting networks to work with just ipv6 concepts- everything from provisioning phones (dhcp options to push config / NetBoot stuff) and more. Layer in privacy extensions, renumbering on uplink wan flapping (slow too - the failover is pathetic compared to NAT wan failover) - icmp traffic differences - firewalls need to be much more careful with ipv6 and related protocols because things can easy break (it’s fragile) or you create risks. Even min subnet sizes mean crazy 2 node subnet sizes (think isp and cpe management subnet for a customer). Also curious why not 48 or 64 bits or 96 bits? 128 bits is ludicrous
128 bits was probably picked to give 64 for "MAC address-based locals" and then the reasonable thing is to have 64 more bits on the other side, if you only had 32 you're just IPv4 with more steps.
Layer 3 exists as a layer of routing and aggregation on top of layer 2. Aggregation necessarily consumes address space, so L3 needs to be bigger than L2 to accommodate the full L2 address space. The L2 address space is 64 bits and the next power of 2 up from 64 is 128, so here we are.
96 bits would probably be enough too, but having large subnets has a few benefits -- it allows for securing NDP by using the extra space for a cryptographic key, and also it makes it much, much harder to scan for active hosts from outside the network.
Plus, can you imaging the wailing and teeth gnashing we'd be getting if v6 wasn't a power of 2 bits long?
96 bits would probably be enough too, but having large subnets has a few benefits -- it allows for securing NDP by using the extra space for a cryptographic key, and also it makes it much, much harder to scan for active hosts from outside the network.
Plus, can you imaging the wailing and teeth gnashing we'd be getting if v6 wasn't a power of 2 bits long?
> 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
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
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”.
Yeah, but I have to say, even as someone who wants IPv6 to succeed and supersede IPv4, from the perspective of building that network infrastructure software, I think this "IPv4+" would have been massively simpler to add, extremely so, and that may have aided adoption a lot.
It's really hard to overstate how much simpler tacking on 128bit IP addresses to an otherwise unmodified protocol would have been in the software stack of network infrastructure.
But, as I also said a few times here, the time to make desirable compatibility-breaking changes was exactly then, when every piece of network equipment needed massive alteration or replacement anyway. And I look forward to the day IPv6 hopefully becomes predominant, and the advantages it brings.
It's really hard to overstate how much simpler tacking on 128bit IP addresses to an otherwise unmodified protocol would have been in the software stack of network infrastructure.
But, as I also said a few times here, the time to make desirable compatibility-breaking changes was exactly then, when every piece of network equipment needed massive alteration or replacement anyway. And I look forward to the day IPv6 hopefully becomes predominant, and the advantages it brings.
The majority of the problems seem to come from the fact that v6 addresses are longer than v4 ones. That's why we need socket(AF_INET6)s and AAAA records and a DNS API that supports multiple address families and dual stack and new firewalling and updates to all protocols that embed v4 addresses.
You're going to have the exact same problems with any protocol that has addresses longer than v4's.
You're going to have the exact same problems with any protocol that has addresses longer than v4's.
BSD Sockets ensured that we have problems using anything other than what the software was originally written for, unless it's a program recent enough to use the one bit of API that got back ported from OSI-oriented Ed networks, the getaddressinfo() call.
Otherwise there's a ton of low level IPv4 details leaking all around the basic idea of connecting from one service to another.
Otherwise there's a ton of low level IPv4 details leaking all around the basic idea of connecting from one service to another.
I find that hard to believe. That may be true for endpoints, but I'm talking about the network infrastructure in between. There, I believe that the vast differences in the protocols on higher level (autoconfiguration, link-local addresses, temporary addresses, Neighbor Discovery as part of ICMP6 instead of ARP, ICMP6 itself, and so on and so forth) are much, much more work to implement than dealing with new DNS records and APIs, and the new struct sockaddr variants.
My point is exactly that I have a strong suspicion that the longer addresses are not the problem for slow adoption, the different network protocols and semantics are.
My point is exactly that I have a strong suspicion that the longer addresses are not the problem for slow adoption, the different network protocols and semantics are.
We've tried to roll out IPv6 at my work, and after several years of it causing more issues than it help we turned it all off again... We're gonna get back to it again this year, but I can see many organizations just not doing that until absolutely forced.
Thank you to share a real world story. Failure is usually more interesting to study than success. Real question (no trolling): Is there any business value upgrading to IPv6 or is this a forced upgrade? I think that is number one reason that delays IPv6 upgrades: no business value (or so limited compared to cost of IPv6 impl).
If you're running something that isn't absolute shit it's not this much of an issue to upgrade to ipv6. There's business value in that simply because ipv4 addresses are expensive.
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?
That it's much easier to set up.
That it's much easier to set up.
> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?
The hallmark of a good IPv4+ solution is that it autodeploys without anyone at the network configuration and administration level having to think too much about it. IPv6+IPv4 by contrast generally doubles the configuration complexity of more things than you can count.
It is true that for IPv4+ to be successful nearly everyone currently using IPv4 would need some sort of behind the scenes upgrade to be IPv4+ compatible first before the extended address space would be portable. And that includes incremental upgrades of just about everything that touches IPv4 or IPv4 compatible addresses.
The hallmark of a good IPv4+ solution is that it autodeploys without anyone at the network configuration and administration level having to think too much about it. IPv6+IPv4 by contrast generally doubles the configuration complexity of more things than you can count.
It is true that for IPv4+ to be successful nearly everyone currently using IPv4 would need some sort of behind the scenes upgrade to be IPv4+ compatible first before the extended address space would be portable. And that includes incremental upgrades of just about everything that touches IPv4 or IPv4 compatible addresses.
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.
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.
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?
Have you actually seen any large scale deployments of CPEs without an active IPv6 firewall blocking incoming connections by default?
Fritz!OS also does, it's used by many consumer routers in Germany.
There is of course also OpenWRT.
I am doing this on my pfSense box. My ISP delegates me a /56 and I have them assigned to several different VLANs.
Same situation, I use IPv6 NAT and VPN, huge letdown but c'est la vie.
If I understand correctly, variable SLAAC tries to fix this by allowing you to further split a /64
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-...
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-...
> 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.
I'm curious why you need multiple subnets at home; I at one point had separate subnets because I was using a wifi client as a ip level router, but was wondering what your use-case is.
> 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.
I would like to humbly suggest that you don't remember what the internet was around the turn of the century with devices configuring IGD via UPnP so every device you hooked up to your home router automatically setup a port-mapping to put itself on the open internet.
Eventually everyone realized this sucked and UPnP NAT traversal was disabled everywhere. The same will happen (and actually more-or-less has already happened) with default-allow home routers switching to default-block.
I'm curious why you need multiple subnets at home; I at one point had separate subnets because I was using a wifi client as a ip level router, but was wondering what your use-case is.
> 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.
I would like to humbly suggest that you don't remember what the internet was around the turn of the century with devices configuring IGD via UPnP so every device you hooked up to your home router automatically setup a port-mapping to put itself on the open internet.
Eventually everyone realized this sucked and UPnP NAT traversal was disabled everywhere. The same will happen (and actually more-or-less has already happened) with default-allow home routers switching to default-block.
>I'm curious why you need multiple subnets at home; I at one point had separate subnets because I was using a wifi client as a ip level router, but was wondering what your use-case is.
Not OP, but there are many use cases. First is device isolation so untrusted devices can be put in their own network while you can selectively add ressources from your main network via VLANs and add simple firewall rules because the untrusted network is a different interface on your VM than the others.
Second, you might want to put any managment interfaces (and ssh-enabled IPs) on a seperate network both for ease of organization and security.
Third, if you want to have your network services configured differently for different clients (think VPN vs local clients, adblocking DNS for mobile only) it's a lot easier to do that for whole subnets.
Not OP, but there are many use cases. First is device isolation so untrusted devices can be put in their own network while you can selectively add ressources from your main network via VLANs and add simple firewall rules because the untrusted network is a different interface on your VM than the others.
Second, you might want to put any managment interfaces (and ssh-enabled IPs) on a seperate network both for ease of organization and security.
Third, if you want to have your network services configured differently for different clients (think VPN vs local clients, adblocking DNS for mobile only) it's a lot easier to do that for whole subnets.
Why can't you use it as a firewall? It's weird, and against RFCs for your ISP to only give you a /64, but that should still be routed address space is routed through your router/firewall box, and therefore trivial to firewall with the normal tools. This is also pretty much the necessary topology, because if the box needs to do NAT for IPv4, it needs to terminate the address on the firewall too. You'd need separate interfaces to do some scheme where IPv6 was layer-2 to the ISP, and IPv4 terminated at the firewall.
Most/all such boxes, especially those deployed by ISPs, have a stateful firewall with an allow-out deny-in policy in place by default. I've never seen otherwise, but I guess it's possible?
Back in the day, cable modems didn't include a 'router' and lots of users plugged their Windows XP PCs into them and got compromised. Most weren't really blaming the ISP for this; go buy a router they said. And some providers will still just give you a public IP with full access by default when you plug into their demarc equipment; indeed many users want this because that's what Internet access should be. Security is on the end user. I don't see this situation as any different, though your ISP should know better than shipping insecure-by-default, this isn't really a problem with the protocol.
Most/all such boxes, especially those deployed by ISPs, have a stateful firewall with an allow-out deny-in policy in place by default. I've never seen otherwise, but I guess it's possible?
Back in the day, cable modems didn't include a 'router' and lots of users plugged their Windows XP PCs into them and got compromised. Most weren't really blaming the ISP for this; go buy a router they said. And some providers will still just give you a public IP with full access by default when you plug into their demarc equipment; indeed many users want this because that's what Internet access should be. Security is on the end user. I don't see this situation as any different, though your ISP should know better than shipping insecure-by-default, this isn't really a problem with the protocol.
I'm dealing with this now as well..=(
Do you happen to have a reference from the RFC, about it being against spec to hand out just a /64?
Do you happen to have a reference from the RFC, about it being against spec to hand out just a /64?
Originally (2002) a /48 per site was recommended in RFC3177.
More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:
More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:
- it should be easy for an end site to obtain address space to
number multiple subnets (i.e., a block larger than a single /64)
and to support reasonable growth projections over long time
periods (e.g., a decade or more).
I suspect it's to make business plans artificially more appealing. After all, why offer a better service when instead you can just make your cheaper one worse?
It's not an RFC, but RIPE690 is pretty clear on the matter:
https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefi...
https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefi...
Those ISPs are broken and not following the RFCs or RIR guidelines.
There's nothing stopping you from using NAT with IPv6, people just don't do it because the only benefit of NAT is conserving limited address space. NAT on IPv6 just brings all downsides and no benefit because you (should) have no shortage of address space. In any case v6 with nat is no worse than legacy ip with nat, its just stupid because they're forcing a newer and better protocol to run in a degraded mode.
Consumer oriented routers and firewalls do not allow arbitrary inbound IPv6 connections by default, you have to explicitly enable them.
I still don't get scanned over IPv6, despite having a static /56 range for more than 10 years. Everything that's reachable over legacy IP is also reachable over v6, and i have several v6-only devices because i simply don't have enough legacy addresses for everything. Scanning v6 is extremely difficult, while the legacy blocks get scanned continuously.
Modern operating systems are not sitting there with exposed services by default, you have to manually open them up if you want. Simply connecting a win11 box to an open IPv6 connection is not going to get you joined to a botnet like connecting a winxp machine directly to a legacy connection did.
Modern devices are often exposed to hostile networks/users - every time you connect a portable device to a public wifi network you are exposing your device to the operators and other users of the network. Depending how that network is configured, you might be exposed to the internet too. You don't have any separate device between you and the hostile network, you are relying on the configuration of your machine itself.
ISP supplied routers are limited and generally garbage, this is a problem for legacy ip just as much as v6.
There's nothing stopping you from using NAT with IPv6, people just don't do it because the only benefit of NAT is conserving limited address space. NAT on IPv6 just brings all downsides and no benefit because you (should) have no shortage of address space. In any case v6 with nat is no worse than legacy ip with nat, its just stupid because they're forcing a newer and better protocol to run in a degraded mode.
Consumer oriented routers and firewalls do not allow arbitrary inbound IPv6 connections by default, you have to explicitly enable them.
I still don't get scanned over IPv6, despite having a static /56 range for more than 10 years. Everything that's reachable over legacy IP is also reachable over v6, and i have several v6-only devices because i simply don't have enough legacy addresses for everything. Scanning v6 is extremely difficult, while the legacy blocks get scanned continuously.
Modern operating systems are not sitting there with exposed services by default, you have to manually open them up if you want. Simply connecting a win11 box to an open IPv6 connection is not going to get you joined to a botnet like connecting a winxp machine directly to a legacy connection did.
Modern devices are often exposed to hostile networks/users - every time you connect a portable device to a public wifi network you are exposing your device to the operators and other users of the network. Depending how that network is configured, you might be exposed to the internet too. You don't have any separate device between you and the hostile network, you are relying on the configuration of your machine itself.
ISP supplied routers are limited and generally garbage, this is a problem for legacy ip just as much as v6.
> the only benefit of NAT is conserving limited address space.
It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.
It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.
hide might be generous as fingerprinting devices based on their characteristics is pretty well understood nowadays.
> It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.
A combination of: (a) my Asus AC-68U not allowing non-reply, inbound connections for IPv6, and (b) my clients using rotating, randomly generated addresses, accomplishes the exact same thing.
NAT doesn't add much over a decent stateful firewall with a default-deny rule on incoming connections.
A combination of: (a) my Asus AC-68U not allowing non-reply, inbound connections for IPv6, and (b) my clients using rotating, randomly generated addresses, accomplishes the exact same thing.
NAT doesn't add much over a decent stateful firewall with a default-deny rule on incoming connections.
> 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.
And my ISP gives me a /56. What's your point? What you say is not a knock against the protocol, but stupid ISPs.
In fact, you're actually better off compared to IPv4. At least you now have publicly available IPs with can easily be connected to if you wish, rather than having to go through the silliness of port forwarding with NAT.
> IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.
Not on my Asus AC-68U: it has a default-deny rule on incoming connections. Only replies to existing connections are allowed.
Again: your critique is not against the protocol itself, but stupidity.
And my ISP gives me a /56. What's your point? What you say is not a knock against the protocol, but stupid ISPs.
In fact, you're actually better off compared to IPv4. At least you now have publicly available IPs with can easily be connected to if you wish, rather than having to go through the silliness of port forwarding with NAT.
> IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.
Not on my Asus AC-68U: it has a default-deny rule on incoming connections. Only replies to existing connections are allowed.
Again: your critique is not against the protocol itself, but stupidity.
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.
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 ?
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…
IPv6 adoption is growing at 5% per year and is currently around 40% https://www.google.com/intl/en/ipv6/statistics.html
I expect as we get closer to the end we will see it pick up speed. Countries are now mandating IPv6 support as early as this month https://www.indiatimes.com/technology/news/india-sets-new-de...
Things are still moving forward, faster than ever at this point.
I expect as we get closer to the end we will see it pick up speed. Countries are now mandating IPv6 support as early as this month https://www.indiatimes.com/technology/news/india-sets-new-de...
Things are still moving forward, faster than ever at this point.
You'd be surprised. A former employer is still writing new Python 2 code.
What are you going to use instead? IPv4 is already bursting at the seams and starting over from scratch at this point means at least a decade before a new solution could even be considered.
> 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...
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...
There was an idea floated in the early 2010s to do an overlay network over IPv4 that did this just: https://seam.cs.umd.edu/EnhancedIP/index.html
It "died" as an Internet-Draft: https://datatracker.ietf.org/doc/html/draft-chimiak-enhanced...
It "died" as an Internet-Draft: https://datatracker.ietf.org/doc/html/draft-chimiak-enhanced...
I don't see how this has any advantage over just deploying more NAT like people are already doing. Plus it adds IP options which routers hate.
They claim "EnIP supports end-to-end connectivity, a shortcoming of NAT, making it easier to implement mobile networks." but I don't see where mobile network operators would care about end-to-end connectivity?
They claim "EnIP supports end-to-end connectivity, a shortcoming of NAT, making it easier to implement mobile networks." but I don't see where mobile network operators would care about end-to-end connectivity?
I think the big problem of ipv6 is, that it’s not backwards compatible. You can’t just switch to ipv6 only and have a some network box rewrite ip addresses for example 1.2.3.4.5.6.7.8 to 10.6.7.8 or simple kernel module that translates it.
Just imagine if ipv6 stacks could just completely replace ipv4 stacks on every system, with full access to all ipv4 resources, as long as the first 12 bytes are all 0.
Just imagine if ipv6 stacks could just completely replace ipv4 stacks on every system, with full access to all ipv4 resources, as long as the first 12 bytes are all 0.
I always thought to start they should have just allowed each octet two-ish more bits, so you could have 999.999.999.999. I know it’s the hackiest of all hacks, but it sure would have been an easy upgrade from the software perspective. And it would have given about a 256x increase in the number of ips. Which I kinda think actually might have served us for a long time.
And where do those two extra bits go? How do existing routers that don’t know anything about two extra bits route those packets? Here’s the ip packet header: https://commons.wikimedia.org/wiki/File:IPv4_Packet-en.svg
In this thread, lots of people seem to think in terms of 255.255.255.255 and fail to recognize the IP address is 32bits and the textual representation of 4 octets means very little.
But the confidence and armchair expertise offered… wow.
But the confidence and armchair expertise offered… wow.
The IPv4 dotted quad format carries a lot of baggage. You also have to handle forms with two numeric fields with a mixture of 8, 16, and 24-bit numbers and implicit zero octets. Support for the full syntax is sporadic. IPv6 deliberately uses a new text encoding to make a clean break.
I don't want to be rude, and I'll assume good faith. But it seems naive to think the syntax of an address would be the sticking point.
128 bit addresses, NDP, SLAAC, etc., there are many huge changes that I don't think syntactic sugar would have saved.
Maybe though? Perhaps it would have been doable but I simply don't know.
We, the world, should ha e legislated some of these standards. The fact that in 2022 I have to worry about if I will get a /60, /64 or /128 from an ISP is criminal. That I can't get a consumer router with prefix delegation available.
128 bit addresses, NDP, SLAAC, etc., there are many huge changes that I don't think syntactic sugar would have saved.
Maybe though? Perhaps it would have been doable but I simply don't know.
We, the world, should ha e legislated some of these standards. The fact that in 2022 I have to worry about if I will get a /60, /64 or /128 from an ISP is criminal. That I can't get a consumer router with prefix delegation available.
OMG! What were we all thinking! Thank you redox99 for figuring this out. Only now that you have pointed out this idea is it suddenly obvious.
But, since this is, you know, the entire internet, can you maybe write a more detailed specification?
So like, when my TCP stack creates a presumably backwards compatible IPv4 header, where does it put the extra 4 bytes? Or do we only send these IPv4+ packets to devices that we also know are IPv4+? If we add four bytes at the end of the IPv4 header, then when I send to 12.4.1.0.8.8.8.8, then the legacy server will read it as 8.8.8.8 and send my information to Google. That seems bad.
Or will we create a new IP header format? If so, how will we make sure that all the software on a given box understands the new format? How do we incrementally roll out these new applications, kernels, modules, etc, in such a way that we dont break the internet in interesting and fatal-for-real-people ways? Maybe we could deploy IPv4 and IPv4+ side-by-side, so that both are running, and so the new IPv4+ can fail with no risk to the IPv4 services?
How about parsing IP addresses. What if I send to 10.44321? This is a valid IP address. Are we going to say that the various short-hand representations only apply to IPv4, so you an't shorten 127.0.0.0.0.0.0.1 to 127.1? How will we handle scripts where the subnet is specified as /24 independently of the address, such that IPv4+ subnets will contain 32 billion IPs instead of 256? Or do you imagine that IPv4 and IPv4+ scripts must be kept separate?
I am looking forward to your specifications! While you are addressing all these issues, could we also look at expanding the number of ports available too? Also, what if IPv4+ used sixteen bytes, instead of eight?
But, since this is, you know, the entire internet, can you maybe write a more detailed specification?
So like, when my TCP stack creates a presumably backwards compatible IPv4 header, where does it put the extra 4 bytes? Or do we only send these IPv4+ packets to devices that we also know are IPv4+? If we add four bytes at the end of the IPv4 header, then when I send to 12.4.1.0.8.8.8.8, then the legacy server will read it as 8.8.8.8 and send my information to Google. That seems bad.
Or will we create a new IP header format? If so, how will we make sure that all the software on a given box understands the new format? How do we incrementally roll out these new applications, kernels, modules, etc, in such a way that we dont break the internet in interesting and fatal-for-real-people ways? Maybe we could deploy IPv4 and IPv4+ side-by-side, so that both are running, and so the new IPv4+ can fail with no risk to the IPv4 services?
How about parsing IP addresses. What if I send to 10.44321? This is a valid IP address. Are we going to say that the various short-hand representations only apply to IPv4, so you an't shorten 127.0.0.0.0.0.0.1 to 127.1? How will we handle scripts where the subnet is specified as /24 independently of the address, such that IPv4+ subnets will contain 32 billion IPs instead of 256? Or do you imagine that IPv4 and IPv4+ scripts must be kept separate?
I am looking forward to your specifications! While you are addressing all these issues, could we also look at expanding the number of ports available too? Also, what if IPv4+ used sixteen bytes, instead of eight?
Please look at the structure of an IP header. Note the "options and padding" section.
Also SECTIONS of the internet (that is, routers) can have IPV4+ packets wrapped in IPV4 packets that will transmit them through "IPV4-old" only branches.
We pretend like the major routing backbones aren't known and fairly set in stone, and that routers don't know about each other.
Yeah, his approach doesn't fix the Comcast-doesn't support-IPV6 and is stuck in old IPV4. But those places are using NAT of their own.
If we have all these cgnats and other address translations happening, well shit how is that different that the IPv4 wrapping ipv4+ and other things.
Also, oh yes please give me more fucking ports. IPv6 keeping the same number of ports is stupid. Please give me 64 bits of ports. Ok, I'll take 32.
If you use 10.44321 for a port number these days, well I have no sympathy for you. As for /24, clearly that will mean "IPV4 /24", and whatever new protocol will use some other convention like /000024. But /24 maps to a bit mask. You just interpret the bit mask differently.
Yes I am handwaving a ton of stuff. A ton. But ipv6 basically said "fuck you our way or the highway" and here we are.
At this point, maybe we need a superprotocol ipv8 that will wrap the ipv6 address space, the old ipv4 address space, into an even bigger address space. Get the router vendors and designers back in the room.
Also SECTIONS of the internet (that is, routers) can have IPV4+ packets wrapped in IPV4 packets that will transmit them through "IPV4-old" only branches.
We pretend like the major routing backbones aren't known and fairly set in stone, and that routers don't know about each other.
Yeah, his approach doesn't fix the Comcast-doesn't support-IPV6 and is stuck in old IPV4. But those places are using NAT of their own.
If we have all these cgnats and other address translations happening, well shit how is that different that the IPv4 wrapping ipv4+ and other things.
Also, oh yes please give me more fucking ports. IPv6 keeping the same number of ports is stupid. Please give me 64 bits of ports. Ok, I'll take 32.
If you use 10.44321 for a port number these days, well I have no sympathy for you. As for /24, clearly that will mean "IPV4 /24", and whatever new protocol will use some other convention like /000024. But /24 maps to a bit mask. You just interpret the bit mask differently.
Yes I am handwaving a ton of stuff. A ton. But ipv6 basically said "fuck you our way or the highway" and here we are.
At this point, maybe we need a superprotocol ipv8 that will wrap the ipv6 address space, the old ipv4 address space, into an even bigger address space. Get the router vendors and designers back in the room.
You should learn a bit about v6 before criticizing it for not doing things that it is doing. You're basically reinventing 6to4.
> Also, oh yes please give me more fucking ports. IPv6 keeping the same number of ports is stupid.
IP doesn't have ports.
> Also, oh yes please give me more fucking ports. IPv6 keeping the same number of ports is stupid.
IP doesn't have ports.
I don't think you are refuting my claims. If you put the extra 4 bytes of address at the end of the header, telling the legacy software that the header is now bigger doesn't mean that it will use those bytes for routing. Hence it will route to the IPv4 address. Hence if we send to a.b.c.d.8.8.8.8, it will actually get sent to 8.8.8.8.
IPv4+ packets wrapped in IPv4 is just 6in4.
And all the handwaving is exactly that. It doesn't solve the actual problems that OP claims, e.g. being able to keep existing scripts and everything just works. If anything it makes those systems far more fraught. IPv6 does allow an admin to keep all those scripts for IPv4 and have them still just work.
If anything, what this whole thing shows is that many network admins don't know what the fuck they are doing and are relying on existing scripts and cargo culting.
IPv4+ packets wrapped in IPv4 is just 6in4.
And all the handwaving is exactly that. It doesn't solve the actual problems that OP claims, e.g. being able to keep existing scripts and everything just works. If anything it makes those systems far more fraught. IPv6 does allow an admin to keep all those scripts for IPv4 and have them still just work.
If anything, what this whole thing shows is that many network admins don't know what the fuck they are doing and are relying on existing scripts and cargo culting.
>If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade.
The only real reason v4 is being replaced after decades is that it has a single showstopping flaw - the lack of addresses. v6 solves this forever with its massive address space. We've seen how incredibly hard replacing v4 has been. Without a similarly huge flaw to drive a replacement it's very possible that v4's successor could be the universal internet protocol for hundreds or even thousands of years. With that in mind, even though progress has been frustratingly slow, going for something closer to the global maximum in design and avoiding ease-of-adoption hacks might be the right thing to do.
That's not necessarily to say that your suggestion of still using dot-separated numeric values would be objectively worse, but bear in mind that doubling the number of fields from 4 to 8 as you've done only gives you a 64-bit address space, whereas IPv6 as it exists has a 128-bit space, so would require something like 0.0.0.0.0.0.0.0.0.0.0.0.1.2.3.4.
The only real reason v4 is being replaced after decades is that it has a single showstopping flaw - the lack of addresses. v6 solves this forever with its massive address space. We've seen how incredibly hard replacing v4 has been. Without a similarly huge flaw to drive a replacement it's very possible that v4's successor could be the universal internet protocol for hundreds or even thousands of years. With that in mind, even though progress has been frustratingly slow, going for something closer to the global maximum in design and avoiding ease-of-adoption hacks might be the right thing to do.
That's not necessarily to say that your suggestion of still using dot-separated numeric values would be objectively worse, but bear in mind that doubling the number of fields from 4 to 8 as you've done only gives you a 64-bit address space, whereas IPv6 as it exists has a 128-bit space, so would require something like 0.0.0.0.0.0.0.0.0.0.0.0.1.2.3.4.
I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like:
1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet.
2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure.
3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it.
IP4.4 aware routers at the network border could swap inbound IP4 destination with the .4 address before forwarding on to the internal network. Basically like NAT, but you can allow inbound connections without maintaining state.
EDIT: formatting
1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet.
2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure.
3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it.
IP4.4 aware routers at the network border could swap inbound IP4 destination with the .4 address before forwarding on to the internal network. Basically like NAT, but you can allow inbound connections without maintaining state.
EDIT: formatting
What happens when your 4.4 packet hits a router box somewhere out there that doesn’t understand 4.4? Where’s it going to send that packet? To the wrong address (or potentially even create an infinite loop). Now what?
I understand what you're saying, but isn't IP supposed to be about routing things around failure points? So routers that "know" IP 4.4 would "know" what routers aren't 4.4.
By definition you’re trying to retain back compat. So you have a 4.4 source IP address. You try to establish a TCP connection to a legacy IPv4 website that isn’t 4.4 aware. What address is that website sending the response back to? Even if it is 4.4 aware, how do you guarantee it’s taking a path back through 4.4 aware servers? The whole point of adding an option header is to allow unmolested transit through existing IP stacks. If you’re saying you’re routing around them, then you’ve bifurcated the networks and you’re back to IPv6.
You're basically doing carrier grade NAT for that, the same thing that is apparently tooootallly acceptable to the ipv6 people for their big success story: mobile.
The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.
The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.
Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC.
So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
If a source behind an IP4.4 router sent a packet to an IP4 destination, then yes, the source router would need to apply NAT to the source address. But this is already a standard IP4 router capability, and I think that most connection origins on the internet are already behind a NAT.
I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware.
The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.
I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware.
The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.
How would changes not have been required in the ISPs? An IPv4 router wouldn't know what to do with a 4.4 packet. At best, it'd route it to the wrong place - 1.2.3.4.5.6.7.8 and 5.6.7.8 are totally different hosts that may well not even be on the same continent.
Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.
Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.
I think you have missed that a IP4.4 packet would be a valid IP4 packet. The first 4 octets of the 4.4 address are where IP4 expects them to be. The router at this IP4 address needs to understand IP4.4, but routers before do not. The additional octets are smuggled within the IP4 options header.
You've basically invented 6to4. This isn't a new idea; v6 already has it.
I didn't claim it to be a new idea - I asked why we didn't do something simple like that (as the solution) instead of all the expensive complexity of trying to upgrade the entire Internet to IP6 over multiple decades.
It routes it as an IP4 packet, because it still is a valid IP4 address. Think of it as a way to let a stateless IP4.4 aware NAT router at the edge join two 32-bit networks together. An IP4.4 client could send a packet to a destination in that network by putting the address of the IP4.4 router in the usual IP4 destination, and the 'internal' IP address in the IP options header. No 'entire Internet update' necessary
> or potentially even create an infinite loop
I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.
I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.
We had a IPv6 transition mechanism that worked a bit like this (but nicer), it was phased out when native v6 support was deemed widespread enough.
https://en.wikipedia.org/wiki/6to4
https://en.wikipedia.org/wiki/6to4
Thanks for that. As a transition-to-IP6 technology that makes a lot of sense, but I think it required a lot of prerequisite technology and work (i.e. IP6 itself). The hack I described could have been implemented on top of existing IP4 codebases.
Sure, we could have had hacks that would have been faster to implement, but there isn't reason to believe it would have helped. The bottleneck was never in the code. Routers and OSes got v6 support ages ago and it's been working in lots of edu & gov networks all over the world for 20+ years. ISPs just haven't been enabling it.
Lukewarm deployment incentives for ISPs, lack of pull from device/app makers, etc have been the main problems. Apps adapted to the NAT world quickly, users forgot what capabilities they lost and started to fall into the NAT = security cognitive trap.
Lukewarm deployment incentives for ISPs, lack of pull from device/app makers, etc have been the main problems. Apps adapted to the NAT world quickly, users forgot what capabilities they lost and started to fall into the NAT = security cognitive trap.
> ISPs just haven't been enabling it.
It’s a chicken and egg problem. It would have been nice if everybody everywhere agreed to build and use an entirely new network at the same time, but that was never going to be practical.
The actual problem at hand was lack of address space, and I think this could have been addressed with a more viable upgrade path - turn every IP4 address into x number of addresses behind it, and allow retail ISPs to remain IP4 only.
It’s a chicken and egg problem. It would have been nice if everybody everywhere agreed to build and use an entirely new network at the same time, but that was never going to be practical.
The actual problem at hand was lack of address space, and I think this could have been addressed with a more viable upgrade path - turn every IP4 address into x number of addresses behind it, and allow retail ISPs to remain IP4 only.
djb proposed this back in 2002: https://cr.yp.to/djbdns/ipv6mess.html
> How do we teach every client on the Internet to talk to servers on public IPv6 addresses [and vice versa]?
> Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place.
> ...
> Unfortunately, the straightforward transition plan described above does not work with the current IPv6 specifications. The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> ...
> This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.
> How do we teach every client on the Internet to talk to servers on public IPv6 addresses [and vice versa]?
> Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place.
> ...
> Unfortunately, the straightforward transition plan described above does not work with the current IPv6 specifications. The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> ...
> This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.
That is the exact right reason, none of the other BS that’s been written (notice the lack of complaints about new IPv6 features). It’s purely about v4/v6 interop. I’m still not 100% sure how you would have solved some of these problems though. It’s easy to state that’s the problem. A lot harder to show how you have these things interconnecting seemlessly.
so somehow 0.0.0.0.8.8.8.8 is an extension of the legacy address 8.8.8.8, and ::ffff:8.8.8.8 isn't?
There have been no experiments to show why this is any better than IPv6 given that you still need to modify routers and end user devices to route traffic, nor does it address the fact that IPv6 has additional features such as flows and prioritization to handle the modern Internet's traffic requirements.
The scheme you propose had already been proposed by Elad Cohen, but with "evil" intentions as they're linked to a IPv4 misappropriation scheme[1].
[1] https://mybroadband.co.za/news/security/367188-the-great-afr...
The scheme you propose had already been proposed by Elad Cohen, but with "evil" intentions as they're linked to a IPv4 misappropriation scheme[1].
[1] https://mybroadband.co.za/news/security/367188-the-great-afr...
An even better idea: Right now, the biggest address is 255.255.255.255. Why not just make it go up to 999.999.999.999? Problem solved!
Because on the wire it's encoded as four bytes. If you can make eight binary digits count up to 999, you can do a lot more than just make IPv4 last longer.
> 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.
I find that very wild optimism.
- You will still get two incompatible address space V4 and V4+ and that would imply: -> You still need to modify your software to adapt for V4+ for the transition.
-> Most of your middlebox and firewall rules will get in the way for anything served over V4+. Exactly like for V6
-> DNS would still need to be updated with new record and it will be the same mess
It would be mostly the same mess.
IPv6 has its quirks, but let's be honest: the main problem with Ipv6 is not technical any-more.
The main reason the switch does not happen is that there is no business incentive to switch to IPv6 for most companies and consequently, most companies do not give a fuck.
I find that very wild optimism.
- You will still get two incompatible address space V4 and V4+ and that would imply: -> You still need to modify your software to adapt for V4+ for the transition.
-> Most of your middlebox and firewall rules will get in the way for anything served over V4+. Exactly like for V6
-> DNS would still need to be updated with new record and it will be the same mess
It would be mostly the same mess.
IPv6 has its quirks, but let's be honest: the main problem with Ipv6 is not technical any-more.
The main reason the switch does not happen is that there is no business incentive to switch to IPv6 for most companies and consequently, most companies do not give a fuck.
Which is weird, because there is a business incentive: money. But instead, companies seem to be willing to pay out huge amounts of money to not deploy v6.
You're solving the wrong problem.
IPv4 is a pain in the ass, but never in 20 years have I thought to myself "gee, I really wish I had more IP addresses available".
I'm not Amazon and I will never run out of 192.168.0.0/16.
Focus on the real use-cases, please.
IPv4 is a pain in the ass, but never in 20 years have I thought to myself "gee, I really wish I had more IP addresses available".
I'm not Amazon and I will never run out of 192.168.0.0/16.
Focus on the real use-cases, please.
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
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
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.
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.
> 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.
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.
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.
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.
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.)
(I know that v6 has been a success within datacenters and such.)
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.
More like 15 years of active deployment, and I'd expect levels at 90%. The world changed after IPv6 with smartphones that are controlled by a select few carriers, so it's easy to deploy IPv6 in which they're in dire need.
But the rest of the networks: enterprises, hosting providers, cloud providers, ISPs really don't give a shit. It's merely a cost centre or a burden.
But the rest of the networks: enterprises, hosting providers, cloud providers, ISPs really don't give a shit. It's merely a cost centre or a burden.
Actually, aws and the big cloud providers are only now starting to release ipv6 aware services.
If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
If it describes problems we're still struggling with, it's still relevant.
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.
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
This is an astoundingly narrow take. They (vendors, practitioners, stodgy luddites) didn't listen because there was nothing on fire and no money to grab at when the conversations began 20 years ago.
Networks exist (and have always existed) globally that operate using parallel, incompatible protocols from layer 1 to layer 3. None of this is new, and none of it should be a surprise.
The outrage all stems from a lack of awareness of history and increased visibility from armchair experts that fixate on how things work for them, and not from the long-term perspective or the point of view of a large provider, global network, or resource of significant scale / size.
IPv4 is the poster child for the sunk cost fallacy; it is an outdated shit pile that has become the outdated shit pile we know, and therefor somehow the option that needs extended in perpetuity.
"Good Enough" is subjective. A bicycle is "good enough" for moving a person from point A to point B over short distances. It's not good enough when it is below freezing, raining, or needs to transport large cargo. It's not good enough when there are 3 people that need to travel from point A to point B and there is only one bicycle. A car may be good enough for that. But a car isn't good enough when part of that trip spans an ocean. The fact that a person thinks IPv6 is a stupid idea and that extending or making compatible the pant load of diarrhea that is IPv4 is "good enough" is fine for that one person, or even a group of persons.
However, it does not scale globally, and it provides no supportable longevity. Even with the release of every single extra block of IPv4 - 240, 127, all of the unused or dark /8 addresses, 0.0.0.0, 255, and even with the proliferation of carrier NAT - it is still too limited to scale long term or introduces blindingly unnecessary complexity.
There is already significant IPv6 deployment globally, and it has grown by a large margin in the last 3 years, prior posts have clearly shown that. As far as IPv4, The goal was never to turn it off like a light switch, it has always been to phase it out, and by and large that has been happening at a fairly accelerated rate.
If we spend half as much time on IPv6 that we do moaning about IPv6, we would have been done with this a decade ago. The point is that IPv4 is functionally legacy. It'll continue to exist until it doesn't, but refusal to learn and implement IPv6 (and contribute to improving it) is truly a disservice. It's well past the point of no return, so learn it. Or don't. It won't really change the direction we are moving.
If we spend half as much time on IPv6 that we do moaning about IPv6, we would have been done with this a decade ago. The point is that IPv4 is functionally legacy. It'll continue to exist until it doesn't, but refusal to learn and implement IPv6 (and contribute to improving it) is truly a disservice. It's well past the point of no return, so learn it. Or don't. It won't really change the direction we are moving.
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.
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.
Some ISPs have v6 enabled but it's just broken or sub optimal. I imagine the logic is that v4 always works and the user could only see a benefit from having v6 off by default.
True, on an individual level that probably represents the best benefit. Anyone who actually cares would also know to go through the settings to check the defaults on all of those things with a new router too.
IPv6 is a security liability and provides no benefit to the user.
Both of those statements are wrong. It provides benefits to the user and it's no more of a security vulnerability than having any other networking protocol is.
If anything, v4 is more of a vulnerability because it's so easy to scan and because NAT increases the complexity enough that most people don't understand how their networks work.
If anything, v4 is more of a vulnerability because it's so easy to scan and because NAT increases the complexity enough that most people don't understand how their networks work.
Three decades of IPv6 mis-adoption shows otherwise. "Running out of IPv4 addresses" is not a problem you face unless you're an internet service provider or a mobile network.
99.99999% of the rest of us don't care because we use 192.168.0.0/16 or 10.0.0.0/8 when we have to do networking.
Yes, NAT is complex. That sucks. No, blindly stating "you don't need NAT and you're holding it wrong" is just plain incorrect.
Please make NAT easier to use and configure, don't sweep it under the rug and pretend like the world can function without it.
99.99999% of the rest of us don't care because we use 192.168.0.0/16 or 10.0.0.0/8 when we have to do networking.
Yes, NAT is complex. That sucks. No, blindly stating "you don't need NAT and you're holding it wrong" is just plain incorrect.
Please make NAT easier to use and configure, don't sweep it under the rug and pretend like the world can function without it.
It causes no end of problems, not just for ISPs and mobile networks but also for people running server networks and for end users like us. I suppose it can be hard to see that when you grew up with the problems and have never used a network where you didn't need to deal with them though.
The world can mostly function without NAT. It's mainly only used to work around address shortages, which aren't an issue on v6, so there's simply no reason to use it most of the time. It can be a useful tool in your toolbox, but it's one that you only need to use very rarely.
Here's a benefit from v6: 40% faster connection setup†. Measurable benefits show that there are benefits. "No need to use NAT" is of course another obvious benefit of v6.
†: https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip....
The world can mostly function without NAT. It's mainly only used to work around address shortages, which aren't an issue on v6, so there's simply no reason to use it most of the time. It can be a useful tool in your toolbox, but it's one that you only need to use very rarely.
Here's a benefit from v6: 40% faster connection setup†. Measurable benefits show that there are benefits. "No need to use NAT" is of course another obvious benefit of v6.
†: https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip....
No, NAT is not for network address shortages.
NAT is a cruicial privacy and security feature.
"No need to use NAT" is, of course, a horrible anti-feature, not a benefit of IPv6. (And, of course, in the real world the vast majority of IPv6 is rolled out with NAT anyways.)
NAT is a cruicial privacy and security feature.
"No need to use NAT" is, of course, a horrible anti-feature, not a benefit of IPv6. (And, of course, in the real world the vast majority of IPv6 is rolled out with NAT anyways.)
NAT is neither a privacy nor security feature, what are you talking about? Have you actually tested what your CPE does when it gets packets addressed to internal IPs from the WAN port? Almost every time, the answer is just pass it on to the target host. Thinking NAT is a security feature makes your network MUCH less secure.
As for privacy - you can fingerprint individual devices pretty trivially, and with privacy extensions for SLAAC you can only tell what /64 network it's coming from, which is no more information than IPv4 (unless you're behind CGNAT, but frankly being behind a 4-to-4 CGNAT shouldn't count as internet access because you literally can't get incoming connections.)
As for privacy - you can fingerprint individual devices pretty trivially, and with privacy extensions for SLAAC you can only tell what /64 network it's coming from, which is no more information than IPv4 (unless you're behind CGNAT, but frankly being behind a 4-to-4 CGNAT shouldn't count as internet access because you literally can't get incoming connections.)
Having enough address space to not need to NAT is hardly an anti-feature.
I don't have any hard stats, but NAT seems to be very rare in v6 deployments. You don't really hear of ISPs using it. I'm certain you could find some if you looked hard enough, but mostly it's not a thing.
I don't have any hard stats, but NAT seems to be very rare in v6 deployments. You don't really hear of ISPs using it. I'm certain you could find some if you looked hard enough, but mostly it's not a thing.
NAT was never intended for security and privacy.
IPv6 security is like IPv4 security: Firewalls
For privacy IPv6 uses Security Extensions, which shuffles your ipv6 ip.
IPv6 security is like IPv4 security: Firewalls
For privacy IPv6 uses Security Extensions, which shuffles your ipv6 ip.
If it was easy to set up, the providers would just include it (or the price would be low enough to shrug it on).
But it's not really trivial and IPv4 works well enough for most people to bother. Remember the typical workaround for network issues being disabling IPv6?
But it's not really trivial and IPv4 works well enough for most people to bother. Remember the typical workaround for network issues being disabling IPv6?
Hey all... unquietwiki from r/ipv6; been lead-mod there for a while now (though the rest of the folks are really amazing on the mod-side).
IPv6 has saved my bacon more times in the past 15 years, than IPv4 has fought with me. No clashing of IPv4 ranges. No fighting with NAT. Ability to easily have concurrent networks, for different purposes. Ability to assign multiple network addresses. Internally, it "just works" on basically anything not an older licensing server, or LAN game. Microsoft is using it internally. Apple has been mandating MacOS and iOS apps to support it for several years now. Usage over the Internet is exceeding 50% in major countries.
Where it falls short... a lot of ISPs use equipment that don't handle it well, and/or don't have the staff to implement it properly; and the ISP buyouts and mergers here in the US of the past 15-20 years REALLY messed up the timeline on adoption. Cloud services, a lot of the stuff Google & Microsoft built up their public offerings on, they were designed largely on older virtualization setups that precluded how IPv6 works, until recently; same goes for Docker & Kubernetes. A lot of VPS hosts support it just fine; but a lot of businesses aren't leveraging those, as they could be. And lastly... a lot of IT guys still don't care for IPv6; as those biases show up in these & on Reddit; so that perpetuates the cycle.
IPv6 has saved my bacon more times in the past 15 years, than IPv4 has fought with me. No clashing of IPv4 ranges. No fighting with NAT. Ability to easily have concurrent networks, for different purposes. Ability to assign multiple network addresses. Internally, it "just works" on basically anything not an older licensing server, or LAN game. Microsoft is using it internally. Apple has been mandating MacOS and iOS apps to support it for several years now. Usage over the Internet is exceeding 50% in major countries.
Where it falls short... a lot of ISPs use equipment that don't handle it well, and/or don't have the staff to implement it properly; and the ISP buyouts and mergers here in the US of the past 15-20 years REALLY messed up the timeline on adoption. Cloud services, a lot of the stuff Google & Microsoft built up their public offerings on, they were designed largely on older virtualization setups that precluded how IPv6 works, until recently; same goes for Docker & Kubernetes. A lot of VPS hosts support it just fine; but a lot of businesses aren't leveraging those, as they could be. And lastly... a lot of IT guys still don't care for IPv6; as those biases show up in these & on Reddit; so that perpetuates the cycle.
So the largest expansion of general availability compute (and associated addressing needs) occurs and it ignores ipv6.
Re: 50% ... Your ipv6 numbers are very likely mobile, are they not? And those all CGNAT to ipv4 land? So the entire ipv6 mobile space (the biggest victory of the ipv6 war) is basically behind the #1 thing that ipv6 hate more than anything: a NAT.
If you can't get ISPs to support it............
............... ...............
ISPs! The central access points to the internet for consumers! THE MAIN PEOPLE THAT YOU SHOULD HAVE CORRALLED. If you didn't get these people on IPv6 within a decade of the protocol, well I don't know what to say. I can't explain the massive degree of failure. Well, I don't have to, look at this thread. I just hear excuses. Blah blah ISPs Blah blah VMs blah blah kubernetes.
If the ISPs don't support ipv6, then the software applications CANNOT be upgraded. If it is 2022 and there are major failures in ipv6 support (and there are) in places like comcast and the like, then whose fault is that?
It is the fault of the ipv6 organizations, designers, ratifiers, etc.
To underline, in America we have MASSIVE monopolies on consumer ISP access, and have for decades. That means in order to wrangle these organizations, you, what, get 10 people in the room and the FCC and get it hammered out?
IPV6 isn't just a failure of protocol design. It is a massive failure of organization and outreach. The attitude, rife throughout all ipv6 conversations, is the protocol designers forced it on the internet and said "take it or leave it".
The issue is ipv4 has ALWAYS been easier for a programmer. ipv6 always makes for more headaches. This is a massive massive failure. IPV4 networking sucks! NAT! bridges! Gateways! Prozies! port forwarding! CGNAT! It's still all easier than ipv6. Think about that.
The issue here is that ipv6 has no hammer. It didn't have the FCC on board or some ultra-powerful group that could deliver the hammer.
This is like IE6 (what is it about the number 6? don't answer that), that required a grassroots rebellion in silicon valley to dislodge. Well, and Google Chrome.
GET A HAMMER. Idea: GOOGLE IS THE HAMMER.
Re: 50% ... Your ipv6 numbers are very likely mobile, are they not? And those all CGNAT to ipv4 land? So the entire ipv6 mobile space (the biggest victory of the ipv6 war) is basically behind the #1 thing that ipv6 hate more than anything: a NAT.
If you can't get ISPs to support it............
............... ...............
ISPs! The central access points to the internet for consumers! THE MAIN PEOPLE THAT YOU SHOULD HAVE CORRALLED. If you didn't get these people on IPv6 within a decade of the protocol, well I don't know what to say. I can't explain the massive degree of failure. Well, I don't have to, look at this thread. I just hear excuses. Blah blah ISPs Blah blah VMs blah blah kubernetes.
If the ISPs don't support ipv6, then the software applications CANNOT be upgraded. If it is 2022 and there are major failures in ipv6 support (and there are) in places like comcast and the like, then whose fault is that?
It is the fault of the ipv6 organizations, designers, ratifiers, etc.
To underline, in America we have MASSIVE monopolies on consumer ISP access, and have for decades. That means in order to wrangle these organizations, you, what, get 10 people in the room and the FCC and get it hammered out?
IPV6 isn't just a failure of protocol design. It is a massive failure of organization and outreach. The attitude, rife throughout all ipv6 conversations, is the protocol designers forced it on the internet and said "take it or leave it".
The issue is ipv4 has ALWAYS been easier for a programmer. ipv6 always makes for more headaches. This is a massive massive failure. IPV4 networking sucks! NAT! bridges! Gateways! Prozies! port forwarding! CGNAT! It's still all easier than ipv6. Think about that.
The issue here is that ipv6 has no hammer. It didn't have the FCC on board or some ultra-powerful group that could deliver the hammer.
This is like IE6 (what is it about the number 6? don't answer that), that required a grassroots rebellion in silicon valley to dislodge. Well, and Google Chrome.
GET A HAMMER. Idea: GOOGLE IS THE HAMMER.
Windows Vista came out in 2007, and it explicitly had a dual-stack IPv4+IPv6 implementation. Around that same time, the BSDs were finishing up KAME, and Linux support was decently mature. That was 15 years ago. Software and OS-wise; with the exception of some features of Mikrotik routers + managed Meraki & Ubiquiti stuff just now getting onboard; the support is there. Node's using it properly now. I was able to update Pidgin to use it 10+ years ago. So I think we've got the software-side long figured out; we just needed to get the damn vendors on-board.
I'm glad we agree on NAT sucking. Though given a lot of ISPs are doing DHCPv6 without fixed net-ranges to clients; a work environment does benefit from having ULAs still; sometimes even with NAT66. Performance & security-wise, IPv6 still wins that battle: most routers disable automatic inbound traffic, and you can pinhole traffic directly between hosts.
I'm glad we agree on NAT sucking. Though given a lot of ISPs are doing DHCPv6 without fixed net-ranges to clients; a work environment does benefit from having ULAs still; sometimes even with NAT66. Performance & security-wise, IPv6 still wins that battle: most routers disable automatic inbound traffic, and you can pinhole traffic directly between hosts.
I'm willing to bet that every ISP in America has IPV6 capabilities but the ones that have not activated it have done so out of corporate lethargy.
The bosses aren't yelling, "TURN ON IPV6 AND MAKE IT WORK" so the peons have no reason to flip the switches. The bosses have no reason to push for IPV6 as it will increase support costs and add work hours but it will not increase income or improve profits.
We need a mandate from the FCC that says that any ISP that has accepted federal funds to build or deploy internet access systems must turn on IPV6 to the consumer or face penalties. Short of that, it's not going to happen.
The bosses aren't yelling, "TURN ON IPV6 AND MAKE IT WORK" so the peons have no reason to flip the switches. The bosses have no reason to push for IPV6 as it will increase support costs and add work hours but it will not increase income or improve profits.
We need a mandate from the FCC that says that any ISP that has accepted federal funds to build or deploy internet access systems must turn on IPV6 to the consumer or face penalties. Short of that, it's not going to happen.
> And lastly... a lot of IT guys still don't care for IPv6; as those biases show up in these & on Reddit; so that perpetuates the cycle
You know the 3rd and 7th largest networks on the internet still can't reach each other over IPv6, right? It is super awesome that it "just works" for you, but recognize you might just not have the perspective of one of the people who has to make it "just work" for you.
You know the 3rd and 7th largest networks on the internet still can't reach each other over IPv6, right? It is super awesome that it "just works" for you, but recognize you might just not have the perspective of one of the people who has to make it "just work" for you.
>You know the 3rd and 7th largest networks on the internet still can't reach each other over IPv6
Who is responsible? Which networks are those?
Who is responsible? Which networks are those?
Cogent and Hurricane Electric, the upstream providers of 31% and 17% of networks on the internet respectfully.
The reason as an end user you can access both sides of the spit is because network engineers for end user/eyeball networks will buy transit from both.
The reason as an end user you can access both sides of the spit is because network engineers for end user/eyeball networks will buy transit from both.
I’m sorry but how is cogents shitty business model somehow the fault of ipv6? Peering disputes happen on ipv4 as well
I think HE's been begging to peer to Cogent for years now. I've even seen cakes posted online.
> And lastly... a lot of IT guys still don't care for IPv6
The issue I have with IPv6 is that it's so complex compared to the IPv4 I know, and still has lacking support in routers and similar.
For example, I want to be sure my local devices uses my local NTP server. With IPv4 it's trivial, I just add an option to the DHCP server. With IPv6 I can't do that with RA, I have to use DHCPv6. But Android doesn't support DHCPv6, so I have to run both RA and DHCPv6, and hope it just works out.
Next there's firewall rules. I used to run pfSense, and it just didn't support changing prefixes. Everything was configured based on the full IPv6 address, so everything had to be reconfigured when the prefix changed. Not only that, but stuff like DNS server address didn't get updated properly, so all the clients still tried to connect to the DNS server (my router) using the old prefix, so no internet for any of the clients all of a sudden.
Additionally, using the full IPv6 address internally is a PITA, since even if I assign a server a nice ::2 ending, my prefix is a full 64 bits of random noise (which changes, yay!). So I ended up using ULAs, which at least preserved some of my sanity, but it's another thing to manage.
So yeah, once I start having IPv6 issues and have to figure out some solution I wonder why bother. Mostly because it's so different, and it's still under development, both specification wise and the implementations. IPv4 for most people is quite simple in comparison, due to an established ecosystem. IPv6 on the other hand feels quite rough, including the impedance mismatches due to clearly being designed for large enterprise networks.
That being said, I've now had IPv6 enabled at home for over a year, things mostly work well. The key change was to ditch pfSense and switch to OpenWRT.
The issue I have with IPv6 is that it's so complex compared to the IPv4 I know, and still has lacking support in routers and similar.
For example, I want to be sure my local devices uses my local NTP server. With IPv4 it's trivial, I just add an option to the DHCP server. With IPv6 I can't do that with RA, I have to use DHCPv6. But Android doesn't support DHCPv6, so I have to run both RA and DHCPv6, and hope it just works out.
Next there's firewall rules. I used to run pfSense, and it just didn't support changing prefixes. Everything was configured based on the full IPv6 address, so everything had to be reconfigured when the prefix changed. Not only that, but stuff like DNS server address didn't get updated properly, so all the clients still tried to connect to the DNS server (my router) using the old prefix, so no internet for any of the clients all of a sudden.
Additionally, using the full IPv6 address internally is a PITA, since even if I assign a server a nice ::2 ending, my prefix is a full 64 bits of random noise (which changes, yay!). So I ended up using ULAs, which at least preserved some of my sanity, but it's another thing to manage.
So yeah, once I start having IPv6 issues and have to figure out some solution I wonder why bother. Mostly because it's so different, and it's still under development, both specification wise and the implementations. IPv4 for most people is quite simple in comparison, due to an established ecosystem. IPv6 on the other hand feels quite rough, including the impedance mismatches due to clearly being designed for large enterprise networks.
That being said, I've now had IPv6 enabled at home for over a year, things mostly work well. The key change was to ditch pfSense and switch to OpenWRT.
> For example, I want to be sure my local devices uses my local NTP server. With IPv4 it's trivial, I just add an option to the DHCP server. With IPv6 I can't do that with RA, I have to use DHCPv6. But Android doesn't support DHCPv6, so I have to run both RA and DHCPv6, and hope it just works out.
Out of curiosity, why does this require DHCPv6? Cant you just point your local devices to ntp.homedomain (or whatever the DNS name of the local NTP server is)?
Out of curiosity, why does this require DHCPv6? Cant you just point your local devices to ntp.homedomain (or whatever the DNS name of the local NTP server is)?
I think if you're using the Meinberg NTP client on Windows, or chrony on Linux, that's feasible. Older systems may prefer to snag it from DHCP: which probably would only do IPv4 anyway.
> Cant you just point your local devices to ntp.homedomain
So how do I do that without configuring each device manually? I mean, that's way too much hassle.
So how do I do that without configuring each device manually? I mean, that's way too much hassle.
Why are you using IP addresses directly? That's what DNS is for. There's even mDNS for in simple home networks.
(The DHCP thing is valid but that's one single android dev being an ass who can't read deciding that it imposes limitations it doesn't and ruining it for the rest of us)
(The DHCP thing is valid but that's one single android dev being an ass who can't read deciding that it imposes limitations it doesn't and ruining it for the rest of us)
> Why are you using IP addresses directly? That's what DNS is for.
Sometimes DNS is down, like when I rand pfSense and the prefix changed, so I like to have the core services in my network on easily accessible IPs.
Sometimes DNS is down, like when I rand pfSense and the prefix changed, so I like to have the core services in my network on easily accessible IPs.
I have to say I’m super disappointed in the ignorance and negativity in the comments on this thread. Ignorance of both the difficulties inherent in upgrading a fixed size wire protocol designed for a research network fifty years ago, and the widespread adoption of ipv6 for real customer deployments. Heck most of you are probably using ipv6 through your mobile carrier and don’t even know it!
I think you're being unfair to the audience. The main complaints here aren't about the consequences of those legacy problems, they're about the fact that IPv6 is just such a mediocre designed-by-committee protocol.
Your point about mobile networks kind of illustrates this. There are all sorts of weird and wonderful protocols used in the mobile world, and it doesn't matter because 99.999% of us never have to deal with it, and the 0.001% that do have time and space to become experts. IPv6 isn't like that -- it needs to be a consumer grade protocol that people can understand and work with. It either fails that test, or perhaps at best scrapes a borderline pass. We deserved better.
Your point about mobile networks kind of illustrates this. There are all sorts of weird and wonderful protocols used in the mobile world, and it doesn't matter because 99.999% of us never have to deal with it, and the 0.001% that do have time and space to become experts. IPv6 isn't like that -- it needs to be a consumer grade protocol that people can understand and work with. It either fails that test, or perhaps at best scrapes a borderline pass. We deserved better.
IPv6 is very similar to IPv4 it's just IPv4 wasn't a consumer grade protocol either. The problem isn't the protocol it's that there is little incentive for the average user to switch to anything else on their own volition when most didn't even really set up what they are switching from (and already working on today) anyways.
Again, this is kind of making my point. IPv4 had an excuse for being a bit crap, because it was designed in the early 1980s. IPv6 should have been much better than it is.
Adoption was always going to be slow, but it never needed to be this slow. If the designers had thought a but more about usability and not done stupid stuff like making the address space contain twice as many bits as it actually needs, then we would have transitioned by now.
Adoption was always going to be slow, but it never needed to be this slow. If the designers had thought a but more about usability and not done stupid stuff like making the address space contain twice as many bits as it actually needs, then we would have transitioned by now.
IPv6's introduction is closer to IPv4's introduction that to now. By nearly twice as much.
It should be mentioned that 2^32 was widely considered to be unfathomongly large when ipv4 was developed as well.
However now we are pumping out something like 4 ARM cores per person on the planet, per year. Clearly we will need to plan for those devices to communicate.
Also the effective address space in ipv6 is much smaller than 2^128 as the default subnet prefix is /64. So in a sense, it has already “addressed” your concern? Pun intended.
However now we are pumping out something like 4 ARM cores per person on the planet, per year. Clearly we will need to plan for those devices to communicate.
Also the effective address space in ipv6 is much smaller than 2^128 as the default subnet prefix is /64. So in a sense, it has already “addressed” your concern? Pun intended.
I could say IPv6 addresses should have been 8 bits because it would have been more usable but that's not reasoning I'm right and IPv6 is a mediocre design-by-committee protocol it's just me lambasting the designers based on some number I thought sounded nice.
If the addresses were 64 bit instead of 128 bit the situation wouldn't be any different, beyond IPv6 would be harder to use. For humans unused bits end up hidden when written out and for machines most of the bits are used and are used in a way that make it scale and be simplified over using fewer bits. E.g. the assumption that every user subnet is a /64 instead of based on the number of devices in it is a massive simplification that hides a ton of complexity people ran into with IPv4 networks. /48 being the minimum aggregate advertisable on the internet makes the number of participants in the internet scale much better. Giving RIRs blocks of /23 leaves room to expand as assignments grow in the future - avoiding the problem we hit with IPv4. Just saying "half the bits is simpler" doesn't actually make your assumptions correct or the deployment happen any faster.
To re-iterate on this part: The problem isn't the protocol it's that there is little incentive for the average user to switch to anything else on their own volition when most didn't even really set up what they are switching from (and already working on today) anyways.
That's not to say the end user needs a more "usable" protocol so it becomes attractive to switch - that's not where the lack of attractiveness sources. The cost to use the protocol could be 0 (and IPv6 is actually extremely close to that to be honest) and there is still no incentive for consumers or businesses to make the switch yet. Even if everything goes perfect and is 100% done without any human intervention it still provides them no benefit until very recently when IPv4 prices started to rise so why would anyone have rushed to make the switch 20 years ago?
An example of this comes back to the cell carriers - they didn't go to IPv6 because they just like and have the time to do complicated things it was the simplest way to enable mobility across their networks with a large scale of devices. They hit this need much sooner than the price of a /24 went up enough for people to start caring so they pushed for their networks and phones to support this faster (on top of needing to build out a lot of new greenfield stuff anyways so why bother building greenfield with the old).
If the addresses were 64 bit instead of 128 bit the situation wouldn't be any different, beyond IPv6 would be harder to use. For humans unused bits end up hidden when written out and for machines most of the bits are used and are used in a way that make it scale and be simplified over using fewer bits. E.g. the assumption that every user subnet is a /64 instead of based on the number of devices in it is a massive simplification that hides a ton of complexity people ran into with IPv4 networks. /48 being the minimum aggregate advertisable on the internet makes the number of participants in the internet scale much better. Giving RIRs blocks of /23 leaves room to expand as assignments grow in the future - avoiding the problem we hit with IPv4. Just saying "half the bits is simpler" doesn't actually make your assumptions correct or the deployment happen any faster.
To re-iterate on this part: The problem isn't the protocol it's that there is little incentive for the average user to switch to anything else on their own volition when most didn't even really set up what they are switching from (and already working on today) anyways.
That's not to say the end user needs a more "usable" protocol so it becomes attractive to switch - that's not where the lack of attractiveness sources. The cost to use the protocol could be 0 (and IPv6 is actually extremely close to that to be honest) and there is still no incentive for consumers or businesses to make the switch yet. Even if everything goes perfect and is 100% done without any human intervention it still provides them no benefit until very recently when IPv4 prices started to rise so why would anyone have rushed to make the switch 20 years ago?
An example of this comes back to the cell carriers - they didn't go to IPv6 because they just like and have the time to do complicated things it was the simplest way to enable mobility across their networks with a large scale of devices. They hit this need much sooner than the price of a /24 went up enough for people to start caring so they pushed for their networks and phones to support this faster (on top of needing to build out a lot of new greenfield stuff anyways so why bother building greenfield with the old).
IPv6 was designed in the late 80s/early 90s, before home users had internet access. At the time there was serious debate over switching to the OSI stack instead. You're showing your lack of history knowledge more than anything.
What parts of ipv6 used in consumer grade equipment are not understandable or “consumer grade”? Ipv6 in some areas is actually simpler than ipv4.
I gave the example of mobile networks because it’s one of the few places consumer facing networks are growing rapidly and in some cases build entirely greenfield networks. And they have overwhelmingly chosen to build using ipv6 to do so.
I gave the example of mobile networks because it’s one of the few places consumer facing networks are growing rapidly and in some cases build entirely greenfield networks. And they have overwhelmingly chosen to build using ipv6 to do so.
It is worse than that. They implement 'carrier grade NAT' on top of double NAT.
Maybe mobile devices don't need incoming connectivity but doing a hack on a hack to save IPv4 addresses is a reflection on the genuine expertise at some of the national carriers.
When I was younger, telecom providers had all the professional expert engineering talent.
(I'm on superloop down under here, they actually have engineers and seem to have deployed a, what seems to be to me, a faultless IPV6 setup. The only issues I have found have been with toy things like pihole not behaving properly. Once I went to the Technitium thing my ipv6 experience over the last few years has been faultless.
Maybe mobile devices don't need incoming connectivity but doing a hack on a hack to save IPv4 addresses is a reflection on the genuine expertise at some of the national carriers.
When I was younger, telecom providers had all the professional expert engineering talent.
(I'm on superloop down under here, they actually have engineers and seem to have deployed a, what seems to be to me, a faultless IPV6 setup. The only issues I have found have been with toy things like pihole not behaving properly. Once I went to the Technitium thing my ipv6 experience over the last few years has been faultless.
>I think you're being unfair to the audience. The main complaints here aren't >about the consequences of those legacy problems, they're about the fact that IPv6 >is just such a mediocre designed-by-committee protocol.
That's every standard protocol.
>Your point about mobile networks kind of illustrates this. There are all sorts of >weird and wonderful protocols used in the mobile world, and it doesn't matter >because 99.999% of us never have to deal with it, and the 0.001% that do have >time and space to become experts. IPv6 isn't like that -- it needs to be a >consumer grade protocol that people can understand and work with. It either fails >that test, or perhaps at best scrapes a borderline pass. We deserved better.
Wireline networks aren't any different, gobs of weird and wonderful protocols in MEF, carrier TE, DOCSIS, etc. Implementation issues drive 90% of the problems described. And don't think for a second that those kinds of issues are unique - all of this happened the same way in IPv4. It just happened so long ago that most either were not around for it, or forgot the pain. that shit box was classful in its original state. The difference now is that a bunch of people can see the sausage getting made and they don't like the ingredients, even though they've likely been eating the sausage for years.
That's every standard protocol.
>Your point about mobile networks kind of illustrates this. There are all sorts of >weird and wonderful protocols used in the mobile world, and it doesn't matter >because 99.999% of us never have to deal with it, and the 0.001% that do have >time and space to become experts. IPv6 isn't like that -- it needs to be a >consumer grade protocol that people can understand and work with. It either fails >that test, or perhaps at best scrapes a borderline pass. We deserved better.
Wireline networks aren't any different, gobs of weird and wonderful protocols in MEF, carrier TE, DOCSIS, etc. Implementation issues drive 90% of the problems described. And don't think for a second that those kinds of issues are unique - all of this happened the same way in IPv4. It just happened so long ago that most either were not around for it, or forgot the pain. that shit box was classful in its original state. The difference now is that a bunch of people can see the sausage getting made and they don't like the ingredients, even though they've likely been eating the sausage for years.
> most of you are probably using ipv6 through your mobile carrier and don’t even know it!
My mobile carrier provides dual stack (with NAT in the IPv4 side). So no problem with any kind of site. Are there operators who provide IPv6 only? Haven't really read up on that topic, but I guess that requires NAT64 because the average user needs to reach IPv4-only sites. Does that generally work well?
If yes, why can the poster of the submission not use that on his Hetzner instances?
My mobile carrier provides dual stack (with NAT in the IPv4 side). So no problem with any kind of site. Are there operators who provide IPv6 only? Haven't really read up on that topic, but I guess that requires NAT64 because the average user needs to reach IPv4-only sites. Does that generally work well?
If yes, why can the poster of the submission not use that on his Hetzner instances?
T-Mobile has been IPv6-only for a while.
I guess you can't use NAT64 at Hetzner because Hetzner doesn't provide it.
I guess you can't use NAT64 at Hetzner because Hetzner doesn't provide it.
Why would Hetzner need to provide it? If you have several IPv6-only nodes you can rune one NAT64 node yourself. Of course that would work only if you save enough on IPv4 to pay for the extra node. And not if you are heavily network-bound.
There are also free NAT64 solutions, but of course you can't base anything but a random hobby project on something free. Maybe there are also commercial solutions, but IPv4 might still be too cheap to make that really interesting.
Actually the AskHN talks mostly about client cases. Those still seem "easy". Offering more than one service on let's say port 443 would require a full application level gateway / forward-proxy.
There are also free NAT64 solutions, but of course you can't base anything but a random hobby project on something free. Maybe there are also commercial solutions, but IPv4 might still be too cheap to make that really interesting.
Actually the AskHN talks mostly about client cases. Those still seem "easy". Offering more than one service on let's say port 443 would require a full application level gateway / forward-proxy.
Yes, T-Mobile for example. I just dumped the interface information from my iPhone and the only address available is an ipv6 address. Everything else is put through an ipv6 to ipv4 gateway. Works fine.
Apple has required app developers to support ipv6 only deployments since 2015: https://developer.apple.com/support/ipv6/
Apple has required app developers to support ipv6 only deployments since 2015: https://developer.apple.com/support/ipv6/
I had IPv6 only on the default APN configuration pushed by my carrier on Android, last time I checked it
And IPv4 only for roaming
Both v6 only, v4 only and v4+v6 were supported
For landlines, I'm surprised because some ISPs who were not having difficulties with ipv4 are being the fastest to switch to ipv6. While some who had to deal with CG-NAT and other horrible stuff are fine with ipv4, and haven't yet planned to move to ipv6
Is this due to corporate culture or something ?
For landlines, I'm surprised because some ISPs who were not having difficulties with ipv4 are being the fastest to switch to ipv6. While some who had to deal with CG-NAT and other horrible stuff are fine with ipv4, and haven't yet planned to move to ipv6
Is this due to corporate culture or something ?
You're essentially blaming the victim.
The ISPs still haven't adopted it after 25 years.
ISPs are a massive monopoly in the USA. IPV6 can't be adopted by software until a sufficient number of the backbone works. I've heard that "the backbone is all working for ipv6". Um, is comcast? Wasn't last time I had comcast.
If the ISP monopolies aren't 100% ipv6 (and you see lots of comments here that ipv6 support in ISPs is still "substandard") and convenient, then you can't blame the software people.
Look at your success story in mobile (which is behind a huge NAT to translate things to the "real" internet by the way). How did that work? Oh, you probably wrangled the three or four mobile companies into a room and got them to agree on protocols. Wow, success.
This needs to happen for the rest of ISPs. The fact it hasn't isn't a software issue, it is a governance issue. The failure is in the governance, the outreach with the real policy hammers like the FCC and ISP monopolies.
The governance has failed. It's been failing about 15 years longer than it should. FIFTEEN YEARS OF FAILURE!
Stop blaming reticent programmers, because IPV4 networking is still much much much easier than ipv6 in software, and IPV4 networking SUCKS between NATs and bridges and internal/external IPs and port mappings and what's-my-ip-on-the-other-end and dynamic DNS. Ohmygod it sucks. And ipv6 is worse than that!
Stop blaming the software people. IPV6 governance and outreach failed. Failed failed failed failed.
I don't want ipv6 to fail. I WANT STATIC IPs! EVERY PROGRAMMER WANTS STATIC IPS!
Get the ISPs and FCC in a room. Get google and microsoft and whoever else you need to lean on them. Get Amazon and google and microsoft IAAS into a room (hm, look, the same companies basically) and lean on them to support ipv6.
The ISPs still haven't adopted it after 25 years.
ISPs are a massive monopoly in the USA. IPV6 can't be adopted by software until a sufficient number of the backbone works. I've heard that "the backbone is all working for ipv6". Um, is comcast? Wasn't last time I had comcast.
If the ISP monopolies aren't 100% ipv6 (and you see lots of comments here that ipv6 support in ISPs is still "substandard") and convenient, then you can't blame the software people.
Look at your success story in mobile (which is behind a huge NAT to translate things to the "real" internet by the way). How did that work? Oh, you probably wrangled the three or four mobile companies into a room and got them to agree on protocols. Wow, success.
This needs to happen for the rest of ISPs. The fact it hasn't isn't a software issue, it is a governance issue. The failure is in the governance, the outreach with the real policy hammers like the FCC and ISP monopolies.
The governance has failed. It's been failing about 15 years longer than it should. FIFTEEN YEARS OF FAILURE!
Stop blaming reticent programmers, because IPV4 networking is still much much much easier than ipv6 in software, and IPV4 networking SUCKS between NATs and bridges and internal/external IPs and port mappings and what's-my-ip-on-the-other-end and dynamic DNS. Ohmygod it sucks. And ipv6 is worse than that!
Stop blaming the software people. IPV6 governance and outreach failed. Failed failed failed failed.
I don't want ipv6 to fail. I WANT STATIC IPs! EVERY PROGRAMMER WANTS STATIC IPS!
Get the ISPs and FCC in a room. Get google and microsoft and whoever else you need to lean on them. Get Amazon and google and microsoft IAAS into a room (hm, look, the same companies basically) and lean on them to support ipv6.
45% of users are on IPv6. Clearly almost half of ISPs have adopted it, probably more than half of consumer ISPs.
How many of those are Mobile?
And how many of those mobile ipv6 addresses are communicating with the "real" internet through a carrier grade NAT to translate/intermediate with IPV4 servers/addresses?
And about the most offensive, disgusting thing to ipv6 people is the NAT. It's the thorn in their side that 1) IPV6 "trivially" solves (allegedly) but even worse 2) it's what keeps ipv4 on life support with the ISPs.
Can some ipv6 person tell me with a straight face that mobiles being ipv6 behind a huge cgnat is "success"?
So the fact that the big success story of ipv6 is all enabled by a huge massive NAT is ... morbidly hilarious.
So that actually means that most "regular internet" HAVEN'T adopted it, a statistic meant to show good uptake actually shows the real problem. The ISPs for cable/internet, Despite huge huge monopoly-protected revenues, aren't doing anything at all.
Again, as a programmer, I would like to work with static IPs. NATs suck, ipv4 sucks, private addresses vs public addresses suck. If not for the condescending, ivory tower, shove-down-throat, bungled incompetent planning, utter lack of outreach and transition planning, an addres transition plan (per the MX + A guy's thesis), I would love ipv6. I WANT A STATIC IP. EVERY PROGRAMMER WANTS A STATIC IP. We don't want to think about all the ipv4 bullshit.
The failure is with the ipv6 mafia. They failed. They keep failing. And based on everything they say and their representatives, they will continue to fail.
And how many of those mobile ipv6 addresses are communicating with the "real" internet through a carrier grade NAT to translate/intermediate with IPV4 servers/addresses?
And about the most offensive, disgusting thing to ipv6 people is the NAT. It's the thorn in their side that 1) IPV6 "trivially" solves (allegedly) but even worse 2) it's what keeps ipv4 on life support with the ISPs.
Can some ipv6 person tell me with a straight face that mobiles being ipv6 behind a huge cgnat is "success"?
So the fact that the big success story of ipv6 is all enabled by a huge massive NAT is ... morbidly hilarious.
So that actually means that most "regular internet" HAVEN'T adopted it, a statistic meant to show good uptake actually shows the real problem. The ISPs for cable/internet, Despite huge huge monopoly-protected revenues, aren't doing anything at all.
Again, as a programmer, I would like to work with static IPs. NATs suck, ipv4 sucks, private addresses vs public addresses suck. If not for the condescending, ivory tower, shove-down-throat, bungled incompetent planning, utter lack of outreach and transition planning, an addres transition plan (per the MX + A guy's thesis), I would love ipv6. I WANT A STATIC IP. EVERY PROGRAMMER WANTS A STATIC IP. We don't want to think about all the ipv4 bullshit.
The failure is with the ipv6 mafia. They failed. They keep failing. And based on everything they say and their representatives, they will continue to fail.
Too much of the web is mobile these days to be dismissing it.
Yes, mobiles on v6-only with NAT64 to reach legacy v4 hosts is a massive success story. How can you say with a straight face that it's not?
Most big landline ISPs in the US are doing v6. Comcast, the poster child for awful ISPs, winner of multiple worst company in America awards, has been running v6 over their entire network for years now.
Yes, mobiles on v6-only with NAT64 to reach legacy v4 hosts is a massive success story. How can you say with a straight face that it's not?
Most big landline ISPs in the US are doing v6. Comcast, the poster child for awful ISPs, winner of multiple worst company in America awards, has been running v6 over their entire network for years now.
Because you should talk to an ipv6 person and say the word "NAT". They froth at the mouth.
It IS a success, but it's a success that is singularly enabled by the #1 thing that ipv6 people hate with a passion: a NAT. The evil NAT that has kept IPV4 address space alive, that was the crutch that kept ipv6 from being adopted earlier. The evil NAT isn't a firewall, the evil NAT can be replaced by string-of-acronyms.
And, it's a success which paves the way for practically any protocol to replace ipv6 as the real successor, like the casually thrown out ipv4.4++v2, which is getting dismissed right and left by the ipv6 people here. Or god forbid a better protocol. Please give me ipv8.
Not that I was in the room, but it's apparent that the mobile success is due to the fact the cartel of phone makers and spectrum owners/mobile carriers got in a room and adopted ipv6 head to toe.
I would like to know if the FCC had a role here, or it's just that the mobile carrier industry is used to adopting new standards so this wasn't a big deal, or it was the OEMs that enforced/enabled it.
For the rest of ipv4-land, where is this cooperation/regulation/coordination for migrating?
My comcast modems do not support ipv6 last I tried, but that was three years ago. Maybe the magic wand has been waved finally. But I look at this thread and think: Eh, nope.
It IS a success, but it's a success that is singularly enabled by the #1 thing that ipv6 people hate with a passion: a NAT. The evil NAT that has kept IPV4 address space alive, that was the crutch that kept ipv6 from being adopted earlier. The evil NAT isn't a firewall, the evil NAT can be replaced by string-of-acronyms.
And, it's a success which paves the way for practically any protocol to replace ipv6 as the real successor, like the casually thrown out ipv4.4++v2, which is getting dismissed right and left by the ipv6 people here. Or god forbid a better protocol. Please give me ipv8.
Not that I was in the room, but it's apparent that the mobile success is due to the fact the cartel of phone makers and spectrum owners/mobile carriers got in a room and adopted ipv6 head to toe.
I would like to know if the FCC had a role here, or it's just that the mobile carrier industry is used to adopting new standards so this wasn't a big deal, or it was the OEMs that enforced/enabled it.
For the rest of ipv4-land, where is this cooperation/regulation/coordination for migrating?
My comcast modems do not support ipv6 last I tried, but that was three years ago. Maybe the magic wand has been waved finally. But I look at this thread and think: Eh, nope.
No need for conspiracies - see for example the presentations from T-Mobile to nanog: https://pc.nanog.org/static/published/meetings/NANOG73/1645/... and https://www.internetsociety.org/resources/deploy360/2014/cas..., just for two examples after thirty seconds of googling.
Comcast has had ipv6 support rolled out for some time now. I don’t know why you don’t see it.
Comcast has had ipv6 support rolled out for some time now. I don’t know why you don’t see it.
Mobile carriers want v6 because it saves them money. CGNAT capacity is expensive. Having native v6 means that >50% of your traffic won't need to touch the CGNAT, which reduces your costs significantly.
NAT is a necessary evil to deal with address space exhaustion in v4. NAT64 is just another application of that. In v6, when not dealing with backwards compatibility to v4, NAT is an unnecessary evil. Do you see the difference?
> And, it's a success which paves the way for practically any protocol to replace ipv6 as the real successor, like the casually thrown out ipv4.4++v2, which is getting dismissed right and left by the ipv6 people here.
It's being dismissed because it brings nothing new to the table. The people casually throwing out alternatives aren't thinking through them enough to realize that they've either come up with something that doesn't work, or they've come up with something that's basically v6 and has the same limitations v6 does. There's zero point in replacing v6 -- which 40% of the Internet's clients are already using -- with another protocol that's just as hard to deploy.
NAT is a necessary evil to deal with address space exhaustion in v4. NAT64 is just another application of that. In v6, when not dealing with backwards compatibility to v4, NAT is an unnecessary evil. Do you see the difference?
> And, it's a success which paves the way for practically any protocol to replace ipv6 as the real successor, like the casually thrown out ipv4.4++v2, which is getting dismissed right and left by the ipv6 people here.
It's being dismissed because it brings nothing new to the table. The people casually throwing out alternatives aren't thinking through them enough to realize that they've either come up with something that doesn't work, or they've come up with something that's basically v6 and has the same limitations v6 does. There's zero point in replacing v6 -- which 40% of the Internet's clients are already using -- with another protocol that's just as hard to deploy.
Plenty of cable/fibre ISPs use IPv6, but it varies by country.
In the UK, the two largest providers have been running IPv6 for years (BT and Sky), that's about 55% of the market.
Virgin and TalkTalk are ignoring it, that's a further 25%.
Vodafone are working on it ("next year due to Covid"), 5%.
The remaining 20% is small ISPs, and many of these support it.
In the UK, the two largest providers have been running IPv6 for years (BT and Sky), that's about 55% of the market.
Virgin and TalkTalk are ignoring it, that's a further 25%.
Vodafone are working on it ("next year due to Covid"), 5%.
The remaining 20% is small ISPs, and many of these support it.
The government has a poor track record of pushing a technology in this space. They’ve been mandating ipv6 in the dod for - gosh at least since 2008 or so.
Oh, and you have the government to thank for the useless posix subsystem for windows back in the 90s (remember that?) as a way to force software “interoperability” between Unix and windows. Companies vying for federal contracts will look at the poorly defined requirements and find a way to just barely meet the letter but not the spirit.
Oh, and you have the government to thank for the useless posix subsystem for windows back in the 90s (remember that?) as a way to force software “interoperability” between Unix and windows. Companies vying for federal contracts will look at the poorly defined requirements and find a way to just barely meet the letter but not the spirit.
This is not a complicated regulatory decree.
"THOU SHALT USE IPV6 BY XXXX date or you don't get subsidies and/or lose spectrum and/or lose IPV4 ranges".
This is not designing a new complicated api compatibility. ALLEGEDLY the ipv6 geniuses have everything figured out technically. There is ALLEGEDLY no protocol development, RFC, standards body formation. ALLEGEDLY it's all been laid out. There are some success stories, there are "reference implementations" in production.
Again, it's not like this is hard to disseminate to the necessary powers that be. America is a bunch of monopolies and cartels. That means the regulatory agencies can call like 10 people and tell them the lay of the land. This is not herding a thousand cats with a fork, this is using shock treatment on elephants.
"THOU SHALT USE IPV6 BY XXXX date or you don't get subsidies and/or lose spectrum and/or lose IPV4 ranges".
This is not designing a new complicated api compatibility. ALLEGEDLY the ipv6 geniuses have everything figured out technically. There is ALLEGEDLY no protocol development, RFC, standards body formation. ALLEGEDLY it's all been laid out. There are some success stories, there are "reference implementations" in production.
Again, it's not like this is hard to disseminate to the necessary powers that be. America is a bunch of monopolies and cartels. That means the regulatory agencies can call like 10 people and tell them the lay of the land. This is not herding a thousand cats with a fork, this is using shock treatment on elephants.
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.
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.
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.
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.
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.
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.
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.
This is a home cable connection in the Bay Area.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
the most exhaustive list thus far is https://sites.ip-update.net/ afaik
I'm not asking for ipv6-only, but ipv4-only.
Those are the ones blocking adoption for me, as an end user.
Those are the ones blocking adoption for me, as an end user.
derp yes
https://whynoipv6.com/
https://whynoipv6.com/
How are they blocking? You're just behind a NAT64, which is no worse than NAT44, with the bonus of having actual connectivity on the IPv6 side.
Ugh, Centurylink. Their networks, both DSL and Fiber, support IPv6 but you need to go into the router config and explicitly enable it which is why they show up as 0.5% IPv6 supported in that first link despite every other top-10 US ISP having at least 50%. I've enabled v6 on my home connections with them on both DSL and fiber and I've had absolutely no problems with it. I wish they would enable it by default with their consumer network equipment.
Comcast added IPv6 ages ago. Time Warner and AT&T (FTTH, not just mobile internet) support it now as well.
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.
Is it enabled by default on customer equipment?
On their leased hardware, it is enabled from what I've seen. And if you are running your own modem and router, you will get IPv6 if you configure your setup to request it (via DHCP). They will even give you a /60 if your DHCP client asks for it.
Weak, here in Sweden I get a /56 from my ISP. You'll run out of IP addresses long before I do!
Even? /60 should be the minimum, even home users usually have a couple subnets (guest networks for example, sometimes one for the router's WAN link) and you want the boundary to be on a nybble boundary
A /60 network consists of 295,147,905,179,352,825,856 addresses. I think most users will probably be fine with that.
This is v6; nobody counts individual IPs, because the answer is always "enough".
A /60 is only 16 /64s (i.e. 16 subnets), and that's not always enough.
A /60 is only 16 /64s (i.e. 16 subnets), and that's not always enough.
When I had Comcast about 5 years ago it was enabled by default.
> Not sure what France is doing though, maybe something right.
The telecom regulator (ARCEP) conditioned 5G bands on rolling out IPv6.
The telecom regulator (ARCEP) conditioned 5G bands on rolling out IPv6.
Not sure what France is doing because Im in Paris and I can tell ipv6 only router does not work. Maybe it's also about mobile.
> 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?
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?
> 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.
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.
> 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.
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.
What I think (or at least hope) that this post is missing, is the ever-growing opportunity cost of having a population of people that are flat out unable to access your service. Google's IPv6 page currently has almost all of Africa at near-0% v6 adoption, but this map https://data.worldbank.org/indicator/IT.NET.USER.ZS?view=map shows a lot of African countries that still have low internet access. With such a long way to go towards full access, and in a lot of countries, exponentially rising populations, could a lot of African ISPs give up on the cost and/or CGNAT complexity of trying to magic up so many new IPv4 connections, and go all in on v6? That's only my layman speculation though.
The thing is, it's not v6 or v4, it's v6, v4 with a price premium, or v4 with CGNAT.
CGNAT sucks. Stuff blocks you because you get lumped in with other users. You can't take inbound connections. Average users don't know that, but they get annoyed with side effects. Not being able to play multiplayer stuff or it being slow/high latency because of no inbound connection. Having to do extra CAPTCHAs, being straight out blocked, etc...
Price and annoyance are absolutely things people want to avoid.
I guarantee you at some point, some ISP is going to realise they can market themselves as the gamer ISP and sell IPv6 as the option for pro gamers to ensure the lowest latency in their games. CGNAT will be the congested roads, IPv6 the open motorway. (To be clear, it obviously isn't that simple, but I'd put money on that's how they'll sell it.)
CGNAT sucks. Stuff blocks you because you get lumped in with other users. You can't take inbound connections. Average users don't know that, but they get annoyed with side effects. Not being able to play multiplayer stuff or it being slow/high latency because of no inbound connection. Having to do extra CAPTCHAs, being straight out blocked, etc...
Price and annoyance are absolutely things people want to avoid.
I guarantee you at some point, some ISP is going to realise they can market themselves as the gamer ISP and sell IPv6 as the option for pro gamers to ensure the lowest latency in their games. CGNAT will be the congested roads, IPv6 the open motorway. (To be clear, it obviously isn't that simple, but I'd put money on that's how they'll sell it.)
I agree that CGNAT sucks -- for the user. But users don't exactly have a ton of power here. And CGNAT is mostly fine for anyone but power users; I've never experienced being blocked or excessive CAPTCHAs when on a CGNATed cell network.
At previous gig already seen some isps in India that are ipv6 only
Setting a website to be available over IPv6 is relatively easy, yet we see:
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
;; QUESTION SECTION:
;news.ycombinator.com. IN AAAA
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
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.
In fact I am posting this comment over IPv6.
> hosts file
1986 wants a word.
1986 wants a word.
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.
I only mentioned hosts file because it is the easiest way to spoof the domain.
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.
> You have to add a CF IPv6 it to the hosts file.
That's worse, yeah? You do see how that's worse?
That's worse, yeah? You do see how that's worse?
Your comment has no useful information.
Put this in your /etc/hosts file and it should work (I don't know if it does as I don't have ipv6)
2a06:98c1:3120::5 news.ycombinator.com
2a06:98c1:3120::5 news.ycombinator.com
Can confirm, works like a charm!
Which is not useful information in this discussion.
Ok, but please don't respond to a bad comment (or one you feel is bad) by posting bad comments yourself. That only makes everything worse.
A better way to counter comments that don't contain useful information would be to add some useful information; or perhaps to post a question explaining what information is missing and asking for it.
https://news.ycombinator.com/newsguidelines.html
A better way to counter comments that don't contain useful information would be to add some useful information; or perhaps to post a question explaining what information is missing and asking for it.
https://news.ycombinator.com/newsguidelines.html
The fact anyone should think this is somehow acceptable state of art is obscene to me.
> 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!
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!
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).
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).
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.
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. [...]
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. [...]
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?
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?
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?
Every friends phone that wants to connect to my wifi needs manual setup?
That is a problem. To which the solution is IPv4?
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.
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.
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.
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.
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.
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.
Windows supports SLAAC+RDNSS, as long as you're running Windows 10 or newer.
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.
SLAAC is more than capable of sending DNS settings to devices. There's no manual configuration involved.
My post said to use DHCPv6 and RDNSS. Follow up claimed to use SLAAC instead.
SLAAC does not do DNS. Clear as day?
SLAAC does not do DNS. Clear as day?
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_...
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_...
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)
IPv6 router advertisement.
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.
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.
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.
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.
just a funny joke: what about using IBGP/OSPF for prefix delegation?
How does that work you have more than one ISP giving you an IPv6 prefix?
Oops. Meant to reply to parent. Now I can't delete the comment.
You can even do prefix delegation with SLAAC, although not really in a standard way
https://doc.riot-os.org/group__net__gnrc__ipv6__auto__subnet...
https://doc.riot-os.org/group__net__gnrc__ipv6__auto__subnet...
How does that work you have more than one ISP giving you an IPv6 prefix?
Bookmarking for future. I want to fill this out but don't have the info in front of me at the moment.
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.
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.
Thanks for the insightful primer!
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)
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)
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.
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.
>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?
Define "public/private". Your server has an IPv6 address that is globally identifiable. Your gateway may not necessarily route traffic to it.
>(in ipv4 world, you know that server is truly unreachable via public internet)
You don't know that, because a port forward rule on the gateway would route traffic to it after doing NAT. And if you made the effort to know that your gateway doesn't have such a rule, then you can equally make the effort to know that your gateway doesn't have a rule to forward traffic to the server's subnet.
Define "public/private". Your server has an IPv6 address that is globally identifiable. Your gateway may not necessarily route traffic to it.
>(in ipv4 world, you know that server is truly unreachable via public internet)
You don't know that, because a port forward rule on the gateway would route traffic to it after doing NAT. And if you made the effort to know that your gateway doesn't have such a rule, then you can equally make the effort to know that your gateway doesn't have a rule to forward traffic to the server's subnet.
[deleted]
Its pretty much the same.
The reason why NAT with ipv4 works is because routers by default do not forward any incoming traffic from outside to inside host unless there is an entry in the lookup table based on ports or based on port forwarding rules. The important thing to realize is that the local ip addresses (192.x, 10.x, e.t.c) don't actually matter - they can be replaced with any schema as far as router is concerned, and made public. And this is because the core routing logic of the entry table based on port doesn't change.
Ipv6 implementation doesn't really differ in this. With IPV6 routers can deny incoming traffic to the particular machine without a previous outgoing request connection, just like in the IPV4 NAT implementation. Receiving end knowing the full ip address of the machine (and even then, with privacy extensions, that ip address will no longer be valid in a day) doesn't really do anything against you security wise.
However, unlike IPV4, if you actually want to set up connectivity across networks and in fact enable routers to forward traffic based on the ip address, you don't have to deal with NAT translation, udp hole punching, e.t.c.
And furthermore, forcing harder endpoint security is a good thing. Routers are notoriously easy to exploit in a lot of cases, and once an attacker is on a router, NAT is worthless. Likewise for IoT devices that can be exploited through http based attacks against central servers also give you the same access.
The reason why NAT with ipv4 works is because routers by default do not forward any incoming traffic from outside to inside host unless there is an entry in the lookup table based on ports or based on port forwarding rules. The important thing to realize is that the local ip addresses (192.x, 10.x, e.t.c) don't actually matter - they can be replaced with any schema as far as router is concerned, and made public. And this is because the core routing logic of the entry table based on port doesn't change.
Ipv6 implementation doesn't really differ in this. With IPV6 routers can deny incoming traffic to the particular machine without a previous outgoing request connection, just like in the IPV4 NAT implementation. Receiving end knowing the full ip address of the machine (and even then, with privacy extensions, that ip address will no longer be valid in a day) doesn't really do anything against you security wise.
However, unlike IPV4, if you actually want to set up connectivity across networks and in fact enable routers to forward traffic based on the ip address, you don't have to deal with NAT translation, udp hole punching, e.t.c.
And furthermore, forcing harder endpoint security is a good thing. Routers are notoriously easy to exploit in a lot of cases, and once an attacker is on a router, NAT is worthless. Likewise for IoT devices that can be exploited through http based attacks against central servers also give you the same access.
> Is the general model of public/private subnet still valid?
You're getting replies that are tiptoeing around the truth, saying that the answer to this is basically 'yes' when it sure looks like the answer is firmly 'no.' My home IPv4 network isn't routable, it is a private network. If my IPv6 address is globally unique and addressable by someone across the world, my network is not private in the way that most people have come to understand the term. I'm just part of the public network but with a firewall to stop unwanted packets from reaching my local nodes.
You're getting replies that are tiptoeing around the truth, saying that the answer to this is basically 'yes' when it sure looks like the answer is firmly 'no.' My home IPv4 network isn't routable, it is a private network. If my IPv6 address is globally unique and addressable by someone across the world, my network is not private in the way that most people have come to understand the term. I'm just part of the public network but with a firewall to stop unwanted packets from reaching my local nodes.
> My home IPv4 network isn't routable, it is a private network.
An IPv6 network with a firewall configured to disallow incoming traffic isn't routable, it is a private network
> If my IPv6 address is globally unique and addressable by someone across the world, my network is not private in the way that most people have come to understand the term.
In what way? All NAT does is funnel traffic over one address (or more), that address is still exposed to the internet and it's your firewall that prevents that incoming traffic. If your firewall is compromised, then NAT isn't protecting you from anything, your network will absolutely be routable despite what you are suggesting. The assumptions you are making are part of the reason why NAT can be dangerous.
> I'm just part of the public network but with a firewall to stop unwanted packets from reaching my local nodes.
This is an oxymoron, you are either a part of the public network or you are not. The only thing that has changed is the semantics.
An IPv6 network with a firewall configured to disallow incoming traffic isn't routable, it is a private network
> If my IPv6 address is globally unique and addressable by someone across the world, my network is not private in the way that most people have come to understand the term.
In what way? All NAT does is funnel traffic over one address (or more), that address is still exposed to the internet and it's your firewall that prevents that incoming traffic. If your firewall is compromised, then NAT isn't protecting you from anything, your network will absolutely be routable despite what you are suggesting. The assumptions you are making are part of the reason why NAT can be dangerous.
> I'm just part of the public network but with a firewall to stop unwanted packets from reaching my local nodes.
This is an oxymoron, you are either a part of the public network or you are not. The only thing that has changed is the semantics.
> 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?
This is one thing that's actually been vastly improved in IPv6 (IMO), though I guess it is somewhat more complicated, it is standardized.
In the IPv4 model, your hosts get 'internal' addresses and some gateway device translates these addresses to/from the associated 'public' addresses as necessary. Behaviour when multiple addresses are assigned is undefined, and there are plenty of weird corner cases with internal hosts trying to hit the public addresses of forwarded services and such.
In the typical IPv6 model, your hosts (if they need to talk to the Internet) get a (or several) Globally Unique Address (GUA), which is routeable on the Internet. Optionally, hosts can also have a Unique Local Address (ULA) which is analogous to an RFC1918 address in IPv4. Because it's codified in the standard, hosts will choose the correct source address depending on the destination they want to talk to; a ULA address if the server is also ULA, and a GUA source will be chosen for talking to GUA addresses.
In a typical corporate network, you'd give hosts both classes of address, and your internal services run on ULA addressing. But in most residential or hosting environments, you'd just use GUA as there is no benefit to segregating things this way.
This is one thing that's actually been vastly improved in IPv6 (IMO), though I guess it is somewhat more complicated, it is standardized.
In the IPv4 model, your hosts get 'internal' addresses and some gateway device translates these addresses to/from the associated 'public' addresses as necessary. Behaviour when multiple addresses are assigned is undefined, and there are plenty of weird corner cases with internal hosts trying to hit the public addresses of forwarded services and such.
In the typical IPv6 model, your hosts (if they need to talk to the Internet) get a (or several) Globally Unique Address (GUA), which is routeable on the Internet. Optionally, hosts can also have a Unique Local Address (ULA) which is analogous to an RFC1918 address in IPv4. Because it's codified in the standard, hosts will choose the correct source address depending on the destination they want to talk to; a ULA address if the server is also ULA, and a GUA source will be chosen for talking to GUA addresses.
In a typical corporate network, you'd give hosts both classes of address, and your internal services run on ULA addressing. But in most residential or hosting environments, you'd just use GUA as there is no benefit to segregating things this way.
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.
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.
If you want failover-independent IPs you can keep using NAT, ie NPTv6, at the gateway level and not bother with giving public IPs to your LAN machines.
Have you implemented NPTv6 before? What routing product(s) have you implemented this with? Do you happen to have some documentation links handy?
In my experience, this capability is missing from most off-the-shelf solutions, and in the cases where it is available, the documentation of this feature is missing or incomplete.
In my experience, this capability is missing from most off-the-shelf solutions, and in the cases where it is available, the documentation of this feature is missing or incomplete.
That's possible, but my understanding is that NPTv6 is strongly discouraged. Part of the point of IPv6 is do away with NAT and the problems caused by it.
I was hoping there was a better way.
I was hoping there was a better way.
Yes, that is correct. But not having NAT is the same as having addresses that depend on the subnet prefix.
NPTv6 is different from IPv4 NAT and doesn't really have the same issues.
A different solution I've seen proposed for networks with multiple ISPs is to advertise both public prefixes to the network and let each client endpoint figure out which egress to use. This seems like a worse idea though.
The most official approach is to get your own public IPv6 prefix and work with your ISPs to BGP route that to you on both links. However, home and small business ISPs generally don't offer this.
A different solution I've seen proposed for networks with multiple ISPs is to advertise both public prefixes to the network and let each client endpoint figure out which egress to use. This seems like a worse idea though.
The most official approach is to get your own public IPv6 prefix and work with your ISPs to BGP route that to you on both links. However, home and small business ISPs generally don't offer this.
Use the GUA prefix from the main ISP. During failover, retract it and switch to the GUA prefix from the second ISP. Prefix translate any stragglers that don't switch to the new prefix for whatever reason.
For active/active you can distribute both prefixes, but you don't get much control over which network clients pick. You can do the same thing here though: NAT only the outbound connections that you specifically want to steer onto the other ISP.
This way you avoid most of the problems of NAT.
For active/active you can distribute both prefixes, but you don't get much control over which network clients pick. You can do the same thing here though: NAT only the outbound connections that you specifically want to steer onto the other ISP.
This way you avoid most of the problems of NAT.
You don’t have to be a large corporation to have your own IP space. Getting your own IP space assigned by an authority like ARIN and getting a BGP AS number is the way to go here. I think ARIN allocates out IPv6 space out for free or low cost. There are yearly maintenance fees involved but should still be affordable for a small business. If this is for home use, then yeah that would be overkill.
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?
> 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?
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
You only need two addresses:
- a global address
- a link-local address
Not clear. How do i reach a device in my local network? Via the optional internal address if my uplink is down and via my link-local address if my uplink is up?
Is the link-local address any good if i'm on wifi but want to ssh into a wired host in my home?
Are you getting my point yet?
Edit: actually I won't wait. The point is it's needlessly overcomplicated. It was done by a commitee that didn't even consider people could try to set up their home network. It's good enough for the enterprise (except cloud sellers it seems) and the plebs should just buy a router.
They also didn't consider someone would try to use the command line, since those addresses are not typable.
Is the link-local address any good if i'm on wifi but want to ssh into a wired host in my home?
Are you getting my point yet?
Edit: actually I won't wait. The point is it's needlessly overcomplicated. It was done by a commitee that didn't even consider people could try to set up their home network. It's good enough for the enterprise (except cloud sellers it seems) and the plebs should just buy a router.
They also didn't consider someone would try to use the command line, since those addresses are not typable.
> Is the link-local address any good if i'm on wifi but want to ssh into a wired host in my home?
Lets breath and think about this for a second, you want to know how to reach a device on your local network, your host has a "link-local" address. Could there be a connection here?
The answer is yes because it's in the name, it's literally in the name, why are you confused? What is over complicated about this?
Back when I was in college I did IPv6 compliance testing as a part time job. Me and random other freshman computer science + IT students were able to pick this up after a day or two of training (aka reading RFCs) with next to zero network experience. I really can't help but see your complaints about complexity as nothing but the whining of a child. (we also exclusively used the commandline)
Lets breath and think about this for a second, you want to know how to reach a device on your local network, your host has a "link-local" address. Could there be a connection here?
The answer is yes because it's in the name, it's literally in the name, why are you confused? What is over complicated about this?
Back when I was in college I did IPv6 compliance testing as a part time job. Me and random other freshman computer science + IT students were able to pick this up after a day or two of training (aka reading RFCs) with next to zero network experience. I really can't help but see your complaints about complexity as nothing but the whining of a child. (we also exclusively used the commandline)
> your host has a "link-local" address. Could there be a connection here?
Maybe. Or maybe not. It could apply only to hosts connected via the same switch? Or same AP? That's how i read link-local. It's obvious to you because you already know.
> see your complaints about complexity as nothing but the whining of a child
So point me to an overview of ipv6, enough to manually configure a small network, that is clear and complete. Not the RFCs please, I don't want to learn to configure an enterprise (or university) network.
Last time I searched for one there wasn't one.
Maybe. Or maybe not. It could apply only to hosts connected via the same switch? Or same AP? That's how i read link-local. It's obvious to you because you already know.
> see your complaints about complexity as nothing but the whining of a child
So point me to an overview of ipv6, enough to manually configure a small network, that is clear and complete. Not the RFCs please, I don't want to learn to configure an enterprise (or university) network.
Last time I searched for one there wasn't one.
Yes link-local is only local to the link (same broadcast domain).
But most home networks are bridged on layer 2 anyway.
IPv6 allows for a design where you don't have everything on the same broadcast domain but actually use subnets for e.g. the WiFi network. But since you still want to retain IPv4 compatibility, this is usually not an option in home networks.
> So point me to an overview of ipv6, enough to manually configure a small network
Just enable router advertisements on your router (likely already the case) to announce a /64 prefix that was derived from the prefix you got from your ISP. You also want to enable RDNSS so DNS server information is included with the router advertisement. (also usually the default)
Then enable SLAAC on your hosts (already the default) to automatically select an address based on the prefix from the router advertisement. A /64 is big enough that the router doesn't have to individually assign addresses. Hosts can just pick one and if they are polite, ask if it's already used by someone else (duplicate address detection).
Presto! You now have IPv6 connectivity.
But most home networks are bridged on layer 2 anyway.
IPv6 allows for a design where you don't have everything on the same broadcast domain but actually use subnets for e.g. the WiFi network. But since you still want to retain IPv4 compatibility, this is usually not an option in home networks.
> So point me to an overview of ipv6, enough to manually configure a small network
Just enable router advertisements on your router (likely already the case) to announce a /64 prefix that was derived from the prefix you got from your ISP. You also want to enable RDNSS so DNS server information is included with the router advertisement. (also usually the default)
Then enable SLAAC on your hosts (already the default) to automatically select an address based on the prefix from the router advertisement. A /64 is big enough that the router doesn't have to individually assign addresses. Hosts can just pick one and if they are polite, ask if it's already used by someone else (duplicate address detection).
Presto! You now have IPv6 connectivity.
> Just enable router advertisements on your router
Thats not “manually”. Thats clicking in the routers UI. My idea of manually is roll your own Linux.
Worked just fine for ipv4, looks like a full time job for 6.
Thats not “manually”. Thats clicking in the routers UI. My idea of manually is roll your own Linux.
Worked just fine for ipv4, looks like a full time job for 6.
Then install radvd to enable router advertisements.
I think you are a bit confused.
A global address is an address that is routable over the internet. You can reach it from anywhere as long as your firewall permits so.
A link-local address is never routed. It is only valid on a single network segment. You can use it if your uplink is down and you don't have multiple networks at home. It is usually derived from the MAC address of your NIC.
There are some special link-local multicast groups, ff02::1 is the 'all nodes' address. If you send something there it will be received by all hosts on the link.
ff02::2 is 'all routers' - this will be received by all routers on the link. There are more [0].
If you have multiple internal networks and want to reach hosts without an uplink, you can use the unique local address range fc00::/7
This functions just like 10.0.0.0/8 on IPv4 and is only routed within your site.
[0] https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
A global address is an address that is routable over the internet. You can reach it from anywhere as long as your firewall permits so.
A link-local address is never routed. It is only valid on a single network segment. You can use it if your uplink is down and you don't have multiple networks at home. It is usually derived from the MAC address of your NIC.
There are some special link-local multicast groups, ff02::1 is the 'all nodes' address. If you send something there it will be received by all hosts on the link.
ff02::2 is 'all routers' - this will be received by all routers on the link. There are more [0].
If you have multiple internal networks and want to reach hosts without an uplink, you can use the unique local address range fc00::/7
This functions just like 10.0.0.0/8 on IPv4 and is only routed within your site.
[0] https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
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.
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.
It is very normal for devices to have multiple IPv6 addresses. Pretty much every device will have at least two: a link-local address and a public address. When autoconfigured, some devices generate both a long-term and a temporary public address.
One thing I wish they had done with the much larger address space is make it easy for an individual to get their own block of IPv6 addresses. Letting enthusiasts experiment with their own address space seems like it would help with knowledge / adoption.
Big evil Comcast gives out a /60 to residential customers if you ask for it (via setting a DHCP option). That allows for 16 networks to work with.
DHCPv6 Prefix Delegation. If you're a business customer, you get a larger allocation seemingly depending on the size of your IPv4 static block. I've been given /56 and /54 from their business service. It's quite nice.
I’m a network engineer by trade and think that would be cool, but I don’t think it’s a great idea to have a bunch of amateurs all of a sudden participating in BGP for numerous reasons. It’s certainly possible for an individual to setup a LLC, get an allocation from ARIN + AS number, order a business ISP connection w/ BGP and get an adequate router. It’s a high barrier of entry and won’t be cheap. Making that easier will likely lead to more widespread BGP issues (intentional or unintentional), filling up router TCAMs with even more prefixes, etc.
There’s already communities out there for hobbyists to play with/learn BGP on private networks over VPN tunnels if you really want to.
There’s already communities out there for hobbyists to play with/learn BGP on private networks over VPN tunnels if you really want to.
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.
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.
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.
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.
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.
With all these limitations, why did you prefer IPv6 over IPv4?
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.
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.
> 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.
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.
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! :)
If anybody from Liwest (our local ISP) reads this - IPv6 would be really nice! :)
He.net needs a fixed non-CGNAT IPv4 address, with protocol 41 open, and this is quite difficult to get.
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.
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.
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.
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.
> 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".
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".
Pricing, fyi: https://docs.hetzner.com/general/others/ipv4-pricing/
Around €19.00 setup per IP.
Around €19.00 setup per IP.
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.
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.
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.
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.
As a comparison, I pay ~$1.60/ip/mo (no setup fee) for my IPs.
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.
> 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.
Well, that's ominous. Basically a promise that they will sell your data.
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.)
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.)
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.
Considering how many old, IPv4 based management and security tools are probably in use, it will be an exciting time.
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:
This can just go into your /etc/hosts:
2a01:4f8:c2c:123f:64::140.82.121.3 github.com www.github.comThat’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.
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.
And if any Github reps are reading this thread, put together a presence on IPv6. If Google can do it, so can Microsoft.
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:
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?
$ dig +short a icanhazip.com
104.18.115.97
104.18.114.97
$ curl -6 -k -H 'Host: icanhazip.com' https://[2001:67c:2960:6464::104.18.115.97]/
141.98.136.43
$ dig +short -x 141.98.136.43
de-fra2-nat641.level66.network.
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?
> 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.
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.
Ugh, I was under really looking forward to trying out NAT64 one day. Potential complications with DNSSEC never occurred to me. Thanks for the reality check.
Just rent a small vps somewhere with dual stack ipv6 and ipv4 and run Tayga on it to make your own NAT64 endpoint.
Luckily (or sadly) many clients still don't do any actual DNSSEC validation instead relying on the outdated mechanism of validating the records on the DNS server and flagging them as secure.
You can keep the level of protection most people get from their DNS servers by doing the same; validating DNSSEC before NAT64 before rewriting them and disabling additional validation on the clients if enabled.
This does require trust in the connection between your devices and your server, but if you were planning on altering the DNS records automatically anyway, this shouldn't be too much of an issue.
Another thing to keep in mind is that some (headless) browsers will switch to DoH automatically depending on your network configuration. To fix this, you can run a DoH server next to the NAT64 server quite easily and configure your devices to use that, or disable DoH entirely. As far as I know only Firefox is enabling DoH in some privacy unfriendly countries, so you'll probably be fine if you forget, but this is something to check if your browser starts having weird issues.
TL;DR it'll probably still work
You can keep the level of protection most people get from their DNS servers by doing the same; validating DNSSEC before NAT64 before rewriting them and disabling additional validation on the clients if enabled.
This does require trust in the connection between your devices and your server, but if you were planning on altering the DNS records automatically anyway, this shouldn't be too much of an issue.
Another thing to keep in mind is that some (headless) browsers will switch to DoH automatically depending on your network configuration. To fix this, you can run a DoH server next to the NAT64 server quite easily and configure your devices to use that, or disable DoH entirely. As far as I know only Firefox is enabling DoH in some privacy unfriendly countries, so you'll probably be fine if you forget, but this is something to check if your browser starts having weird issues.
TL;DR it'll probably still work
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.
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.
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!
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!
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.
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.
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.
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?
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...
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...
*) https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...
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)
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)
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.
And Chinese companies have bought all of the free space in places like Africa and are leasing them out.
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.
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...
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...
Heh, yeah, I opened that issue. Nathan is awesome for maintaining that kernel.
Haha, I didn't even notice. I should clean my glasses!
got bitten by this recently. Another nail in the Microsoft Windows' coffin. It is such a fundamental thing and the fact that the issue has been open for ~2years is nothing short of pure shame.
> 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.
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.
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.
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.
There's probably a ddos service in front of the public facing commercial service that isn't there on the government service.
This seems to be the github ticket / request for IPv6:
https://github.com/community/community/discussions/10539
Apparently github are working on it as of Oct 2022 ... https://twitter.com/AS36459/status/1582728252199964672
https://github.com/community/community/discussions/10539
Apparently github are working on it as of Oct 2022 ... https://twitter.com/AS36459/status/1582728252199964672
It's 2022 and I've never yet seen an IPv6-capable internet connection at any home I've lived in, office I've worked at, coffee shop or library whose network I've used. And I've lived in a lot of places
Phones have it. But when I connect my computers via my phone's hotspot, the computers only get IPv4.
My data SIM at home enables IPv6 when used in a phone. But when installed in my 4G router, same contract, same provider, there is no IPv6 despite the router supporting it. That is, supporting in theory. Since I've never seen it enabled, I can't say if it works.
My bare metal servers have IPv6. But my cloud VMs and containers only get IPv4.
The last major network protocol I worked with, a P2P mesh protocol that needs to pass around IP addresses, has IPv6 on the todo list. Last I saw, earlier this year, there was a debate about whether it was worth adding or not. At the moment it's defaulting to no, even though I've seen a few IPv6 addresses attempt to join and be rejected
I can add IPv6 tunnels (VPNs and such) wherever I want, if I want to test software. But I could do that 20 years ago. It feels a bit artifical, not having the real thing.
My current work has a VPN we must use to access work dev servers. Obviously that doesn't use IPv6.
Forget about IPv6-"only", I'm still yet to see much IPv6 at all (except on phones).
Phones have it. But when I connect my computers via my phone's hotspot, the computers only get IPv4.
My data SIM at home enables IPv6 when used in a phone. But when installed in my 4G router, same contract, same provider, there is no IPv6 despite the router supporting it. That is, supporting in theory. Since I've never seen it enabled, I can't say if it works.
My bare metal servers have IPv6. But my cloud VMs and containers only get IPv4.
The last major network protocol I worked with, a P2P mesh protocol that needs to pass around IP addresses, has IPv6 on the todo list. Last I saw, earlier this year, there was a debate about whether it was worth adding or not. At the moment it's defaulting to no, even though I've seen a few IPv6 addresses attempt to join and be rejected
I can add IPv6 tunnels (VPNs and such) wherever I want, if I want to test software. But I could do that 20 years ago. It feels a bit artifical, not having the real thing.
My current work has a VPN we must use to access work dev servers. Obviously that doesn't use IPv6.
Forget about IPv6-"only", I'm still yet to see much IPv6 at all (except on phones).
My experience is quite different from yours:
- my ISP has offered IPv6 /64 delegations for over 5 years now.
- One cloud provider I use gives a discount for VMs with no IPv4 address, the other has ipv6 addresses.
- my ISP has offered IPv6 /64 delegations for over 5 years now.
- One cloud provider I use gives a discount for VMs with no IPv4 address, the other has ipv6 addresses.
I've had IPv6 at my home for at least 10 years I would say.
My parents do as well.
I was recently surprised that ssh to my dual stack private server didn't connect at work. It turned out I had set up the config file as V6 only.
Location: Southern Germany.
My parents do as well.
I was recently surprised that ssh to my dual stack private server didn't connect at work. It turned out I had set up the config file as V6 only.
Location: Southern Germany.
The biggest problem remains cloud and CDN companies with poor to nonexistent IPv6 support. Most ISPs, especially on mobile, have it now or are adding it very soon.
I've wondered whether some might be dragging their feet because they see an advantage in IP address scarcity to sell cloud gateways, CDNs, and other middle box type services. But the most likely explanation remains that not enough customers are asking for it so it's not the highest priority.
I happen to know that Google Cloud started moving on IPv6 seriously only when they lost some big telecom customers to AWS because they didn't have it.
I've wondered whether some might be dragging their feet because they see an advantage in IP address scarcity to sell cloud gateways, CDNs, and other middle box type services. But the most likely explanation remains that not enough customers are asking for it so it's not the highest priority.
I happen to know that Google Cloud started moving on IPv6 seriously only when they lost some big telecom customers to AWS because they didn't have it.
> Most ISPs, especially on mobile, have it now or are adding it very soon.
Except Charter/Spectrum in the US.
Except Charter/Spectrum in the US.
Maybe it's because we're in the former Time Warner Cable/Road Runner part of Spectrum's territory, but we've had IPv6 for years now.
I'm in original Charter territory and have v6
Sure, as long as you're ok with having a constantly changing prefix. At least that's how it is for home connections and it nullifies nearly all the benefits of v6.
You don't need a fixed prefix to get most of the benefits of v6.
DNS is a thing.
DNS is a thing.
I can do dynamic DNS on v4 too.
It also complicates firewalls, because now they need to deal with the prefix switching on them and updating their rules to match. As I recall this was only recently added to pfSense.
It also complicates firewalls, because now they need to deal with the prefix switching on them and updating their rules to match. As I recall this was only recently added to pfSense.
https://www.spectrum.net/support/internet/ipv6-faq:
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
Very curious what "majority of Spectrum’s footprint" means in this context.
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
Very curious what "majority of Spectrum’s footprint" means in this context.
Telia in Finland refuses to enable IPv6 for mobile. I'm sure there's no lack of providers doing the same.
I'm on Spectrum (via TW acquisition) and have had IPv6 for around a decade, if not longer.
I have it on Spectrum in Ohio. It may vary by market.
I've never been on a non-mobile connection with IPv6. It's not a thing in Norway.
is the 22+% ipv6 adoption in .no all mobile? (honest question - i don't know)
https://stats.labs.apnic.net/ipv6/NO
https://stats.labs.apnic.net/ipv6/NO
Hetzner should provide free CGNAT IPv4 Addresses (IPv4 Gateway) for IPv6-Only VMs
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.
Communal ipv4 is very problematic for certain services due to bad neighbors causing it to be blacklisted.
Not for hosting services, but for things like accessing Github.
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.
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!
Actually, that's not even that bad a way to get IPv4 on any IPv6-only host: route it all through TOR!
this sounds like a valid argument for deploying ipv6 wherever you can, tbqh
cgnat is only going to get MORE common, globally
cgnat is only going to get MORE common, globally
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.)
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.
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.
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.
IP geolocation is a bad idea for lots of reasons. Unfortunately it's also a reality of how services work.
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
& to be clear, that is CRAZY growth!
edit: that's traffic to monitoring resources, not in general, sorry /facepalm
[deleted]
IP-based geolocation is fundamentally broken. Making it visibly broken in more cases is good.
All our internal systems use IPv6. Internal traffic is almost totally IPv6. Traffic to/from the public Internet on our networks is 30-40% IPv6.
We just started treating it like a first class citizen and worked through the learning experiences, and it quit seeming like such a big deal.
IPv6-only, when interfacing with the public internet or the public cloud (which we don't much use), does seem like a challenge, but only due to external factors.
It's no more difficult to get a handle on it than any other technology, at which point it pretty much becomes routine.
We just started treating it like a first class citizen and worked through the learning experiences, and it quit seeming like such a big deal.
IPv6-only, when interfacing with the public internet or the public cloud (which we don't much use), does seem like a challenge, but only due to external factors.
It's no more difficult to get a handle on it than any other technology, at which point it pretty much becomes routine.
Yearly reminder that Hacker News still is IPv4 only.
We enable IPv6 on CDNs e.g. Cloudfront/Cloudflare and load balancers, never had an issue and I do see IPv6 traffic hitting them. Apart from that it doesn't see much use. Personally I don't use IPv6 since I've never had and ISP with at home or on mobile living in the UK.
Every couple of months, I enable dual-stack on my home network, to see if it works. And inevitably I get a terrible experience. Some sites fail to load, others load after a huge delay (presumably because we're waiting for an ip6 timeout of some sort) and some things just don't work right. I'm always too lazy to figure out why these things don't work, but I turn off dual stack and everything works fine again.
I'm a network engineer and I can't make ip6 work seamlessly in my house -- what chance do regular consumers have?
I'm a network engineer and I can't make ip6 work seamlessly in my house -- what chance do regular consumers have?
Your experience, and your home network, is absolutely exceptional then.
> what chance do regular consumers have?
Clearly, quite a good deal, since dual-stack is the default. Nearly half the Internet[1] is using IPv6 using dual-stack just fine, and the other half is using dual stack with a LL v6 because their ISP sucks.
Like many others, my laptop routinely travels, and visits a variety of dual-stack and IPv4 only networks, just as VRBO rentals, café WiFi, airports, etc. I've never had an issue connecting to those networks that case caused by dual-stack. Far more often do some form of captive portals (from misconfigured DHCP servers to MitMs wreaking havoc) cause more failures.
> others load after a huge delay (presumably because we're waiting for an ip6 timeout of some sort)
This isn't how v6 works. It isn't impossible that there's some site out there somewhere with a broken AAAA record, but again, it is the exception given the amount of Internet-connected dual stacks. Most v4-only sites aren't going to have a AAAA.
[1]: https://www.google.com/intl/en/ipv6/statistics.html
> what chance do regular consumers have?
Clearly, quite a good deal, since dual-stack is the default. Nearly half the Internet[1] is using IPv6 using dual-stack just fine, and the other half is using dual stack with a LL v6 because their ISP sucks.
Like many others, my laptop routinely travels, and visits a variety of dual-stack and IPv4 only networks, just as VRBO rentals, café WiFi, airports, etc. I've never had an issue connecting to those networks that case caused by dual-stack. Far more often do some form of captive portals (from misconfigured DHCP servers to MitMs wreaking havoc) cause more failures.
> others load after a huge delay (presumably because we're waiting for an ip6 timeout of some sort)
This isn't how v6 works. It isn't impossible that there's some site out there somewhere with a broken AAAA record, but again, it is the exception given the amount of Internet-connected dual stacks. Most v4-only sites aren't going to have a AAAA.
[1]: https://www.google.com/intl/en/ipv6/statistics.html
> Your experience, and your home network, is absolutely exceptional then.
Actually, it's not. Just check google for "ipv6 slow internet" and check it's not exceptional. It's normal because many sites/games/software isn't that tested/optimized for IPv6.
Even the basic step of having setup Google/Cloudflare DNS for you forget that you have not set it up for IPv6 might make your experience of IPv6 really bad.
Actually, it's not. Just check google for "ipv6 slow internet" and check it's not exceptional. It's normal because many sites/games/software isn't that tested/optimized for IPv6.
Even the basic step of having setup Google/Cloudflare DNS for you forget that you have not set it up for IPv6 might make your experience of IPv6 really bad.
That sounds like pMTUd failure. The easiest check for that would be to set your client machine's MTU to 1280 and see if it fixes it.
Most people work around that problem with TCP MSS clamping in v4. Sometimes they don't apply the workaround for v6, then blame v6 for the problems.
Most people work around that problem with TCP MSS clamping in v4. Sometimes they don't apply the workaround for v6, then blame v6 for the problems.
I think regular consumers have more ordinary setups and those work totally fine in a lot of places.
That aside, out of interest I blocked outgoing port 80, now that is fun. So many things break in weird and bizarre ways. It's also interesting to see how many things are potentially vulnerable to eavesdropping.
That aside, out of interest I blocked outgoing port 80, now that is fun. So many things break in weird and bizarre ways. It's also interesting to see how many things are potentially vulnerable to eavesdropping.
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.
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.
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.
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.
All of those things should be able to cope with a 1-minute loss of connectivity already. To do otherwise would be astonishingly negligent.
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.
That's a novel tactic, love it!
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.
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.
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.
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.
>If they wanted to prevent inbound connections then all they would need to do is firewall them.
Note that this already happens to an extent. Some ISPs try to protect their users from UPNP attacks and block certain inbound ports. On the outbound side, many ISPs ban port 25. ISPs could have easily claimed security and limit inbound connections far more - but the reasons for these limits are apparently money+security and not a secret government mandate, so they didn't limit everything.
Note that this already happens to an extent. Some ISPs try to protect their users from UPNP attacks and block certain inbound ports. On the outbound side, many ISPs ban port 25. ISPs could have easily claimed security and limit inbound connections far more - but the reasons for these limits are apparently money+security and not a secret government mandate, so they didn't limit everything.
Can you provide a source for that government claim?
- Comment sections getting closed for anonymous replies almost everywhere over the course of the last 15 years
- Undisguised surveillance becoming the new normal
- Confinement of all communication to a handful of platforms
- Snowden's disclosures
- Huge datacenters built by NSA to tap into telecom
- Crackdown on p2p sharing
- Push for The Cloud
- Closure of Lavabit and other independent email providers
- Rabid push for phone-based 2fa
- Ongoing merger and conglomeration of everything into a venture-fund-owned megacorporation invisible only for those who call these obvious practices "conspiracy theories" with religious zeal
- Failure of everything initially claimed to be decentrallized to live up the name, including blockchains, IPFS etc
These and many other similar issues combined don't quite make for an illusion that the govenments are willing to allow us to communicate freely via a greater number of tapping and datamining points than they could possibly manage.
Now burn this heretic!
- Undisguised surveillance becoming the new normal
- Confinement of all communication to a handful of platforms
- Snowden's disclosures
- Huge datacenters built by NSA to tap into telecom
- Crackdown on p2p sharing
- Push for The Cloud
- Closure of Lavabit and other independent email providers
- Rabid push for phone-based 2fa
- Ongoing merger and conglomeration of everything into a venture-fund-owned megacorporation invisible only for those who call these obvious practices "conspiracy theories" with religious zeal
- Failure of everything initially claimed to be decentrallized to live up the name, including blockchains, IPFS etc
These and many other similar issues combined don't quite make for an illusion that the govenments are willing to allow us to communicate freely via a greater number of tapping and datamining points than they could possibly manage.
Now burn this heretic!
Sigh, I need to stop engaging with obvious tinfoil hats.
Oh boy, all my points are definitely beaten with this single one of ineffable precision and efficiency!
What you need is to learn to reinforce your opinion with counterarguments instead of allegorically admitting your inability to formulate them.
What you need is to learn to reinforce your opinion with counterarguments instead of allegorically admitting your inability to formulate them.
Nope! You can do better and you should if you want a real discussion.
Have a good one, mate.
Have a good one, mate.
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.
I expected that someone would plant this prefabricated gag phrase of "conspiracy theory" as an argument, thanks for confirming my gut feeling.
Your theory is contrary to what happened in reality: It was governments mandating router and OS support of IPv6 that jump-started protocol support. Had the mandate not existed, MS would not have added IPv6 as early as Win XP (in preview during Win 2000).
I've downvoted you for being combative, wide-sweepingly conspiratorial, off-topic, and thinking everyone who disagrees with you is out to get you.
Count yourself downvoted for disguising your own combativeness as didactic neutrality, not being pinpoint-factual and on-topic and for actually being out to get me with your downvote for disagreeing with people who you think were right.
I think US cloud companies got a huge boost when ISPs in the US handicapped users with NAT and asymmetric download speeds. You basically are forced to use a middle-man to serve to the internet.
With IPV6, anyone anywhere can be a host again and p2p applications have a chance to be competitive with Cloud SaaS offerings.
With IPV6, anyone anywhere can be a host again and p2p applications have a chance to be competitive with Cloud SaaS offerings.
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.
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.
> 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.
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.
The legacy IP at their edge is what I meant by terminating IPv4+IPv6 at the load balancers.
The tricky part is that almost all datacenters today need to talk out to other datacenters. Not all of them use IPv6 which means they will still need some way to speak IPv4 until all their 3rd party data processors are also doing IPv6 and for Facebook I happen to know that is a lot of 3rd parties. If they are truly IPv6-only in the datacenter then they would have to forward-proxy all outbound connections through something with an IPv4 address on the edge as well and that can not go away until all their partners and vendors are also purely IPv6.
The tricky part is that almost all datacenters today need to talk out to other datacenters. Not all of them use IPv6 which means they will still need some way to speak IPv4 until all their 3rd party data processors are also doing IPv6 and for Facebook I happen to know that is a lot of 3rd parties. If they are truly IPv6-only in the datacenter then they would have to forward-proxy all outbound connections through something with an IPv4 address on the edge as well and that can not go away until all their partners and vendors are also purely IPv6.
You can do that with NAT64, which you can run as a service in your datacenter rather than needing to deal with v4 throughout it. (In fact it doesn't have to be run in your datacenter -- it could be outsourced to somebody else, which will probably make sense eventually as v4 use dwindles.)
Unfortunately this is true. I've been running IPv4/IPv6 dual stack since 2014 for most of my infrastructure and since 2016 for all of it. The company I work for now is a major AWS customer, and we managed to pressure them into enabling IPv6 for Global Accelerator, and have just recently launched full IPv4/IPv6 dual stack for our endpoints... in 2022.
I think that the primary root cause of this is economics, if we're being perfectly blunt. The countries/regions of the world that got most of the IPv4 address space are also the places where most of the money is, so businesses, especially businesses serving businesses, are not heavily driven to support IPv6 other than as a "checkbox", because their customers all have IPv4 and are not asking for it. Meanwhile in APJC/BRIC IPv6 is the dominant mode of connectivity, and many major businesses are IPv6 only or IPv6 primary w/ IPv4 CGNAT. When you enter into this market, IPv6 quickly becomes a requirement, however in EU/NA, it's just not required.
I am seeing this shift though, because of mobile-first consumer-oriented businesses. Globally, pretty much all mobile providers issue only IPv6 addresses that are globally routed to their subscriber devices and utilize CGNAT to get IPv4 connectivity. This is true even in North America. The problem is that CGNAT is /really/ good as far as "working", so from the perspective of endpoints they communicate with, it may not be obvious that IPv6 would actually benefit them. For mobile applications, IPv6 has a significant performance advantage because it skips CGNAT, and so at least in that space businesses are doing more to support it directly.
I think that the primary root cause of this is economics, if we're being perfectly blunt. The countries/regions of the world that got most of the IPv4 address space are also the places where most of the money is, so businesses, especially businesses serving businesses, are not heavily driven to support IPv6 other than as a "checkbox", because their customers all have IPv4 and are not asking for it. Meanwhile in APJC/BRIC IPv6 is the dominant mode of connectivity, and many major businesses are IPv6 only or IPv6 primary w/ IPv4 CGNAT. When you enter into this market, IPv6 quickly becomes a requirement, however in EU/NA, it's just not required.
I am seeing this shift though, because of mobile-first consumer-oriented businesses. Globally, pretty much all mobile providers issue only IPv6 addresses that are globally routed to their subscriber devices and utilize CGNAT to get IPv4 connectivity. This is true even in North America. The problem is that CGNAT is /really/ good as far as "working", so from the perspective of endpoints they communicate with, it may not be obvious that IPv6 would actually benefit them. For mobile applications, IPv6 has a significant performance advantage because it skips CGNAT, and so at least in that space businesses are doing more to support it directly.
That's really cool that global accelerator got support, I was about to bash AWS. It's one of those things when trying to optimize product market fit and quick launches, that we needed global accelerator, but not IPv6 on a project I worked on.
So when major AWS / cloud services don't have the ability to just turn it on, is one part of the chicken and egg that contributes to the lack of adoption. Thanks for pressuring for that support.
So when major AWS / cloud services don't have the ability to just turn it on, is one part of the chicken and egg that contributes to the lack of adoption. Thanks for pressuring for that support.
Yep, there are unfortunately some other AWS services that still don't support IPv6, but at least with Global Accelerator and ALB support, we can hide that from end-customers that require IPv6 endpoints.
https://aws.amazon.com/blogs/networking-and-content-delivery...
ALB/ELB/NLB support for IPv6 is fairly recent as well, November 2021: https://aws.amazon.com/about-aws/whats-new/2021/11/applicati...
https://aws.amazon.com/blogs/networking-and-content-delivery...
ALB/ELB/NLB support for IPv6 is fairly recent as well, November 2021: https://aws.amazon.com/about-aws/whats-new/2021/11/applicati...
AWS have a documentation page which display everything that supports IPv6 in a single place. They are definitely working on supporting IPv6 only.
https://docs.aws.amazon.com/general/latest/gr/aws-ipv6-suppo...
https://docs.aws.amazon.com/general/latest/gr/aws-ipv6-suppo...
Sounds like IPv6 isn't broken, GitHub and Ubuntu and BitBucket are broken.
If the question is, "Why isn't IPv6 the most prominent protocol and v4 a legacy thing?" the answer is NAT and RFC1918 addresses. And NATs within NATs within NATs. The only "real" v4 address you need is for your publicly facing servers.
There has been no incentive to go to v6.
There has been no incentive to go to v6.
The industry doesn't give a shit. Everyone follows the path of least resistance, which is: don't change, apply crappy hacks, try to prevent any work you don't want to do. IPv6 was never going to be adopted quickly because nobody was forced to.
I think IPv6 internal-only is viable with some kind of NAT64 setup, maybe not at scale though. What is everyone using for NAT64?
afaik jool is the currently-recommended foss nat64 (since tayga is apparently unmaintained)
alot of commercial vendors have mature nat64 implementations tho
alot of commercial vendors have mature nat64 implementations tho
Jool also has the best documentation I've ever seen. It does not only explain how to configure the software but it also has illustrated explanations that do a far better job than the actual RFCs in describing the motivation and use cases of the many protocols it supports.
& for "at scale" - how about 100,000,000 users?
https://twitter.com/iPv4depletion/status/1584376525427978240
https://twitter.com/iPv4depletion/status/1584376525427978240
Would use OpenBSD + unbound to get NAT64 + DNS64.
I'd prefer a dual-stack setup with RFC1918 IPv4 internally + a NAT44 gateway and IPv6 "just" on top.
Drawback: if you find yourself to have to do a lot of firewalling it essentially doubles your work.
Given how long it's been since IPv6 was released, I'm surprised that there hasn't been a big proposal for an IPv7 that would fix the alleged problems with IPv6. Has anyone worked on anything like that?
The "alleged problems" are not with IPv6. They're with not-IPv4.
It's more the case that the panic around IP space exhaustion turned out to be unfounded - or at least we've been able to work around it for much much longer than expected. Back in 1994 the IETF predicted that the internet would stop working in 3-7 years. Almost 30 years later we're still going. So there's no sense of urgency to invent something better.
For the record I also believe that v6 will be abandoned and eventually replaced, most likely with a backwards-compatible protocol. Or something that provides a more compelling reason to upgrade than v6, which basically has nothing. Or at least nothing that people want - the lack of NAT is really an anti-feature.
The history of tech is littered with "standards" that never achieved critical mass.
For the record I also believe that v6 will be abandoned and eventually replaced, most likely with a backwards-compatible protocol. Or something that provides a more compelling reason to upgrade than v6, which basically has nothing. Or at least nothing that people want - the lack of NAT is really an anti-feature.
The history of tech is littered with "standards" that never achieved critical mass.
v6 already is backwards compatible. Pretty much every form of backwards compatibility that is possible with v4 is available in v6.
The problem is that v4 isn't forwards compatible with larger address spaces, and that's a problem that any protocol with >32-bit addresses faces, because it's a problem with the design of v4, not the design of the new protocol. Replacing v6 will not help.
> the lack of NAT is really an anti-feature.
v6 doesn't lack NAT -- what it lacks is any sane reason to use NAT. That's a good thing.
The problem is that v4 isn't forwards compatible with larger address spaces, and that's a problem that any protocol with >32-bit addresses faces, because it's a problem with the design of v4, not the design of the new protocol. Replacing v6 will not help.
> the lack of NAT is really an anti-feature.
v6 doesn't lack NAT -- what it lacks is any sane reason to use NAT. That's a good thing.
Maybe IPv6 should have had a stronger backwards compatibility story. Maybe not IPv4+ as described in a sibling comment, but something that lets me easily be compatible with IPv4 without having to do the whole setup again.
Having to actively manage 2 totally separate systems isn't economical at all, so it's no surprise that so few bother, myself included. I totally want to "switch to" (-> add) IPv6, but just can't justify the cost. There's nothing in it for me here, I would only lose.
Having to actively manage 2 totally separate systems isn't economical at all, so it's no surprise that so few bother, myself included. I totally want to "switch to" (-> add) IPv6, but just can't justify the cost. There's nothing in it for me here, I would only lose.
I just like to call out Starlink for not supporting ipv6, massive headache as calls to various ipv4 only sites fail in python then you need to set a timeout in your request to trick python into falling back to ipv4, also no public adresses on Starlink made self hosting https://text-generator.io a pain but CloudFlared tunnels helped
Aside about AI text generation: Rule 34 will be tested when it comes to generating adulting text content.
Starlink are working on it; they've turned on v6 in lots of places over the past month or so.
Although you shouldn't need to do any special handling for v4-only sites on v4-only networks. Your DNS results should be sorted to put v4 at the top in that case, so it should be tried first.
Although you shouldn't need to do any special handling for v4-only sites on v4-only networks. Your DNS results should be sorted to put v4 at the top in that case, so it should be tried first.
[deleted]
I see this just as repetition of the 32 bit vs 64 bit operating systems. Why would anyone want to use 64 bit operating system? Instructions are longer, it requires more cache, RAM, disk space and so on, making performance worse. Nobody actually wants 64 bit systems. Endless problems with drivers, programs, etc.
The furthest I ever got was creating firewall rules for ipv6 that mostly corresponded to our ipv4 rules. These were never used, but they were tested and ready. This was around "ipv6 day" (2014? 2015?) I've thought about it on and off since then and wondered whether I should be doing more with ipv6, but haven't actually taken any action in that direction.
I wonder if there's a relatively simple solution to at least most of the OPs list, all having to do with outgoing ipv6 requests, which would be proxying such (or all) requests through another computer on the network that has both ipv4 and ipv6 interfaces. Maybe that is an oversimplification.
Anyway, ipv4 definitely has a problem, and something is going to have to be done eventually.
Edit regarding World IPv6 day. I must be thinking of June 6, 2012: "This time, it's for real."
I wonder if there's a relatively simple solution to at least most of the OPs list, all having to do with outgoing ipv6 requests, which would be proxying such (or all) requests through another computer on the network that has both ipv4 and ipv6 interfaces. Maybe that is an oversimplification.
Anyway, ipv4 definitely has a problem, and something is going to have to be done eventually.
Edit regarding World IPv6 day. I must be thinking of June 6, 2012: "This time, it's for real."
> Edit regarding World IPv6 day. I must be thinking of June 6, 2012: "This time, it's for real."
world ipv6 day (24 hours) was in 2011.
world ipv6 launch (turn it on & leave it on) was in 2012.
(ppl mix the two up all the time, understandably!)
world ipv6 day (24 hours) was in 2011.
world ipv6 launch (turn it on & leave it on) was in 2012.
(ppl mix the two up all the time, understandably!)
> I wonder if there's a relatively simple solution to at least most of the OPs list, all having to do with outgoing ipv6 requests, which would be proxying such (or all) requests through another computer on the network that has both ipv4 and ipv6 interfaces. Maybe that is an oversimplification.
If you have an IPv4+IPv6 capable server around, you can set it up yourself if your ISP hasn't made a proxy available. There are various NAT64 implementations you can use; running them and setting up a DNS64 server is all you need to make such a feature available. You'd probably also want to add a firewall/whitelist to prevent other abusing your NAT64 gateway, though.
If you have an IPv4+IPv6 capable server around, you can set it up yourself if your ISP hasn't made a proxy available. There are various NAT64 implementations you can use; running them and setting up a DNS64 server is all you need to make such a feature available. You'd probably also want to add a firewall/whitelist to prevent other abusing your NAT64 gateway, though.
Totally viable.. Been IPv6-only since Fall 2014
https://www.internetsociety.org/blog/2014/06/facebook-moving...
It's unlikely that IPv6 will be deployed widely for a few reasons. First, many companies and organizations have already invested heavily in IPv4 infrastructure, so it would be costly and time-consuming for them to switch to IPv6. Additionally, IPv4 and IPv6 are not interoperable, which means that devices using one protocol cannot communicate with devices using the other. Finally, there are still a large number of available IPv4 addresses, so there is no immediate need to switch to IPv6. Until these issues are addressed, it's unlikely that IPv6 will be widely deployed.
Please, no ChatGPT in the comment section.
One interesting thing is the asymmetry making it slower for all those backend services to move, as opposed to, say, a brand new ISP.
Cloud/hosting services only need one IPv4 per machine, making them relatively cheap, and easy to include in pricing. ISPs need one IPv4 per customer, or resort to CGNAT or IPv4-sharing. This often means that customers might have better IPv6 than IPv4 performance. All of this does not apply to oldest ISPs that all have a war-chest of IPv4 they got for cheap (free).
Where I'm getting at is that the usecase you're testing is basically worst-case scenario. Fun that Hetzner does not even have AAAA records for their API. Do they have at least RFC1918 (private) IPv4 addresses ?
Cloud/hosting services only need one IPv4 per machine, making them relatively cheap, and easy to include in pricing. ISPs need one IPv4 per customer, or resort to CGNAT or IPv4-sharing. This often means that customers might have better IPv6 than IPv4 performance. All of this does not apply to oldest ISPs that all have a war-chest of IPv4 they got for cheap (free).
Where I'm getting at is that the usecase you're testing is basically worst-case scenario. Fun that Hetzner does not even have AAAA records for their API. Do they have at least RFC1918 (private) IPv4 addresses ?
i for one am also extremely frustrated with the state of ipv6
some time ago i tried to selfhost a personal website and run into all kinds of problems, most frustrating being
- my website not opening when having only AAAA record set (ended up using v4-frontend.netiter.com as a proxy)
- my linux box not handling the ipv6 prefix broadcast from my router and binding to some random address
the latter thing was main reason for frustration as i could find any information how to diagnose and all the message boards/ chat rooms just told me to install random stuff in hope it will then magically work. (i know its a misconfiguration on my linux machine as my windows 10 one can host the website no problem)
some time ago i tried to selfhost a personal website and run into all kinds of problems, most frustrating being
- my website not opening when having only AAAA record set (ended up using v4-frontend.netiter.com as a proxy)
- my linux box not handling the ipv6 prefix broadcast from my router and binding to some random address
the latter thing was main reason for frustration as i could find any information how to diagnose and all the message boards/ chat rooms just told me to install random stuff in hope it will then magically work. (i know its a misconfiguration on my linux machine as my windows 10 one can host the website no problem)
Various software vendors who dont support IPv6 and render IPv6 only setups without any kind of tunneling useless. And for the worst part play it down with stupid reasons in 202x. My favs "Why you need IPv6, just use 6to4 tunnels", "what do you mean IPv6 only?", "We dont have the resources", "It will take some time die to major changes in the software" - jesus...
I tried running IPv6 only with one machine (VPS in own hypervisor) but gave up after 2-3 hours of yak shaving and quickfixing things that should just work out, official Ubuntu repos not speaking v6 was one of them.
I tried running IPv6 only with one machine (VPS in own hypervisor) but gave up after 2-3 hours of yak shaving and quickfixing things that should just work out, official Ubuntu repos not speaking v6 was one of 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.
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.
If you're on Fios, there's an issue between checksum offloading on Intel NICs and the ONTs that Fios uses. The workaround is to disable checksum offloading.
If not, perhaps you forgot to apply TCP MSS clamping on v6. (An easy test for this is to set the MTU on your client machine to 1280.)
If not, perhaps you forgot to apply TCP MSS clamping on v6. (An easy test for this is to set the MTU on your client machine to 1280.)
> The GitHub API and its code load endpoints are not reachable via IPv6
Should it matter that GitHub or whatever doesn't support IPv6? I understood that it is possible to bridge the divide through an IPv6<->IPv4 gateway. IPv6 is designed to incorporate the IPv4 32 bit address space as a segment of the IPv6 address space and automatically translating between the two is relatively straightforward.
At least that what I believe. The next time someone asks me about supporting IPv6 will be the first, so I've been able to avoid the matter for a couple decades now.
Should it matter that GitHub or whatever doesn't support IPv6? I understood that it is possible to bridge the divide through an IPv6<->IPv4 gateway. IPv6 is designed to incorporate the IPv4 32 bit address space as a segment of the IPv6 address space and automatically translating between the two is relatively straightforward.
At least that what I believe. The next time someone asks me about supporting IPv6 will be the first, so I've been able to avoid the matter for a couple decades now.
That's NAT64. It's something that Hetzner could and should be providing for their customers, but as far as I can see they aren't.
Well ok... the problem stops right there then. Why would anyone expect -- given the low adoption of IPv6 -- IPv6 sans NAT64 to be workable? Why even bother without it?
I don't imagine it would be hard to locate any number of IPv6 zealots proselytizing a NAT64-less world, but here we have someone that made a legitimate effort to apply IPv6 and failed because it wasn't there. One fewer potential convert added to the pile...
I don't imagine it would be hard to locate any number of IPv6 zealots proselytizing a NAT64-less world, but here we have someone that made a legitimate effort to apply IPv6 and failed because it wasn't there. One fewer potential convert added to the pile...
It's workable if all of the machines you're going to talk to have v6, which is doable. Or you can run your own NAT64.
It would also be very easy to suggest that maybe Hetzner want to encourage people to keep paying for v4.
It would also be very easy to suggest that maybe Hetzner want to encourage people to keep paying for v4.
[deleted]
I think it's the format of the numbers that's not user-friendly enough. They can be too long to remember and my first thought is that there should be a clever algorithm to use "catchy names" or words and then map them to the numeric values. Could even down-sample the names/words that need remembering and then up-sample them to the full numeric range behind the scenes to help add a larger range of values.
We use it in production. Much of our traffic comes in to us on it.
We dual stack, though, as we know we won’t be able to access all external resources we need over it.
If you are expecting everything else to work over v6 before you deploy it then you’re hoping to be the last network on earth to do so. And there can only be one of them so that game of chicken can’t end.
There will be a very long tail of networks only on v4. Yep.
We dual stack, though, as we know we won’t be able to access all external resources we need over it.
If you are expecting everything else to work over v6 before you deploy it then you’re hoping to be the last network on earth to do so. And there can only be one of them so that game of chicken can’t end.
There will be a very long tail of networks only on v4. Yep.
Many small business routers and firewalls still don't have reasonable IPv6 support, for example https://forum.peplink.com/t/ipv6-support/3675/54 (from 2015) says they are working on it. People are asking "what's the status" now in 2022.
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.
I've always figured the easy way to improve adoption rates is to build in a statistical failure to ipv4 stacks; add a kernel option to drop 0.1% of ipv4 packets, or add a 250ms delay to ipv4 packets, and adoption of ipv6 will skyrocket without significantly impacting existing workloads because v4 will still work 99.9% of the time.
Who would opt in to using it? Only people who don't need the extra encouragement. It would be easy but entirely ineffective.
ipv6 would be completely unnecessary. Only a handful of things on the internet actually need to be publicly addressable. Even something as simple as SRV record support in browsers would solve 99% of the invented ipv4 "crisis". Furthermore if people could come up with actual technical reasons why NAT is bad, rather than "I don't like it"... because guess what? It's here, it's now, and it's been working just fine for 30+ years.
That being said ipv6 offers some really nice features around flow-ids and getting rid of dumb and dangerous ipv4 flags. Credit is due where credit is due and these debugging features of ipv6 are worth mentioning as they really did get it right.
Despite this, in my opinion, we simply don't have a use case for ipv6. ipv4 + NAT + BGP (and maybe some SRV records) is all humanity needs, forever.
I will continue to disable ipv6 on all the networks and devices I manage, as it's an unnecessary and useless attack surface that ultimately offers me 0 benefit, just downsides.
That being said ipv6 offers some really nice features around flow-ids and getting rid of dumb and dangerous ipv4 flags. Credit is due where credit is due and these debugging features of ipv6 are worth mentioning as they really did get it right.
Despite this, in my opinion, we simply don't have a use case for ipv6. ipv4 + NAT + BGP (and maybe some SRV records) is all humanity needs, forever.
I will continue to disable ipv6 on all the networks and devices I manage, as it's an unnecessary and useless attack surface that ultimately offers me 0 benefit, just downsides.
NAT is not working fine. Have you ever needed to set up STUN + TURN?
I think many people are oblivious to STUN/TURN, and the amount it happens in alleged "peer-to-peer" stuff like <insert "Show HN: I built X on top of WebRTC" article here>.
Or setting up port-forwarding. Or having to deal with "hairpin NAT". Or having to deal with trying to route two networks together over VPN without having their address spaces collide because literally everyone uses the low end of 10/8. Or the amount of money being siphoned off for the privilege of having an IPv4 address.
Or setting up port-forwarding. Or having to deal with "hairpin NAT". Or having to deal with trying to route two networks together over VPN without having their address spaces collide because literally everyone uses the low end of 10/8. Or the amount of money being siphoned off for the privilege of having an IPv4 address.
Never actually once in 30 years.
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
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
> 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.
please read about rfc4941 privacy extensions & how prevalent their use is before continuing to regurgitate decade-old, outdated privacy alarmism about MaC aDdReSsEs.
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.
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.
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.
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.
Indeed, I've had similar difficulties... and my needs are rather low! Basically get to the distribution-provided repositories.
This doesn't reliably work. If I get lucky and get a mirror with AAAA, all's well. If not, I may get stuck in an annoying retry loop.
I resorted to making a dumb router VM. It has v4 that everything else uses to route public traffic through
This doesn't reliably work. If I get lucky and get a mirror with AAAA, all's well. If not, I may get stuck in an annoying retry loop.
I resorted to making a dumb router VM. It has v4 that everything else uses to route public traffic through
I tried to deploy ipv6 with my vlans on my Ubiquiti stuff. Good luck debugging or calling any tech support when stuff doesn't work, no one understands it heh. Hell even comcast couldn't answer the question as to the delegation subnet size on their provisioned routers (key for deploying more then 1 vlan behind it).
My take is that they should have used alphanumeric addressing. You could have addresses like company:office:laptop and it shouldn't have reinvented arp and dhcp or added more complex routing like anycast or link local. It tried to solve too many problems at once.
How would alphanumeric addressing help anything?
You currently have an address hierarchy like <AS Number>:<Network Allocation>:<Subnet>:<Host>. That hierarchy is conveniently conveyed in a single 128 bit number. With an alphanumeric address, 128 bits of ASCII would get you `company:office:l` and your net/subnet/host would require more CPU horsepower to compute.
You currently have an address hierarchy like <AS Number>:<Network Allocation>:<Subnet>:<Host>. That hierarchy is conveniently conveyed in a single 128 bit number. With an alphanumeric address, 128 bits of ASCII would get you `company:office:l` and your net/subnet/host would require more CPU horsepower to compute.
The ascii is for presenting to the user not for hardware processing. It is not a wire format. Onlh when logging or parsing a config (human interfacing) is an ascii conversion required and a modern protocol that wants adoption should prioritize human friendliess at the human interface of the protocol.
Right now the hex lets you mental model the wire bytes nicely but it is unpleasant to use. V4 used decimal which is pleasant to use. UX trumps all.
Right now the hex lets you mental model the wire bytes nicely but it is unpleasant to use. V4 used decimal which is pleasant to use. UX trumps all.
You're thinking of DNS, which... we already have.
v6 actually changed very little from v4. It more or less works in exactly the same way v4 does.
v6 actually changed very little from v4. It more or less works in exactly the same way v4 does.
No, ipv6. Could have eliminated the need for DNS in a LAN. There is no reason to use hex other than maybe it would be easier for control planes to translate config to bytes/asic? But that's only when a config changes. Routing and forwarding uses bits and bytes, the hex is just one of many ways they could have chosen to represent the bytes. Defining prefixes in alphanumeric and how that translates to bytes could have been worked out. It could be something like 2601:hchsh:eevbo::home/64 for example
That could actually work for the host ID part of the address (not so much the network part). You could do it today with v6 just by extending getaddrinfo() (e.g. with an NSS plugin on Linux).
But L3 addresses aren't the place for naming. They're meant for computers, not humans. DNS supports names longer than 2-8 characters, descriptive hierarchies, multiple address families, other useful info types like SSH keys, and in general operates at the right layer for it.
But L3 addresses aren't the place for naming. They're meant for computers, not humans. DNS supports names longer than 2-8 characters, descriptive hierarchies, multiple address families, other useful info types like SSH keys, and in general operates at the right layer for it.
My whole country of 80 million people with very high Internet usage is still not supporting IPv6 at all (and residential connections are behind CGNAT). I'm pretty sure there are many more. IPv6 might be a thing in US or Europe, but definitely not in the world.
IPv6 penetration:
1. France 72.63%
2. India 66.47%
3. Germany 65.45%
4. Greece 62.13%
5. Malaysia 60.03%
...
15. United Arab Emirates 48.69%
16. United States 47.99%is "not supporting IPv6 at all" a data-backed statement?
https://stats.labs.apnic.net/ipv6/ fwiw
https://stats.labs.apnic.net/ipv6/ fwiw
Going by the "80 million" comment and the map you've linked, the countries that come closest are Germany (±60%), Iran (0.34%), and Turkey (1.79%).
Iran has an oppressive government with severe internet restrictions, so I'm not surprised they're not making IPv6 a priority. I'd assume their traffic interception devices don't work all that well without IPv4, they never seem to.
With 1.79% being IPv6 capable (not even configured), I'd say availability is effectively 0%. It's technically 2%, but I'd imagine those 2% are mostly hosting services and such.
Reverse sort the availability table and lots of countries have availability below even 5%. Nigeria, the 7th most populated country in the world, is at 0.38%. Lithuania, part of the EU and its economic bloc, is at 0.16%.
Iran has an oppressive government with severe internet restrictions, so I'm not surprised they're not making IPv6 a priority. I'd assume their traffic interception devices don't work all that well without IPv4, they never seem to.
With 1.79% being IPv6 capable (not even configured), I'd say availability is effectively 0%. It's technically 2%, but I'd imagine those 2% are mostly hosting services and such.
Reverse sort the availability table and lots of countries have availability below even 5%. Nigeria, the 7th most populated country in the world, is at 0.38%. Lithuania, part of the EU and its economic bloc, is at 0.16%.
On the dark web IPV6 is seen as a way for hackers to hide amoungst the forest of trees. I can detail millions of IPV4 addresses that are not being used, some blocks with ISP / WISP that have never been allocated to a 'customer'
There are large swaths at work that are IPv6 only. There is a proxy to work with things like Github that don't do it.
Ideally, every OS and device should be able to do IPv[46] only and dual-stack.
IoT stuff has the most problems where they're 2.4 GHz and IPv4 only.
Ideally, every OS and device should be able to do IPv[46] only and dual-stack.
IoT stuff has the most problems where they're 2.4 GHz and IPv4 only.
I believe a lot of mobile traffic to services like facebook/netflix/youtube use IPv6. That's a large percentage of internet traffic. And that allows telcos to NAT more customers onto fewer ipv4 addresses.
I disabled IPv6 on my home network completely because it interferes with my use of my Raspberry Pi as a DNS blocker. I was never able to get DNS working properly, which, apparently, is intentional with regards to the IPv6 protocol.
Meh.
Meh.
It's not supposed to. My pihole blocks IPv6 just fine, whether it's being reached from an IPv4 or an IPv6 address. IPv6 has very little to do with DNS.
It definitely doesn't do any of that.
Your problem was having a non-Pi-hole DNS server configured. If you want to run all of your DNS queries through Pi-hole, don't configure a DNS server that's not the Pi-hole server (or which doesn't forward its queries to it).
Your problem was having a non-Pi-hole DNS server configured. If you want to run all of your DNS queries through Pi-hole, don't configure a DNS server that's not the Pi-hole server (or which doesn't forward its queries to it).
> 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 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 can trivially remember a bunch of ipv4 addressed, and recognize them at a glance (”oh that’s just our office vpn endpoint, that traffic is benign”). No hope of that with ipv6.
If your office has a /48 you could surely memorize the subnet itself and/or give your important endpoint the shortest possible IP address like: 2001:db8:a0b0::1 or even something funny like 2001:db8:a0b0::0ff1:ce
Yeah, just pick <prefix>::200 instead of <WAN IP>+<RFC 1918>.200. Forget "no hope", that actually looks easier than the v4 case to me... especially if you have any RFC1918 clashes going on, which many companies do.
Many of the services we work with are just broken with ipv6. Our own services are broken with ipv6.
I just gave up and forced everything in ipv4 mode.
I just gave up and forced everything in ipv4 mode.
I had to disable IPv6 on my macOS in order to download packages from GitHub that brew uses, it took me days to figure out the problem.
Is there an "awesome"-style list of things that are slowing server-side IPv6 adoption? If not, these would be a good start.
[deleted]
Poor support for IPv6 is not new, however a cheap way to workaround is to grab a VPN service and use it for your IPv4 needs.
I will never use something like "2a00:1450:4004:801::200e"
I have to think
Instead with 162.241.217.123 I don't have to
Instead with 162.241.217.123 I don't have to
they don't offer free private ipv4 with nat?
these are all outbound reachability issues. the bigger concern i'd have would be inbound reachability for public services.
you don't need routable ipv4 addresses on every host to hit public ipv4 internet services!
these are all outbound reachability issues. the bigger concern i'd have would be inbound reachability for public services.
you don't need routable ipv4 addresses on every host to hit public ipv4 internet services!
I’m still waiting for Amazon to start supporting Elastic IPv6 in their AWS.
You can remove the address(/128) from old instance and assign it in the new instance and it will works just as EIP.
Why?
What are you using EIP's for and the ability to float them?
What are you using EIP's for and the ability to float them?
That just made me look at Google Cloud again, and it's depressing to see.
At least some types of load balancer do support dual-stack setups, but not if you configure them via GKE with the k8s ingress controller. If you use that one you're out of luck and they maybe now implement it for the new gateway API controller.
So if you use GKE and ingress you can configure two of them. One with a static v4 address and another one with a static v6 address. Of course you pay twice then.
Maybe it’s time to declare IPv6 as failed and find something new?
Can you attach floating ip4 to your ip6only hetzner machines?
> I noticed huge swaths of the GPG infrastructure are defunct
Many key servers shut down because they were receiving way too many GDPR requests. The idea of public permanent name and email records sound crazy in today's landscape.
Many key servers shut down because they were receiving way too many GDPR requests. The idea of public permanent name and email records sound crazy in today's landscape.
15 years ago I connected 1000s of computers natively to the IPv6 Internet. Today, I don't have IPv6 at home.
DJB was right, I'm afraid.
DJB was right, I'm afraid.
IPv6 drives lock sync AD personalization which represents trillions of dollars; it's no wonder there are so many social engineering attempts to try and herd the public into using it.
The experiment ended much sooner than I had anticipated. Some of the road blocks I hit along the way:
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?