Tell HN: IPv6-only still pretty much unusable
Our Hosting provider, Hetzner, has recently started charging for public IPv4 addresses - as they should! Those numbers started getting expensive. This prompted me to try and set up a new server cluster using IPv6 exclusively, and see how far I could get before having to give in and purchase an additional v4 address.
The experiment ended much sooner than I had anticipated. Some of the road blocks I hit along the way:
- The GitHub API and its code load endpoints are not reachable via IPv6, making it impossible to download release artefacts from many projects, lots of which distribute their software via GitHub exclusively (Prometheus for instance).
- The default Ubuntu key servers aren't reachable via IPv6, making it difficult to install packages from third-party registries, such as Docker or Grafana. While debugging, I noticed huge swaths of the GPG infrastructure are defunct: There aren't many key servers left at all, and the only one I found actually working via IPv6 was pgpkeys.eu.
- BitBucket cannot deploy to IPv6 hosts, as pipelines don't support IPv6 at all. You can self-host a pipeline runner and connect to it via v6, BUT it needs to have a dual stack - otherwise the runner won't start.
- Hetzner itself doesn't even provide their own API via IPv6 (which we talk to for in-cluster service discovery. Oh, the irony.
648 comments
[ 3.0 ms ] story [ 152 ms ] threadActually, that's not even that bad a way to get IPv4 on any IPv6-only host: route it all through TOR!
cgnat is only going to get MORE common, globally
IP geolocation is a bad idea for lots of reasons. Unfortunately it's also a reality of how services work.
& to be clear, that is CRAZY growth!
edit: that's traffic to monitoring resources, not in general, sorry /facepalm
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.
Except Charter/Spectrum in the US.
DNS is a thing.
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.
> 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.
https://stats.labs.apnic.net/ipv6/NO
alot of commercial vendors have mature nat64 implementations tho
https://twitter.com/iPv4depletion/status/1584376525427978240
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.
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.
https://github.com/community/community/discussions/10539
Apparently github are working on it as of Oct 2022 ... https://twitter.com/AS36459/status/1582728252199964672
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
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.
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 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 know that v6 has been a success within datacenters and such.)
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.
If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
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.
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.
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.
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.
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 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.
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.
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....
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.)
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.)
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.
IPv6 security is like IPv4 security: Firewalls
For privacy IPv6 uses Security Extensions, which shuffles your ipv6 ip.
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?
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.
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).
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. [...]
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?
Every friends phone that wants to connect to my wifi needs manual setup?
That is a problem. To which the solution is IPv4?
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.
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.
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.
SLAAC is more than capable of sending DNS settings to devices. There's no manual configuration involved.
SLAAC does not do DNS. Clear as day?
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_...
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.
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.
https://doc.riot-os.org/group__net__gnrc__ipv6__auto__subnet...
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.
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)
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.
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.
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.
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.
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.
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 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.
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.
I was hoping there was a better way.
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.
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.
> 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?
You only need two addresses:
- a global address
- a link-local address
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.
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)
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.
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.
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.
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...
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.
There’s already communities out there for hobbyists to play with/learn BGP on private networks over VPN tunnels if you really want to.
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".
Around €19.00 setup per IP.
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.
As a comparison, I pay ~$1.60/ip/mo (no setup fee) for my IPs.
Well, that's ominous. Basically a promise that they will sell your data.
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.
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.
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://docs.aws.amazon.com/general/latest/gr/aws-ipv6-suppo...
What are you using EIP's for and the ability to float them?
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!
https://stats.labs.apnic.net/ipv6/ fwiw
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%.
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)
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.
This is a home cable connection in the Bay Area.
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.
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.
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.
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.
the most exhaustive list thus far is https://sites.ip-update.net/ afaik
Those are the ones blocking adoption for me, as an end user.
https://whynoipv6.com/
A /60 is only 16 /64s (i.e. 16 subnets), and that's not always enough.
The telecom regulator (ARCEP) conditioned 5G bands on rolling out IPv6.
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?
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.
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.
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.)
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".
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?
Which would need translation support at the edges between devices speaking only old-IPv4 and the superset-IPv4. Just as is done with IPv6.
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.
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+"
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.
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?
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.
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 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.
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.
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.
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.
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 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.
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 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.
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.)
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.
Ipv6 is not backwards compatible at all.
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?
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.
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.
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 make sure what I build supports IPv6 (and I'll use tunnels if it's what it takes) but I can't make the only cable ISP available at my place support IPv6. I wish it did. I wish I didn't have to use its garbage hardware.
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.
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.
A naive NAT implementation can allow an attacker to bypass the firewall.
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.
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
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.
NAT is not a substitute for a 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?
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.
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.
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.)
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.
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.
any exceptions to this should be roasted (my twitter dm's are open)
Only, and only, if you configured your router that way.
In both cases, it's absolutely the same:
See?Of course if you are on someone's else network (typical for hosting when you aren't provided with your own v6 subnet, instead you have a bunch of addresses) then you should configure firewall on each your machine... which is what you need to do anyway?
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.
That is usually not true. NAT punching is a thing for decades now.
- And is it any different from a stateful firewall on IPv6?
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.
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)?
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.
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.
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` can't connect to 10.0.0.2:1313 since it's not routable from their position. Thus, the fact that NAT on its own doesn't prohibit traffic to `C` doesn't matter in this scenario, practically `A` still can't reach it. So far so good?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[*]:
[*] Of course that requires that any outgoing connections that `C` makes are not vulnerable against the possible packet manipulation from `G`.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.
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.
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).
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 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.
That's what reasonable people would do for a V4 network too.
The popularity of uPnP for automatic port forwarding should be a clue, anything that uses that is blocked by cgnat.
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.
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.
"IPv6 Multihoming without Network Address Translation"
* https://datatracker.ietf.org/doc/html/rfc7157The 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.
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.
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.
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 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.
Developed countries will pay obscene amounts for ipv4 space. Just as they do for shorthand .com domains.
By this metric, we still haven't finished migrating to v4.
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.
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.
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.
Ideally the number of ipv6 allocations should be close to 1 rather than close to 1000.
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.
https://networkengineering.stackexchange.com/questions/76562...
https://blog.apnic.net/2021/03/03/what-will-happen-when-the-...
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.
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.
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.
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.
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
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 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.
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...
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.
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'?
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?
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.
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.
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.
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.
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.
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.
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.
I'm struggling to see how this would improve anything over what v6 did though.
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.
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.
Kind of like how PF does it?
* https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tut...If an address family ("af") is not specified, the rule applies to both:
* https://www.freebsd.org/cgi/man.cgi?query=pf.conf * https://www.openbsd.org/faq/pf/filter.html#syntaxPerhaps the protocol isn't the problem and you're just using firewall software that doesn't have very good syntax?
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.
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.
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.
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.
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.
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.
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.
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 +++.
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.
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.
https://datatracker.ietf.org/doc/rfc9229/
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.
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.
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?
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
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.
You're going to have the exact same problems with any protocol that has addresses longer than v4's.
Otherwise there's a ton of low level IPv4 details leaking all around the basic idea of connecting from one service to another.
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.
That it's much easier to set up.
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.
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.
Have you actually seen any large scale deployments of CPEs without an active IPv6 firewall blocking incoming connections by default?
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-...
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.
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.
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.
Do you happen to have a reference from the RFC, about it being against spec to hand out just a /64?
More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:
I don't really understand why ISPs choose to be so stingy with allocations. An extra 8 bits of address space to allocate /56 instead of /64 costs them effectively nothing and has considerable operational benefits, simplifies CPE configuration etc. Just minds still living in IPv4 land I guess.https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefi...
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.
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.
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.
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.
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...
It "died" as an Internet-Draft: https://datatracker.ietf.org/doc/html/draft-chimiak-enhanced...
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?
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.
But the confidence and armchair expertise offered… wow.
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.
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?
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, oh yes please give me more fucking ports. IPv6 keeping the same number of ports is stupid.
IP doesn't have ports.
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.
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.
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
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.
So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
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.
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.
(Also, I don't think it's fair to call it simple. Many of the things we've done to deploy v6 are things which need to be done to deploy any IP protocol with bigger addresses than v4. If you count those things against v6 while ignoring them for any alternative, you aren't doing a fair comparison.)
I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.
https://en.wikipedia.org/wiki/6to4
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.
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.
> 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.
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...
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.
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.
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
In fact I am posting this comment over IPv6.
1986 wants a word.
I only mentioned hosts file because it is the easiest way to spoof the domain.
That's worse, yeah? You do see how that's worse?
2a06:98c1:3120::5 news.ycombinator.com
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 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!
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!
*) https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...
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)
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...
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.
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.