Reasons for servers to support IPv6
jvns.ca
jvns.ca
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.
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.
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:
As the sibling points out, if both site and device support v6 the intermediate translation isn't required.
It'll be NAT64.
(Most US carriers have IPv6 enabled and issue IPv6 addresses to their phones.)
Many think cost of ip4 addresses but that hasn't panned out with solutions like NAT.
It is one of the more frustrating parts of trying to explain why we don't all just jump to do this.
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.
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.
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.
So I stay with IPv4.
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.
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.
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.
For example see the video "T-Mobile’s path to IPv6 Only":
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
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.
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.
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.
I’ve never accidentally let something through NAT.
But accidentally not configuring a firewall? Everyone does that and has done that and will forever do it.
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.
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.
From a quick search, UPnP seems capable of automating this for user convenience, especially with stateless addressing.
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.
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.
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".
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.
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.
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.
Umm, the IPv6 firewall interface is exactly the same as the IPv4 firewall interface on UniFi[1].
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.
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)
Mine at home is configured to change every 30 minutes.
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 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.
You’ll lose weight in a famine but nobody would suggest it as a diet plan.
What overhead does NAT add compared to a L4 firewall?
> plus losing functionality that cannot operate through NAT.
What functionality does NAT prevent that a L4 firewall doesn't?
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.
[1] https://tailscale.com/blog/how-nat-traversal-works/
[2] https://www.computerworld.com/article/2556611/nat-traversal-...
edit: formatting
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.
You need a defense at depth, not a crunchy perimeter with a squishy inside.
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.
It was in the parent comment!
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
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.
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...
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.
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.
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").
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.
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?
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.
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."
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.
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.
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.
I use a UDM Pro by the way.
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.)
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?
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).
I wish my edgerouter had something like that...
fd::1
fd::2
fd::3
You can even do:
fd::10.0.0.1
fd::10.0.0.2
I certainly support it, but I'm not sure we'll see an end to NAT for some time, even with an IPv6 option.
https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...
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?
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.
Not true on my german mobile carrier O2. They only provide IPv4 behind a CGNAT.
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.
- 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.
It’s port forwarding on steroids!
A /64 is the most valid IPv4 prefix there is. Most consumers should be given multiple (usually about 16) and the router starts with the first one.
> And if you get a /128 prefix, good luck that
No kidding, that's a single address subnet!
> NATs are apparently disallowed in IPV6 world.
It's allowed it's just not the right answer in the vast majority of cases.
https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-...
... "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."
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.
Also, honestly, using IPv4 on LANs still makes sense no matter what trend the internet goes for.
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”.
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.
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.
- IPv6 is basically an abandoned standard. I wouldn't expect them to support gopher either.
- Residential ISP support for ipv6 is spotty, and anyone who does offer ipv6 offers ipv4 as well.
- When it is supported, ipv6 tends to be substantially slower than ipv4 in practice.
- The addresses are a pain to look at and work with.
- You now have twice as many things to fail.
https://www.google.com/intl/en/ipv6/statistics.html
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.
It should be a greater proportion by bandwidth, cause several huge sites support IPv6 (Netflix, Youtube, Facebook etc), but I can't find figures.
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.
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.
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.
$ ssh freenas.local
freenas$ ping6 2606:2800:220:1:248:1893:25c8:1946
ping6: UDP connect: No route to host
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
(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.)
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.
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.
And my free time isn't billable.
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.
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 scarce due to lack of foresight and useful.
NFTs are scarce by design and useless.
So, I know of one real-world usecase that's not useless: Some startups have begun legally selling properties (homes, ranches, plots) via NFTs.
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.
Some are covered in this article: https://archive.is/k3w7F
> ...if someone loses access to their wallet they presumably lose the ability to ever sell their house.
It is software at the end of the day and seems like there is already a solution for it: https://en.bitcoin.it/wiki/Multi-signature
At this point what is the blockchain providing that normal title records don't?
[0] https://moxie.org/2022/01/07/web3-first-impressions.html
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.
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? ;)
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...
That's rich
What utility do NFTs provide other than entertainment/status?
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.
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.
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.
How's that work? It can't be sending actual v4 traffic or it'd work like normal v4.
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.
> The "IPv4-Compatible IPv6 address" is now deprecated because the current IPv6 transition mechanisms no longer use these addresses.
«We forbid you to go right because we are going left.» It doesn't look like a technical issue. How I should call it?
$ 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
$ 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
[0]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
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.
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.
> 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!)
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.
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.
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.
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 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.
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.
One of these scenarios is obviously just broken.
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.
https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-ka...
A fast NAT gateway which is lightly loaded might make little difference, a heavily loaded one can make a big difference.
Google stats also show slight latency improvements for IPv6: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
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.
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
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.
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.
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?
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.
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.
(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.
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.
> 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?
How does that work?
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.
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
v6 is a mechanism like container ships. It will dominate when the incentives and disincentives make sense for the participants.
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 kind of assumed that this was true nowadays for most home ISPs.
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.)
https://datatracker.ietf.org/doc/html/draft-iab-case-for-ipv...
(EDIT: Updated to non-archive link provided by cesarb)
What would be the best way to get ipv6?
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.
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.
Let me know when we're ready to turn off IPv4.
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.
And the way to "resolve" it is IPv6.