It's good to wonder publicly and have a discussion!
I set up IPv6 on all my servers in 2001 and thought we'd all be on IPv6 in just a couple of years :P
What's interesting is how much resistance there is to adding IPv6 which comes from entrenched IT. People who never learned (much) about IPv6 seem to be afraid of it and often respond with some variant or another of "don't fix it if it ain't broke", or "it's extra work for no return", or "we'll have to pay licensing to add IPv6 because we bought crap routers, so let's not", et cetera.
My favorite is, "we have no record of people trying to use IPv6" - yes, that's real :D
It just shows their ignorance. Adding IPv6 has myriad advantages - no need for NAT, proxies or port forwards to share addresses, no need to renumber networks if allocations or upstream change, redundancy, valid security-through-obscurity (imagine port scanning a /64 looking for open ssh ports)...
What's really interesting is how many of these "we fear change" IT people don't realize they're already using IPv6 on their phones every day, with a majority of the sites they visit.
There's a fair amount of "who goes first" or "who sees that it works end-to-end". My personal experience has been several situations where some piece of software that doesn't work, or is slow, suddenly works when I disable ipv6. That includes vpn client software I had to use for a job, dns configuration at another job, a mesh network for some hobby thing, etc.
Had I spent the time to dig into it, I'm sure I'd have found the issue. And it probably wouldn't have been directly a true ipv6 problem. But I had more important things to deal with, so it moved to number 11 on my "top 10 list".
I'm guessing I'm not alone in that. So while individual teams and products might be working to support it, end users often see that it doesn't, because of some peripheral thing that's misconfigured, doesn't have support, etc. So they give up, which reduces perceived demand.
If you don’t have AAAA records and you don’t have Interfaces listening to those addresses. You won’t “see” ANY “demand.” So since they don’t see ipv6 traffic, they think there’s no demand for it. It’s a self-fulfilling statistic.
It's far more likely the statement refers to a lack of user tickets, project requests, or compliance requirements as that's normally how IT finds out what to do next. I've never seen an IT staff with so little to do they are monitoring the network looking for packets for ideas of what they should implement next instead of implementing things they've been trying to get time for for the last 5 years. Link utilization maybe but that's a completely different beast.
Not to mention it's extremely hard to know how to check the statistic you described without becoming aware you don't have the things needed to generate the statistics so this reasoning kind of rules itself out with the exception of AAAA records - you'll actually see those requests even if all you have is A records on an IPv4 only DNS server.
I worked at an MSP during the peak of covid getting remote workers at many different companies settled in. When turning off IPv6 solved connectivity problems, 100% of the time it was because IPv6 DNS was taking precedence over IPv4. IPv6 DNS request gets sent over VPN, firewall doesn't know how to resolve it, and you can't get to anything on the network. Turn that off and the IPv4 requests are happily resolved. I'm not sure what else that problem could possibly be other than maybe misconfigured domain controllers, but that seems pretty unlikely if dual stack was enabled on the firewall as that is not the default in my experience.
Yikes. Pushing IPv6 traffic through the IPv4 tunnel is just bad software design, seems like a bug. That's just bizarre. Incidentally, none of our clients used that. The issue is similar though, but different root causes.
Nothing wrong with doing that in the slightest. Just because the user's home internet is IPv4 does not mean corporate side v6 services should be unreachable. Either way the user is going through a tunnel to reach things, it doesn't matter if what's inside the tunnel is the same as what's outside it... it's a tunnel! Doesn't even have to be IP!
Now that doesn't mean things can't get misconfigured or poorly set up in that regard but by no means is the concept just wrong, I have several clients it has been useful for.
> Adding IPv6 has myriad advantages - no need for NAT, proxies or port forwards to share addresses, no need to renumber networks if allocations or upstream change, redundancy, valid security-through-obscurity (imagine port scanning a /64 looking for open ssh ports)...
problem is that adding ipv6 gives none of those. Removing ipv4 would do so, but realistically most people are going to run dual-stack of some sort for a while, and as long as that is the case then adding ipv6 is mostly just additive effort.
I think most corporate network should be able to do pure IPv6 internally, and then tunnel to IPv4 at the gateway.
The number one complaint I hear (and have myself) is that maybe I don’t _want_ all devices on my LAN to have public IP addresses. NAT makes security a lot easier to reason about.
> The number one complaint I hear (and have myself) is that maybe I don’t _want_ all devices on my LAN to have public IP addresses.
This isn't a goal in itself. The formerly problematic and unwanted side effects of NAT, namely a broken peer to peer relationship of hosts on the internet, are now understood as a feature. Machines were forced by this technology to be clients and the initiators of all connections to the internet. Historically this has interfered greatly with several internet protocols (ftp, IRC DCC, p2p file sharing, ...) all mostly dead now or reworked to operate in a world full of NAT gateways.
IPv6 would reverse this state of affairs. If machines need to be denied the server role, this can be enforced by a firewall. As far as tracking of clients by IP goes, dynamic address assignment via DHCP or IPv6 privacy extension take care of that.
> The formerly problematic and unwanted side effects of NAT, namely a broken peer to peer relationship of hosts on the internet, are now understood as a feature
A feature? I’ve never heard that. If you want to break the end to end nature of the net you can do that in your router, easily and more powerfully, without all the overhead of NAT.
The net has turned back to the old mainframe days, and things like NAT make it hard to go the other way.
Because you have all the overhead of NAT plus losing functionality that cannot operate through NAT. If all you want is to have addresses that done leave the local net, just do that.
You’ll lose weight in a famine but nobody would suggest it as a diet plan.
You can simply not route a specific range, no firewall needed.
NAT, on its own, doesn't provide security. At best, it provides obscurity. At worst, it breaks security [2]. NAT needs a properly configured firewall to provide security [1]. In this sense, NAT vs a Firewall is a false dichotomy.
I wasn't claiming NAT is adding security. A combined IPv4 NAT/firewall will not necessarily be less performant than an IPv6 firewall - that was my claim.
Also, GP claimed that certain services that don't work because of NAT would work on an IPv6 network. I was curious which services those might be, that don't work because of NAT but wouldn't be affected by a firewall.
These stateful devices have to look at all the traffic and maintain connection data for every transaction. That takes space and time and is bounded in volume.
The same is true of firewalls, so I don't get your point. Even in IPv6, your router-level firewall will need to know if a packet with dst_port=31536 is part of an existing connection or not, which means it has to monitor all traffic and maintain connection data for every transaction, no different from a NAT device.
What is the point of a perimiter firewall in the modern Internet? Those TV and lightbulbs are attack vectors inside the firewall. And there are (and will be more) plenty of devices that bridge the cellular networks and the LAN.
You need a defense at depth, not a crunchy perimeter with a squishy inside.
NAT doesn’t improve security if port numbers are easy to guess, which is usually the case.
If you wanna block inbound connections, just drop them with your firewall. Most home routers already do this by default and if yours doesn’t, you better enable it for IPv4 too.
“Block everything” works as long as you aren’t actually opening any services on the local network.
If I want to open up a device with a single port, I should open that in the firewall. But wait, my IPv6 addresses aren’t stateful, so they can change any time.
And then suddenly someone decides to just open port 80 and 443 on the main router, and bam! I’ve just opened up those ports for _all_ IPv6 clients in my LAN.
You think all those IP cameras and ring doorbells were vulnerable when they are behind a NAT? Just wait what happens when they all get assigned public IPv6 addresses.
I’m not saying that these problems are unsolvable. But I think it’s important to at least recognize that, yes, this is different than how we did things with NAT, and you now have more tools to shoot yourself in the foot with.
> you now have more tools to shoot yourself in the foot with
And the tools for managing IPv6 firewall rules suck on "SMB grade" stuff like ubiquiti and are virtually non-existant on any consumer grade router. If I have to SSH into the router and treat it like a "real" router to set up IPv6 firewall rules... it is never gonna fly for anybody who isn't proficient with "real" routers (i.e. >99% of the world).
Hell I'm pretty sure comcast's cable modem doesn't even have IPv6 firewall capabilities and if they do it is default wide open. Thats not what I want. I have no interest in outsiders being able to ping hosts on my network or even know of their existence. I have no interest in letting random IoT devices expose open ports to the entire world (by default).
IPv6 is cool and all, but no consumer gear sets it up even remotely secure. At least with NAT a "script kiddy" grade attacker won't see what is behind your router. NAT isn't perfect but it solves a lot of problems. Not so with IPv6.
Honestly I just don't really see IPv6 replacing IPv4. It introduces too many problems and offers too little benefit. Whatever actually replaces IPv4 will either need to be 10x better than IPv4 in every way or be a completely transparent migration that works with IPv4 "but with more addresses".
> Hell I'm pretty sure comcast's cable modem doesn't even have IPv6 firewall capabilities and if they do it is default wide open. Thats not what I want. I have no interest in outsiders being able to ping hosts on my network or even know of their existence. I have no interest in letting random IoT devices expose open ports to the entire world (by default).
Comcasts cable modem also doesn't have any firewall for IPv4... it's a cable modem, it passes packets.
Your CPE (customer premises endpoint) is where the firewall lives.
> IPv6 is cool and all, but no consumer gear sets it up even remotely secure. At least with NAT a "script kiddy" grade attacker won't see what is behind your router. NAT isn't perfect but it solves a lot of problems. Not so with IPv6.
Most newer consumer gear that does IPv6 blocks all in-bound traffic on IPv6, just like it does on IPv4.
> Comcasts cable modem also doesn't have any firewall for IPv4... it's a cable modem, it passes packets.
Most of the new stuff comcast ships is an "all in one" device that acts as an access point, a router and a cable modem. You can buy third party cable modems that do what you describe but what comcast gives you is much more fancy.
You should almost always buy a 'dumb' cable modem and have your own router that you manage behind it. These devices are commonly behind on firmware and may have completely insecure settings that you'll never have insight into.
Having an outdated firmware (which could be solved by mandatory updates from the ISP, which appears to be the direction AT&T is going) is still much better than having no firewall at all. An incredible minority of people, who “manage” their household internet access are aware of any of this.
If your firewall has exploitable outdated firmware, I might argue it's worse than no firewall because now you potentially have malicious code living on your network. Whereas if you don't have a firewall (on a home network) there generally isn't anything someone could get into anyway. "Oh I see port 22 is open." Great, there's nothing to SSH into anyway, who cares?
Surprisingly, it probably does have a firewall. Cable modems are really odd devices.
That said, the relevant part is the router (which may be part of the same physical device these days), and that part certainly does have both a v4 and a v6 firewall, configured securely for both.
> And the tools for managing IPv6 firewall rules suck on "SMB grade" stuff like ubiquiti and are virtually non-existant on any consumer grade router. If I have to SSH into the router and treat it like a "real" router to set up IPv6 firewall rules... it is never gonna fly for anybody who isn't proficient with "real" routers (i.e. >99% of the world).
Umm, the IPv6 firewall interface is exactly the same as the IPv4 firewall interface on UniFi[1].
You should use one of your PDs as a DMZ not putting your externally exposed web server in the same subnet as your IOT or other outbound only devices. If you're hosting a lot of things™ you should be using a static DMZ, same as you would on IPv4.
For the more general user case ("I want to host a game session with my friend") I'm not sure if there is something like UPnP for dynamically registering allowed ports without needing to actually do any NAT work but that would certainly seem useful.
I hear this and I'm always curious how this happens. The Linux distributions I've used, the home routers I've encountered, etc, all default to a restrictive firewall that only needs to be changed if you want stuff allowed through.
Yeah, incorrect firewall rules are a HUGE problem at super large companies that aren't doing infra-as-code at scale yet.
Sysadmins/server engineering/DevOps/SRE, Networks, and Security are usually hard silos at big companies.
"DevOps" gets a request from an app team to open a port between subnet A and subnet B.
DevOps asks Networks to do it. Security needs to approve it before Networks can do it (usually). A cohort of VPs somewhere need to approve it if those subnets are "production" (i.e. subject to serious fines if the data therein fails audit).
Networks outsources the request to their global services team in India/Phillippines/China/Brazil since it's literally a single command, but they are done in bulk. These changes are only done afterhours, partly because of outsourcing latency, partly because of regulations.
The firewall person types in the wrong port. Emergency change request gets filed to fix. Fixed in 1-3 days after the CTO/CIO and some SVPs approve it (and maybe yells at people for wasting their time).
The requester asks for the wrong port. Too bad, so sad, you're waiting another week.
The app team asked for the wrong port. Same outcome as the DevOps person.
The thing is, once you start to do any complicated firewall setup where defaults can no longer be restrictive, you are bound to screw it up at some point.
What kind of firewall work didn't have default drop? Once you take that off the table you really do have a problem but I've only seen that one in 20 years of professional work.
I’ve had to do it fairly recently due to a lot of dynamic bridges and routing on the internal network vlan. I wanted to allow all traffic through the vlan from any device. However, wanted a default drop on the external interface.
Once you are working with VLAN's you are out of the bailiwick of consumer hardware, and you should be looking at more enterprise grade gear.
At that point having a default drop on the external interface and different rules for traffic traversing VLAN's is entirely possible, in fact that is what it is designed and built to do.
As far as consumer routers go, wouldn’t it be trivial to re-tool the usual port forwarding interface to simply accept connections to a specific address-port? That combined with a internal block-all-inbound rule would be quite hard for a user to footgun themselves horribly with.
From a quick search, UPnP seems capable of automating this for user convenience, especially with stateless addressing.
Are you sure you haven't? NAT in fact doesn't stop connections, so if you accidentally didn't configure the firewall then you won't be saved by NAT.
Odds are that there weren't many people in a position to connect to you, and probably nobody actually did so, but it would certainly have been possible without a firewall in place.
It's not just about inbound connections, people also generally don't want to have their outbound devices clearly visible by counting unique IPs, or MAC addresses (and thus manufacturer) of devices sent out with every packet when MAC is used to generate the address, or another globally unique identifier for ad networks to track.
They 100% most certainly don't. I would have no idea what anything is on my network if every workstation's MAC addresses was constantly changing. Some OS's do randomize per SSID, but it doesn't constantly change, it would break DHCP by using up all the addresses. You can't just constantly change your L2 address.
This is in IPv6, not v4. I highlight that because you mention DHCP, which generally isn’t used there. And it’s not the MAC address that changes, but the 64-bit interface identifier. Ethernet would probably stop working if the MAC address changed with any regularity. You can read more about this at https://www.internetsociety.org/blog/2014/12/ipv6-privacy-ad...
From that article written in 2014, these OSes have privacy extensions enabled by default:
- All versions of Windows after Windows XP
- All versions of Mac OS X from 10.7 onward
- All versions of iOS since iOS 4.3
- All versions of Android since 4.0 (ICS)
- Some versions of Linux (and for others it can be easily configured)
This is why I haven't swapped, but I didn't realize they've accounted for this at the client level. Makes sense, still makes me think about IoT devices though and things I don't have 'control' over like my chrome cast.
> I think most corporate network should be able to do pure IPv6 internally, and then tunnel to IPv4 at the gateway.
With the amount of legacy applications and systems populating the typical internal network that idea won't be going far.
Where IPv6 actually can be used and should be deployed in addition to v4 is in the perimeter networks. Offering or being able to use services on the internet over v6 (via proxy) overcomes the real shortage of ipv4 addresses in the internet at large.
I expect internal networks to be last places to be moved to IPv6 only.
This simple workflow, a new internal network deployed on IPv6 only
Edge Firewalls -- source natting to allow access to IPv4 networks
Edge Firewalls -- destination natting to allow access from IPv4 to a service hosted on IPv6
Doesn't seem to widely adopted. It's all dual stack stuff, which means more work and more things to go wrong for no benefit.
Of course there's then the renumbering of your entire internal network every time you change ISP because you're using public IPs rather than private ones
NAT actually makes security harder to reason about.
For example, did you know that NAT doesn't prevent inbound connections? At least in v6 people are more likely to realize that, yes, they do need a firewall.
You can get many of the benefits by adding v6 and then ignoring the v4 for some things. For example, sometimes you might need to allow an inbound connection on v4, but if all potential clients have v6 then you can just ignore v4 for that server. It's not necessary to remove v4 immediately, although v6 provides ways to help do that when you want to.
When you run dual stack, the v4 is there as backwards compatibility. It's lovely that people will simultaneously complain that v6 doesn't have backwards compatibility, _and_ also use the backwards compatibility it does have as a reason to not deploy it...
> What's interesting is how much resistance there is to adding IPv6 which comes from entrenched IT. People who never learned (much) about IPv6 seem to be afraid of it
Right, you're only suggesting that they change out a fundamental part of the network for no benefit that they can see; why would they possibly object except out of fear and ignorance? After all, their fears are totally unfounded; most, probably all, of the random breakage and slowdowns that happened last time they tried to enable v6 have been fixed now.
I mean, yes, plenty of people don't want to learn new things for bad reasons, but plenty of people have insufficient time and have to make cost/benefit decisions - and you not liking their conclusion doesn't make them wrong - and there are a fair number of people who were all on board with upgrading a decade ago and got bitten by the then very real problems with IPv6 (which mostly boiled down to "not everything supports it properly, and lots of things fail ungracefully and create weird breakage").
Well put. I’ve been shocked by the elitist attitude by many commenter who don’t see the issue IPv6 has for _most_ non-IT professionals.
Facts are these: IPv6 is a failure; it didn’t provide a way to conexist with IPv4 [1] and it did _not_ have a _compelling_ benefit to most people. The benefits cited makes no difference to most.
I wonder if people will ever stop bringing that article up...
v6 provides lots of ways to coexist with v4. There's dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how can you argue it doesn't?
> My favorite is, "we have no record of people trying to use IPv6" - yes, that's real :D
Have you ever worked at a IT department for a medium to large company? It’s usually a total shit show. IT gets blamed (justly or unjustly) for any issue with computers. As a result they become rather thick skinned and incredibly conservative in the projects they undertake.
So it’s not surprising that folks are unwilling to spend time on something they don’t have prior art for, haven’t operated before, and doesn’t offer significant benefits over what they already have.
100%. Anytime something happens to a PC it's either the sever, internet, or the network is down! Or all 3!
Right. Our entire network is down and IT has no idea, thanks for the help Karen.
You learn to keep things simple and make as few changes as possible so you can't be blamed for other departments mistakes. "Network is up, haven't made a single change to infra in a month. Find someone else to blame."
It’s easy to blame IT, but usually they have either business objectives assigned to them or they need to justify it to the business.
So I see the “if it ain’t broke don’t fix it” more of a business problem and not an IT problem. I worked at one organization where for any networking work, you had to bill that time to a business project (which was usually a customer contract). proponents of IPv6 inside a business probably seem to the business like they’ve got excited over pointless science projects with nothing to ‘bill’ their time against
The benefit of switching doesn't outweigh the costs yet. The switch to ssl was largely over google rankings vs greater security. What is going to be the reason people switch?
Many think cost of ip4 addresses but that hasn't panned out with solutions like NAT.
No, because isps dont care about page rank. I have to operate a small isp. IPv6 solves nothing for us and just makes even more problems. The comments in here keep saying that ipv6 will fix everything but it is hogwash. It just means I have to support two things instead of one. IPv4 on the internet will not go away even if I do the ipv6 transition perfectly.
It is one of the more frustrating parts of trying to explain why we don't all just jump to do this.
That’s fair. My ISP not only doesn’t provide IPv6 but actively blocks using 6to4/6in4. They claim they don’t but I can clearly see that they do. It’s bad.
Think of all of the hours I have to spend researching the following and implementing it:
1. Does all of the intermediate equipment support it
2. Does my IPAM support it
3. How do I even give ipv6 addresses to my ONTs?
4. How do I keep track of all of the address assignments for x months
5. Does my staff even understand how ipv6 works?
6. Does the off hours call center understand it?
7. Build the servers and add them to all of the monitoring, backups, do updates on them
8. What if I do this and the choice for ipv6 dhcp was wrong and in a year I have to redo it all
etc etc
There are no good answers for any of this that I have seen. There are sometimes 5+ options for everything to do with ipv6. How do I even weigh the pros and cons of approaches I have never used before.
Its hundreds of man hours at a minimum for no benefit other than to be ideologically on the correct side of technology. It will continue to work as it is now with absolutely no hours or risk for 10+ years at least.
I completely understand that it’s a huge amount of work. But v6 has been around for 20 years. Spread across decades the work becomes a much smaller lift.
Since we already have an ASN, its free basically. I already have one. Its at least a /32 and maybe a /28.
My upstreams support it, my ONTs support it but there isnt a nice ipv6 dhcp server with logging and a lookup interface that I have found yet. It probably exists but I don't know what it is.
IPv6 blocks are usually quite reasonably priced. You might even get them for free, if you're already paying maintenance on an IPv4 block (which are expensive to obtain these days)
That's only one side of the issue, the server side. There's also the client side to consider. Carrier-grade NAT for mobile/home use is expensive and harder to run than just giving everyone an IP address, and generally means a lower quality connection so you can't charge as much as an ISP, which is why ISPs are increasingly using IPv6. They otherwise need a lot of IP addresses!
ISPs are also making it more difficult to themselves: if there is a support for IPv6 at all, it is DS-lite, not full dual stack.
So let's say I'm willing to migrate to IPv6, but I still need IPv4 for some reason (maybe I need to do the migration with multiple independent ISPs and every single of them is traveling at different speed wrt IPv6). This approach makes it impossible for me to switch where it would be possible, I cannot drop IPv4 yet, CGNAT-ed connection is unusable, but also I cannot use IPv6 where I otherwise could.
> What's really interesting is how many of these "we fear change" IT people don't realize they're already using IPv6 on their phones every day, with a majority of the sites they visit.
For example see the video "T-Mobile’s path to IPv6 Only":
Wow, interesting to see such a video coming from T-Mobile. We have a DSL connection with T-Mobile Netherlands and they still don't support IPv6. Any inquiries about this on their community forums are met with a reply of 'there are currently no plans for IPv6 support'.
They used to be just a mobile provider here, but a number of years ago they acquired Vodafone's DSL division. They don't actually own any DSL lines though, they just rent line access from KPN (the country's incumbent telco).
Regardless of the IPv6 situation, IT departments take this position for a reason. It might be obvious to individual engineers how to safely deploy IPv6 on their home network if they fully understand all the moving parts. But large corporations with deep legacy to maintain don’t have the luxury of running a fully understood system. Isn’t that a big risk? Hell yeah, and of course they’ve all got modernization projects running. But in the meantime, they fear change - legitimately.
The problem is, it is NOT a simple idea, but one that requires a lot of relative heavy lifting with deep packet inspection for a lot of protocols that have to deal with the spaghetti that is NAT.
Yeah but even if it isn't simple it is mostly a solved problem at this point. NAT has been around for, what, 15 years now?
And quite honestly the default configurations for IPv6 on consumer routers is "wide the fuck open"--which is not at all what I want. But if they don't make it "wide the fuck open" suddenly you are asking normal people to learn how to punch holes in their firewall.
NAT has fundamental flaws that simply can't be solved, and even when it can be made to work it's still an extra layer of completely unnecessary complexity. It does work surprisingly well despite all that, but it's not something to build the entire future of the internet around.
The default config for most routers is to deny inbound connections, for both v4 and v6. I'm certain you can find routers that don't do that, but it's not common.
You wouldn't be doubling your workload. Most of your work applies equally well to both protocols without any additional effort, and even if you can't remove v4 completely you can often ignore it for some things, which saves you some workload.
If I want to communicate with v4 hosts I have to support v4. If I want my v4 clients to talk to me I have to support v4. What can I drop? I still need an IP, distributed by DHCP, I still need the subnets, I still need to manage the routing internally, I still need to have boundary nat, both out and in, I still need to have A records in DNS.
I have to do all of that in v6 land (perhaps my user interface will allow me to manage the firewall rules together, but I'm still doubling my testing). On top of that, if I change my ISP, I have to renumber my entire internal network rather than just change the public IPs.
It's not even common practice to have a v6 only network and nat from v4 to v6 at the edge, and more crucially it seems from this thread that v6 removed it's v4 compatability layer (so I can't type "ping 1.2.3.4" and have it translate that to "ping -6 ::ffff:1.2.3.4", with my 6:4 gateway handling the nat
Until people start using v6 only, where's the benefit in increasing my workload?
Calling people ignorant because you don’t agree with their opinions or reasons is a non starter for constructive discussions. Using IPV4 has never ever caused me a problem and I will never ever run out of addresses. I prefer to focus my time on real issues that actually affect end users and improve their experiences.
Yeah everyone says this but I can't access any ports on my IPv6 address from outside my home network.
Back to IPv4 + NAT + port forwarding, I guess.
I have bigger problems I need to solve in my life right now. When one day I can just ssh <my-ipv6-address> from the outside I'll do that. Thanks.
Also, there's the DNS problem. I can remember 10.0.0.3, 10.0.0.20, etc. pretty damn easily. I can't remember 8cef::fasd:8000:c00a:::99aa:::::81/42:8fe
that easily.
Which is an issue when things like 'foobar.local' don't work half the time. I have the IPv4 addresses of all my internal machines memorized thanks to the the fact that .local just doesn't work, period.
You can't access a service on a server on your local network using your router's global IP. You should use server's global IP address (and open the port for that IP on the firewall).
If your server uses SLAAC, it will always use the same local address (whether using EUI-64 or stable privacy), or you can configure it manually. In either case the address won't change.
NAT made you think in a different way, but if you started with IPv4 before there was NAT, this setup is exactly the same as it was with IPv4 a long time ago.
If I type ifconfig on my machine I only have one 'inet6' address and it isn't reachable from the outside.
The relevant people who want to popularize IPv6 should make that "just work". Until then IPv4 works for me, and a port forward is easy to understand, I don't need to google what SLAAC and EU-64.
They advertise it as "oh you don't need a NAT" but in reality IPv4+NAT is easier to deal with.
Most of us have actual jobs and don't have time to also be devops people.
I realize this sounds like a shitpost, but this UX is exactly why IPv6 isn't popular yet. If you want something to be popular, you need to make it easier not harder than the current thing everyone uses.
Half the discussion is FUD that a consumer router wouldn't have an IPv6 firewall.
Your router, like every other, has a default deny firewall for IPv6. You'll find the settings near to where you set up IPv4 port forwarding. My router calls it "pinholing" or something.
Then you can SSH directly to the servers you allow access to, using port 22 for all of them if you wish.
I tried enabling IPv6 on my router just now. It asked me for a delegation size. How TF do I know. I just randomly put in 60. It's what a google search told me to put in. Save changes.
Go to main screen. Still only shows my IPv4 WAN address. No IPv6 "pinhole" setting near the port forwarding.
Back to making breakfast and doing what I needed to actually do.
Sorry, I thought you were asking about a home broadband connection with the typical basic router supplied by the ISP.
The UDB Pro looks like something for a small/medium business, so you presumably have a business connection. You'd need to ask your ISP for the configuration, as it will depend on what service they're providing. (Just like for IPv4 you'd need configuration if the ISP is providing you with 4, 16, 32, ... IPv4 addresses -- also a common situation.)
If ifconfig is showing IPv6 addresses starting with fe80:, these are local/private, a bit like 169.254.x.y IPv4 addresses.
So far, all global/routable IPv6 addresses begin with 2.
(And for most home users, IPv6 is just as easy as IPv4, i.e. they don't know anything about either. After a test period, ISPs that support IPv6 generally enable it for all the normal home users -- it saves them money! That it is the default is how we got to 35% of Internet users using IPv6.)
> I tried enabling IPv6 on my router just now. It asked me for a delegation size. How TF do I know. I just randomly put in 60. It's what a google search told me to put in. Save changes.
Sorry but how is that any different to IPv4?
> I tried enabling IPv4 on my router just now. It asked me for a CIDR range. How TF do I know? I just randomly put 143.156.200.0/8. It's what google search told me to put in. Save changes.
If you (the royal you, as in people) don't know how what they are you expecting it to work?
Totally agree. The UX for IPv6 sucks. Every time I poke with it I get worried I'm exposing the guts of my internal network onto the internet. With NAT, at least I know nothing is getting in without me intentionally punching a hole. With IPv6 to do the same I have to go fiddle with the router's command line interface and rules by hand. And even then who knows if I fucked something up or missed something... its just a lot of work.
There is no web UI for managing IPv6 firewall rules but there is for IPv4. On the consumer grade routers I've touched there isn't even a way to configure the IPv6 firewall rules (and again, they all offer web UX for IPv4 rules).
The interface on the router provided by the UK's largest ISP is almost identical to the interface for IPv4 port forwarding: https://imgur.com/a/NXqwoA6
.local not working might be your router trying to be helpful and snoop multicast to limit it to pairs of devices. Something about iptv optimization or whatever I don't really understand. Since I turned this feature off .local works as it should.
> "we fear change" IT people don't realize they're already using IPv6 on their phones every day,
Is that US specific? Because as far as I am aware only 5G "purposed" ( I am not sure if it mandatory ) the use of IPv6. 5G requires the support of IPv6, but not usage.
Does your phone only have a v6 address though? If it did, you would need some kind of proxy (6to4 [1], the most likely example) connecting to HN's IPv4 address on your behalf.
As the sibling points out, if both site and device support v6 the intermediate translation isn't required.
That's exactly what it is. There is always a proxy, which negates part of the argument, but is a very useful tool in transitioning over the next 2 other decades at least... the way this is going.
> Wait, if my phone is IPv6, then what does it mean that a site 'supports' v6? I can get on HN just fine.
It means that the phone doesn't have to talk through a network-translation box, which may add latency. For some things (gaming?) this may be important, while for others it may not be.
Further, the price of each IPv4 address is going up, and so having your hosts on IPv6 may allow for the lowering of your costs, which you can pass onto your customers or add to your margin.
About a year ago they were US$ 30/IPv4, and they now seem to be in the $50 range:
We use VPS from tilaa.com and they charge 2 Euro per extra IPv4 and for the third etc. address per server one needs to submit a technical reason for doing that that they manually review.
Websites have separate DNS records for ipv6 (AAAA record) and ipv4 (A record). Since ipv6 is not universally supported, the de facto expectation is that if website has ipv6 DNS record, it should also have an ipv4 one for the users who can't talk ipv6.
Your device's network stack first learns if your mobile ISP supports ipv6 or not, and based on that and DNS reply decides how to connect to a given website.
You establish a TCP session with the IPv6 address of that site instead of its IPv4 one by way of getting its AAAA record and your phone having dual-stack networking enabled.
(Most US carriers have IPv6 enabled and issue IPv6 addresses to their phones.)
> What's really interesting is how many of these "we fear change" IT people don't realize they're already using IPv6 on their phones every day, with a majority of the sites they visit.
Not true on my german mobile carrier O2. They only provide IPv4 behind a CGNAT.
Telekom is v6-only (464XLAT), Vodafone and o2 are dualstacking (with CGNAT for v4). You might need need to manually update your APN settings if your phone was set up before they enabled it though.
If I provided users with an IPv6 block to allowlist for my apps, I think most IT directors' heads would explode, but _everything_ works with 32 bit CIDR ranges.
I certainly support it, but I'm not sure we'll see an end to NAT for some time, even with an IPv6 option.
I'll admit to not understanding this position. Without NAT, you could do the same sort of firewalling, where the inbound allow list is driven dynamically. The only thing I can think of is that not using NAT exposes more detail about an internal network. Is that the reason you're hinting at, or is the reason something else?
It's extremely funny how a network with NAT needs hole punching in the firewall and network without NAT sudenly doesn't have firewall at all. Like OK, in 1995 a router would have been a dedicated machine or appliance, but since 2005 anyone can buy a sub $30 device which routes, firewalls, provides a bunch a of (unnecessary) services... but suddenly incapable of firewalling if IPv6 is involved.
> but suddenly incapable of firewalling if IPv6 is involved.
It's been a few years but I've yet to see a consumer grade router that lets you mess with IPv6 firewall rules. I don't even know what these routers use for a default policy.
They all seem to have web ui's for IPv4 firewalls and port forwarding though...
Ever seen an average IPv6 firewall, even on $500 devices?
You can have dynamic prefix that can change with every moment on your wan interface, but then you have static IPv6 rules and you cannot specify something like use current prefix there.
So I understand if the first reaction is screw that.
If my internal network is 10.0.0.0/8 and I have 100,000 hosts and a single IPV4 address that they all appear to be to the public Internet, I’ll sleep a lot better than if I had all 100,000 hosts with public routable IPV6 IP addresses attached to them.
Yes, you can depend on a firewall to protect you but at the very least it exposes information about your internal network and at worst opens you up to future firewall flaws.
I remember the days when people used to have every system have it’s own public IP address. People would scan for broadcast addresses of their networks and we got Smurf attacks as a result. Obviously those wouldn’t work with properly firewalled hosts but it still scares me.
Firewalls are fine but having the ability to make machines unroutable is even more powerful, no?
While I get that firewalls are probably safe like 99.99% of the time… I’ve gotta say, I just don’t trust software to not have vulns of some sort that someone important already knows how to break. So eg for a corporate network I would be hesitant to do this, for my personal network not so much (unlikely that a 3 letter agency gives a shit about what I do).
Additionally. Firewall changes can sometimes fail for whatever reasons so you might have accidentally exposed a node publicly for some time.
Making those nodes not reachable from the internet seems prudent. It’s like your office building has a public address but your office assignments don’t need to be public.
>Firewalls are fine but having the ability to make machines unroutable is even more powerful, no?
For the whole world there is absolutely no difference betwen routable address, non-routable address or even an absense of the machine... behind a firewall with drop all on a public interface.
Your statement doesn’t address the point you are responding to so it makes me think you completely missed the point you are replying to.
You are correct in theory. What you don’t seem to be taking into consideration are firewall vulnerabilities or other unknown things that could happen that make it different from a practical standpoint.
I started an ISP from the ground in 1996. I’ve seen a lot of weird stuff. You seem to just hand waive it away like firewalls are this perfect bastion of security.
Anything smaller than a IPv6 /48 is effectively unroutable. Your ISP has to route smaller blocks, like /64s, privately (because only /48s hit public bgp). And then you have to route the /64 they assign you privately once again.
IPv4 with nat is effectively routing your 100,000 hosts through one of 4,294,967,296 possible IP prefixes (a /32).
IPv6 with a /64 routes one of 18,889,465,931,478,580,854,783 possible IP prefixes to your router. Everything that happens behind that is opaque. There are so many IPs in that prefix that people can't even guess which ones you're using. It's easier to guess internal IPv4 NAT addresses.
The internet can't see your IPs. "Publicly routable" doesn't mean much when you're talking about prefixes.
As soon as one of the computers in the subnet initiates traffic outside the network, its IP address becomes public knowledge though, right? Doesn't matter how large the space is, that information leaks, whereas with NAT it doesn't.
Some of our service providers require us to provide the IP addresses of our services to them for them to safelist. It’s stupid, but it’s not something we can control.
Rather than constantly update them as our servers change, we route through a NAT. I wouldn’t know how to do it with IPv6. Maybe the service provider could safelist a subnet?
They probably wouldn’t support that. Most non software heavy companies outsource these sorts of projects and to make changes to their systems requires a bunch of upfront capital costs which can be expensive so they will push back against changes unless you are big enough to force them to or you convince them of the merits of such changes.
Depending on the type of connection it's fairy easy to set up squid as a proxy for outbound connections so everything appears to come from the squid box which can have a static address and can be added to an allow list
I mean, the original purpose of NAT was to let you move hosts between networks without renumbering them. No one really does that though, your laptop or phone happily renumber themselves when you move networks.
No one's going to use NAT for keeping IPv6 between networks.
Do you know you can have DENY FROM ALL by default in any IPv4 firewall?
Do you know what you would be hardly pressed to find a router without firewall not only in the year 2022, but in the year 2012 too, when there was 10G *switches* capable of routing AND firewalling traffic almost at the line rate?
Exposing your LAN configuration for the whole world to see is insanity. (Yes, we sometimes do this, but only because we still don't have sane VPN solutions here in the year 2022.)
You can have the public IPs on everything in your LAN... and still it would be completely inaccessible to the outside world. Because you know, firewalls exists.
> Exposing your LAN configuration for the whole world to see is insanity
Bullshit. BGP doesn't 'expose' your internal routing configuration and there is absolutely no other way for someone to see how exactly the things in your network. OSPF could be used for it, but it requires: 1) being right next to your router 2) be configured to send on the external interface.
What I haven't quite fathomed with IPv6 is that as a home user without my own AS, am I supposed to use my ISP provided addresses in my internal network? ISP provided addresses that I have no control over and could change at any time? With IPv4, I just use RFC1918 addresses as I like and I have full control over the addresses and their allocation and I can then very easily set up iptables rules, dhcp pools, dns records etc. Then I just NAT at the edge of my network, and the configuration is practically completely isolated from my ISP and whatever addressing they do.
IPv6 has private addresses too. In my network, all computers have 3 addresses: public, private and link-local. All local services use the private ones and those never change. (I don't think they're called "private" in the spec, but the idea is the same)
In addition IPv6 has this weird restrictions on which prefixes are valid. For example if your ISP gives you /64 prefix, most consumer routers will not recognize it as valid. And even if you have a very configurable router it will take lots of work to configure that - even though in theory you should have tons of addresses available.
And if you get a /128 prefix, good luck that - NATs are apparently disallowed in IPV6 world.
RIPE approved prefix lengths for end customers are /48, /52, /56, /60, and /64; though the prefixes longer than /56 are strongly discouraged and probably reflect either an ISP that doesn't get IPv6 or that is anti-consumer if they do.
... "Each hexadecimal character in an IPv6 prefix represents one nibble, which is 4 bits. The length of a delegated prefix should therefore always be a multiple of 4.
A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64.
...
The following sections explain why /48 and /56 are the recommended prefix assignment sizes for end customers.
...
It is strongly discouraged to assign prefixes longer than /56 unless there are very strong and unsolvable technical reasons for doing this."
It's not law but going to hurt your ISP to not give at minimum a /64 way more than it's going to hurt anyone else as everything is made to make doing so easy from standards all the way down to hardware. Besides RIPE is going to hand them a /32 which is ~4 billion /64s without question and will keep doing that 'til the cows come home so it's not like trying to keep all of the customers in a single /64 saves them from running out of anything. Shoot I even got a /32 for a single non-ISP company without much hassle.
Also RIPE reserves the ability to retract the ISP's IPv6 space, though I really doubt it'd come to that. A lot of the original large swaths of IPv4 were considered owned not leased, that is no longer.
NAT is not disallowed in IPv6, it's just discouraged as it breaks end-to-end principle. You can still have stateful firewalls that work for the majority of cases and you can also use NPT (network prefix translation also called 1-to-1 NAT) if you want. There is even a RFC specifying on how to do NPT without creating compute overhead for routers by making the packets have the same CRC.
NAT is actually probably preferred too for homelabbers one because you don’t have to re-address things ever and also because you can use your whole ISP assignment as a pool of dynamically assignable/attachable public addresses.
Not that I know of. I’m using ip6tables with an, honestly garbage, script to give me similar functionality to AWS Elastic IPs.
- Everything inside the network gets a private address from DHCPv6.
- I have a pool of some of my assigned prefix designated as generic outbound which use masquerading and multipath routing so my home traffic isn’t all coming from a single address. This is mostly useless but was fun to set up.
- Then for the rest of the prefix I can create “attachments” where traffic from one of the public ips in the pool is routed to the private address using DNAT and then all outbound traffic from that host is SNATted to come from that public ip.
So the internal hosts can have zero knowledge that they even have a public address, their privates will just start receiving traffic from the internet. When I get a new assignment from my ISP nothing internal will have to change.
I see. Well it sounds like you "should" be using prefix translation instead of DNAT/SNAT (i.e., use the iptables DNPT/SNPT targets instead). Probably doesn't matter enough to change though.
IPv6 has fc00::/7 (everything from fc00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) as the equivalent to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). You can set some private v6 subnet in DHCPv6 and be happy (or do static assignments or whatever suits you).
Also, honestly, using IPv4 on LANs still makes sense no matter what trend the internet goes for.
Exactly. With IPv6 you are expected to have multiple addresses. Some to access the internet with that may change, some that don't change and aren't globally routable to access your own stuff with. Though you can also (if your router supports it) assign hostnames to your devices so you can access them via their non-static global addresses.
If I understood correctly, the link between ULA-based address and host name is done through a DUID. This is assuming that DUID values do not change over time and can easily be harvested from everything you want to connect to the local network. What guarantees that DUIDs are fixed and easily collectable? What are the solutions if they aren't?
You can do this with IPV6, these days it's called ULAs (unique unicast local addresses)[0]. Previously there was a formal prefix allocation to solve for this (site local addresses), however they have been deprecated for a bit now.
[0]: https://blog.apnic.net/2020/05/20/getting-ipv6-private-addre...
There’s already a lot of FUD around IPv6 and I’m not sure that an article which seems to amount to a survey on Twitter really moves the conversation forward much.
Clearly there’s pain points to rolling out v6 (although I’d question how many of them are still an issue outside the glacial pace of Enterprise IT) and we’d be better trying to address that than re-hash the same old arguments.
Edit: not much more than 2 weeks ago we had this chestnut [1] where Nintendo was telling you to forward thousands of UDP ports to a Switch in order to play online but still we hear “but NAT works fine for me”.
I think the decades of dominance of UDP/TCP over IPv4 over Ethernet (which comes with the pre-existing knowledge in everyone, the years of experience working with it for any IT person, the additional workarounds like NAT and UPnP and so on, and even the oldest hardware still reasonably running having full support) has made people think it was all just always easy and obvious from the get-go. Where some of these protocol assumptions and ingrained history didn't exist, like the mobile carrier space, we see by far the most adoption of IPv6 out of any area and even a few non-dual stack players.
The truth is like most topics in computing after 20 or 30 years of using one protocol/interface the baggage, limitations, or cost of the old keep piling up and eventually the new thing is going to seem like less work/cost/baggage than the old.
The thing that seems to be moving it forward the most nowadays is cost and baggage (= complexity = long way around to more cost). The direct cost is per IPv4 prices going from ~$25/per to ~$45/per in the last year alone. The baggage/complexity cost is particularly on the carrier or large enterprise side where ever growing device counts and ever growing public address costs combine to make NAT needs larger and sometimes multi-staged (e.g. CG-NAT).
I think the breaking point will be when we start to see most hosting providers and carriers continue to either push consumers to more IPv6 to reduce NAT load or cost incentivize hosted services to do the same. There are limited instances of this now, an occasional hosting provider offering IPv6 only for a lower monthly cost or a mobile carrier that migrates all of it's users to IPv6 transparently, but there are still more providers/carriers that don't do anything IPv6 than there are that incentivize IPv6. Definitely moving in that direction these last few years though.
What I don't think we'll see is a sudden "aha" moment where people give up IPv4 and stop being uncertain about v6 just because they read about it more or were told some detail.
> I think the decades of dominance of UDP/TCP over IPv4 over Ethernet (which comes with the pre-existing knowledge in everyone, the years of experience working with it for any IT person, the additional workarounds like NAT and UPnP and so on, and even the oldest hardware still reasonably running having full support) has made people think it was all just always easy and obvious from the get-go.
Yeah, it doesn't feel like that long ago when consumer routers with tiny translation tables would crash hard when anything opened a load of connections (think games but especially BitTorrent) because they didn't have much RAM.
I think for most people the switching moment will be something they don't even see - their ISP enables it and off they go.
I'd love to read an honest post from somebody from Twitter (or GitHub or...) on why they don't support IPv6. Not a shaming thing, it's something I don't quite get. Like I get why an old school bank wouldn't: their infrastructure predates IPv6 and it's a project that has to be financially justified and I can understand how that can be hard. But presumably something like Twitter had an experienced networking team, who surely know all the advantages here and want to somewhat future-proof, build up their infrastructure and they decided not to support IPv6 and I would love to understand the reasoning. Is the extra cost really that high?
I have no special insight, but it's probably something like "we're working on it, but there are lots of legacy things that expect v4 (including non-obvious like anti-abuse systems) and since all our users have some sort of v4 connectivity it's not urgent".
I am guessing the reasoning goes like this: if we only support IPv4, then it's on all these ISPs with IPv6-to-IPv4 CGNAT to make sure their stuff works properly (and chances are they will notice if it doesn't). But if we support IPv6, it will be on us to make sure people behind those ISPs can still reach us (because hardly anyone goes via this IPv6 route and if it doesn't work it's likely nobody at the ISP will notice).
IPv6 is also usually faster than ipv4 these days, because the overhead of fragmented ipv4 routing is large. In the past it was slower because of lack of understanding/support for it from larger ISPs, and consequently poor routes, or really suboptimal tunneling setups.
I read all the time about how great the latest technology like Docker and Kubernetes is, and how one should always update every 20 minutes or else you'll have your entire life, much less your identity, stolen by hackers, and besides, who wants to use software that's an entire six months old? And yet, trying to get anyone to upgrade to IPv6 and suddenly the entire world gets super conservative and "hey now! Let's not get too hasty here!" I can't quite square this circle.
I think because the only thing IPv6 really has going for it is the larger address space and the bigger number in the name. That’s not nothing but if IPv6 had been literally just IPv4 but with 8 octets then adoption would have been a lot faster. And it doesn’t help that IPv6rs want to change the internet architecture as well so even if you port you still run into the flame war that is IPv6 NAT that was only begrudgingly was implemented in Linux in 2012.
You can’t upgrade to IPv6 you have to port your code to IPv6. There’s no concept of broadcast domains, IPSec built in for some reason — sorry WireGuard. And because IPv6 is fundamentally different it’s not enough to just be like okay all my shit is IPv6 capable turn it on, you also have to rearchitect your network since everyone builds their network with the concept of public and private addresses and IPv6 is/was openly hostile to it.
TLDR IPv6 made it really god damn hard to just turn it on. Would it have been so bad to just support the way of the IPv4 world for compatibility and then say “hey there’s this cool new thing that’s better” which is an easier sell once you’re already using IPv6.
> IPv4 but with 8 octets then adoption would have been a lot faster.
> You can’t upgrade to IPv6 you have to port your code to IPv6.
There is no physical way to increase the address space without requiring code changes. People having making the same complaint for 20 years and it's even more hollow now then it was then.
99% of the time, you will use your OS standard library functions and completely ignore the networking underneath. Literally, all the libraries will transparently handle IPv4 or IPv6 with no problem.
If you're in the 1% of software that has coding in some implicit assumption of field size for IPv4 then you are the 2020 equivalent of the Y2K problem. Grow your field sizes, fix your regexes, and use the platform support as much as possible.
Finally, you can literally just turn on IPv6. Everything will work just fine. IPv6 has private addresses, you can do all the dumb stuff from IPv4 in v6. Unsurprisingly though, most major vendors don't want to spend a lot of energy supporting those hacks.
It's not that different to v4. Broadcast domains are an L2 concept and still exist (although L3 broadcast doesn't; there's just multicast). IPsec isn't really built in, it was just developed for v6 initially. It uses the exact same address-family-agnostic socket and name resolution APIs as v4 does, so for most functionality the same code handles both.
You don't need to rearchitect your network either, because v6 fundamentally works in exactly the same way v4 does. All you need to do is deploy a v6 /64 everywhere you have a v4 /24 (or /22 or whatever).
There's really not much that's different between them at all... and making v6 64 bits wouldn't have helped either, because that would have the same compatibility issues that v6 does while also not being big enough. It'd be pretty silly to go through all this to deploy a new L3 protocol, only to then have to do it again because we didn't make it big enough the first time.
This seems like a good place to mention a neat trick: If you're behind cloudflare or such, you can probably trivially go pure IPv6 on your servers and not even have to worry about NAT because cloudflare will provide v4 to users that use it. So you end up with (your server) -v6-> (cloudflare) -v4/v6-> (users). (Which I admit is a sort of NAT, just not at the IP level)
> When I try to ping an IPv6 address (like example.com’s IP 2606:2800:220:1:248:1893:25c8:1946 for example) I get the error ping: connect: Network is unreachable. Why? (answer: it’s because my ISP doesn’t support IPv6 so my computer doesn’t have a public IPv6 address)
$ ssh freenas.local
freenas$ ping6 2606:2800:220:1:248:1893:25c8:1946
ping6: UDP connect: No route to host
Crap I should fix that. Login to web-interface, click the "IPv6 Autoconfigure" checkbox, click test, click save.
freenas$ ping6 2606:2800:220:1:248:1893:25c8:1946
PING6(56=40+8+8 bytes) 2600:1700:3d40:6300:6a05:caff:fe58:a370 --> 2606:2800:220:1:248:1893:25c8:1946
16 bytes from 2606:2800:220:1:248:1893:25c8:1946, icmp_seq=0 hlim=54 time=11.408 ms
Wow, IPv6 _is_ easy! :-)
(AT&T is my ISP and it took a bit of screwing around over a weekend with my router a couple years ago to get IPv6 working properly on my home network. But it's been painless ever since.)
If you like tinkering and you've got the AT&T fiber service and don't use the voice/TV U-Verse stuff) you can get significantly better IPv4 and IPv6 performance not using their gateway (even if it's just in bridge mode with every service disabled). It's not officially supported and they actually 802.1x auth the modem but there are convenient scripts out there to proxy the auth packets allowing you to use your own router directly. Particularly helpful for maxing out their gig service or for drastically improving jitter at any service speed.
AT&T has transitioned to issuing a combined ONT/Router, where this will no longer be possible, but apparently the newer gear doesn't have any of the performance issues of the Pace 5268AC.
BTW, I was annoyed that AT&T installed the ONT on the southern wall of my home where it was baking in full sun everyday, so I relocated it myself into my network closet. You can just unplug the ONT and extend the existing fiber with an optical coupler and an SC-APC to SC-APC single-mode patch cable.
Lol HN is amazing, this was actually the first one I got to work a few years back! Kudos for the tool - it worked wonders.
Have you heard what gear they are using for the new >1G deploys? I haven't kept as up to date with ONT/GPON gear the last couple of years but I'm curious what they have that does 5 gigabit NAT.
IPv6 is a 'tragedy of the commons' issue just like recycling: you get no benefits to you individually from addressing the issue.
However the day the issue is solved, and ee can forget IPv4, a myriad issues dissapear - routing, port forwarding, P2P software for torrents and calls, multiplayer games, etc.
As often when people reference the metaphor of the tragedy of the commons, which had no historical basis in reality (quite the opposite), there's more going on here.
IPv4 addresses are a significant competitive moat for incumbent businesses. Existing companies have no interest in making IP addresses a non-scarce resource that aids competitors or alternatives (on-prem hosting, p2p, local ISPs, etc).
The only reason things have begun changing recently is government mandates and that the moat has gotten so big that they've started falling into it themselves.
Tangent, but as someone who often finds the tragedy of the commons as the simplest explanation to many things, I'm interested in hearing your take on it
There's a lot of more qualified people who have written better criticisms of it than I can, but it generally boils down to a few things:
1. Lack of basis in reality. While of course there are occasional cases of communities mismanaging resources, this was and is far from univeral or usual. In fact the english public land that the thought expermiment gets it's name from and claims can not work had succesfully been in common ownership for to my knowledge all of recorded history until it's relatively recent enclosure (privatization).
2. It supposes the commoners would desire infinite short term growth above and beyond what they needed, could personally tend to or the land could sustain. This is both ahistorical and circular logic. In reality commoners had long known the amount of cattle the commons could sustain and allocated limits among themselves.
3. Where examples of over-grazing do exist, it was as a result of deliberate action by wealthy people to drive commoners off of the land for enclosure. This is not unlike the patterns we do commonly see in the real world today, where resource exhaustion generally takes place when there there are big power differences.
4. Far more than as a prediction of reality, it has been successful as a justification for various unsightly things, from land theft and colonialism past and present, to eugenics and global poverty. It is not a neutral description of human nature and historical tendencies, but a distortion of them that aids the wealthy and poweful.
If you are looking for a better alternative I suggest you look at the power relationships between the people who are using the commons instead, it's usually much more enlightening.
Well, you are gonna have to replace port forwarding with firewall rules instead. At least for me, I really don't excited about my parents or in-laws internal networks being wide open to the internet. Thus their entire subnet would need to sit behind a "default deny" firewall. And if they need to expose some service to the internet, they'd need to punch a hole in the firewall--which is exactly the same dance you'd have to play with port forwarding.
The only thing IPv6 brings to the table for consumers is each device gets a globally routable address. But that doesn't mean each device can or should be be reachable from outside the router. One way or another client software will not get away from having to open ports on the router.
The difference is that with a firewall, you open the port and that's that. With port forwarding, you get whatever port happens to be available. If done manually, you have to tell the other sode which port to use. If done automatically (like upnp), you need to do that every time your port changes.
There is no difference of opening a port in a firewall or a NAT (well, as long as there is a single machine that wants to listen on that port, at least).
And some kind of UPnP will still be required even if your internal network were using ISP-assigned IPv6 addresses for protocols that want to open multiple connections, like VoIP conferencing, bit torrent etc.
Of course, if you have an internal network where you actually communicate between your various machines, you won't want to use ISP-assigned publicly routable IPs, since those can change at any time, so you'll also need some kind of network address translation at the edge.
> well, as long as there is a single machine that wants to listen on that port, at least
Well yes, most networks have more than one machine and multiple users might want to run the same service.
> you'll also need some kind of network address translation at the edge.
Not at all, each machine gets two addresses - one routable from the ISP and one non-routable from the router. Internal services simply use the non-routable ones.
> And if they need to expose some service to the internet, they'd need to punch a hole in the firewall--which is exactly the same dance you'd have to play with port forwarding.
The difference being, with IPv4 only one machine in the house can have a port open. You don't just open a port, you choose _which_ single machine gets the port. Sometimes you can't open a port on a machine because the port's already taken.
With IPv6 any/every machine can have the same port open at the same time.
The setup you describe, a default deny firewall, is in fact how consumer routers operate. It's not something you need to configure yourself - router manufacturers do this by default, as recommended by RFC 6092. The idea that IPv6 home networks are "wide open to the internet" is a myth.
Real estate on the blockchain is my favourite bad blockchain idea because if someone loses access to their wallet they presumably lose the ability to ever sell their house.
Nah, it just becomes one of those impediments to sale that you wave aside during purchase and earns lawyers a few bucks.
There are a few of these in England, Chancel Repair Liability is the most famous. In theory you could be forced to pay for repairs to a nearby church you never visit and have no interest in, on account of land you own was historically liable for such repairs and this was never cancelled. A real person, this century, had to pay about £350 000 as a result, so that's not inconsequential (although the circumstances were pretty unusual). But that's scary enough that a real estate lawyer might argue they're not sure the property you want to buy is unaffected, you should take out Insurance against the liability, conveniently sold by another lawyer.
The government tried to "fix" this, but the problem with lawyers is, obviously no fix will be good enough to prevent lawyers saying what if the fix didn't work, so chances are you get persuaded to buy insurance even though the liability probably no longer exists because hey, if I'm wrong I'm not going to pay £350 000 so...
Fifty years from now, if the fact there's "an NFT on the blockchain" for a property you want to buy is even something anybody knows about, your lawyer will know, and they'll tell you that another lawyer offers $1000 insurance, buy that and if "the blockchain" ever tries to sue you and take the property back they'll have your back...
You just gotta etch the block into the foundation. Then it's physically part of the house. Maybe make a radioactive label and bury it on the property. That way people now the property they're standing is on actual property.
The startups in that article don't seem to be selling entire properties on the blockchain though - it looks like they're doing things like buying a property and then selling fractional interest in that property to different investors as tokens.
I'll believe that multi-sig wallets solve this when I hear frequent stories about regular human beings (not highly sophisticated tech insiders) who both understand them and use them successfully.
Or, do what enterprises do with sensitive documents: Store it with a custodian (or a hardware wallet).
Mutli-sig wallets are but one non-custodial solution.
Not long ago, Signal demonstrated a way to recover passphrases in a way that server compromise doesn't really reveal anything at all about the passphrase itself: https://signal.org/blog/secure-value-recovery/ The OPAQUE standard also has similar properties to Signal's design but much more cheaper to implement: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque... I point these out because Novi (Facebook's Diem wallet) implements the latter. These never require keys to ever leave a client device (which inturn could be a hardware wallet).
Useable security will take time. It was a long road from GnuPG to Keybase/Signal. Given the amount of cryptographers and engs building for "web3", I'm sure something useable will crop up. May be it is Moxie himself who comes up with it, who knows? ;)
It isn't as much about blockchain, than what NFTs enable. Properties can be sold digitally, like any other goods are on e-commerce websites, for example. Of course, NFTs aren't strictly needed, but could be used as a cryptographically secure (for some definition of secure [0]), publicly verifiable, record of ownership.
IPv4 addresses have utility. You still need one in order to participate in the largest communication network in the history of the earth. And theirs a limited number of them. Demand + Scarcity = non-zero price.
What utility do NFTs provide other than entertainment/status?
If the address space wasn't assigned to you via a RIR, it won't take long for someone to notice though and get your announcement by enough relevant large tier 1 & tier 2 ISPs that your announcement won't reach most of the Internet.
At that point you can of course use the addresses locally, but you can't reach the rest of the internet.
This type of squatting was somewhat easier in the past when less of the IPv4 space was actually in use and when less strict filtering (or RPKI) was in place.
Still happens, but it's getting harder and harder.
So lets say Centurylink decide to start advertising blocks they don't own, people like Cogent and Tata drop their links, people with multiple ISPs drop their links (shifting traffic to other tier 1 ISPs), and those with centurylink only change their ISP because they can no longer get to facebook.
That would work if most people had multiple ISPs, but most don't actually. Thus, you have some bargaining power, especially if you have some network advantage or feature nobody else has.
If you are leaking routes you shouldn’t then a decent ISP will disconnect your crappy network.
It happens a lot, usually because of mistakes, it’s typically fixed quickly.
Feel free to null route or redirect any IP you want in your network. Just don’t be surprised when other networks cut you off if you advertise those routes out of your network, and don’t be surprised when your customers are unhappy because you aren’t transporting the packet to the target IP as is your job.
If you really believe what you’re saying, which I find hard to believe myself, I recommend you try doing what you’re saying and report back the results.
They're a scarce commodity, and unlike NFTs, have a real use-case.
Until everyone moves to IPv6, if you want people to be able to reach your service, you need an IPv4 address. If you're an ISP or cloud provider, you need those so your customers can still communicate with v4-only peers.
ipv4 addresses are unique in the default free zone.
they cost money because without having a prefix that is unique, you cannot route across the internet.
IPv6 has a political issue. Support for IPv4 addresses (::0.0.0.0) was removed, because IPv6 users were able to connect to IPv4 hosts directly, bypassing IPv4 NAT's and firewalls.
> Support for IPv4 addresses (::0.0.0.0) was removed, because IPv6 users were able to connect to IPv4 hosts directly, bypassing IPv4 NAT's and firewalls.
How's that work? It can't be sending actual v4 traffic or it'd work like normal v4.
IPv6 is large enough to represent the whole IPv4 range. Multiple times. Initially (at the very beginning) it was possible to connect to IPv4 address using IPv6 socket. They were called «IPv4-Compatible IPv6 Address»[0]. For example, I can ping both ipv4 and ipv6 addresses using ping:
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.044 ms
However, this feature allowed to bypass NAT and connect to IPv4 hosts directly via IPv6, so it deprecated. (I skipped names to avoid scapegoating).
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.043 ms
$ ping6 127.0.0.1
ping6: 127.0.0.1: Address family for hostname not supported
It's not a technical issue, see above: it's possible to serve both protocols at the same time. It worked for a brief period. It's purely political decision: backward support for IPv4 in IPv6 was disabled because some people are thinking that such behavior is dangerous.
That's... really not how any of it works, and the ping examples are a red herring.
IPv4-compatible IPv6 addresses basically allows applications to connect to IPv4 hosts using just a single IPv6-compatible network stack. The operating system kernel handles the translation to and from IPv4 native. There's no way it can "bypass NAT" -- that doesn't even make sense, NAT causes the hosts behind a network to all have the same external network, the exact same incoming rules would apply as they always have.
As for ping: back in the 1990s and 2000s, ping only understood IPv4 addresses and an independent command "ping6" was made to work on IPv6. In the mean time, regular ping understand both protocols just fine and you don't need a separate one. Modern Linux distros don't even have a "ping6" anymore.
Ping is just example to illustrate that the problem is not technical in a way which makes it easy to understand. I'm talking about this issue for more than decade (at national level), so I nailed some patterns.
Yes, IPv4 packets and address range are too small to support IPv6, but IPv6 can encapsulate them with room to spare, so IPv6 network can address and handle IPv4 networks and hosts directly. However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network.
For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). Theoretically, when IPv6 will support both IPv6 and IPv4, I can expose my internal IPv4 network via IPv6, which may create security risk, same as for IPv6 native network without NAT.
This is the key problem: people don't want to expose internal networks to the public, so the feature was cut with hope that everyone will switch to IPv6 and this will no longer be a problem.
In 2004, I was lead of OPS team, so I spent some time trying to invent a way to switch our internal network to IPv6, when it will hit mainstream, and found that seamless transition is not possible at all: IPv6 requires switch, because backward compatibility is disabled, just because a corporation asked for that.
You're still confusing unrelated topics in the field.
> However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network.
If they share an IPv6 network, they can communicate over IPv6. If they are truly disconnected from each other with IPv4, they cannot in any way communicate over IPv4, this includes using, for example, "::ffff:192.168.1.1" as an address.
> For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo).
This has nothing to do with IPv4 encapsulating in an IPv6 stack. Instead, you've configured your host to have a public IPv6 address by way of using proxy servers to provide bidirectional communication. If you don't want this, stop using miredo.
> people don't want to expose internal networks to the public
Well, stop doing it. Stop running miredo if you don't want that behavior. Install firewalls and policies to block incoming traffic.
IPv6 doesn't magically transform your NAT'd IPv4 network into a public free-for-all space. You really have to work at opening up that possibility yourself (such as by installing/using miredo). IPv6 cannot in any way bypass a NAT and reach IPv4 hosts directly behind them. Encapsulated IPv4 packets in IPv6 are translated at some point along the chain (typically the computer running the application using an ::ffff:0.0.0.0/96 address) into the native IPv4 networking world where the packets are handled as if the application used an IPv4 address directly. The encapsulated addresses are primarily a convenience factor, nothing else, and no security implications.
(I sort of think you are also thinking of 6to4 and/or NAT64 in this discussion, which can punch a hole through your NAT in the way you are describing. If you don't want this, don't do this!)
Backwards compatibility isn't "disabled" in v6. There are plenty of backwards compatibility methods available.
You can do a seamless transition by deploying v6 and then undeploying v4 once you no longer need it. You can speed the second part up by using NAT64+DNS64.
It was using IPv6 in IP, just like 6to4, protocol 41.
I haven't heard it called a political issue before though. It just had problems, like being blocked in firewalls and security problems where the encapsulated packet wasn't checked properly, etc.
Home servers are not quite as easy as the article makes it sound. Home routers block incoming IPv6 packets, the same as they do for IPv4. To make a home server accessible, you need to explicitly allow that incoming IPv6 traffic in your router's firewall. This is analogous to adding a port forward rule in IPv4 NAT. The only benefit IPv6 has here is you can use the same port (e.g. SSH) for multiple home servers.
A few of these reasons boil down to "it's faster to not NAT". That makes some intuitive sense, but does anyone know of any studies/tests so we can get numbers? Are we talking higher time to first connect? Slight increase in hops/latency on every packet?
The "faster than NAT" argument made very little sense to me. A NAT adds like a few microseconds of latency, nothing to be perceptible for virtually all applications.
Of course these are generalised stats, there will be some users with tunnels which will impair IPv6 performance, while other users might be behind multiple layers of NAT.
> A few people mentioned that it’s much easier to use IPv6 with home servers – instead of having to do port forwarding through your router, you can just give every server a unique IPv6 address and then access it directly.
My ISP firewalls IPV6 addresses on their end, so no ssh to my IPV6 Machines from the outside, not even ping works. I don't know why they do this
They likely still sell static ipv4 addresses, which made sense back in the day, but ipv6 doesn't work with the existing monetization model. I had the same sort of issue and when I called about it they tried to upsell me to a business account.
A lot of residential ISPs block certain incoming traffic (any that doesn't seem to be part of a stream originated at the user side in some cases) by default because many home users who have something open did not open it intentionally themselves so it could be an insured attack vector.
Unless you have a gazillion servers at home, port forwarding through a router is fairly simple and has the additional benefit of a rudimentary firewall. So there isn't a clearly visible benefit for most people. Most people can't even tell whether they're behind carrier-grade NAT. It makes no tangible difference in their lives.
Techies like you and I can appreciate the technical arguments, but if we want to convince anybody else who can actually make decisions for large numbers of ordinary people, we're going to need better arguments.
I don’t get the “firewall” argument. You can use the firewall the same way with v6 as you do with v4, only allow incoming traffic on specific ports, just minus the NAT which makes everything simpler and better for everyone
With nat you have to configure the firewall part and the nat part. That's two separate parts of your config you have to cock up in the same way to let a packet through.
But this is only because everything mainstream that is P2P uses some kind of a centralized relay server. P2P would be much much cheaper for everyone if everyone used IPv6, so it makes a difference.
> P2P would be much much cheaper for everyone if everyone used IPv6, so it makes a difference.
How would P2P work any different in an IPv6 world? You still need to open a port for each incoming connection, which still isn't secure unless the target machine is explicitly requesting this.
Tell that to management. As soon as they hear "P2P" they will decide to perpetuate the status quo that makes P2P hard, because P2P is evil and illegal in their books.
And we sit here wondering why the powers that be are not interested in faster IPv6 adoption. Few if any of the reasons we exchange on HN have any bearing outside of this bubble. A typical business in 2022 still has no incentive to embrace IPv6, facilitate P2P, or make the internet more decentralized.
How would you facilitate P2P in an IPv6 world? Do you stop using a firewall and just let anyone open connections to your machine on any port from the internet? If not, how do you allow connections from peers but not random botnets?
Not to mention, would you really use IPv6 addresses that your ISP assigns for your internal network as a business? Do you really want to re-IP everything if you find a way to switch ISPs?
> P2P would be much much cheaper for everyone if everyone used IPv6, so it makes a difference.
I dunno how true that is gonna be. P2P clients will still have to traverse a firewall that may do deep packet inspection. A lot of the problems faced by P2P will still exist even in a pure IPv6 world.
My office ISP is a mobile phone running a wifi hotspot.
(Don't judge, it's faster than the last ADSL connection at about 80Mbit/s on a good day, much cheaper, and the office goes through about 40GB/month no problem.)
The phone has an IPv6 address but no IPv4 address.
Ironic, then, that the hotspot only provides IPv4 to all connected devices, not IPv6. As a result, all connected devices in the office can only use IPv4.
My home ISP is a mobile 4G router providing wifi.
The router doesn't get an IPv6 from upstream, just IPv4, so it only provides IPv4 to connected devices at home. I have no idea if it would provide IPv6 service if it got one from upstream. It is a little strange that it doesn't get IPv6 from upstream, because it's exactly the same type of mobile data contract as the office phone-router is using.
It's 2022. I've had IPv6 on my servers since about 2003.
But aside from my actual phone, I've never had IPv6 on any device I'm using, living at numerous homes, using many and varied ISPs, working at numerous offices, or anywhere else. Not even when travelling.
I had to turn off IPv6 on my mail server, because gmail.com was rejecting mail from it when sent over IPv6, but not when sent over IPv4.
I use LXD and Docker on some of my servers for containers, and libvirt/KVM for VMs. In theory they support IPv6 but in practice it's easier to work with IPv4 address or port forwarding with them. That means the containers and VMs are only reachable from the internet over IPv4, even when the host servers have IPv6.
All together, anything I do to support IPv6 ends up poorly tested because it's not really used, and everything has to be done with IPv4 in parallel anyway.
I still have IPv6 on my servers, and DNS configured appropriately. But as it virtually never gets used, it seems a bit pointless. Sometimes I don't set up IPv6 on a new server straight away, and nothing is missed.
Depends on the phone and carrier, if i enable tethering (iphone 8) then my connected devices get IPv6 addresses.
Some android tethering implementations use CLAT and only give you legacy IP.
Some old routers might do the same, or might do so by default until you reconfigure them.
Here at least the mobile network uses cgnat for ipv4, but fully routable ipv6 - so the only way i can get inbound connections over the mobile network is to use ipv6.
> Apparently you can buy IPv6 addresses, use them for the servers on your home network, and then if you change your ISP, continue to use the same IP addresses?
> I’m still not totally sure how this works but it sounds cool.
Naively I would say this is completely impossible without some form of your home router (or ISP?) relaying your traffic, or perhaps telling the sender that I am now actually located in a different subnet somewhere. If anyone can have IP(v6) addresses and keep them and take them with you, then wouldn't that result in an unmanageably large lookup table at routing nodes to know where to route stuff to?
So this is typically what BGP is for, but this is definitely not something that is typically offered to residential customers, nor even most business AFAIK. This is what you would typically get with a Direct Internet Access (DIA) connection. This is an uncontended connection where to setup a BGP peering with your provider. You then give the provider some documentation proving you own a range of addresses, and they agree to accept those routes from you via the BGP connection. They then advertise that to their upstream providers, and thus the routes propagate to the entire internet.
There are a couple of gotchas though. Firstly, there is generally a minimum prefix size of routes that will be accepted into the global routing table. For IPv4 I think it is a /24, and for IPv6 I think it is a /32. You can get a /32 from regional IP registry (for free?) but you will probably need to become a member which – last time I checked - costs 3-4 figures a year. You can use a private-AS number though, as you'll only have one upstream provider.
The other gotcha is cost. Depending where you are in the world, a DIA connection will cost in the very rough region of (EUR/USD/GBP) 1/megabit/month, although it becomes much cheaper when going from 1gb to 10gb.
Now maybe there is some cool facility that some nice ISPs offer to bypass all this, if so then please let me know. I'm personally skeptical it would be worth their while for the 0.001% of residential customers that would want this service though.
Source: I run a small ISP. I have some industry knowledge, but not loads.
You can get your own autonomous system, and take your IPs with you when you change ISPs, or have the same IPs reachable through multiple ISPs. This is possible for both ipv4 and ipv6 but ipv6 is much cheaper. Still not really something that makes sense for a residential user. You need to have networking gear that handles routing on the internet, bgp advertisement instead of having your ISP handle it. There are annual fees, you generally need to be on a business plan with the ISP. For ipv4 the minimum ASN size is a /24, it costs around $12k to buy the IPs for a /24. Ipv6 ips are free. It also costs around $1000 in annual fees for an ipv4 asn, ipv6 is less. ipv4 ASNs smaller than /24 aren't advertised outside of your current ISP and aren't really portable.
Currently there are about a million ipv4 prefixes advertised. And about 150k ipv6 prefixes. Some older ipv4 equipment has a limit of 1024k, or near 1 million advertised prefixes. This equipment is usually 15+ years old, but still is what runs the internet. Generally equipment that supports ipv6 can support many more networks
I believe this might be talking about getting an ARIN reservation, as elsewhere it is mentioned that it is not cheap and points to the ARIN fees page. The list of ARIN requirements includes: "You plan to immediately be multi-homed". So you're going to need to be connected to multiple ISPs that will talk to you via BGP would be my assumption.
By now I'm semi-convinced ISPs are deliberately holding back IPv6 in order to make a buck selling static IPs. They charge a good chunk of money per month for an IPv4 address (at least in Switzerland, the UK, and New Zealand), which is basically just rent extraction from artificial scarcity. And it's pretty obvious that once they transition to IPv6 there is no good reason not to give every single customer enough static IPs for a lifetime of devices.
The perspective on this one is rather important I'd say.
To run a service and buying a few IPv4 addresses is quite feasible. But operating an ISP and maintaining either large numbers of prefixes or costly CGNAT hardware at that scale puts it way more into focus.
Of course I'm not implying that IPv6 isn't nice to run inside your infrastructure but I guess it isnt at the top of ones expenses.
I’m surprised at all the people here saying that they can’t get IPv6 to ‘work’ on their home internet connection. In my experience, in the Bay Area, with Comcast cable and AT&T DSL connections in the last few years (5 or 10), it’s ‘just worked’ for any device connected to the router they provide, no configuration required.
I kind of assumed that this was true nowadays for most home ISPs.
I was in the Bay Area when Comcast (finally) rolled it out; it wasn't that long ago; it might have been >5 years now, but definitely it was within the last 10.
Now I'm in the Boston MSA (a very rural place, I know /s); the ISP here, Verizon, does not offer IPv6. (They state they are "rolling it out", but this year will be the fifth anniversary of that.)
Speaking of Twitter, follow @noipv6 for some great commentary and/or heckling of ISPs who make false claims about IPv6 to defend their lack of support.
Thank you! (I have edited my link to use yours.) The link I originally had went bad due to the renaming from “draft-ietf-iab-case” to “draft-iab-case”, so I assumed that the document had somehow vanished, and changed to an archive.org link. Thank you for pointing me to the correct link again!
I’ll add one: for servers accessed only via private networks, IPv6 still allows easy use of globally unique addresses. The finance world is full of IPv4 systems using 10.x.y.z, and there aren’t enough of those addresses to go around.
My ISPs v4 is down sometimes (Vodafone in Germany), while v6 continues working just fine. Severe loss of legacy internet services in those situations (no twitter, reddit, pornhub, battle.net, twitch...)
What is the best way to get ipv6 if your ISP doesn’t support it? I tried getting HurricaneElectric to work for tunnelling on my Ubiquity USG3 but couldn’t make it to work.
Agree and would like to add that you may want to disable ipv6 tunneling for streaming services. (Google it) because they consider it a “vpn” thus you must be a copyright thief. (Yet any other “real” vpn will stream just fine lol)
Joining the other thread about ipmi/iLO interface being exposed to the WAN: make your server non discoverable by the different services that scan the entire internet address space. It is security by obscurity and you must have other layers of security but it’s not an insignificant layer.
IPv6 is cool in theory and the idea of literally everything having its own directly-reachable IP address is extremely compelling, but I never use it because so many services STILL don't support it or don't support it correctly. (As Julia pointed out, some HUGE websites don't have quad-A records, so good luck dealing with NXDOMAIN for like everything.)
Shoot, Kubernetes _just_ got support for IPv6 in 1.23 (it was in beta since 1.20). I know that 6to4 exists and many kernels can do it out of the box, but that comes with problems, as Julia rightfully pointed out here, and at that point, you might as well just NAT over IPv4.
You mean you explicitly disable it? Or you never use sites like Google or Netflix? Why would you get NXDOMAIN for anything with IPv6 enabled? No ISP would only offer IPv6 without IPv4 as well.
You can use the Firefox add-on "SixIndicator" to see which websites support IPv6 and which don't (assuming your client supports IPv6). The add-on shows a 4 or 6 icon in your address bar. https://addons.mozilla.org/en-US/firefox/addon/sixindicator/
I noticed that effectively all my home machines support dual stack right now. I decided to make an experiment and move to only IPv6.
It was a huge mess (the autoconfig functionality, naming, routing) that all sort of failed in ways that involved deep hacking to debug. Ultimately I realized that since most sites on the net aren't ipv6, I'd need to NAT or proxy my traffic to them anyway.
As a LIR you can request network address space tied to your organization. To my knowledge there are almost no cloud hosting providers that support "bring your own IP space". Vultr.com seems
to be the sole exception.
I've read many an IPv6 book and led many an IPv6 projects/in person training classes and, as lame as it may sound, the Wikipedia page is an amazing resource to get the background needed to understand home and homelab setups. https://en.wikipedia.org/wiki/IPv6
I'd recommend diving into the more detailed articles it links on SLAAC (alternative to DHCP, most common way to dynamically assign addresses) and NDP (replaced ARP) for a full understanding. If you want to go all in for v6 only setups with access to the v4 internet NAT64 is worth reading as well.
Obviously it doesn't cover how to configure/implement for your specific scenario but it gives a solid background that lets you better understand what guides for doing it with Linux or prosumer hardware or typical consumer hardware are actually talking about.
The NATs work as VPNs to a large extent. To quote Steven Wilson from Europol: "The issues relating to CGN, specifically the non-attribution of malicious groups and individuals, should be resolved."
I set up IPv6 on all my servers in 2001 and thought we'd all be on IPv6 in just a couple of years :P
What's interesting is how much resistance there is to adding IPv6 which comes from entrenched IT. People who never learned (much) about IPv6 seem to be afraid of it and often respond with some variant or another of "don't fix it if it ain't broke", or "it's extra work for no return", or "we'll have to pay licensing to add IPv6 because we bought crap routers, so let's not", et cetera.
My favorite is, "we have no record of people trying to use IPv6" - yes, that's real :D
It just shows their ignorance. Adding IPv6 has myriad advantages - no need for NAT, proxies or port forwards to share addresses, no need to renumber networks if allocations or upstream change, redundancy, valid security-through-obscurity (imagine port scanning a /64 looking for open ssh ports)...
What's really interesting is how many of these "we fear change" IT people don't realize they're already using IPv6 on their phones every day, with a majority of the sites they visit.