Why should I spend the time and energy to deal with IPv6 when disabling it fix many issues ? The listed advantages are not worth the troubles in my experience.
It's not so much that the advantages of IPv6 are all that compelling. Rather, it's more that the mechanisms put in place to deal with a nearly-exhausted IPv4 pool (NAT, and CGNAT in particular, etc.) are not great, and any opportunity to negate the need for them ought to be pursued.
But you still need these mechanisms for the time being. And personally, I do like NAT. I'm not a fan of exposing my internal networks to the internet. Having everything hidden behind a single address is neat.
As has been discussed ad nauseam, getting rid of NAT does not mean all your hosts are exposed. You would still have a firewall, and managing that firewall is much more straightforward when one doesn’t have to deal with address or port translations.
My current internet provider doesn't support IPv6 so I'm good. I noticed that removing the AAAA records in the DNS configurations of my domains magically fixed a lot of weird network issues reported by the users.
Increased number of available IP addresses, improved security features, simplified network management, reduced network complexity, and support for new technologies. The adoption of IPv6 will lead to cost savings, improved network performance, and increased scalability. Scalability may not matter in the typical home network, but in an enterprise environment, the cost of up-keeping the network backbone is significant.
I keep hearing this, but it doesn’t seem more simple to me. My ISP won’t reserve me a /48, so I can’t control the management ips of devices on my network. The solution is apparently to set up dynamic dns, which I have no interest in doing.
But that's in a world where IPv4 doesn't exist. But it does, so I see an increased number of available IP addresses that many people can't access, so you must keep an IPv4 stack which makes everything more complex and more expensive.
I understand the support of new technologies but IPv6 is 27 years old.
Making your computer traceable on the internet is not a security feature but all the contrary, it is a threat to security and privacy.
Cracking and Hacking world is awaiting with open arms IPv6 because a pain in the ass called NAT was removed from the specification, and only a tinny exploitable fence was left for Router's future. Now the enterprise environment will have their needed paid additional security devices with their scalability while the average user at home have to cross fingers for not being the target of a zero day. Tracking Advertisers are also very happy.
Its sad to hear about the supposed reduced network complexity when its needed even an external DNS service for being able to manage your own network at home, lets say your NAS with audiovisual content as mere example, what forces one to create additional secondary real local networks if one don't what to rely in external DNS services for to being able to know the IP of your own device.
The advantage mostly falls to the infrastructure. In theory it performs better, but only marginally, which is quickly overwhelmed by simple issues like inferior routes. As an end user, frankly I stopped caring long ago.
IPv4 is now stretched to the point that you often end up requiring multiple layers of NAT, such as carrier-grade NAT plus endpoint NAT. That reduces the reliability of pretty much all protocols and makes any protocol doing peer to peer communication really hard or even impossible to run. The latter includes tons of games, video chat, peer to peer VPNs, decentralized social networks, and so on.
These problems will only get worse from here on out, but they're not as visible to people outside networking because this degradation of quality of service is a slow creep. The IPv4 Internet just gradually gets more and more limited in capability and less reliable for anything beyond the most basic use cases.
IPv4's address space is simply too small. There are already almost twice as many people on Earth as there are possible IPv4 addresses, and that assumes perfectly efficient utilization of IP addresses which is pretty much impossible. In reality there are probably 8-10X as many humans as viable IPv4 addresses. If every human being tends to have a computer and a phone that means there's at least 20X more devices than IPs.
> If every human being tends to have a computer and a phone that means there's at least 20X more devices than IPs.
You know, that used to be only "if every human being tends to have a computer", since phones didn't have an IP address. Now it's "a computer and a phone". A few years down the line, you'll have "a computer and a phone and a watch", then "a computer and a phone and a watch and a standalone VR headset", and so on.
I get that there are people in the world with severe lack of IPv4 addresses and this is a valid reason for them to switch to IPv6.
However, assuming that I and my organization have enough IPv4 addresses (without requiring any of the tricks of multiple layers of NAT), is there a sufficient reason for us to justify the effort/expense of changing what works?
_You_ might not need to deal with the tricks of NAT, but more and more, your customers _do_.
For example, I'm in the US, and my mobile device has an IPv4 IP sitting behind the mobile provider's CG-NAT. My mobile device also gets IPv6.
Since you only provide your site over IPv4, that means my opinion of your site is governed in part by my ISP's CG-NAT, which you do not control. If the CG-NAT is overloaded, or otherwise having issues, that will manifest to me as problems with your site. I will assume the problem is with your site, and take my business elsewhere. In this example, if your site was also provided over IPv6, then my phone would have skipped the IPv4-only CG-NAT, and things would be fine.
I disagree, because as of now the vast majority of top sites are IPv4-only (see e.g. http://www.delong.com/ipv6_alexa500.html for semi-fresh stats) so if someone gets bad experience on my IPv4 site, they will not assume that the problem is with my site, as that will match their overall experience with most sites on the web.
Perhaps you will diagnose the issue as caused both by the combination of your ISP flaws and my choice to be IPv4, however, the vast majority of users definitely won't, they will notice that most of the web (i.e. IPv4 web) sucks for them but doesn't suck for other ISPs and will put on the pressure on your ISP to get their stuff working to properly support the IPv4 net (or take their business to another ISP) instead of putting the pressure on IPv4 sites to switch to IPv6 or taking their business to another site.
IPv4-only still has enough critical mass (and will have for quite a few years still) to ensure that 100% of ISPs in the world have to support decent service for IPv4 only servers; IPv6-only does not yet have enough critical mass to ensure that all or even half of servers have to support decent service for IPv6-only clients - this is a quite literal chicken-and-egg problem for the motivation to switch.
I'm a little concerned about that site: For its test connecting to Google, besides using port 80 (instead of 443), it reports "500 Can't connect to google.com:80 (No route to host)". I just tested to Google IPv6 ports 80, and it works fine for me.
Regardless, Google's chart of IPv6 adoption (https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...) continues to trend towards IPv6 adoption. I expect that if you looked at a chart of web site IPv6 adoption, it would also be trending upwards (though not at as steep a rate).
If that's true, then it stops being a chicken-and-egg problem, and turns in to a game of chicken: Who starts supporting IPv6 first, you or your competitors?
> However, assuming that I and my organization have enough IPv4 addresses (without requiring any of the tricks of multiple layers of NAT), is there a sufficient reason for us to justify the effort/expense of changing what works?
No, unless you're running servers for users who might have those issues on their side (e.g. anyone accessing your servers from mobile). May as well wait until you can save money by giving up your IPv4 addresses.
Increased number of available IP addresses, improved security features, simplified network management, reduced network complexity, and support for new technologies. IPv6 also provides significant performance benefits for mobile networks, IoT devices, and cloud services. The adoption of IPv6 will lead to cost savings, improved network performance, and increased scalability.
Unless you're calling NAT "more secure", yes, I maintain that IPv6 is more secure. It simplifies network security operations and especially makes it easier to understand your network when you start visualizing logs and data with a real threat hunting platform. Try dealing with IPv4+IPv6 vs IPv6-only in one of those dashboards.
IPv6 being more secure used to be feature back when IPsec was cool. IPv6 has better integration with IPsec. But everyone is using TLS and other more secure VPNs these days.
Less operational complexity. VPN overlays for remote management, realtime peer to peer video and audio streaming, etc. just work reliably. You also get to build the address plan to fit your (business) requirements instead of working around which addressspace is available where.
OPEX and CAPEX costs are significantly reduced with native IPv6 vs large NAT deployments. Adding layers to stretch IPv4 = complexity/gear. Gear/complexity = higher costs.
And if you're already moving away from perimeter defense, to more identity based zero-trust, the move to IPv6 makes much sense.
It is unfortunate that businesses are behind in rolling out IPv6. I get the impression that IPv6-only is more doable and has more advantages for business. It is feasible to run NAT64 in business cause don't have to support as much old software like games that people want to play. It helps with internal addressing issues which get complicated in big companies with acquisitions. Finally, it adds a security barrier between IPv4 for external and IPv6 for internal.
But upgrading a working network is lots of trouble. Most existing businesses have plenty of public IPv4 addresses and don't have to conserve.
The benefit for the business is their eng team isn’t bogged down by working around ipv4 network cruft on big networks. On small ones it probably doesn’t matter yeah
I am quite happy that all those shady IoT devices cannot be reached from the internet directly when I am using IPv4 and NAT - what would be the best way forward to keep it that way in a IPv6-only future?
The best idea I can come up with (at least right now) is: put all less trustworthy (read: Closed source) devices into a special legacy IPv4 network and only use IPv6 on my workstation and little Raspis?
Yeah, it seems to be the common consensus to just block everything going in and just make exceptions, where you really want to offer a service to the internet.
Makes total sense, thinking about it. I guess, all those years of just sitting behind a NAT makes one forget all these networking basics if you're not using them regularly.
Moving closed-source IoT devices into a special vlan, with some even more rigid rules (something like: only allow http/https traffic into the internal network) might be an additional level of security.
You'd probably do it in the same way you'd do it with NAT, by using a stateful firewall blocking inbound connections (it's just that you get this for "free" with NAT)
> what would be the best way forward to keep it that way in a IPv6-only future?
Firewalls. You configure what traffic should be allowed from who to who. Default deny incoming traffic, and its the same behavior as when you had a NAT.
Something having a routable IP address doesn't mean it needs to receive all traffic addressed to it.
The problem I have had with this setup is allowing inbound traffic to things that need it becomes tricky. Some devices don't support DHCPv6 like Android) and some firewalls don't let you do suffix matching. With a dynamic block via PD, the rules to allow inbound traffic to say an Xbox become quite complicated.
You can still have a firewall on the router level, just as you do with IPv4. You shouldn’t allow any external traffic by default anyway and NAT shouldn’t be a security measure.
I know, I'm saying that when you want to embrace global routable addresses for outbound AND inbound, it's hard with Prefix Delegation and spotty DHCPv6 support.
ISPs should be forced to let customers get IPv6 prefix reservations. Yes, PD doesn't change for most, but I'd rather not use PD at all.
My ISP does not allow BYOM (bring your own modem) and assigns me a /64 net, so I have a hard time running an (ipv6) router behind it that would do the firewalling.. I guess I'm stuck with ipv4 for the time being...
A firewall can be run "in-line" and not have IP addresses on the interfaces. On a Palo Alto firewall this would be a "virtual wire", and "transparent firewall" or "bridging firewall" would be other common terms.
Thanks for the hints. Currently, I have a fully routed setup with two routers behind the IPSs box, multiple wireless networks and VPN uplinks (via wireguard) to my servers. It's just that all of this is ipv4, because I don't see any way of doing that using a single /64 network.
ISP uses DS-Lite: ipv6 is native, ipv4 is 4-in-6/CG-NAT. When
I switch to bridge mode, it loses ipv6 connectivity, so sadly, that's not an option if ipv6 is the goal.
I'm not very familiar with DS-Lite. My ISP also uses CG-NAT but I get my connection details over DHCP - both native v6 with /56 PD and the v4 CG-NAT 100.x.x.x IP. That means I connect my OpenWRT router directly to the ISP's plug in the flat.
You said v6 is native for you, but if you put the modem in bridge mode you lose v6 connectivity. Why is that so? Shouldn't you lose v4 instead, which relies on tunneling?
> I am quite happy that all those shady IoT devices cannot be reached from the internet directly when I am using IPv4 and NAT - what would be the best way forward to keep it that way in a IPv6-only future?
The same exact way you do it right now.
Think of NAT as an implicit default-deny firewall rule, that's all it's doing.
Basically any firewall worth using will do exactly the same thing in IPv6, deny unsolicited inbound traffic unless explicitly allowed.
For some reason there's this belief out there that a device having a globally routable IP address inherently means it's globally reachable, and that's just not true. Your firewall still works exactly the same way.
Not to mention that 99.99% of IoT devices connect to the mothership using an outbound connection, which is permitted by default on both IPv6 and IPv4+NAT.
But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.
If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.
Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.
Lots router have UPNP disabled or blocked, and thing still work. UPNP isn't great.
First The firewalls are stateful. Client inside your network attempts to connect to some system outside. The firewall adds an entry to the state table with client ip, destination ip, protocol, ports, and so on. If an incoming packet is received by the firewall, the state table is checked. If there is an matching entry for the ips, proto, ports, etc, then the packet is forwarded. If there is no match the packet is dropped or rejected depending on your config. So it is easy to permit packets based on the interface it was received or transmitted on.
Ports can be opened for some incoming traffic pretty much the same with as IPv4 using STUN, TURN, and so on.
Past that, you can do manual port forwards the same way you do with IPv4.
I understand how stateful firewalls work. But to allow game servers etc to run, you need to explicitly accept incoming connections somewhere, as you don't know the IPs in advance that will connect.
Then if you're using STUN and TURN (which you'll have to, because non technical users do not find configuring firewalls easy) then what is the advantage of IPv6 to a consumer? There is no real p2p benefits.
I'm trying to call out this contradiction:
1) You need a firewall on IPv6 instead of relying on NAT, otherwise everything is routable globally and insecure
2) There will be this glorious new p2p world for consumers with ipv6
If you need a firewall, then really for non technical users you cannot have this p2p world. It is too complicated.
Every guide I see tells you to disable Upnp (or IGD, the part of UPNP that lets you open ports), for good reason. It's a protocol that just disables the security you thought you had before.
The reason Xboxes need port forwarding in the first place is that IPv4 relies on NAT. The unreliability and unpredictability of NAT means remote devices won't know what ports to talk to or if those ports will even be mapped to the right device. IPv6 removes that problem all together! It alleviates the need for 99% of the port forwarding cases that UPNP provides, assuming you've manually enabled it in the first place.
If port forwards are really necessary for Xboxes to work, then IPv6 brings another advantage: you can run multiple Xboxes behind the same IPv4 address. That IPv4 address can be your home connection, or it can be a thousand people behind CGNAT. In countries where CGNAT is the norm (India comes to mind) you can't possibly expect UPNP to be a requirement for Xbox to work!
UPNP is just fine assuming a secure implementation (some of the early ones were awful, but that doesn't make the concept bad). It doesn't reduce security anywhere near like what is made out. If you already have a device on your network that is compromised and is able to do UPNP requests, then you have a much bigger problem (in a home setting).
But IPv6 doesn't solve the problem at all if all incoming connections are blocked on the firewall - which they have to be for security! You need some protocol for the xbox to be able to tell the firewall to open ports, which doesn't exist. Or users have to manually set the firewall rules, which is the same as port forwarding on NAT from a users perspective (ie impossibly complicated)
You can run multiple xboxes behind NAT right now, they get different ports.
Again, for a non technical user there is no major difference between being behind CGNAT IPv4 (impossible to get incoming connections), and firewalled IPv6 (possible to get incoming connections, but the firewall is too complicated to use so it may as well be impossible). If there was a protocol which would allow devices to open ports on IPv6 firewalls programmatically similar to UPNP it would be entirely different, but there isn't.
libupnp/miniupnp seem to support IPv6 pinholes just fine through WANIPv6FirewallControl. I don't sell routers so I don't know how up to date the libraries on your average router firmware are (most likely "ancient") but this isn't a protocol problem. If you run firmware like OpenWRT you've had support for it for at least five years now.
Most consumer routers I've seen these days come with UPNP disabled by default, though.
For most P2P traffic (which includes a third party handshake server) you can probably skip port forwarding entirely; just send UDP packets both ways and the firewall will figure it out. For stateful protocols like TCP and friends (SCTP etc.) that's harder to accomplish this, that's where you need pinholing.
It's possible that your router simply doesn't support IPv6 pinholing but I think the more likely scenario for breakages is that client software doesn't bother implementing it.
That said most "P2P" traffic is still mediated by a central server though and does not need this. The lack of port remapping from NAT means that tricks like UDP hole punching work simply and reliably rather than the semi-random performance seen through NAT. Multiplayer gaming, VoIP, voice/video chat, etc. where a central server does the setup doesn't need ports opened to the world, it just needs to punch a hole for that specific session. A SIP phone opening a port forward on 5060 for itself is a bad thing, but it's sometimes needed in the NAT world.
True unsolicited incoming traffic will still need an allow rule but that's a lot more rare.
> If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.
I disagree. These days the sorts of things normal people do that deal with P2P connections are pretty good at dealing with NAT, but far from perfect. You don't have to look far in to the gaming world to find people complaining about not being able to join a session, not being able to connect to voice, etc.
Any VoIP provider serving users on their own internet connections is going to be doing things like regular keepalives, setting their media systems to accept RTP from and send it back to whatever port it comes out of the user's NAT on instead of the one it's supposed to be on, etc.
All these things work pretty well, most of the time. But they're not perfectly reliable because every NAT implementation is different in subtle ways.
> Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.
As noted previously, in IPv6 it doesn't need to open the port at all. Anything the Xbox, or any other modern game console, will be doing is server-mediated P2P for which standard basic UDP hole punching is a perfect fit.
Basically anything that definitely always requires a port forward in IPv4 NAT will probably still require an allow rule in the firewall, but anything where port forwards aren't supposed to be required but sometimes they help some people more reliably connect is a problem caused entirely by the NAT and those problems go away. Hosting a dedicated game server is in the former category, playing games is in the latter category.
There's a reason all the modern consoles include NAT tests in their network diagnostics, but can only offer vague suggestions at the fix, because how the NAT is breaking things varies by the NAT and may or may not be fixable. The only real fix is to eliminate the NAT.
FWIW Xbox prefers IPv6 when available and Xbox Support specifically recommends having it enabled if you can. That tells me that it works either equally well or better than IPv4 in the real world, which fits my view of things.
Put internet of shit devices on their own VLAN(s). Almost all wifi APs today support multiple SSIDs with separate VLANs. Have your firewall block inbound connections to devices on that VLAN. Every OS firewall has built-in support for this.
I spent a lot of time figuring out how to do all this in the most efficient way (in terms of my time and effort) during covid, and I suggest getting any arbitrary box with 2 ethernet ports and putting freebsd on it.
I actually thought about that for a minute when I set up my home network a while ago, but that seems to be a pretty hard (or at least inconvenient) problem.
Often I need to access a device from my local network (think: use my phone to control Wi-Fi LED Strips, Sonos speakers, etc.), which makes it impossible (I guess?) to separate these devices into their own network completely (if they aren't controlled by an online service in general). Or is it possible to allow access from my trusted network INTO the restricted network, but not the other way around?
Total network noob here, in case you haven't figured that out yet. :)
Each of the VLAN is (or can be) just another network from the router’s and firewall’s perspective. So you just have to set up appropriate firewall rules to allow traffic between the networks that you want to communicate.
You could, for example, allow only TCP traffic initiated by hosts in the “normal” VLAN to hosts the IoT VLAN. So IoT stuff can’t initiate outgoing connections to any other network, and can only receive TCP connections from one network.
You can also set up an MDNS reflector on your router if your IoT devices use that (e.g. HomeKit) to send data proactively back to “normal network” hosts.
There are mDNS repeaters that can in some cases make bonjour work across different networks. In my experience I spend more time fighting with mDNS than I do enjoying it.
I go one further - the IoT VLAN (Sonos, Philips Hue, wifi controlled light strips, TV's) is hard segmented from my "trusted" VLAN (except for some specific holes punched so things like SSDP and streaming from a media server work).
It's worth noting that NAT is not a security feature in itself, but rather a way of conserving public IP addresses and hiding the internal network structure. The best way is to use a stateful firewall that is built into nearly every router.
Another option is to use IPv6 Unique Local Addresses (ULA), which are similar to private IPv4 addresses and can only be used within a specific site. This approach enables internal connectivity for devices that do not require direct access to the Internet. I use it for several IoT devices that I do not want reaching out to the mothership.
Although I'm going to get comments saying this is wrong...
What I did was:
- IPv6 DHPC - private address range within: fc00::/7
- IPv6 NAT, same as for IPv4.
- Firewall.
Why:
- digital ocean only allowed ~16 IPv6 addresses.
- I wanted a local IPv6 network exiting through digital ocean.
- I see no reason to give public route-able addresses to each device in my home (allows remote websites to determine who is calling it and set up profiles/target each remote device).
- Sure, privacy extensions which cycle unique addresses, but it still allows profiling based on source address, even if a bit of work is needed for each new addresses.
Why would your firewall allow your ipv6 IoT devices to receive inbound connections from the internet? Whats the difference between "ipv6 Nat" and a firewall when theres not likely to be any address overlap.
> Why would your firewall allow your ipv6 IoT devices to receive inbound connections from the internet?
It does not, problem is with outbound connections.
> Whats the difference between "ipv6 Nat" and a firewall when theres not likely to be any address overlap.
Outbound connections can be profiled by remote websites.
With NAT (Well... Port-address-translation to be fair, so single outgoing address), traffic can't as easily be profiled.
Imagine ISPs/Ad providers having easier time identifying you, your spouse, your kids, etc. (and device, and so on just by observing addresses)
With initial SLAAC it is even nicer as MAC address is included in the address... Can look up device much easier just cross reference manufacturer database...
I think NAT is a bit of an unfortunate "janky" solution of addressing protocols (giving some security and some address expansion, and sacrificing interoperability and connectivity). I think the security part should be fixed by proper firewalls and/or authentication -- in fact some kind of security mechanism should be default for home routers and such.
I think ideally we should also think of new interoperable defenses that fill the NAT gap. Perhaps each device should have an authentication key apart from its IP, which it could pass onto trusted devices like local network routers, which would only allow authenticated incoming data. Maybe even better would be a global scheme including this authentication and also more private addressed (than IP), although that would probably require a redesign of IP and might be a project for the far future.
Unlike in IPv4, in IPv6 there is a lower risk of nodes assigning the same IPv6 address if there's no central DHCP. This is because IPv6 uses a unique interface identifier (IID) that is automatically generated by the node based on its MAC address and a random value. This makes it highly unlikely that two nodes on the same network would generate the same IID and therefore, the same IPv6 address.
For some time now, it's not unusual for systems to have multiple, publicly-routable IPv6 IPs. Right now my macOS system has four randomly-generated IPv6 IPs, which are being used for internet traffic. New IPs are generated regularly, and old ones eventually get removed.
And thanks to Duplicate Address Detection, before a new randomly-generated IP is used, a check is made to ensure it is not in use by someone else.
Firstly, normally nodes base their automatic IPv6 address on their MAC address, so there will be no conflict between these, since MAC addresses are supposed to be unique to the hardware. Otherwise, it’s a random 64-bit number (actually a few less bits, but not many). It’s very unlikely a collision will happen. And even if it does, there is a protocol (Duplicate Address Detection) to detect it, and avoid it.
Personally, I don’t feel the need for privacy at this level of the protocol stack, and if I did, I would not consider IPv6 Privacy Extensions to be adequate. Also, I might like to keep TCP connections alive for more than a day. Therefore, I personally prefer regular MAC-based SLAAC, or even hard-coded addresses, over randomized and rotating addresses.
You can generate sqrt(2^64) random suffixes before the probability of collision becomes significant. That number is in the billions for a single /64 network.
The IPv6 transition is challenging because it requires coordination and cooperation from many different stakeholders, including site admins, CDNs, network designers, and device manufacturers. However, as the author realized, IPv6 is ready for prime time and offers significant benefits over IPv4. Looking forward to the transition to IPv6 for unlock its full potential for a more secure, efficient, and connected internet.
Microsoft's GitHub Actions (continuous integration) runner machines do not have IPv6, and cannot be used for things like unit tests that require an IPv6 network interface for whatever thing they are testing.
I have built a couple of dual stack Kubernetes clusters already and they work much better to be honest.
Most of the problems are solved and especially for node-based-ranges it works really well. Even in ipv6 only mode calico will manage amazingly and so do my OpenWRT routers.
HOWEVER,
My ISP regularly messes up with its ipv6 routing (deutsche Telekom (so as big as it can get for me) and if that's not the problem, the mesh networks on my (current gen) fritz networking equipment (very widely used in de) eats itself and sometimes just routes my traffic to nirvana.
This is especially bad with online gaming services like xbox live, who for the love of themselves don't have a fallback to ipv4 implemented, once ipv6 drops. "i have an ipv6 so I'm gonna use it no matter what".
Therefore I have dual stack vpns hooked up to my office network which connect to the datacenters I am using. My private network is ipv4 and sadly will remain like that for a while.
Yeah I found the same on Hyperoptic in London. Works fine 99.9% of the time, but occasionally ipv6 drops until I restart the router/restart the WAN connection. Which of course I barely ever notice because most stuff switches back to ipv4.
I think unless we start seeing ipv6-only stuff this will be the case, there's really no incentive for a lot of testing/debugging on at least consumer ipv6 connections until stuff actually breaks.
Would be cool if Google added a 'ipv4' warning to Chrome similar to how they do with HTTPS (maybe not as strong though). That would drive a lot of adoption.
> Would be cool if Google added a 'ipv4' warning to Chrome similar to how they do with HTTPS (maybe not as strong though). That would drive a lot of adoption.
You can kinda already do this by setting search to ipv6.google.com
Images search does not work on that domain, looks like the new Google devs don't know about it.
> My ISP regularly messes up with its ipv6 routing
Can you expand on this? I recently upgraded my network to support ipv6 but a big concern I have is what if they (Verizon Fios) change my assigned block? How can I make sure my PI hole and server has the same static IP address?
In that situation, don't connect to your pi hole using its GUA (global address, starting with 2), connect with it's ULA (link-local address, starting with f). Link local addresses are not routed outside your LAN, so they don't change when your ISP changes your prefix.
I got so fed up with IPv6 being either straight up unavailable or being deployed in a botched fashion by residential ISPs in my area in the last 10+ years that I picked up an ASN and a /44 last year. I advertise it from a VM on Vultr in a datacenter close to home and the experience is just amazing.
I also got fed up with people discriminating against Hurricane Electric's tunnel broker (streaming services, etc) so now I just have my own tunnel broker. It's really great to have my own addresses, use them in my kubernetes clusters (via calico and cilium) and have my homelab directly advertised to the internet, knowing I will never need to re-number.
This articles section "here are some reasons you should start using IPv6 within your own network" seems to comfirm this. None of the 6 "reasons" speak to me.
Here's an easy one for you: if you have a gigabit connection, most home routers can barely handle the load of NAT. That's why gamers push for IPv6. It's mentioned in the article but few people realize how inefficient NAT can be at gigabit and more.
My ISP router could do max 800 mbps, which isn't so bad, but it degraded when we were multiple people using the link. With IPv6 it's much less of a problem, we can easily saturate the 1gbps without the router having a meltdown.
> if you have a gigabit connection, most home routers can barely handle the load of NAT.
I remember reading about this as well. Wouldn't that also apply to stateful firewalling, though? Or is NAT inherently more computationally difficult (e.g. due to having to recompute IP and/or TCP/UDP checksums) than checking a state table?
The consumer links are usually oversubscribed. In Prague, you can easily get 1Gbps if you're near fibre. However, office-quality link will cost you 10x more for the same nominal speed.
I have a symmetrical gig connection, ISP doesn't provide IPv6. Can route full line speed using their router, no matter if it's 1 device or 50 connected.
I don't know of a single game that supports IPv6, although some consoles might?
Maybe it's a ricer thing, but I definitely see a difference and I compared my ISP's router (which didn't display CPU load), an openwrt router without hw flow offloading support (horrible), and an UDM SE.
(I don't have an Xbox, I just see posts on my local ISP's forum)
Haha bollocks. NAT adds probably at most 1 microsecond to the processing of packets. It’s state for a flow is roughly 16 bytes. The nonsense about NAT being inefficient or slow astounds me.
> The results show that rewriting the packets is quite a bit more expensive than just allowing or dropping a packet. For example, if we look at the unidirectional test with 10,000 flows, we see that we dropped from 14M pps [packets per second] to 3.2M pps, we also needed 13 cores more to do this!
Everyone always goes with the "You don't need NAT, everything is globally routable!" argument, as if that's something that anybody wants. Everything on my network is going to go through my firewall anyway. I don't want anything on my network to be globally routable.
Of course, this is not a good reason to not use IPv6, don't get me wrong. It's a problem that's easy to overcome, I just think it's not a good way to get people excited about the transition.
With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not.
If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
IPv6 has so many addresses that the default is for /64 subnets to be the minimum network size, allowing devices to choose their addresses randomly within that range. If they do that, 2^64 is big enough that it's not practical to enumerate all devices on a given network. Attempting to do so would be a bandwidth DoS attack: attempting to ping 2^64 devices requires 2^64 * 64 bytes = 1024EiB, roughly equal to total global internet traffic per year.
Now, sometimes NAT is needed anyway: QubesOS supports IPv6 using NAT because it splits things up into many different VMs on one computer. But that's a pretty rare case.
EUI64 means that random space is effectively reduced to just 48-bits of real entropy, <40 bits if you start making assumptions about device vendors. For example maybe the attacker has a VMWare exploit: enumerating that OUI (00:50:56) leaves them with just 24-bits of address space to scan, a measly 1GiB of traffic.
It's security through obscurity at best, i.e: not security. You shouldn't be relying on size of address space to protect you from anything. An IDS/IPS that alerts on abnormal ICMP behavior will be useful whether an attack is 1GiB of traffic in size or 1024EiB of traffic in size. (Also you don't even need automated scanning to find some juicy targets: I've seen a lot of routers on the edge of a prefix configured at ::1/64 and ::2/64 for instance.)
Most systems aren't using EUI64. Within a subnet, they're using random addresses per RFC 4941. So, if I've got a /64 IPv6 allocation (which I do right now), that means I've got 64 bits of randomness to play with. Right now, my macOS system has four publicly-routable IPv6 IPs, all of which were randomly-generated, and which regularly regenerate.
I did not have to do anything to get this. My macOS system has IPv6 set to Automatic. My home ASUS router picks up the /64 allocation from my ISP, passes the info on to things on the LAN, and acts as a firewall for IPv6 (while continuing to act as a NAT for IPv4).
I don't see what's wrong with the outside knowing your local IP addresses. But I absolutely wouldn't want EUI64 encoding my device vendors in the addrs.
To be fair that info is already available w/ port sequence analysis, the same machine will pick from the same set of ephemeral ports for outgoing connections. I'd say the time for vanity privacy arguments is over, I'm all-in for team globally routable addresses w/ firewalls just saying "yes" or "no" to connections instead of routers guessing at port mappings.
Your machines could change their IPs for every second of every day and you wouldn't come close to exhausting your /64 subnet for the next billion years.
Won't this break your TCP connections? NAT won't, because it's connection-aware by its nature. And you also get a new "address"(=port) on each new connection, regardless of any setting.
My network would look like it has dozens of machines, since everything is periodically rotating its IP randomly around the subnet, and often have multiple IP addresses at once with privacy extensions…
> Unconfigured/not activated firewalls usually fail reachable
Local firewalls on devices, maybe, but network firewalls generally are default-deny on untrusted interfaces, and between 0 and 1 interfaces are trusted by default.
Back in 2007 Apple's Airport Extreme Base Station shipped with a firmware that defaulted to allowing all IPv6 traffic, which was quickly pointed out in the tech media and fixed in a patch a few months later. A few of the garbage pile combo modem/router devices distributed by ISPs have had similar issues over the years as well. That's not normal behavior though, when it's observed it's rightfully considered a security flaw and tends to get the kind of attention vendors don't want.
If you know of a mainstream device that would "fail reachable" as you claim here, name and shame please.
> without explicit port forwarding or exposed hosts, NATs fail unreachable.
I work in VoIP and can say from plenty of direct experience this is not true. In the modern work from home era I've had to deal with a lot of the aforementioned garbage pile consumer devices and a recurring issue with some of our clients who had older phones is that their users' home routers did the laziest NAT possible and literally just opened a two way hole on port 5060 (SIP) so as long as the phone was communicating with our server and keeping the pinhole open *ANY* other traffic that hit port 5060 was also sent to the phone, which meant they got all kinds of "phantom calls" from bots looking for unprotected SIP relays.
Newer phones generally have an option to only accept SIP messages from trusted servers, but older ones sometimes don't so when combined with badly implemented NAT that happens.
And yea, obviously that's a consequence of a particularly bad NAT implementation, but your complaint is about an issue that would only occur in a particularly bad IPv6 implementation.
It takes effort to make NAT that bad. Something jank like UPnP has to map the port, and even that requires action on the device's part. I don't quite understand your SIP example; how does the router know which IP is the phone's?
Bad IPv6 is as simple as not having a firewall or default-allowing it like AirPort did. If Apple can make that mistake, a lot of random manufacturers can too. I can see the whole NATless firewall setup but wouldn't use it for a very long time, to let things settle.
One could argue that if e.g. FTP is not working behind the NAT then the NAT is misconfigured. NAT needs to aware of certain protocols so that it can modify the application layer data.
Of course, if the protocol added workaround for NAT and NAT is modifying that application layer data then it can cause another set of issues.
IP networking was designed with separate layers, NAT breaks this by having to span multiple layers.
Generally NAT gateways only support TCP/UDP, other protocols are simply not supported, which has basically stifled protocol innovation (eg look at SCTP, it has some neat features but is hardly ever used because of NAT).
It gets even worse with higher level protocols like FTP. There is such a thing as FTPS (FTP over SSL) but it's rarely used because if you encrypt the traffic then the NAT gateway can't inspect and rewrite the traffic.
The same is true of IPSEC/ESP, if you have an encrypted TCP packet encapsulated with ESP the NAT gateway can't keep track of which internal host to forward it to because it can't see the source and destination ports.
A normal router does not need to care about anything further up the stack than IP. A firewall does, but even when a firewall doesn't explicitly support a particular protocol you could write a rule allowing any traffic with a particular protocol number between specific hosts is allowed, and anything else denied.
The amount of firewall config I have to write to let an incoming connection cross from WAN to LAN is the same regardless of whether it goes to a NAT'd IPv4 address or to an IPv6 address.
NAT does nothing? The NAT setup is the reason incoming connections don't reach devices on the LAN. I get that you can phrase this as NAT actually being the thing forwarding the packets, and on a home ipv4 router without NAT the incoming packets would just go nowhere, but everyone is talking about the realistic options of NAT vs device having own public IP addr.
I get that an ipv6 router can have a firewall with good defaults blocking incoming connections, emulating that aspect of a NAT.
> I don't want anything on my network to be globally routable.
Then... don't route anything on your network.
NAT is address translation, not routing.
NAT makes it difficult for you to host services on your network, forcing dependency on cloud services, and when ISPs do it (CGNAT), it makes it just about impossible unless you want to thread your traffic back through a third-party service. If you want a good chance of keeping some semblance of an Internet around that isn't dominated by huge centralized services, the cargo cult of "NAT is security" needs to die hard.
Imagine if I'm a medium-sized ISP, or a medium-sized software company, or a medium-sized website.
There's a bunch of hassle involved in deploying IPv6. Who knows what it'll do to my users' privacy? Or whether everyone's firewall rules will keep working right? Or whether it'll have some random impact on e-mail deliverability? Or something else?
The main benefit of IPv6 is providing routable addresses for home users, thus avoiding CGNAT.
But zealous firewalling and the rise of mobile devices mean these days almost everything is sent over HTTPS to a cloud server. I haven't had software ask me to open a port on my router in a decade or more. Even games and video conferencing software know they have to work out-of-the-box on networks where the user can't adjust the NAT.
So who's going to benefit from all this hassle - the 0.1% of users who are hosting websites from home?
To "avoid domination by huge centralized services", of course. What if you want to run something like a website from your own IP, but you can't because you're behind CGNAT?
I use a public VPS and Wireguard. Costs $3.50 for the VPS which has a static IP. I host on my laptop. I can take my laptop anywhere in the world there's an Internet connection and my email and web sites continue to work right from the same VPS IP because my laptop connects to the Wireguard server on my VPS when it comes up.
Another reason is that NAT is making IPv4 live longer than it should, making IPv4 addresses more expensive. Maybe you don't want to host cloud services from your home, but if IPv4 addresses start costing millions of dollars (I know blocks of them can go for that much--if we're already there do you want to go further?), that drives up the cost for anyone using the Internet even if you are super okay with CG-NAT (which you shouldn't be).
If home router manufacturers would get their shit together, IPv6 would not be hard to deploy. I get it, it's chicken and egg, but nothing about IPv6 is inherently more difficult than IPv4 other than the length of the address.
The reason IPv6 on a home network is still difficult is because the routers everyone buys at Best Buy still blow at supporting IPv6. Ubiquiti blows at supporting IPv6. It is laziness and/or incompetence of device manufacturers, primarily, holding us back. (and incompetence around IPv6 in general - I talked to a network guy at a large company recently and they were deploying /58s. WHY?!)
The benefits of IPv6 may not be just for you - it's for the planet, it's for the developing nations, it's for the future where IPv4 does not cut it. It's bigger than your home network.
IPv4 cuts it everywhere. IPv6 does not do anything to save the planet. IPv6 does have privacy concerns stated by many on this page. IPv6 could be shut down tomorrow and the Internet would continue working well.
No it wouldn't. Basically all mobile networks would break and have to do even more layers of NAT to meet demand.
> IPv6 does not do anything to save the planet.
The world doesn't have enough IPV4 addresses. It literally solves the problem. It is crazy to me so many people here are arguing for multileveled NAT instead of the obvious solution we have had for 20 years.
If 8 billion people wanted to host their own email and web, yes, we'd not have enough addresses for each person to have one. That isn't the case though. It will never be the case. If we look into the future and say well in 2023 5% of the world's population ran their own email and web for personal or business purposes and that number were to grow by 5% every year then in 20 years we would run out. That's a worse case, contrived scenario but even in that case, we'd still have 20 years to come up with something better than IPv6 that truly respects privacy and doesn't track each person.
The world has been out of IPv4 addresses for more than a decade. Which is horrible news for competition alone.
Try starting a new ISP. You’ll either do CGNAT on a single /24 of v4 space, or you’ll have to spend tens of millions for some pointless, legacy IP addresses.
I don't think EUI-64 being built into link-local fe80 addresses is a privacy issue. Link-local addresses don't get routed, so nothing outside of that network will see or know about them. As far as the router itself, e.g. your ISPs router, it can already gather MAC addresses if it wanted to, so IPv6 using the MAC to generate link-local addresses doesn't add or remove to that situation.
CGNAT is not the Internet working well. CGNAT makes you have to have your ISPs permission and coordination to originate outgoing traffic--imagine if you had to ask the power company for permission to operate each electrical device in your house.
What I don't understand is why governments seemingly ignore this problem ??
Look at what they did with broadcast digital TV : it was announced that it would be illegal in a couple of years to sell hardware not compatible with the new standard, then a couple of years later on illegal to sell hardware compatible with the old standard...
Some are...
China, India, Israel all mandate IPv6 support from ISPs in their territory and the equipment they provide to users, as do some others.
The US has mandated IPv6 support for federal contracts since 2009, although they don't get involved outside of those directly providing services to the government itself. They now have plans to go IPv6-only, and eliminate the use of legacy IP within the federal government.
Allocation of legacy address space was always based on first come first served, so developed countries got the lions share of address space and left developing countries with scraps. This creates a severe inequality, and holds developing countries back. This is also why India and China are leading, as they have a huge disparity between their population and the number of legacy addresses available.
The sad part to me is that the original IP header included variable-length addresses up to 128 bits, using two 4-bit fields called Source Address Length (SAL), and Destination Address Length (DAL). [1]
Early hardware implementations could have settled on 32-bit, but 48-bit would make more sense to be in line with EUI-48/MAC-48 (ethernet frame). The world could then gradually upgrade hardware over the decade to handle a larger address.
Pushing all your traffic through a third party cloud server causes a lot of problems.
It costs that third party real money to run that server...
What happens when they decide to shut if off because they no longer want to bear the costs? Your applications are a ticking timebomb...
What about privacy? What if the operator of that server decides to fund it through selling your data?
Sending your traffic through a third party server adds latency, sometimes a LOT of latency if that server is far away. This is very bad for certain latency sensitive things (gaming, calls etc).
If you're dependent on a third party server then you're screwed if it goes down, even if your own connection is fine.
Doing away with that and going back to peer to peer is MUCH better in most cases.
With NAT it is impossible to make a mistake that causes machines with a private address to become reachable to the internet. That is a reality that is not going anywhere, no matter if you like it or not, no matter if you think it is stupid or not.
Every home router could be built with a default deny inbound for traffic, with big flashing lights saying "do not override this".
IPv6 has private addressing and a form of NAT as well, were it to be the will of router mfg'ers and network admins. No need to stay on a legacy protocol.
Similarly, your comment is a good example of the anti NAT cargo cult mentality that people think is smart but really isn’t.
The reality is that NAT has greatly improved the security of the internet, because before NAT people were exposing everything, including services like Windows file sharing, to the internet. NAT enabled those people to use multiple devices in their home and in return prevented them from unwittingly hosting things to the internet, which causes them to be hacked and turned into bots that harass the rest of the internet. Yes that still happens but not at the scale it happened before everyone was behind a NAT perimeter. If you want to see what could happen look up the SQL Slammer worm and imagine what could have happened if such a worm would have targeted a service more common than SQL Server.
It’s really nice to be able to host things on a consumer connection but it requires thought and management that most consumers just can’t and won’t care to provide and the damage they can cause is not only to themselves but to the rest of the internet as well. This capability really is better off by default.
And all those handwavy ‘workarounds’ for the ‘cargo cult mentality’, you typically can’t tell everyone on your network how to manage their computer to ‘just have their services listen on the local address’ and you can’t ‘just change the defaults of all routers’. But NAT makes it impossible for the default to be wrong and that is its great advantage.
Sure NAT has a lot of disadvantages and breaks the original idea of the internet with every host equally able to host services. But just as Postel’s law just doesn’t work out, every host being able to host services doesn’t work out. Because the internet is not a playground full of friendly colleagues and hasn’t been for a long time. It’s a war zone that requires strong, watertight defenses by default. And if you’re smart and careful enough to safely host a service to the internet, surely you can manage to forward a port.
Slammer (and other worms) propagated heavily despite NAT. If anything NAT made it worse, because once a single internal host got infected the worm now has a predictable and well known address space to scan for other devices it can infect.
NAT created a false sense of security, while also breaking a lot of other things. It is quite easy for the defaults to be wrong, you can end up with all kinds of unexpected scenarios which make internal hosts reachable - eg outbound traffic could open up inbound traffic on the same port from any source not just the one initially communicated with, UPNP can result in ports being opened, NAT slipstream attacks are another possibility, not to mention the fact that "not routable" and "there is no route" are two different things - someone who is on an adjacent network to your wan interface (ie other customers of the same isp) can easily direct traffic to your internal address space.
What reduced external attacks was not NAT, it was improved defaults - such as windows including a software firewall which blocks inbound connections by default, and unix based systems no longer shipping with large number of services (telnet, rpc, finger etc) enabled by default.
Consumer routers with IPv6 support don't allow unsolicited inbound traffic by default. Good luck scanning an IPv6 block in any case.
Slammer and other worms scanned sequential legacy IP addresses, including the well known and predictable RFC1918 space. This method simply couldn't work with IPv6 because the address space is too large, you would be flooding out huge amounts of traffic for years on end before you happened to hit upon an active device.
Once an unreachable host magically got infected, it scanned the entire IP address space but hey, it was worse because some hosts were in a predefined part.
NAT is bad because somehow magically a machine with an unroutable address can become routable. Because magically UPnP forwards every protocol in existence, not only a select group of programs that explicitly support it. And of course a connection opening up a theoretical hole to a specified host is just as bad (actually worse!) as opening it up to the whole internet.
Yet all routers have the right defaults and nobody ever makes a mistake. Oh and there’s so many addresses it’s so obscure it’s secure, and noone would guess to scan one’s own subnet in the absence of NAT.
These arguments are really grasping for straws, mostly nonsensical and the rest describes attacks so impractical they are pretty much impossible to carry out and are so much harder than simply sending a thousand emails with a link to an executable that pretty much nobody ever bothers.
Note I never said that IPv6 is worse, I said that NAT has relevant advantages and mostly irrelevant disadvantages. I really don’t care ftp doesn’t work with NAT.
Those IPv6 privacy extensions still reveal when the same node connects to a sequence of destinations within the address change interval, though. E.g. observers can see a single device connects to Facebook, OnlyFans, Pornhub and PayPal in that order.
Behind a NAT, observers can only make that connection (using only addresses) for the network as a whole, instead of an individual device on the network. So the privacy extensions are weaker than NAT
(If the IPv6 privacy extensions used a different address for each connection, they would be more like NAT in this regard.)
That said, other observable clues still allow connections from a single device to be associated, NAT or not. There's TCP OS fingerprinting for example, and the close timing of related connections.
That requires someone who has the ability to monitor all your traffic - ie the government, your ISP, or a hacker who has infiltrated one of those two.
In this scenario it's a lot more work trying to map out your infrastructure than to try performing a MITM connection against some of your outbound traffic.
Your machines could change their IPs for every second of every day and you wouldn't come close to exhausting your /64 subnet for the next billion years.
Why would changing N seconds break network? It would presumably keep active addresses until connections finish. IPv6 requires supporting multiple addresses per interface.
More reasonable is to use new address for each connection. Then nobody can tell if 10 addresses and 10 connections are one device or ten.
This looks like NAT pushed down to the endpoint itself.
You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME.
What are valid values in the scenario you are proposing? The defaults are 1 week / 1 day, so 7X. If you chose to rotate each second, and say allowed addresses to only be valid for say 20 minutes, this still appears to be a ~1200X blowup in routing overheads.
> You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME.
They have not?
The global routing table size for ipv6 at max is a /32 (if i remember correctly)
every customer gets a /56 prefix to use in their network, so the routing table entry would still be the same, no matter how many addresses you use to cycle through in your /64.
ARP caches do not exist in IPv6, and Neighbour discovery does not have the same "cache" mechanism as ARP does, it uses an entirely different mechanism for neighbour discovery. (which is also far more lightweight considering it is using multicast, compared to the broadcast of ARP).
What kind of observer is 1. able to listen to the entirety of your network's outside communications, 2. interested at all in it, 3. harm you only on the condition that they "map out" your internal infrastructure? This isn't a novel, the goal is not to solve intricate security non-problems.
Your ISP, "mapping your network" means being able to take data that was previously an amalgam of a household and reliably split it into the individual members and devices for better targeting.
Take a moment and learn about Nokia’s Deepfield or Kintec.
The ISPs have the ability to see what is on your network by IPv4 egress. They have been able to do this for a decade.
Worrying that an IPv6 address divulges the network forgets that IPv4 devices betray their existence through DNS, their destinations and other network behavior.
A reader who's actually interested in getting the source, might try Googling for "2070.43", or even "2070.43 million wifi". I must admit, I wasn't serious enough about my comment to spend $3,250 on the whole report, and had to go off of the public preview. Since you seem to be more serious, maybe you could pay the $4,400 for a multi-user licensed copy of the report and share the PDF with me? I'd love to read more of the analysis.
So, I mean, I dunno, 2 billion dollars seems serious to me, but maybe we just have different barometers for what counts as "serious amounts of money". Especially considering these devices that are like $300.
Finally, might I remind you of the guidelines? in particular:
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Most people don't buy their own router, the ISPs bulk buy thousands of routers at a time. The ISPs make up most of the market.
Many of these routers are managed by the ISP using protocols such as TR-069, several ISPs have already been found to not only manage the devices but also monitor certain data including what devices are present.
This is pure anecdata, but almost everyone I know, include the people who aren't particularly computer-savvy, owns their own router and cable modem so that they don't have to pay a rental fee to their ISP.
For HTTP/HTTPS, proxy servers (forward and reverse) offer an equivalent ability to hide addresses and a lot more features for security and performance.
They are, but in practice they are muddled together and I suspect people are going to create subnets with IPv6 in the name of security. In IPv4 NAT is used to make sure your laptop isn't exposed to random script kiddies trying to scan for vulnerable services behind your router. A fun exercise is to plug a RaspberryPi up directly to a public facing IP address and log every packet it receives. Then give those scripts a few services to detect (HTTP server, SSH server, etc.) and look at how the traffic shifts from scanning for ports to scanning for vulnerabilities. Being connected directly to the public internet is a real eye opening experience.
I do believe future IPv6 networks will have gateway machines and/or bastions that are connected to the public internet with public IPv6 addresses. And then they'll have an interior network that they use NAT for. Individual machines will not be routable or discoverable without going through a bastion/gateway that explicitly controls the flow of traffic into a network. Not because this is the ideal way to structure an IPv6 network, but because this pattern is going to carry over from the IPv4 world and there is a lot of momentum in tribal knowledge using NAT as a form of firewall.
>In IPv4 NAT is used to make sure your laptop isn't exposed to random script kiddies trying to scan for vulnerable services behind your router.
NAT does nothing for that. Those incoming connections are dropped on the WAN interface before NAT would even be involved. Which is why it works exactly the same way regardless of whether the destination IP for that traffic was IPv4 or IPv6.
>In IPv4 NAT is used to make sure your laptop isn't exposed to random script kiddies trying to scan for vulnerable services behind your router. A fun exercise is to plug a RaspberryPi up directly to a public facing IP address and log every packet it receives. Then give those scripts a few services to detect (HTTP server, SSH server, etc.) and look at how the traffic shifts from scanning for ports to scanning for vulnerabilities. Being connected directly to the public internet is a real eye opening experience.
That isn't really feasible with IPV6 though is it? The smallest IPV6 subnet is 18,446,744,073,709,551,616 addresses, so even if you setup a Pi fully open to the world with default passwords the chance of someone scanning it is basically zero. That type of scanning only works because the IPV4 range is so small (& you can efficiently ignore large parts of it like the US DOD space, private addresses, etc).
Yes at the moment the IPv6 internet is way more secure even without a firewall but there are possible attacks to enumerate the used IPv6 addresses. [0]
> Everything on my network is going to go through my firewall anyway.
Yes, and that's a very reasonable configuration.
But UDP hole punching (very widely used for VoIP, online gaming etc.) works orders of magnitude better with IPv6 than with IPv4, since there is no address and port translation to worry about.
With IPv4, it's very hit or miss, since it depends on both sides' NATs and also requires additional infrastructure (i.e. STUN discovery servers).
I've actually run into this helping a friend host a game server on their residential internet in a more rural part of Texas. They had to call their ISP and request a static IP address at an extra cost of something like $5/mo.
You’d just use the VPS as a proxy with a publicly accessible IP, and tunnel the connection back to your home. That would add latency that might be undesirable for a game, but maybe not.
Unless you're playing something like a turn based game, adding latency/hops is almost never desirable. Every multi-player game that I play is latency sensitive (and I don't play FPS games.)
There is no downside to everything to be globally routable. It's completely orthogonal to firewalling.
What is the risk you're picturing here? I'm really curious. Features like RFC4941/8981 mean nobody can infer anything about your network from the source addresses they see making requests out if it.
If you want to use link-local V6 addresses and NAT to a global one, you can do that. But IMHO that's sacrificing one of the greatest advantages of IPv6 for no tangible benefit.
I'm not saying there's any downside, I'm just saying it's not the magic bullet "this is why you should use ipv6" that everyone seems to think it is. It's a complete non-issue that nobody really cares about.
The point is that it gives you options. You might not want to have anything on a network reachable from the internet today, but next year you suddenly need that capability and it's useful to be able to take advantage of that, rather than wading through the buggy mess of NAT.
> It's a complete non-issue that nobody really cares about.
A significant number of people spend a significant amount of time trying to carve out and re-use address space in their existing IPv4 allocations and RFC1918 space. This becomes nightmarish the moment you start thinking about networks of any significant size and complexity. All of these problems go away with IPv6, and we care about that a lot.
> It's a complete non-issue that nobody really cares about.
Huh. IMHO it's the single most desirable feature, and the only reason I care about it at all.
If you're approaching this from the home networking point of view, than I suppose I agree: even the most complex home network is just too simple for anything like this to matter much.
As the network gets bigger, that sweet sweet global routability starts to make
a lot of things a lot simpler... I'm lucky to have worked on an enormous deployment of V6-only servers, and it's downright magical in comparison to anything of comparable scale I've seen before or since.
But yes, my home network is three NAT'd /24's because I'm too lazy to figure out how to make prefix delegation work...
Also, IPV6 has far more scalable systems for dynamic address allocation compared to IPv4.
SLAAC scales really, really well, and is fairly stateless compared to DHCPv4 or V6.
Also, slaac allows one to easily change the global prefix of a vm/host if it lives on another layer 3 network.
A good example of this:
you have two seperate datacenter networks based on an EVPN-VXLAN solution, and you do no want to stretch layer 2 across both datacenters because stretching layer 2 is a terrible, terrible idea[0].
Before IPv6, moving VM;s across datacenters which have different public ip space was a major pain for two reasons:
- IPV4 has no concept of using multiple addresses per interface without it having unexpected bahaviour on a host.
- address management at scale is a major PITA because DHCP is not scalable.
How to solve this with IPv6? It's fairly easy:
- Use slaac + prefix delegation of your globally unique address space (which is different per Datacenter).
- Use a different (site local) address to reach the VM for management purposes. Because this address is not globally routable, you are sure it will never leak into the greater internet and be reachable from the outside world.
- If you are using anycast, you can easily announce this prefix to upstream BGP neighbours because you can use BGP Neighbour Autodiscovery[1].
Trying to do this with Ipv4 will result in a mess of administration, not to mention have to do some clever technical hacks to make it work on some operating systems.
With IPv6 solving these issues becomes quite manageable.
> It's a complete non-issue that nobody really cares about.
The availability of IPv4 addresses is something that more people will care about, and getting IPv6 going may help folks. From another comment in this sub-thread:
> I've actually run into this [CG NAT] helping a friend host a game server on their residential internet in a more rural part of Texas. They had to call their ISP and request a static IP address at an extra cost of something like $5/mo.
People care as soon as it bites them. If I can't stream my music when I'm on my work VPN because the IPs are the same, that's a pain. If my wife and I can't game together online because we "have the same IP" that's a pain. There are all these little irritations that come from not having a global address, and they add up.
They can infer that one IPV6 address matches to exactly one device. (reverse is not true, one device may have multiple addresses per privacy extensions)
Once device is identified all its past traffic is discernible.
Changing addresses means identification needs to be done again but once done it can be associated with past addresses and again, all its history is visible.
Identification might just mean querying a data broker with HTTP headers.
> The source address for external connections is effectively randomized
It's still unique to one device right?, even if random my argument still holds.
Or do you mean to say multiple devices can use the same address?
note: I've read the RFCs and they just mean - initial address is random but unique to a device. Each day the address will likely change but new address is still unique to the device (otherwise how would routing work).
This is what I structured my inital argument on. Do you see any fallacy in logic?
You literally wrote "Once device is identified all its past traffic is discernible." How is that compatible with devices changing their address every day?
you identify device each day, identity is X, daughter of Y on iPad. Once identified via data broker all its traffic is identifiable including torrents for example and porn websites, etc (say X goes to facebook with new address it now has real name)
Once identity is known for address X you know its traffic for the day, including past traffic for the day.
once address changes you do the whole identification again.
All these logs where address is identified goes to bucket X.
On addresses where you couldnt identify that day you put them in unknown bucket.
Once you have a profile of the network, you can do exclusion (Only 4 people in household, 3 active with known addresses, not X, one unknown address, you can assume its X)
Nobody bothers to do this kind of tracking because web browsers leak 100x more information by default anyway.
The “I don’t care if they track my household but it’s critical that Daddy’s activity not get disambiguated from my dealing daughter” is just not a valid reason to abandon the benefits of IPv6.
Please stop with this line of argument.
If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT.
> Nobody bothers to do this kind of tracking because web browsers leak 100x more information by default anyway.
That's a broad assumption, and I can assure you they will due to lower costs (no need to pay data broker if you already know target, no need for extra traffic, load, etc). Also due to better targetting you get better prices per ads served.
> just not a valid reason to abandon the benefits of IPv6
What are the benefits to allow each device its own address if I'm going to firewall them anyway?
> Please stop with this line of argument.
Why?, my concern is valid, all you've said so far is nobody cares. I disagree.
> If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT
That says a lot about yourself if you resort to this sort of snarky comments, I have no wish to continue this conversation.
Note: I said in another comment I have set up IPv6 NAT and it works great.
wait ... when you say nobody bothers ... that's a high bar. Most likely a ton of adtech companies are just drooling to use (or already are using) this type of correlation even if browsers leak more info.
> Nobody bothers to do this kind of tracking because web browsers leak 100x more information by default anyway.
If I told my security information officer "We don't protect against foreseeable threat X because we assume no one will bother to try X" she would not be very happy with me.
When a valid data concern has been expressed and described, putting your head in the sand is the incorrect response. I want IPv4 to die as much as the next person but at a minimum organizations such as hospitals and government installations will not accept that sort of outside visibility into their network.
> because web browsers leak 100x more information by default anyway.
I don’t quite feel convinced yet by this argument.
For example, one essential difference is that while it’s true that my web browser does have those leaks, I can be reasonably sure that it’s only leaking to specific hosts, i.e. the one I’m visiting and its embedded resources.
Tracking on the IP source address level, however, would be a whole other thing: that means that whoever happens to see the byte stream can now track who is visiting what. That includes, for example, my ISP, all large Internet exchanges, and anyone tapping into those.
I mean, it's the same point, single address to single node, just more often, so need to identify more often.
Minutes or less I guess would defeat tracking, but then what's the point?, it's almost equivalent to NAT it still breaks reverse connectivity? and does it actually work?
> I mean, it's the same point, single address to single node, just more often, so need to identify more often.
But how would they know it is to the same node?
I have my DSL router-modem reboot every night, and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
Similarly with the reboot I get a new /64 prefix delegation (actually /56), so I would hazard to guess if IPv6 starts getting tracked, I'd get the same crazy results.
ipv4 with NAT gets you a new "adress"(meaning port) on every single new connection. I don't see IPv6 doing the same thing(it has no clue about connections)
> ipv4 with NAT gets you a new "adress"(meaning port) on every single new connection.
No one cares about tracking by port. Folks are tracking by IP(v4) address.
I know this first hand because I have my DSL router-modem auto-reboot every night (built-in Asus functionality), and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
And given that I have IPv6, most OSes generally use that as a first preference for connectivity, and so my IPv6 address/prefix is "in" Quebec.
And this is even with cookies enabled, which should make tracking by browsing easier (esp. since I get decently-accurate recommendations based on viewing history), but yet I still get French ads because my IPv4/IPv6 address is "in" Quebec.
So I have no idea what people are talking about when they say IPv6 will make tracking easier than IPv4. With RFC 4941 it's a solved problem IMHO and no worse under dual-stack than it is under single-stack.
That's not tracking to you specifically, that's geo location so they're just trying to identify the general area for purposes of showing ads.
With IPv6 chances are your ISP has a single large address block, and then they split out parts of that address space to users in ontario and quebec. Unless the ISP publishes details of where they've allocated those blocks, any external site is just guessing.
With legacy IP chances are they have multiple small fragmented blocks, some of which are routed to ontario and some of which are routed to quebec so they're a bit easier to keep track of unless the ISP decides to move them.
Also when you address changes, the legacy address space is probably quite close to full so your previous address is released and probably taken by another customer fairly quickly. The IPv6 space will be much larger, and so recycling occurs far more slowly.
Either way youtube is just guessing, it only knows that the address space belongs to a canadian isp and it has to use the behaviour of whoever used those addresses last. If the previous user set their browser language to french and searched for french sites, youtube will remember that and is more likely to serve you french ads.
I wonder if whoever coined that phrase knew that it would be used so often in contexts where people want both obscurity and security based on their own respective merits.
You're going to have a minimum of a /64, noone is going to scan that looking for devices.
Even if they do, your firewall is not going to allow the traffic unless you've explicitly configured it to do so.
The only way someone will discover devices, is by analysing outbound traffic you make. Outbound IPv6 traffic will come from randomised addresses so the addressing information is useless. Other things disclosed by the devices (eg user-agent headers on web browsers and other fingerprintable data) are protocol agnostic.
Also I'm not going to expect my ISP to actually give me more than one address, so if I have multiple devices at home, I will need to do NAT. Heck, back in the day they used to set TTL to 1 so the packets weren't routable at all without mangling them via iptables. Maybe that will be harder now than 20 years ago since everything connects online...
In large swaths of the US, you don't have a choice about what ISP you have available. If you happen to have a shitty one (and most aren't great), there's nothing you can really do about it.
> Everything on my network is going to go through my firewall anyway. I don't want anything on my network to be globally routable.
Globally routable ≠ globally connectible.
Your (stateful) firewall will still by default block any incoming connection attempts if they are not replies to an initial outgoing connection. It's just that it will no longer be necessary to go through the rigamarole of STUN, TURN, ICE, etc, that goes along with non-global addresses:
Your end-user device knows its address and the address of the other connection point, and can tell the firewall to open a rule between only those two IPs:
Further, because you don't have only one external IP, you don't have to futz around with non-default ports if you want multiple instances of the same service (e.g., Minecraft), because each instance can have its own IP.
Further, if you want certain devices to not able to get outside: (a) give them static assignments and block them at the firewall, (b) don't give them a default route so they are subnet-local, or (c) give them site-local addresses via ULA and do not set up NTPv6 translation.
And what computer is making what requests. Now that i think about it, this cloud be the reason why youtube started making recommendations based on stuff i just watched in private browser tabs...
Not just Android. My laptop does it too (NetworkManager). That's just IPv4 on devices designed to travel so it seems a fair thing to do. Bloody pain to diagnose why a static DHCP lease isn't working the first time, after that you find the mechanisms to turn it off. Nearly everything does it for IPv6, for a given value of everything!
For decades we have generally allowed all outbound and worried and fretted about and filtered inbound. I think it is time for us all to get a grip and do the job properly. However, with the delights of DNS over http and the like, the horse has not only bolted but has a new paint job, far better shoes than you can afford, eats grass that was prepared by a Michelin starred chef and belongs to someone else now.
We all need to be far more sophisticated about how traffic (knowledge/ideas/data) flows in and out of our networks/lives. Packet filtering is just one tool in the box and worrying about an addressing scheme being global (IPv6) instead of a weird hybrid (IPv4) is completely missing the real issue stabbing you in the nadgers.
I have multiple computers in the house, mostly not logged in to Google. YouTube recommendations spill between devices all the time - like, if I watch a video on one device, I’ll see the same video recommended on another. Or if my partner watches something, YouTube will recommend it to me.
They’re obviously doing recommendations based on IP address. (And this is purely over ipv4).
> They’re obviously doing recommendations based on IP address. (And this is purely over ipv4).
I have IPv6 at home and connect to Youtube over IPv6 (that's generally the default behaviour on macOS and many other OSes). I reboot my DSL modem-router every night and get a new IPv4 address and new IPv6 prefix every day.
Now: I live in Ontario, and my ISP is based in Ontario, but they serve clients in Quebec. Every so often, when surfing Youtube, I get served ads in French because according to my (IPv6) address I am "in" Quebec.
And, while I am not logged into any Google service, I do not block cookies. So even with cookies, Youtube seems to be fairly dumb about serving ads correctly just based on IP addresses (or at least IPv6 addresses and/or IPv6 prefixes), since cookies don't seem to be useful.
So I'm not quite sure about what people are talking about when they say "IPv6 tracking" if even Google/Youtube can't get their act together.
> They’re obviously doing recommendations based on IP address
eBay uses IPs showing content, too. I see 'items you've viewed recently' show items I've never looked at, since when on a mobile connection my IP changes fairly frequently and eBay carries over the recently viewed state from whoever else was previously using that IP.
It had puzzled me until I came across this[1] eBay topic where others had experienced this, from shared offices to spouses, etc.
It's fairly limited, without a lot of time and effort, or information from inside the network. I assume you're not acting as an AS, doing BGP, etc; and that you're just getting an IP allocation from a single ISP. In that case, you're probably getting an entire IPv6 subnet (like a /48) allocated to you. Ideally, you make the entire subnet available to your systems.
Assuming you block unsolicited packets (that is, packets not related to existing connections/streams) at your border (the connection to your ISP), then outsiders won't be able to use tools like traceroute to learn anything. All that an outsider has is an IPv6 IP, and since you're not doing BGP with anything, all they'll know to do is to send the traffic to your ISP.
> How does that protect privacy of the private network? I don't want to divulge any information about internal topology.
I'm curious to know: what (attack) do you hope to protect against?
I would think that most attacks come in two fashions: the first being that you run a service of some kind and that there's some JSP/PHP/whatever exploit for a public facing service, and someone does a 'magic' PUT/GET that has the application server execute some code, which downloads a larger malware attack package. After which point the black hats start scanning from the inside.
The second being that someone clicks on a link in a phishing e-mail or executes some attachment, after which malware code starts scanning from the inside and phones home.
(A third being an insider attack, who presumably know about internal topology.)
What attack are you thinking to protect against by hiding subnet and VLAN topology?
This isn't about an attack scenario from this vector, it's about preventing reconnaissance that might yield helpful results to an adversary that can exploit it via any other vector.
Besides compromising a machine that is already inside per the above (which can then do scanning / lateral moves), or perhaps physically getting inside the premises (in which case a scanner can be physically installed to examine the network), what attack are you protecting against?
Can you give me a link about an attack that knowing the topology of the network ahead of time would allow, but that not knowing would prevent?
An example of security being sidestepped is Network intrusion detection. An adversary who knows your network architecture can avoid poking around your network which looks really suspicious.
Just because you've popped a box on the inside doesn't mean you automatically know everything about the network. It doesn't give you a mirrored port on the network switch. It doesn't mean ICMP is enabled, it doesn't automatically tell you what ports are open or what they serve. And any decent security team is going to see your nmap blast in the IDS and kick that box in jail.
Seems intellectually dishonest not to acknowledge that making things easier, just y'know, makes things easier. Keeping attackers, who want to do you harm, in the dark as much as possible seems important to me.
IPv6 actually makes such attacks more difficult, not less.
An attacker looking to be stealthy is not going to blast the network with nmap...
ARP is broadcast, NDP is solicited node multicast so simply by passively listening on the network you will discover nodes in the same layer 2 segment, with v6 and properly configured switches your passive discovery will be a lot more limited.
Other passive techniques would be monitoring things like DNS, and things the host you've compromised is actively communicating with. This isn't any different regardless of the protocol used.
You can also actively communicate with services like DNS or Active Directory and query information about the network, depending on your level of risk.
Just knowing the in-use IPv6 block is useless, the blocks are massive so even just identifying active hosts in a single known IPv6 block is a lot harder than simply scanning the entire RFC1918 legacy address space.
For active discovery, IPv6 is harder to attack - you can't scan the entire address block looking for hosts. The fact that such scans should be detected is exactly the same for either protocol. You also have to consider response time and what an attacker may be able to achieve before your response kicks in.
Correct. If I talk to service A and I see an address that’s in the same /64 as service B, it’s unlikely there’s a firewall between the two. Two different /56 or /48? Probably a different site.
Let’s say the firewall isn’t yours. Or the firewall needs to be replaced and is more open by default until you secure it. It’s also easier to map which kind of devices and how many you have..
In any case, your endpoints really do need to be reasonably secure in themselves - especially if the firewall isn’t yours as then you are probably sharing the network with other devices on the inside of the network that can attack you directly, and even if not, it just takes one device being compromised and somebody has full inside access to the network, with the firewall not being able to do much…
The same comment applies to ipv4. Port bindings accessible from outside by accident, misconfigured upnp, SIP-ALG with vulnerabilities, various other router issues. "What if my firewall is broken" is not a new ipv6 consideration.
It’s not, but the “beauty” of NAT is that you have an extra line of defense because of its limitations.
Port bindings and upnp are far less impactful and less common.
I'm not talking about preconfigured port mapping. I'm taking about bindings as in entries in NAT. That happens on every outbound connection and has stateful processing. We're still finding issues with it, like the relatively recent NAT Slipstream vulnerability.
My ISP's modem doesn't do prefix delegation so I don't even get IPv6 with my own router in-between. And I need that thing in-between to at least have some control over the IPv4 LAN. No idea what security that modem provides, since there are zero controls, so no IPv6 it is.
You could still route within the /64, couldn't you? With a smaller subnet SLAAC wouldn't work, but you could DHCPv6 addresses still. There is also an RFC somewhere for sharing a single /64, intended for mobile hotspots.
No idea. I've tried every setting combination on this consumer grade D-Link router which is supposed to support IPv6. Nothing results in a functioning network. Forum posts I find from other customers of this ISP report the same behaviour on other routers. The modem gets a /56 at least, and hands out addresses from a /64 range under that I assume, the router gets a /128 from the modem, and then gives up entirely on doing anything with IPv6.
It sounds like your ISP is delegating a prefix, then? Weird, that all sounds reasonable to me. What do you mean the router gives up entirely, though? Computers in the LAN don't get an IP address? Packets go out but nothing comes back?
Yup, computers on the LAN don't get any address. From what I understand, the modem would be supposed to delegate a prefix to the router so it can hand out addresses, but this part isn't happening.
Tell us with the next 0 day, because that big problem exist, and unfortunately happens every days.
IPv6 == All your devices are globally ROUTABLE and CONNECTIBLE from Internet, your home network is part of internet. It is an additional rule in the router's firewall what temporarily avoids it. Remark in temporarily, as one day the gifted packet will arrive to the router. This is not cool.
So much so -the home network is part of internet- that if you want to create a simple Video NAS or whatever, one have to use external DNS services, as no one have control over its own local IPs... what are served by the ISP. This is not cool.
Even if it was not designed for it, NAT has been helping to secure and giving flexibility to our local networks along decades, but someones decided to reject it from the specification. Bad decision.
I don't even necessarily disagree with you, but your examples don't seem accurate.
Regarding firewalls bring prone to accepting by default, either way the packet has to go through the CPU to be routed. I don't believe there's any inherent bias in the design. You could argue that routers that use a single switch and vlan isolate the wan port are inherently biased, though.
Regarding local hostname resolution, there are several options that don't require your ISP. There's mDNS, DHCPv6 and DNS on your router, ULA prefixes, or you can continue using IPv4 for local traffic.
The words "local" or "home" network with IPv6 are an illusion, this is what I wanted to show with my examples,
Firstly one ceases to have control of its own home network, what now have to rely on the ISP for to receive the "local" IPs, what are part of internet. And in addition each machine leaves a trace of its "local" ip on the Internet. This if one want internet access in the device, due the absence of NAT in the router's protocol.
Secondly one have to rely on a buggy piece of code called firewall for to make "local" those IPs, due the absence of NAT in the router's protocol.
We are talking about millions of routers provided by the ISPs in each country, barely maintained and updated, what little by little will become exposed. And this without taking in account the unpublished firewall bugs that each artist keeps for themselves and takes 3 to 5 years become detected and fixed by the mainstream. I do not know how to express the negligence is going on, but I can see that Crackers, Advertisers (privacy) and "others" are in good time because things are getting more easier for them than it should be.
Why people keep down-voting the message is a mystery for me. If it is due the local hostname resolution, mDNS, ULA prefixes, etc, all are workarounds due it is a network one does not control, what is one of the main points I exposed (it also needs filters/rules what needs be manually added in the firewall, each user has to make efforts to try to protect the supposed "from internet" separation).
One could create another network as you said, but the main problem keep existing without NAT.
I still don't think you're really providing any examples or arguments that make your point, though. You're just coming across as really salty about IPv6. I'm not downvoting you.
IPv6 has link-local addresses that aren't routable, so you can't really get more local than that. Unlike a typical IPv4 setup, typical IPv6 hosts have multiple addresses, and you can make your own for local traffic and only rely on ISP prefixes for internet access if you want to.
Sure, the internal host's internet routable IP address is visible rather than being masked behind the router's IP address. Pretty much all operating systems periodically randomize the bottom 64 bits, making it effectively as opaque as NAT. You could call that a hack, but people call NAT a hack. There's tradeoffs.
The CVE links you provided are just lists of vulnerabilities with "firewall" in the name. Skimming through them, I don't see how they're specific to IPv6? Most of the vulnerability descriptions I read seem equally problematic for NAT setups. The one IPv6 specific one I saw had to do with a bad firewall rule allowing access to LAN facing services running on the router; it could have just as easily been a bad IPv4 rule.
I agree, consumer network gear all sucks. IPv6 is bolted on as an afterthought, and is probably buggy in a lot of them. More features means more opportunity for bugs, but that's true of anything. IPv6 isn't being deployed for no reason; there's limited IPv4 addresses to go around. I still don't follow why IPv6 is fundamentally riskier than IPv4 when traversing a router. Sure, with NAT an incoming packet needs to have a port number that's been dynamically mapped back to an internal host and port, or have a static port forward. In IPv6, an incoming packet needs to have a destination address and port that's been dynamically mapped back to an internal host and port, or have a static firewall rule. It's basically the same, but also less complicated for the router because there's no translation involved. In time, less complexity is good for software hardness.
I also get anxiety from trying to wrap my head around IPv6 address assignment. It is nuts. It's very comforting to work in the effectively 8-bit address space of a /24 IPv4. I suppose it's true that you can't control internet routable IPv6 addresses in that they are dynamic and ephemeral in their nature. Coming from IPv4, it feels messy. I've experimented in detail with configuring my own ULA, DHCPv6 configuration, and SLAAC. I've tried to embrace the benefits of IPv6, and having used a few of the features I can appreciate them for what they are.
One of my main concerns is when the firewall stops working (due a poisoned packet what shutting it down, what would be the first logic kind of attack I guess) currently the access to the "local" network would be granted with IPv6; the network becomes the same as the attacker's one.
I put the CVE links with the generic word "firewall" because it is the point where the "local" vs "internet" resides with blind faith within IPv6 (without indicating an specific exploit, just vulnerabilities exist). For this case, the DDOS and buffer overflows that force the firewall to shut down, or code execution, what are periodically discovered, is what I wanted to show for being considered as a serious problem. Not everyone reports firewall bugs, and others I guess even wickedly insert them.
With NAT setups, the local and internet networks are different between them, what requires the packets to be filtered and rewritten by NAT for the address what solicited it, while unsolicited packages are discarded. The NAT in consumer gear is run mainly by software, but a poisoned packet will not aim to shut it down for network penetration because it would be the end. If the NAT stops working, the doors close for everyone.
It is about the double checking,
-IPv6 without NAT: If the firewall stop working, opened doors. Feast.
-IPv6 with NAT: If the firewall stop working, many rules get unfiltered, wild. But NAT keeps the local/internet separation besides filtering unsolicited packages. Not absolutely secure, nevertheless keeps being a complex target.
Like all of we, I suffered some problems that NAT can bring losing countless hours trying to make work some specific services, but when I first read IPv6 didn't implemented NAT nor something similar in the protocol (for whom whish to use it at least...) and what the supposed local IPs are merely part of internet (link-local addresses that aren't routable as first target, devices with internet connection are), each device with its own public address, I doubted seriously about what was going on.
Given that even Mikrotik RouterOs periodically have security vulnerabilities related with the firewall, I can't conceive the idea of people relying on firewalls rules to do the home/internet separation within IPv6 (plus the public address of each device gives me also anxiety), as it is a matter of time before such separation ceases to exist; it is like the crossing of fingers.
I mean, it is not a matter of misfit, it is more like the users will not even notice the router's firewall was shut down.
Not at all, your "local" network is the link-local address space, which legacy IP has no analog of. The link-local space cannot be routed either intentionally or accidentally.
RFC1918 address space IS routable, it just doesn't have a global route. There is nothing to stop devices adjacent to your wan interface (ie other customers) from manually adding a route to your RFC1918 address space via your firewall. Will that traffic be allowed? that depends on the device and its configuration, have you ever tested this scenario? probably not.
NAT is a hack to get around a shortage of address space, nothing more. Once the shortage is gone there's no more need for NAT. That's why although NAT with IPv6 is possible, it's very rarely used because you no longer have any valid reason to use it.
If you are think there are any other reasons to use NAT then you need to brush up on your network knowledge because a lot of smarter people than you or I are saying to avoid NAT and designing systems (eg IPv6) to fix the problems it causes.
US government advice is to avoid the use of NAT because of the extra complexity it introduces, which actually reduces security:
> It is an additional rule in the router's firewall what temporarily avoids it.
I really don't understand the fearmongering. Your home router likely runs some flavor of Linux which uses Netfilter/iptables to perform both NAT and filtering. Do you believe that the filtering/firewall modules are inherently flawed, yet the NAT modules are infallible?
I see them as two sides of the same coin. If we're theorizing about a magic packet that not only removes your firewall rules, but also flips the default policy to ACCEPT, the very same packet could also sneak in a few NAT rules into your IPv4-only router.
> Further, because you don't have only one external IP, you don't have to futz around with non-default ports if you want multiple instances of the same service (e.g., Minecraft), because each instance can have its own IP.
This is an interesting point though personally I love how easy container technologies made exposing arbitrary ports, without trying to configure the software itself, or checking whether it even supports customizing the port.
For example, I could have 3 database instances, each using 3306, but expose them on 30000, 30001 and 30002 or whatever I want.
But the things connecting to them need to know which non-default ports to use!
The Gods intended for each database service to have its own IP address and I curse the market forces that have trapped so many of us in the quagmire of NAPT!
Of course I do. Why would you not want the option of easily allowing a device to be globally routable if you need it to be?
I think routers should be more explicit about how you set up each new device on a private network anyway. Guest wifi can have a sane default. Private wifi could make a notification pop up on your trusted device, asking you if you want the now device to have access to the internet, and if the internet should have access to the device, and if so, which subnets/countries should be able to access it through which ports.
It's fairly common to want P2P connections, even if the users aren't aware of it. A lot of online games rely on NAT traversal, sometimes automatically picking a host based on whoever's NAT it can get past. I don't remember the details, but even the Nintendo Switch cares about NAT.
A lot of would-be P2P applications end up using a relay server to get around that restriction, which adds significant cost and latency. Sure it's a well-established workaround by now, but it'd be nice not to rely on it.
The article uses gaming and IPSEC as examples but not, say, ad servers and "tech" company websites or other websites desperate to collect data. Interesting coincidence.
As the parent suggests, IPv6 creates more work to prevent more exfiltration. It is already difficult enough with IPv4.
Could IPv6 fix a web infested with "tech" company intermediaries and return it to one where all participants can connect directly and if desired publish to audiences (without "tech" interplopers). That sort of proposal would make an interesting read for end users.
Even if you never allow anything in from outside that wasn’t established from the inside first, it still removes an added layer of complexity from things.
NAT is not only bad because you don't have publicly routable addresses, but because it's a hack and a pretty "clever" one at that, aka, incredibly nasty.
If we had networking protocols that took into account the complexities of private addresses it could probably work - but we don't have such a luxury. The entire TCP/IP stack assumes peer to peer connections, and NAT is literally a spanner in the works for all that.
Routable does not mean reachable. A firewall is perfectly capable of controlling traffic between two routable addresses, without the added burden and complexity of having to translate the traffic to/from a non routable address.
The whitehouse has a public address, everyone knows its address and yet random people can't just walk in through the front door.
It's been ~10 years since IPv6 became "ready for prime-time" and I wouldn't touch it unless I absolutely have no other choice. In practice you are going to run into bugs and problems at every level, from client software to the OS networking, your router, your ISP, their ISP, their router, their server and so on and so forth. I absolutely support other people using it to iron out all the kinks, so that I can finally do it without headaches in 10 more years.
I've given a try to IPv6 in a company with few tens on servers in a 2 DCs, an office + additional location, 3 ISPs in total. For me the real challenge is not just different way to write an IP address or doing NAT. The challenge is that IPv6 changes a lot of unexpected things:
- Our ISPs support IPv6 but routing quality is way worse than IPv4 including occasional inability to connect to some networks or greater latency than IPv4. I had to create tickets with such issues understood that most probably they just don't have IPv6 BGP sessions to all their upstream providers they connect.
- How the VPN (an employee / road warrior setup) should be configured since from the routing perspective you don't need a VPN to connect from your home to the office? Assuming both have proper IPv6 connection and all devices in the office and your laptop have a globally addressable IP address. Employee can have IPv4 or dual stack at his home, where is dual stack in the office. Very confusing. Looks like Fortigate also don't have an idea and decided to not support such case.
- You have to be careful with site-to-site VPN since even your internal services like database are now globally addressable. You really need proper firewall rules / routing policies to not leak unencrypted packets over internet.
- SLAAC is cool but doesn't provide DNS configuration. (there is RFC8106 but is it supported by all OSes?). You need DHCPv6 for that. You have to choose: use only DHCPv6 or SLAAC + DHCPv6 or just relay on the vast that DNS will be proviedd by DHCP IPv4 in a dual stack setup.
- The way of providing high availability gateway address in a network is different. You need router advertisement where you can provide priorities. That actually is much better than any other VIP mechanisms (no issue with MAC table updates, etc.) but you need to know that.
- OSPF works a bit differently. For example: there is no authentication in router communication in OSPF itself, you are supposed to use IPSec.
> You have to be careful with site-to-site VPN since even your internal services like database are now globally addressable. You really need proper firewall rules / routing policies to not leak unencrypted packets over internet.
Sure, you can. But on advantage of IPv6 is you addresses are globally unique. If you ever need to connect two networks that were created independently (like different companies), unique addresses, even local are very helpful.
Sure, but ULA's within your network are still an extremely useful tool to deal with annoying problems like renumbering if you don't have PI address space (and a majority of businesses won't). It's not an ideal solution, but unless you're a large enough shop to have multi-homed BGP sessions the IANA doesn't give a shit about how much headache changing ISPs or backup connections cause and getting a new allocation causes; so ULAs fill that gap to give a non-changing, probably-unique (if you follow the proper process to generate your prefix) address space.
There's no reason you wouldn't use a VPN in exactly the same way. Just because devices have routable addresses doesn't mean they will allow connections from arbitrary sources. You can configure them to only allow connections from your IPv6 VPN pool.
On the other hand using globally unique IPv6 addresses means your VPN won't conflict with the source network where users are connecting from.
SLAAC can provide DNS configuration, see RFC6106 for instance.
You can do HA in the same way with VRRP or whatever too, as you point out the built in mechanisms are generally better but you don't necessarily have to use them.
The chance of traffic leaking still exists, and does happen a lot with legacy IP too. The difference is that with v6 the traffic will be routed back to you, so you will be able to see it on your border firewalls. With legacy IP, the traffic will be dropped by the ISP or absorbed by the local network so you don't know it's happening and consequently you probably won't try to do anything about it.
> You should stop thinking of NAT as a security mechanism and think of it as the emergency address exhaustion prevention that it is.
I hate this attitude. This is isomporphic to saying "stop thinking of system call interfaces as a security mechanism and think of them as an address space sharing mechanism". It's not technically wrong, but it's wrong in practice.
Even the most naive NAT can't misroute an inbound packet. If you have an internal host and it doesn't talk to anything outside the firewall, then no one else can reach it. They have no name for it, the packets won't go. You get this even if you don't understand how it works. You get this even if the router has no idea about the host.
Give everything a unique address and now the router needs to know who is safe and who isn't. That's a decision point that requires configuration by human beings, and human beings get stuff wrong.
No, NAT is your friend. Use NAT. Use it even if you're an IPv6 nut.
I'm sorry, I don't follow. Our grandparents have working, secure NAT setups that no human being needed to configure. I've never once seen a "firewall ruleset" configured by a non-geek.
Really? I changed ISPs the other day. Got my new modem/router. You know what I did in terms of firewalls? Nothing. You know what I have? A firewall that blocks all unknown incoming connections. Does it work? Yes. Did I even have to do anything besides plug in the box? No.
Not commenting on the whole IPv6 vs IPv4 debate but simply answering your question...
There aren't enough IPv4 addresses, so any ISP using IPv4 addresses is going to give 99.999% of their customers exactly one IPv4 address. Not ten. Not two. One.
So NAT has to work. Grandma has nothing to configure because either NAT works or grandma is calling her ISP to ask why her tablet ain't working.
So when the customer gets exactly one IPv4 address, the ISP is forced to hand a router doing IPv4 NAT. They have no way around it.
While if you take an ISP handing out hundreds of billions of IPv6 addresses to each customer, well... They are not forced to hand a router which does proper firewalling.
It's not a question of whether it'd be easier for the ISP to give a correctly configured IPv6 router firewall vs handing an IPv4 correctly doing NAT.
It's that when they hand one IPv4 address, they don't have the choice. NAT must work and there's no way around it.
I'd love to embrace ipv6, but my ISP's official line, for as long as I can remember, is 'planning it, details to come'.
I don't expect them to move forward on it until significant sites become ipv6 only as they've admitted that they have more than enough ipv4 addresses for their subscriber base, so there's very little incentive for them to do anything atm.
Thanks, I've actually looked at that in the past, but I'm not sure what their throughput is, and I'd have to configure each device individually as the router I have can't be configured for it.
I think I've still got my HE IPv6 t-shirt somewhere, from when I completed their readiness quiz so years ago!
Edit: I actually decided to set up a tunnel, just to see how well it worked, and it turns out my ISP supplied router won't forward the protocol 41 packets anyway, so that's a total no-go.
I suppose I could probably set up a small VPS and Wireguard vpn, then forward the IPv6 packets that way?
https://route48.org/ provides 6 in 4 tunnels and wireguard is an option. Their webpage is a mess, but more info is available behind the login, IIRC. I got part way through and then decided to just use a Hurricane Electric tunnel because HE has presence at the nearest internet exchange and it was more familiar.
Question from a (relative) IPv6 newbie that wasn't addressed in TFA:
Let's say I have a very small home lab. I have a handful of hosts that get their IP addresses via DHCP from my router. In the router, DHCP and DNS are tightly coupled such that the router essentially always knows the MAC address, IP address and hostname of each device.
Now I want to run IPv6 on this network as a first-class citizen. Since DHCPv6 is apparently frowned upon by v6 purists, and not all devices on my network support it, that leaves SLAAC. My understanding of SLAAC is that each node essentially picks its own globally unique IP instead of asking a router for the IP. My question then is: is there some standard for the DNS server on the router to somehow know the v6 IPs of the hosts on the network so that it can automatically create the right A records?
In what way is DNS and DHCP tightly coupled? Automatically creating A records for DHCP hosts is not normal in my experience, especially for consumer routers. If some device your using supports this it could work for IPv6 as well as devices will broadcast on the network for routers when using SLAAC I believe.
Many home devices use dnsmasq as their DHCP server and DNS resolver, and it can optionally use hostnames from the DHCP part of its business during resolving DNS too.
The point GP had that it won't work, then DHCPv6 is not used.
I have a similar setup. I wouldn't say that DHCPv6 is frowned upon, it works quite well and is the only way to automatically add client hostnames to the local name server. I use both SLAAC and DHCPv6 mainly because Android refuses to support DHCPv6, but I don't need to refer to my phones by hostname anyway.
I’m in a similar spot as the OP, and one thing that is important to me about knowing the hostnames is that defining (then tracking) a hostname is the only universally-implemented method that lets me scan through the hosts on the network and understand what they all are.
- I’m never going to remember MACs
- Even when IPs are carefully thought out, if something happens to the DHCP server and it needs to be rebuilt, IP no longer tells you anything about what device it is
Whereas hostname/DHCP client name shows up in almost every router UI, is viewable from any *nix machine on the network (when DHCP and DNS work together), and is typically a first-class citizen in the DHCP lease settings themselves. Super handy. As a side bonus: rogue hostnames are immediately obvious, but rogue MACs or IPs require investigation before you know whether they are benign.
Can't answer your main question, but from what I recall, DHCPv6 is kind of necessary anyway. It's the easiest/main way for the client to receive DNS server information, even if default gateway discovery is now down through multicast.
I believe there is another way, but the router has to support it and I forget what it's called.
It isn't really true that DHCP and DNS are coupled, it's just a common feature for power user routers as it's convient.
There are options for IPv6: PFSense, as an example, has "Assisted" RA mode where devices can use SLAAC or DHCPv6, so you have SLAAC for general clients that don't need more (e.g: phones that don't support DHCPv6), but clients that want more can use DHCP to provide specific reserved addresses and DNS names, etc...
The way I handle this on my home network is to advertise a ULA prefix in addition to the one delegated by my ISP. The ULA addresses are not routed. They’re just used for my network. My home DNS server advertises AAAA records using the stable, ULA addresses for those servers I want to advertise. For other machines (like computers, laptops, etc), I rely on mDNS.
that thread is amazing. Google's stance makes me want to deploy DHCPv6 simply to spite them. I guarantee in 10 years when some Fortune 500 company or top 20 research university IT department, who has no idea about that thread, goes live with a DHCPv6-only IPv6 stack because it's very similar to their IPv4 network, and 30,000 users can't join their Android devices to the campus wifi, this attitude will change
If I want to connect to something by name then I setup a wireguard connection with a fixed ip. The few things that don’t allow for that all use mdns anyway.
>Since DHCPv6 is apparently frowned upon by v6 purists, and not all devices on my network support it, that leaves SLAAC.
It's not a dichotomy between DHCPv6 and SLAAC. You can hard-coded addresses too. Since it's your homelab you presumably already know all the devices that will be connected. It's what I do.
You may not even need to hard-code the prefix everywhere. Eg with systemd-networkd you can configure the device as:
... which will give that interface the address $prefix::1:2:3:4 based on whatever $prefix was advertised by radvd. So the only place where you'd need to hard-code $prefix is in your DNS server.
>My question then is: is there some standard for the DNS server on the router to somehow know the v6 IPs of the hosts on the network
NDP discovery (`ip -6 neigh show`) will let you know about other IPs (and corresponding MAC addresses) on the link. It won't do anything for matching them up to DNS names.
It's important to distinguish between stateful and stateless DHCPv6. stateless DHCPv6 is fine. It's just a way for nodes to get dns/ntp/etc. Nodes still select their addresses with SLAAC.
Stateful DHCPv6 is the bad one. It assigns hosts specific addresses.
> the router essentially always knows the MAC address, IP address and hostname of each device.
You can still have this with ipv6 addresses. They easiest way is to use eui64, the original ipv6 addressing scheme where the address is calculated from the subnet + the MAC address of the interface. That way server VMs get deterministic addresses. If you use network-manager you can configure eui64 with the "add-gen-mode=eui64" setting.
In my homelab, I have a few server VMs that use eui64 addressing whereas the end user devices use privacy addresses randomly selected from the subnet.
My experience with IPv6. I have option to enable full dual stack with my ISP.
After doing this I noticed that YT/FB/Google were significantly faster, however my kids started to complaing that some games began to have connectivity issues. Minecraft have problems to start. On a number of sites load time was noticebly longer. Switching off IPv6 as a experiment on one of kids PC solved all issues.
My conslusion is that it is not worth to enable IPv6 and spend time to diagnose constant issues with random pages and services.
It doesn't say a lot. What says more is how often you seek home networking advice and one of the first troubleshooting steps is to disable ipv6 (though restarting the router is probably first).
If we’re talking anecdotally, I am running dual stack IPv6 and have had zero issues with Minecraft or any other game on my network on Xbox, Switch, iOS and PC.
Minecraft does not support v6 but I wonder what caused the issues. Maybe the presence of v6 support caused DNS to give a v6 address and this caused problems? Seems unusual.
Same, my Xbox series x is noticeably faster with matchmaking games. Lobby time and searching for new games dropped from 3 minutes on average to about 45 seconds.
Agreed- I turned on ipV6 and even tried turning off ipv4. All I found was a bunch of new, different problems to debug that were inevitably because somebody else somewhere doesn't support ipv6, or I would have to run some sort of bridge between the two networks. Of course this is for home where I don't need a gajillion publicly-routed IPs.
This is a frustrating take which I find myself challenging again and again and again. The need for IPv6 is not just about how many IP addresses _you_ need. The need for IPv6 is a global issue for a variety of reasons, including finding addressing for all of the millions of people and billions of devices still to come online, reducing complexity for system and application developers and being able to finally shed decades of protocol design decisions that have ended up being more painful than helpful.
Everyone is always so quick to jump to how _they_ don't need IPv6. The truth is that we _all_ need it. Eventually, there will become a day when services will start to migrate to IPv6 because the cost and limitations of IPv4 addressing will become prohibitive. Then you'll no doubt care when it affects you personally.
First thing I do setting up any network is disable ipv6. It's caused issues at least once, and that's one time too many for something that doesn't benefit me in any other way.
On my linux machine, dns queries would sometimes last 5 seconds with ipv6 enabled. It made my internet surfing experience extremely frustrating. Disabling ipv6 resolved this issue.
Don't really understand networks yet, but I guess it was because my isp doesn't support ipv6, but linux kept defaulting to ipv6 before trying ipv4.
Most likely your DNS (which may be the ISP default) is bad at handling ipv6 queries, solvable by switching to Cloudflare DNS or something. If you care. Probably neither of us would bother.
There's a reason most haven't moved to ipv6. ipv6 is a solution looking for a problem. What we really need is an ipv7 that takes the best of ipv4 and ipv6 instead of trying to force ipv6 down a reluctant user group.
My public IPv4 is something like 14.63.323.85, private is 192.168.1.2 (others are .3, .4, etc), DNS is 1.1.1.1.
My public v6 would be like 2345:0425:2CA1:2020:1100:0567:5673:23b5, private is fc00::::903A:1C1A:E802:11E4, DNS 2606:4700:4700::1111 (don't forget those consecutive colons).
It's not that I don't like change, it's that I don't like changes that make things plainly worse for me.
You can't have the best features of the two - in the sense of interoperability - because they are different on a fundamental level: it's impossible for IPv4 nodes to talk to IPv6 nodes without understanding the much larger address space.
There were proposals back in the day (early 90s) for IPng (IP Next Gen, as IPv6 was called back then) to be a hierarchical routing algorithm, that could have kept backwards compatibility with IPv4 and transparently allow seamless operation and routing of IPng islands over IPv4 infrastructure, taking full advantage of the address space expansion.
Think of a sort of CGNAT that instead of stateful hacking with port numbers and the like, would have dedicated fields in the IPv4.x packet, allowing the gateway to statelesly route between the two domains (public IPv4 internet and internal 10.x.x.x network), while maintaining end-to-end connectivity.
Alas, the ITEF guys really wanted a clean slate design and willfully ignored the economic problem, that IPv6 is only useful when everybody upgrades, and as a consequence nobody upgrades. It's probably one of the most costly failures in the history of computing, along with the NULL pointer, 640kB and the likes.
42% of the internet uses v6, and rising. The economic incentives for ISPs absolutely exist, as v4 addresses become ever more expensive and the cost of CG-NAT deployments continue to climb.
> v4 addresses become ever more expensive and the cost of CG-NAT deployments continue to climb.
But IPv6 is not an alternative to CGNAT. If you don't provide either a routable IPv4 or CGNAT, your customers will ask their money back because their internet is broken. The fact that you provide IPv6 or not is completely irrelevant to the vast majority of consumers or businesses.
This here is the major failure of IPv6 design, confusing what "the internet as a whole and the ISP community" need, with the individual incentives that make a single ISP provide for those needs.
The problem is that IPv4 is not forward-compatible and therefore there cannot be a protocol that is entirely interoperable.
There can only be ones that are somewhat interoperable.
And IPv6 has plenty of mechanisms that make things interoperable (NAT64, embedding ipv4 addresses in ipv6, etc.).
What we need is a pure 4 network to be able to talk to a 6 network - that's what it means to be interoperable. Going 6 to 4 is obviously required or otherwise 6 would be a useless protocol to begin with. Anycast routing plus tunnelling is one way to achieve 4 to 6. But the "ngtrans" team didn't accept this a transition plan, nor did they provide an official transition plan for migrating 4 to 6. Basically 6 has been a disaster since the days of IPng and misstep is ignored because they wanted a "clean slate" architecture with a large IP space that nobody really needs.
I'm holding out for a new protocol/architecture to come along and supplant IP by recognising that it needs to be fully interoperable with 4 before it can supersede it.
I think this discussion is 20 years too late, the only reasonable way forward is IPv6 or bust. We're reached the end of the IPv4 space and the pressure is mounting; any imaginable backwards-compatible technology would have to run for many years in a limited mode where it's basically just a better way to do NAT traversal and only then, when most endpoints are compatible, you would get to see the address-space relief benefits.
Another nail in the coffin of a graceful upgrade from IPv4 is the widespread filtering of IP options in the backbone, the only practical way I know you could craft an extended IPv4 packet that is still routable by the legacy infrastructure while forwarding and maintaining all the extra header data required for routing in the IPng realms. This was not necessarily true in the early 90s, and many hardware generations would have had the ability to fix it.
So I somewhat disagree with the GP that IPv4 was not forward compatible: it included a mechanism for just that in the form of IP options that seemed like a good idea in 1983, but which proved technically inappropriate for the future needs of the internet. So you can't really fault IETF for wanting to break away from that and earnestly thinking people would just upgrade.
How exactly do you propose this 4 to 6 mechanism to work?
How do you fit more than 32-bit of information into the 32-bit destination field of IPv4?
Because that's what's required to make it fully interoperable.
Anything else and it's not a pure IPv4 network anymore and you are in the exact same situation as we are with IPv6.
Having IPv4 host talk to IPv6 server isn't really necessary since there are enough IPv4 addresses for external servers. IPv6 is most important for client addresses to replace NAT, especially carrier-grade NAT, and simplify networks.
The article mentions NAT64, which works well for IPv6-only computers to talk to IPv4 servers. There is enough space in IPv6 to encode the whole IPv4 connection which makes stateless NAT possible.
The other mechanism is 464XLAT and MAP, where IPv4 isn't tunneled over IPv6 network, but encoded in the IPv6 address. 464XLAT is used heavily on mobile phone and uses software on the device. MAP requires support on gateway. MAP is stateless which is savings over carrier-grade NAT.
>There seems to be a lack of drive (judging by forum posts) to enable IPv6 on internet services by admins, either because they don’t care to, or it’s more work to manage a public IPv4 and public IPv6 presence
If you run a mailserver adding ipv6 support is far more risk to your domain's mailserver reputation than it is worth. And if you're just a human person and not a megacorp that new ipv6 address, even if it it doesn't immediately hurt you, will take a very long time to get accept, longer than an ipv4.
And that's the problem! Who can memorize all that?
I mean look, a few days ago Comcast had an outage and I plugged my phone into my USB port to tether it for internet access. It hijacked my DNS entirely, and I couldn't turn on my damn lights or change my thermostat which were on my LAN. Thankfully I know their LAN IPv4 addresses from memory, 10.10.10.x and 10.10.10.y, and I was able to issue CURL commands directly to their local, non-cloud APIs to manipulate them. With IPv6 hell knows what their hex-colon monstrosities would be.
And so now I have to stick stickers on every light bulb with a huge address on it and then get up on a chair several times per bulb while I transfer chunks of its address from the sticker to my terminal?
The reality is with IPv4 I can memorize all of the IPv4 addresses of every light bulb, every robot, every thermostat, every plant watering device in my residence, and I can hammer out CURL commands to control everything almost from muscle memory in the event of a DNS hijacking.
Why do you need stickers? You can just log into your router/switch and inspect the arp/nd table. You could just just use DNS records the first time you set a widget up and never have to remember an address again. Your router likely already does this automatically for you in IPv4 land via the DHCP server's database. The reality is that remembering IP addresses to access things has always been a band-aid fix. When's the last time you typed the IP address of hacker news into your browser's url bar? Using link-local addresses is usually a last-resort kind of scenario where you're glad it exists to save you some headache.
Yes but my phone hijacked all the LAN DNS when I plugged it into a USB port for tethering when Comcrap went down for a few hours
Also separately, when Comcrap is working, my phone on Wi-Fi refuses to ever use the router DNS, http://xyz.local addresses are only available on desktops/laptops and not phones, therefore IPv4 addresses it is when trying to visit a LAN site on a phone.
"Yes you would know exactly, because every hex-colon monstrosity has a predictable hex-colon monstrosity derived from its hex-colon monstrosity."
If the problem wasn't obvious, the problem is that IPv6 addresses (and also MAC addresses) are not human readable. IPv4 addresses, on the other hand, are.
IPv6 adoption might be farther along if the addresses were human readable instead of eye-rolling machinations of a small subset of people who speak strictly in hexes.
Adding A-F to the 0-9 existing digits in ip addresses makes them non-human readable? Give me a break. We've had something human-readable since the dawn of the internet: it's called DNS and works with both IP families.
Tell me Google DNS's IPv6 addresses without looking them up. I won't wait.
Sometimes we need to deal with raw IP addresses instead of abstraction layers, and IPv6 fails hilariously because it clearly goes beyond the realm of direct human consumption.
You saying a non-human readable thing is human readable if it's passed through an abstraction layer to make something human readable only reinforces the argument IPv6 is not human readable.
Windows and many Linux distros by default enable the privacy extensions on the link local address; it's randomized for a period of time. This is right off a Windows 10 VM:
Well, that is unfortunate because it invalidates a lot of the benefit of the link-local address while providing "pivacy" over the local link scope... I have not encountered any equipment in the wild that does this, thankfully. The only distros I use (NixOS and VyOS) do not have this behaviour by default so this was news to me.
The link-local address is generated when you first enable the interface (ie when you load the drivers for your NIC), it won't change unless you manually force it to.
Linux will use EUI-64 if left to its own devices, or privacy extensions if you're using something like networkmanager. This makes sense because a desktop oriented distro will typically use networkmanager while a server oriented distro will not, and having a predictable eui-64 address is usually beneficial for a server.
Seems like a complicated solution to a problem that does not exist. You cannot turn on lights at all without a working network? If your router crashes your whole house is stuck? Seems like there is a bigger issue than the IPv6 protocol
No, it should usually look like v4, except in cases where you're using more address space and need to add more dots. NAT is here to stay, and a LAN doesn't need 128 bits of address space.
...This thread shows that the ipv6 notation is more complicated. It's good to at least use a smaller address space on a LAN like this, but I want the basic decimal notation.
Yes, which is why they shouldn't use those huge prefixes. There's an existing 32-bit address space represented nicely like 8.8.8.8 or 192.168.1.2 for local. Now that we want to extend the address space for more users, the newer ones can be like 8.8.8.8.6 without messing with the existing ones.
You'd still need to upgrade and change every device. There have been transitional software that used ipv6 but allowed for ipv4 address notation. [1] Example:
::ffff:0:8.8.8.8
The huge prefixes allow for a simple hierarchical network structure and gives us room to redo the address scheme if we end up wanting to (only a portion of addresses space is currently allocated right now) without having to go through this entire upgrade the internet again.
Right, I've seen the padded v4-like v6 address spec, but that's not how they attempted to transition everything. ISPs gave everyone new v6 addresses, and the whole home/office router/NAT/PC ecosystem put v6 on a totally separate plane with ::: style addresses presented to users. I understand that the clean slate of reallocated addresses would solve some problems, but they could have focused on just getting all that hardware and software onto the ipv6 protocol with minimal changes before attempting to basically redo the entire Internet along with every LAN.
As an end user who has a choice, they have to give me something that's not harder to use than before. I think they could have managed that if it were a priority.
Not sure I understand. Right now you should have dual stack, which should be easier than merging the v4 onto the v6 network. You didn't have to change anything to keep working with v4 and if you want to work with v6 then that's an option for you but you can disable if you really want.
I'd like to use v6 in the dual-stack setup, with all the v4 addresses copied over so that there's no visible change. I'd just be using a different protocol under the hood, similar to how upgrading DNS or HTTP versions didn't change all the URLs.
I'm not an IT admin, but I disagree the world is not moving forward.
If I need to use IPv6, I would switch. But the reality is people are able to still build rocket ships, electric cars, and large language models with IPv4. The world is moving forward just fine.
I hope you're on the new version of everything then, not just in your area of expertise. You're expecting people to want something that's worse for them if anything, and calling them lazy isn't going to help. What would've helped is making IPv6 more user-friendly.
Not new version, but reliable version. I'm not a bleeding-edge fanatic, but I was testing IPv6 during the 6bone[1] phase while networking was not in my scope. It simply made sense to get to know the future.
The person who's comment I was responding to, is in denial 20 years later because they feel comfortable with IP addresses they can remember.
20 years later, a lot of things still don't support IPv6, and "IP" commonly means v4 unless otherwise specified. v6 isn't the stable thing yet. Less involved users aren't concerned with much about IP other than the addresses, and v6 changes those when it didn't really have to, so this is what happens.
I think the other commenter and I would both happily adopt v6 if it gave us v4-style addresses.
: separates groups of 4 while optionally :: abbreviates a bunch of 0's and leading 0's in groups are optional. The address can be longer, sure, but it's really near identical to dotted decimal beyond the lengths.
I wouldn't mind a simpler DNS server IP though seeing as it's one of the few locations you need to treat as an address regularly. Sprint/T-Mobile has 2600::, which is not only short but seemingly a phreaking reference, active so why can't something similar be active for DNS. I get not wanting 8888 or whatnot, those blocks aren't assigned and advertising random bits for vanity can be annoying, but there are plenty of short IPv6 addresses that could be in use for the most common DNS servers on the planet. Even I have my personal DNS server running on an XXXX:XXXX:: public IPv6 address!
> separates groups of 4 while optionally :: abbreviates a bunch of 0's and leading 0's in groups are optional. The address can be longer, sure, but it's really near identical to dotted decimal beyond the lengths.
Consecutive colons aren't readable or easy to remember.
There are only a few people on my LAN. For the Internet, use more groups when people need more addresses (like 8.8.8.8.3), and leave the existing addresses like 8.8.8.8 alone. This didn't have to be complicated.
I've been saying this too. Don't tell me that going from 8.8.8.8 to :whatever::the::heck:::: is an upgrade.
First step of dual-stack networks should've been, every device's IPv6 address is the same as the IPv4 address, just padded technically, and represented textually the same. If I put in 8.8.8.8 and the systems want to speak IPv6 instead, go ahead. A little hacky but addresses (no pun intended) both technical and marketing problems. You could even use a v4 DHCP server and DNS but speak IPv6, instead of trying to sell people on a whole stack change at once.
Newspapers still work.. Why are you here at all instead of writing a letter to the editor of your local newspaper with good old pen and paper?
New technology has benefits, if you don't know what they are then you need to learn about them properly. Sticking with old technology because you fear the new is not a good plan.
In an organisation of any significant size, remembering legacy IP is much worse than v6.
Chances are you will have lots of disparate legacy blocks, some starting 1.x, some starting 80.x etc. Then you have all the RFC1918 space, and the possibility of overlapping address space in different areas of the business. Then you have to keep track of translations, so an internal address 10.1.1.1 could have an external address of 80.1.1.1 but only on port 25, if you're talking over port 443 then actually the traffic is forwarded to 192.168.1.1 instead.
IPv6 is simpler. You have a single prefix for your company, eg 2001:db8::
Then you split it out in a sensible hierarchical way, for instance 2001:db8:1:: is your facility in the US, 2001:db8:2:: is your facility in Canada etc. Beyond that you go down to VLANs and hosts as needed.
So 2001:db8:2:25::1 is a device in your toronto data center...
80.1.1.1 is where?!?!?
192.168.1.1 is where?!? and which one did you mean?!?!
Then there's no NAT, no address overlap, much simpler. 2001:db8:2:25::1 is the same device wether you're talking to it on port 1 or port 65535. Your firewall rules are simpler and more secure as a result.
Microsoft had a presentation about this, and they are a bigger organisation than most.
If you're only small then you don't care, technologies like SLAAC and MDNS exist for exactly this reason.
Yeah I get it. At an organization your size, you want IPv6.
I was illustrating why there is zero incentive for 99.99% of people to not care, which is the reason why it isn't getting adopted.
If moving my home network to IPv6 came along with some incentives -- e.g. significant tax breaks, free symmetric gigabit for a year for IPv6 traffic, discounts on rent, tax-free early IRA distributions to buy networking equipment, free electric car charging for 5 years, I'd move to IPv6 in a heartbeat.
The point is until everyone moves to IPv6, the rest of us are stuck having to support dual stack - which is expensive (see the recent story about an ISP supporting a tribal reservation who had to spend an extra $300k and wait 11 months to support legacy IP) and introduces complexity/risk.
For a small network it makes no difference, everything is auto configured, mdns is used to lookup names, you can makes your hosts ::1 ::2 etc if you want to. Many ISPs around the world provide IPv6 by default, and users are using it without even realising, so it is being adopted just not fast enough. Global usage is around 42% based on published stats, and is well over 50% in many countries, as high as 80% in some.
IPv6 does provide benefits to end users, it reduces cost for the ISP and makes end to end connectivity viable which opens up a whole new set of opportunities. End to end is immensely beneficial for gaming, voip etc. Having everything centralised because users are encumbered by NAT is a big problem - increased latency, high costs (recouped from the users somehow - eg selling their data), single point of failure, applications which become useless once the central servers are shut down etc.
Maybe the addresses wouldn't look so scary if you formatted them correctly.
For example: d0ff:eefa:10::faff:92:0 (though there are currently no addresses in use that start with d.)
Vanity IPv4 addresses like 8.8.8.8 exist because most addresses have been allocated, so companies with money can go hunting for nice ones. There aren't many IPv6 addresses like 2600:: because internet registries don't allocate them on purpose, and I'm not sure if anyone's cared enough to bribe them.
That's difficult to memorize, just like it would be difficult to memorize the mailing address for a random hut in Africa. The world is a big place, so unique addresses are necessarily long.
If I wanted a memorable local address like 10.10.53.24, I'd pick fd53::24 or something.
510 comments
[ 4.2 ms ] story [ 331 ms ] threadFor networks (order of preference): IPv6 only > IPv4 Only > Dual Stack.
I keep hearing this, but it doesn’t seem more simple to me. My ISP won’t reserve me a /48, so I can’t control the management ips of devices on my network. The solution is apparently to set up dynamic dns, which I have no interest in doing.
The apparent issue here is that you're falling back to what's familiar- static IP addressing. How about mDNS?
(Unless you're putting them behind an IPv6 NAT, so thry can have their oen private /64).
It's not great, but it's an option!
I understand the support of new technologies but IPv6 is 27 years old.
Cracking and Hacking world is awaiting with open arms IPv6 because a pain in the ass called NAT was removed from the specification, and only a tinny exploitable fence was left for Router's future. Now the enterprise environment will have their needed paid additional security devices with their scalability while the average user at home have to cross fingers for not being the target of a zero day. Tracking Advertisers are also very happy.
Its sad to hear about the supposed reduced network complexity when its needed even an external DNS service for being able to manage your own network at home, lets say your NAS with audiovisual content as mere example, what forces one to create additional secondary real local networks if one don't what to rely in external DNS services for to being able to know the IP of your own device.
What are the non-network team business benefits to IPv6 over v4? That is what drives adoption.
These problems will only get worse from here on out, but they're not as visible to people outside networking because this degradation of quality of service is a slow creep. The IPv4 Internet just gradually gets more and more limited in capability and less reliable for anything beyond the most basic use cases.
IPv4's address space is simply too small. There are already almost twice as many people on Earth as there are possible IPv4 addresses, and that assumes perfectly efficient utilization of IP addresses which is pretty much impossible. In reality there are probably 8-10X as many humans as viable IPv4 addresses. If every human being tends to have a computer and a phone that means there's at least 20X more devices than IPs.
You know, that used to be only "if every human being tends to have a computer", since phones didn't have an IP address. Now it's "a computer and a phone". A few years down the line, you'll have "a computer and a phone and a watch", then "a computer and a phone and a watch and a standalone VR headset", and so on.
However, assuming that I and my organization have enough IPv4 addresses (without requiring any of the tricks of multiple layers of NAT), is there a sufficient reason for us to justify the effort/expense of changing what works?
For example, I'm in the US, and my mobile device has an IPv4 IP sitting behind the mobile provider's CG-NAT. My mobile device also gets IPv6.
Since you only provide your site over IPv4, that means my opinion of your site is governed in part by my ISP's CG-NAT, which you do not control. If the CG-NAT is overloaded, or otherwise having issues, that will manifest to me as problems with your site. I will assume the problem is with your site, and take my business elsewhere. In this example, if your site was also provided over IPv6, then my phone would have skipped the IPv4-only CG-NAT, and things would be fine.
Perhaps you will diagnose the issue as caused both by the combination of your ISP flaws and my choice to be IPv4, however, the vast majority of users definitely won't, they will notice that most of the web (i.e. IPv4 web) sucks for them but doesn't suck for other ISPs and will put on the pressure on your ISP to get their stuff working to properly support the IPv4 net (or take their business to another ISP) instead of putting the pressure on IPv4 sites to switch to IPv6 or taking their business to another site.
IPv4-only still has enough critical mass (and will have for quite a few years still) to ensure that 100% of ISPs in the world have to support decent service for IPv4 only servers; IPv6-only does not yet have enough critical mass to ensure that all or even half of servers have to support decent service for IPv6-only clients - this is a quite literal chicken-and-egg problem for the motivation to switch.
Regardless, Google's chart of IPv6 adoption (https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...) continues to trend towards IPv6 adoption. I expect that if you looked at a chart of web site IPv6 adoption, it would also be trending upwards (though not at as steep a rate).
If that's true, then it stops being a chicken-and-egg problem, and turns in to a game of chicken: Who starts supporting IPv6 first, you or your competitors?
https://www.google.com/intl/en/ipv6/statistics.html
No, unless you're running servers for users who might have those issues on their side (e.g. anyone accessing your servers from mobile). May as well wait until you can save money by giving up your IPv4 addresses.
And if you're already moving away from perimeter defense, to more identity based zero-trust, the move to IPv6 makes much sense.
But upgrading a working network is lots of trouble. Most existing businesses have plenty of public IPv4 addresses and don't have to conserve.
The best idea I can come up with (at least right now) is: put all less trustworthy (read: Closed source) devices into a special legacy IPv4 network and only use IPv6 on my workstation and little Raspis?
Makes total sense, thinking about it. I guess, all those years of just sitting behind a NAT makes one forget all these networking basics if you're not using them regularly.
Moving closed-source IoT devices into a special vlan, with some even more rigid rules (something like: only allow http/https traffic into the internal network) might be an additional level of security.
Thank all of you for your replies!
Stateful firewall that allows outgoing connections and blocks incoming (or maybe blocks both)
In general, you probably don't want to allow unsolicited incoming connections to any devices, regardless of IoT.
Or differently put, you don't need to use the net your isp provides everywhere, ipv6 can still use NAT if you want it to: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6
Firewalls. You configure what traffic should be allowed from who to who. Default deny incoming traffic, and its the same behavior as when you had a NAT.
Something having a routable IP address doesn't mean it needs to receive all traffic addressed to it.
ISPs should be forced to let customers get IPv6 prefix reservations. Yes, PD doesn't change for most, but I'd rather not use PD at all.
Examples: https://docs.opnsense.org/manual/how-tos/transparent_bridge.... https://docs.netgate.com/pfsense/en/latest/bridges/index.htm... https://www.fortinet.com/resources/cyberglossary/transparent...
I'm not very familiar with DS-Lite. My ISP also uses CG-NAT but I get my connection details over DHCP - both native v6 with /56 PD and the v4 CG-NAT 100.x.x.x IP. That means I connect my OpenWRT router directly to the ISP's plug in the flat.
You said v6 is native for you, but if you put the modem in bridge mode you lose v6 connectivity. Why is that so? Shouldn't you lose v4 instead, which relies on tunneling?
The same exact way you do it right now.
Think of NAT as an implicit default-deny firewall rule, that's all it's doing.
Basically any firewall worth using will do exactly the same thing in IPv6, deny unsolicited inbound traffic unless explicitly allowed.
For some reason there's this belief out there that a device having a globally routable IP address inherently means it's globally reachable, and that's just not true. Your firewall still works exactly the same way.
If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.
Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.
First The firewalls are stateful. Client inside your network attempts to connect to some system outside. The firewall adds an entry to the state table with client ip, destination ip, protocol, ports, and so on. If an incoming packet is received by the firewall, the state table is checked. If there is an matching entry for the ips, proto, ports, etc, then the packet is forwarded. If there is no match the packet is dropped or rejected depending on your config. So it is easy to permit packets based on the interface it was received or transmitted on.
Ports can be opened for some incoming traffic pretty much the same with as IPv4 using STUN, TURN, and so on.
Past that, you can do manual port forwards the same way you do with IPv4.
Then if you're using STUN and TURN (which you'll have to, because non technical users do not find configuring firewalls easy) then what is the advantage of IPv6 to a consumer? There is no real p2p benefits.
I'm trying to call out this contradiction:
1) You need a firewall on IPv6 instead of relying on NAT, otherwise everything is routable globally and insecure 2) There will be this glorious new p2p world for consumers with ipv6
If you need a firewall, then really for non technical users you cannot have this p2p world. It is too complicated.
The reason Xboxes need port forwarding in the first place is that IPv4 relies on NAT. The unreliability and unpredictability of NAT means remote devices won't know what ports to talk to or if those ports will even be mapped to the right device. IPv6 removes that problem all together! It alleviates the need for 99% of the port forwarding cases that UPNP provides, assuming you've manually enabled it in the first place.
If port forwards are really necessary for Xboxes to work, then IPv6 brings another advantage: you can run multiple Xboxes behind the same IPv4 address. That IPv4 address can be your home connection, or it can be a thousand people behind CGNAT. In countries where CGNAT is the norm (India comes to mind) you can't possibly expect UPNP to be a requirement for Xbox to work!
But IPv6 doesn't solve the problem at all if all incoming connections are blocked on the firewall - which they have to be for security! You need some protocol for the xbox to be able to tell the firewall to open ports, which doesn't exist. Or users have to manually set the firewall rules, which is the same as port forwarding on NAT from a users perspective (ie impossibly complicated)
You can run multiple xboxes behind NAT right now, they get different ports.
Again, for a non technical user there is no major difference between being behind CGNAT IPv4 (impossible to get incoming connections), and firewalled IPv6 (possible to get incoming connections, but the firewall is too complicated to use so it may as well be impossible). If there was a protocol which would allow devices to open ports on IPv6 firewalls programmatically similar to UPNP it would be entirely different, but there isn't.
Most consumer routers I've seen these days come with UPNP disabled by default, though.
For most P2P traffic (which includes a third party handshake server) you can probably skip port forwarding entirely; just send UDP packets both ways and the firewall will figure it out. For stateful protocols like TCP and friends (SCTP etc.) that's harder to accomplish this, that's where you need pinholing.
It's possible that your router simply doesn't support IPv6 pinholing but I think the more likely scenario for breakages is that client software doesn't bother implementing it.
https://en.wikipedia.org/wiki/Port_Control_Protocol, which also allows for UPnP-like functionality when NAT64 is in play.
That said most "P2P" traffic is still mediated by a central server though and does not need this. The lack of port remapping from NAT means that tricks like UDP hole punching work simply and reliably rather than the semi-random performance seen through NAT. Multiplayer gaming, VoIP, voice/video chat, etc. where a central server does the setup doesn't need ports opened to the world, it just needs to punch a hole for that specific session. A SIP phone opening a port forward on 5060 for itself is a bad thing, but it's sometimes needed in the NAT world.
True unsolicited incoming traffic will still need an allow rule but that's a lot more rare.
> If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.
I disagree. These days the sorts of things normal people do that deal with P2P connections are pretty good at dealing with NAT, but far from perfect. You don't have to look far in to the gaming world to find people complaining about not being able to join a session, not being able to connect to voice, etc.
Any VoIP provider serving users on their own internet connections is going to be doing things like regular keepalives, setting their media systems to accept RTP from and send it back to whatever port it comes out of the user's NAT on instead of the one it's supposed to be on, etc.
All these things work pretty well, most of the time. But they're not perfectly reliable because every NAT implementation is different in subtle ways.
> Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.
As noted previously, in IPv6 it doesn't need to open the port at all. Anything the Xbox, or any other modern game console, will be doing is server-mediated P2P for which standard basic UDP hole punching is a perfect fit.
Basically anything that definitely always requires a port forward in IPv4 NAT will probably still require an allow rule in the firewall, but anything where port forwards aren't supposed to be required but sometimes they help some people more reliably connect is a problem caused entirely by the NAT and those problems go away. Hosting a dedicated game server is in the former category, playing games is in the latter category.
There's a reason all the modern consoles include NAT tests in their network diagnostics, but can only offer vague suggestions at the fix, because how the NAT is breaking things varies by the NAT and may or may not be fixable. The only real fix is to eliminate the NAT.
FWIW Xbox prefers IPv6 when available and Xbox Support specifically recommends having it enabled if you can. That tells me that it works either equally well or better than IPv4 in the real world, which fits my view of things.
I spent a lot of time figuring out how to do all this in the most efficient way (in terms of my time and effort) during covid, and I suggest getting any arbitrary box with 2 ethernet ports and putting freebsd on it.
Often I need to access a device from my local network (think: use my phone to control Wi-Fi LED Strips, Sonos speakers, etc.), which makes it impossible (I guess?) to separate these devices into their own network completely (if they aren't controlled by an online service in general). Or is it possible to allow access from my trusted network INTO the restricted network, but not the other way around?
Total network noob here, in case you haven't figured that out yet. :)
Yes
You could, for example, allow only TCP traffic initiated by hosts in the “normal” VLAN to hosts the IoT VLAN. So IoT stuff can’t initiate outgoing connections to any other network, and can only receive TCP connections from one network.
You can also set up an MDNS reflector on your router if your IoT devices use that (e.g. HomeKit) to send data proactively back to “normal network” hosts.
Yes, my home network works exactly like this. I have a vlan called "trusted" which can connect to any other vlan. One line in pf.conf.
My VLANs are something like: trusted, guest, media, cameras, printer, etc.
Many of these aren't allowed inbound or outbound connections (e.g. cameras and printer can only talk to things on their subnet).
Only downside is that stuff that works off broadcast packets (like bonjour) does not work across subnets.
Another option is to use IPv6 Unique Local Addresses (ULA), which are similar to private IPv4 addresses and can only be used within a specific site. This approach enables internal connectivity for devices that do not require direct access to the Internet. I use it for several IoT devices that I do not want reaching out to the mothership.
What I did was:
- IPv6 DHPC - private address range within: fc00::/7
- IPv6 NAT, same as for IPv4.
- Firewall.
Why:
- digital ocean only allowed ~16 IPv6 addresses.
- I wanted a local IPv6 network exiting through digital ocean.
- I see no reason to give public route-able addresses to each device in my home (allows remote websites to determine who is calling it and set up profiles/target each remote device).
- Sure, privacy extensions which cycle unique addresses, but it still allows profiling based on source address, even if a bit of work is needed for each new addresses.
It does not, problem is with outbound connections.
> Whats the difference between "ipv6 Nat" and a firewall when theres not likely to be any address overlap.
Outbound connections can be profiled by remote websites.
With NAT (Well... Port-address-translation to be fair, so single outgoing address), traffic can't as easily be profiled.
Imagine ISPs/Ad providers having easier time identifying you, your spouse, your kids, etc. (and device, and so on just by observing addresses)
With initial SLAAC it is even nicer as MAC address is included in the address... Can look up device much easier just cross reference manufacturer database...
I think ideally we should also think of new interoperable defenses that fill the NAT gap. Perhaps each device should have an authentication key apart from its IP, which it could pass onto trusted devices like local network routers, which would only allow authenticated incoming data. Maybe even better would be a global scheme including this authentication and also more private addressed (than IP), although that would probably require a redesign of IP and might be a project for the far future.
And thanks to Duplicate Address Detection, before a new randomly-generated IP is used, a check is made to ensure it is not in use by someone else.
SLAAC reserves bottom 64 bits for autoconfiguration, and while incredibly wasteful it does ensure every MAC can have its own IP address
Personally, I don’t feel the need for privacy at this level of the protocol stack, and if I did, I would not consider IPv6 Privacy Extensions to be adequate. Also, I might like to keep TCP connections alive for more than a day. Therefore, I personally prefer regular MAC-based SLAAC, or even hard-coded addresses, over randomized and rotating addresses.
In other words, no.
Add that to the list of thousand cuts.
HOWEVER,
My ISP regularly messes up with its ipv6 routing (deutsche Telekom (so as big as it can get for me) and if that's not the problem, the mesh networks on my (current gen) fritz networking equipment (very widely used in de) eats itself and sometimes just routes my traffic to nirvana.
This is especially bad with online gaming services like xbox live, who for the love of themselves don't have a fallback to ipv4 implemented, once ipv6 drops. "i have an ipv6 so I'm gonna use it no matter what".
Therefore I have dual stack vpns hooked up to my office network which connect to the datacenters I am using. My private network is ipv4 and sadly will remain like that for a while.
I think unless we start seeing ipv6-only stuff this will be the case, there's really no incentive for a lot of testing/debugging on at least consumer ipv6 connections until stuff actually breaks.
Would be cool if Google added a 'ipv4' warning to Chrome similar to how they do with HTTPS (maybe not as strong though). That would drive a lot of adoption.
You can kinda already do this by setting search to ipv6.google.com
Images search does not work on that domain, looks like the new Google devs don't know about it.
Can you expand on this? I recently upgraded my network to support ipv6 but a big concern I have is what if they (Verizon Fios) change my assigned block? How can I make sure my PI hole and server has the same static IP address?
I also got fed up with people discriminating against Hurricane Electric's tunnel broker (streaming services, etc) so now I just have my own tunnel broker. It's really great to have my own addresses, use them in my kubernetes clusters (via calico and cilium) and have my homelab directly advertised to the internet, knowing I will never need to re-number.
Networking is a helluva drug
- What was involved with picking up the ASN and the IPv6 block of addresses (process, bureaucracy, initial and ongoing costs)?
- What networking plumbing is involved in being able to have homelab resources advertised to the internet?
I'm not an expert in this area, but I'd very much welcome the hard work that comes with reproducing such a setup. Thanks.
This articles section "here are some reasons you should start using IPv6 within your own network" seems to comfirm this. None of the 6 "reasons" speak to me.
My ISP router could do max 800 mbps, which isn't so bad, but it degraded when we were multiple people using the link. With IPv6 it's much less of a problem, we can easily saturate the 1gbps without the router having a meltdown.
fast.com says 50 "Mbps". Whatever that is.
I remember reading about this as well. Wouldn't that also apply to stateful firewalling, though? Or is NAT inherently more computationally difficult (e.g. due to having to recompute IP and/or TCP/UDP checksums) than checking a state table?
Yeah, not anywhere close. In ten years I’ll have one maybe.
Rare in the US. Hell, we don't even have a 1Gb connection at work.
[citation needed]
>That's why gamers push for IPv6.
[citation needed]
I don't know of a single game that supports IPv6, although some consoles might?
Maybe it's a ricer thing, but I definitely see a difference and I compared my ISP's router (which didn't display CPU load), an openwrt router without hw flow offloading support (horrible), and an UDM SE.
(I don't have an Xbox, I just see posts on my local ISP's forum)
We are on AT&T Fiber, the router has no issues. I've never seen a router have issues with any speed for that matter, where NAT is concerned.
> That's why gamers push for IPv6.
I'm a gamer, I know a lot of gamers, no one is pushing for IPv6 that I'm aware of.
https://atoonk.medium.com/linux-kernel-and-measuring-network...
Just speculating, but I believe the cost comes from all the memory operations of reading/editing/writing every packet, not from the NAT table lookup.
Of course, this is not a good reason to not use IPv6, don't get me wrong. It's a problem that's easy to overcome, I just think it's not a good way to get people excited about the transition.
With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not.
If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
Now, sometimes NAT is needed anyway: QubesOS supports IPv6 using NAT because it splits things up into many different VMs on one computer. But that's a pretty rare case.
It's security through obscurity at best, i.e: not security. You shouldn't be relying on size of address space to protect you from anything. An IDS/IPS that alerts on abnormal ICMP behavior will be useful whether an attack is 1GiB of traffic in size or 1024EiB of traffic in size. (Also you don't even need automated scanning to find some juicy targets: I've seen a lot of routers on the edge of a prefix configured at ::1/64 and ::2/64 for instance.)
I did not have to do anything to get this. My macOS system has IPv6 set to Automatic. My home ASUS router picks up the /64 allocation from my ISP, passes the info on to things on the LAN, and acts as a firewall for IPv6 (while continuing to act as a NAT for IPv4).
According to https://www.internetsociety.org/resources/deploy360/2014/pri..., this has been common for some time.
Ports on router are allocated by it and not client machines. So far my experience has been they're usually sequential without any preferrence.
(Hand waving a bit here with terminology don't shoot me)
Local firewalls on devices, maybe, but network firewalls generally are default-deny on untrusted interfaces, and between 0 and 1 interfaces are trusted by default.
Back in 2007 Apple's Airport Extreme Base Station shipped with a firmware that defaulted to allowing all IPv6 traffic, which was quickly pointed out in the tech media and fixed in a patch a few months later. A few of the garbage pile combo modem/router devices distributed by ISPs have had similar issues over the years as well. That's not normal behavior though, when it's observed it's rightfully considered a security flaw and tends to get the kind of attention vendors don't want.
If you know of a mainstream device that would "fail reachable" as you claim here, name and shame please.
> without explicit port forwarding or exposed hosts, NATs fail unreachable.
I work in VoIP and can say from plenty of direct experience this is not true. In the modern work from home era I've had to deal with a lot of the aforementioned garbage pile consumer devices and a recurring issue with some of our clients who had older phones is that their users' home routers did the laziest NAT possible and literally just opened a two way hole on port 5060 (SIP) so as long as the phone was communicating with our server and keeping the pinhole open *ANY* other traffic that hit port 5060 was also sent to the phone, which meant they got all kinds of "phantom calls" from bots looking for unprotected SIP relays.
Newer phones generally have an option to only accept SIP messages from trusted servers, but older ones sometimes don't so when combined with badly implemented NAT that happens.
And yea, obviously that's a consequence of a particularly bad NAT implementation, but your complaint is about an issue that would only occur in a particularly bad IPv6 implementation.
Bad IPv6 is as simple as not having a firewall or default-allowing it like AirPort did. If Apple can make that mistake, a lot of random manufacturers can too. I can see the whole NATless firewall setup but wouldn't use it for a very long time, to let things settle.
Of course, if the protocol added workaround for NAT and NAT is modifying that application layer data then it can cause another set of issues.
It gets even worse with higher level protocols like FTP. There is such a thing as FTPS (FTP over SSL) but it's rarely used because if you encrypt the traffic then the NAT gateway can't inspect and rewrite the traffic.
The same is true of IPSEC/ESP, if you have an encrypted TCP packet encapsulated with ESP the NAT gateway can't keep track of which internal host to forward it to because it can't see the source and destination ports.
A normal router does not need to care about anything further up the stack than IP. A firewall does, but even when a firewall doesn't explicitly support a particular protocol you could write a rule allowing any traffic with a particular protocol number between specific hosts is allowed, and anything else denied.
I get that an ipv6 router can have a firewall with good defaults blocking incoming connections, emulating that aspect of a NAT.
The type of NAT we're talking about here *only* applies to outbound connections. It doesn't do anything at all to inbound connections.
Then... don't route anything on your network.
NAT is address translation, not routing.
NAT makes it difficult for you to host services on your network, forcing dependency on cloud services, and when ISPs do it (CGNAT), it makes it just about impossible unless you want to thread your traffic back through a third-party service. If you want a good chance of keeping some semblance of an Internet around that isn't dominated by huge centralized services, the cargo cult of "NAT is security" needs to die hard.
Imagine if I'm a medium-sized ISP, or a medium-sized software company, or a medium-sized website.
There's a bunch of hassle involved in deploying IPv6. Who knows what it'll do to my users' privacy? Or whether everyone's firewall rules will keep working right? Or whether it'll have some random impact on e-mail deliverability? Or something else?
The main benefit of IPv6 is providing routable addresses for home users, thus avoiding CGNAT.
But zealous firewalling and the rise of mobile devices mean these days almost everything is sent over HTTPS to a cloud server. I haven't had software ask me to open a port on my router in a decade or more. Even games and video conferencing software know they have to work out-of-the-box on networks where the user can't adjust the NAT.
So who's going to benefit from all this hassle - the 0.1% of users who are hosting websites from home?
IPv6 will fix that.
The reason IPv6 on a home network is still difficult is because the routers everyone buys at Best Buy still blow at supporting IPv6. Ubiquiti blows at supporting IPv6. It is laziness and/or incompetence of device manufacturers, primarily, holding us back. (and incompetence around IPv6 in general - I talked to a network guy at a large company recently and they were deploying /58s. WHY?!)
The benefits of IPv6 may not be just for you - it's for the planet, it's for the developing nations, it's for the future where IPv4 does not cut it. It's bigger than your home network.
> IPv6 does not do anything to save the planet.
The world doesn't have enough IPV4 addresses. It literally solves the problem. It is crazy to me so many people here are arguing for multileveled NAT instead of the obvious solution we have had for 20 years.
If 8 billion people wanted to host their own email and web, yes, we'd not have enough addresses for each person to have one. That isn't the case though. It will never be the case. If we look into the future and say well in 2023 5% of the world's population ran their own email and web for personal or business purposes and that number were to grow by 5% every year then in 20 years we would run out. That's a worse case, contrived scenario but even in that case, we'd still have 20 years to come up with something better than IPv6 that truly respects privacy and doesn't track each person.
Try starting a new ISP. You’ll either do CGNAT on a single /24 of v4 space, or you’ll have to spend tens of millions for some pointless, legacy IP addresses.
CGNAT is not the Internet working well. CGNAT makes you have to have your ISPs permission and coordination to originate outgoing traffic--imagine if you had to ask the power company for permission to operate each electrical device in your house.
Look at what they did with broadcast digital TV : it was announced that it would be illegal in a couple of years to sell hardware not compatible with the new standard, then a couple of years later on illegal to sell hardware compatible with the old standard...
The US has mandated IPv6 support for federal contracts since 2009, although they don't get involved outside of those directly providing services to the government itself. They now have plans to go IPv6-only, and eliminate the use of legacy IP within the federal government.
Allocation of legacy address space was always based on first come first served, so developed countries got the lions share of address space and left developing countries with scraps. This creates a severe inequality, and holds developing countries back. This is also why India and China are leading, as they have a huge disparity between their population and the number of legacy addresses available.
(Though the sooner we ban IPv4, the sooner they will stop using it too...)
Early hardware implementations could have settled on 32-bit, but 48-bit would make more sense to be in line with EUI-48/MAC-48 (ethernet frame). The world could then gradually upgrade hardware over the decade to handle a larger address.
[1] https://www.rfc-editor.org/ien/ien28.pdf
It's because you could get through the firewall without a four month review with the firewall team.
Well, and you could reuse web tools and software. Ok, that's probably it, but the firewall convenience is DEFINITELY a thing.
It costs that third party real money to run that server...
What happens when they decide to shut if off because they no longer want to bear the costs? Your applications are a ticking timebomb...
What about privacy? What if the operator of that server decides to fund it through selling your data?
Sending your traffic through a third party server adds latency, sometimes a LOT of latency if that server is far away. This is very bad for certain latency sensitive things (gaming, calls etc).
If you're dependent on a third party server then you're screwed if it goes down, even if your own connection is fine.
Doing away with that and going back to peer to peer is MUCH better in most cases.
IPv6 has private addressing and a form of NAT as well, were it to be the will of router mfg'ers and network admins. No need to stay on a legacy protocol.
Also STUN makes your private addresses reachable without you making any mistake at all.
Your comment is a good example of the NAT cargo cult mentality that is damaging to the Internet.
The reality is that NAT has greatly improved the security of the internet, because before NAT people were exposing everything, including services like Windows file sharing, to the internet. NAT enabled those people to use multiple devices in their home and in return prevented them from unwittingly hosting things to the internet, which causes them to be hacked and turned into bots that harass the rest of the internet. Yes that still happens but not at the scale it happened before everyone was behind a NAT perimeter. If you want to see what could happen look up the SQL Slammer worm and imagine what could have happened if such a worm would have targeted a service more common than SQL Server.
It’s really nice to be able to host things on a consumer connection but it requires thought and management that most consumers just can’t and won’t care to provide and the damage they can cause is not only to themselves but to the rest of the internet as well. This capability really is better off by default.
And all those handwavy ‘workarounds’ for the ‘cargo cult mentality’, you typically can’t tell everyone on your network how to manage their computer to ‘just have their services listen on the local address’ and you can’t ‘just change the defaults of all routers’. But NAT makes it impossible for the default to be wrong and that is its great advantage.
Sure NAT has a lot of disadvantages and breaks the original idea of the internet with every host equally able to host services. But just as Postel’s law just doesn’t work out, every host being able to host services doesn’t work out. Because the internet is not a playground full of friendly colleagues and hasn’t been for a long time. It’s a war zone that requires strong, watertight defenses by default. And if you’re smart and careful enough to safely host a service to the internet, surely you can manage to forward a port.
NAT created a false sense of security, while also breaking a lot of other things. It is quite easy for the defaults to be wrong, you can end up with all kinds of unexpected scenarios which make internal hosts reachable - eg outbound traffic could open up inbound traffic on the same port from any source not just the one initially communicated with, UPNP can result in ports being opened, NAT slipstream attacks are another possibility, not to mention the fact that "not routable" and "there is no route" are two different things - someone who is on an adjacent network to your wan interface (ie other customers of the same isp) can easily direct traffic to your internal address space.
What reduced external attacks was not NAT, it was improved defaults - such as windows including a software firewall which blocks inbound connections by default, and unix based systems no longer shipping with large number of services (telnet, rpc, finger etc) enabled by default.
Consumer routers with IPv6 support don't allow unsolicited inbound traffic by default. Good luck scanning an IPv6 block in any case.
Slammer and other worms scanned sequential legacy IP addresses, including the well known and predictable RFC1918 space. This method simply couldn't work with IPv6 because the address space is too large, you would be flooding out huge amounts of traffic for years on end before you happened to hit upon an active device.
IPv6 is better, not worse.
NAT is bad because somehow magically a machine with an unroutable address can become routable. Because magically UPnP forwards every protocol in existence, not only a select group of programs that explicitly support it. And of course a connection opening up a theoretical hole to a specified host is just as bad (actually worse!) as opening it up to the whole internet.
Yet all routers have the right defaults and nobody ever makes a mistake. Oh and there’s so many addresses it’s so obscure it’s secure, and noone would guess to scan one’s own subnet in the absence of NAT.
These arguments are really grasping for straws, mostly nonsensical and the rest describes attacks so impractical they are pretty much impossible to carry out and are so much harder than simply sending a thousand emails with a link to an executable that pretty much nobody ever bothers.
Note I never said that IPv6 is worse, I said that NAT has relevant advantages and mostly irrelevant disadvantages. I really don’t care ftp doesn’t work with NAT.
You simply do not host services you do want public on your global unicast address but use a private/site local address instead.
What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?
Behind a NAT, observers can only make that connection (using only addresses) for the network as a whole, instead of an individual device on the network. So the privacy extensions are weaker than NAT
(If the IPv6 privacy extensions used a different address for each connection, they would be more like NAT in this regard.)
That said, other observable clues still allow connections from a single device to be associated, NAT or not. There's TCP OS fingerprinting for example, and the close timing of related connections.
In this scenario it's a lot more work trying to map out your infrastructure than to try performing a MITM connection against some of your outbound traffic.
With any usable N, a clever observer would still easily work out what you were doing and still map out your infrastructure.
More reasonable is to use new address for each connection. Then nobody can tell if 10 addresses and 10 connections are one device or ten.
You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME.
What are valid values in the scenario you are proposing? The defaults are 1 week / 1 day, so 7X. If you chose to rotate each second, and say allowed addresses to only be valid for say 20 minutes, this still appears to be a ~1200X blowup in routing overheads.
They have not?
The global routing table size for ipv6 at max is a /32 (if i remember correctly) every customer gets a /56 prefix to use in their network, so the routing table entry would still be the same, no matter how many addresses you use to cycle through in your /64.
ARP caches do not exist in IPv6, and Neighbour discovery does not have the same "cache" mechanism as ARP does, it uses an entirely different mechanism for neighbour discovery. (which is also far more lightweight considering it is using multicast, compared to the broadcast of ARP).
There is a whole industry built around network traffic analysis.
What makes you think it doesn't happen on the internet?
The ISPs have the ability to see what is on your network by IPv4 egress. They have been able to do this for a decade.
Worrying that an IPv6 address divulges the network forgets that IPv4 devices betray their existence through DNS, their destinations and other network behavior.
The ISPs know.
2. You can't say anything about the percentage with just the absolute market value. At the very least you need something else to compare it too.
Please, be serious.
So, I mean, I dunno, 2 billion dollars seems serious to me, but maybe we just have different barometers for what counts as "serious amounts of money". Especially considering these devices that are like $300.
Finally, might I remind you of the guidelines? in particular:
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
https://news.ycombinator.com/newsguidelines.html
Many of these routers are managed by the ISP using protocols such as TR-069, several ISPs have already been found to not only manage the devices but also monitor certain data including what devices are present.
They are, but in practice they are muddled together and I suspect people are going to create subnets with IPv6 in the name of security. In IPv4 NAT is used to make sure your laptop isn't exposed to random script kiddies trying to scan for vulnerable services behind your router. A fun exercise is to plug a RaspberryPi up directly to a public facing IP address and log every packet it receives. Then give those scripts a few services to detect (HTTP server, SSH server, etc.) and look at how the traffic shifts from scanning for ports to scanning for vulnerabilities. Being connected directly to the public internet is a real eye opening experience.
I do believe future IPv6 networks will have gateway machines and/or bastions that are connected to the public internet with public IPv6 addresses. And then they'll have an interior network that they use NAT for. Individual machines will not be routable or discoverable without going through a bastion/gateway that explicitly controls the flow of traffic into a network. Not because this is the ideal way to structure an IPv6 network, but because this pattern is going to carry over from the IPv4 world and there is a lot of momentum in tribal knowledge using NAT as a form of firewall.
NAT does nothing for that. Those incoming connections are dropped on the WAN interface before NAT would even be involved. Which is why it works exactly the same way regardless of whether the destination IP for that traffic was IPv4 or IPv6.
That isn't really feasible with IPV6 though is it? The smallest IPV6 subnet is 18,446,744,073,709,551,616 addresses, so even if you setup a Pi fully open to the world with default passwords the chance of someone scanning it is basically zero. That type of scanning only works because the IPV4 range is so small (& you can efficiently ignore large parts of it like the US DOD space, private addresses, etc).
[0]: https://isc.sans.edu/diary/Targeted+IPv6+Scans+Using+pool.nt...
Right now, my macOS system has four publicly-routable IPv6 IPs, all random. New ones are generated, and old ones removed, regularly.
https://www.internetsociety.org/resources/deploy360/2014/pri...
Yes, and that's a very reasonable configuration.
But UDP hole punching (very widely used for VoIP, online gaming etc.) works orders of magnitude better with IPv6 than with IPv4, since there is no address and port translation to worry about.
With IPv4, it's very hit or miss, since it depends on both sides' NATs and also requires additional infrastructure (i.e. STUN discovery servers).
It's also probably impossible if you're with an ISP that does CG NAT.
What is the risk you're picturing here? I'm really curious. Features like RFC4941/8981 mean nobody can infer anything about your network from the source addresses they see making requests out if it.
If you want to use link-local V6 addresses and NAT to a global one, you can do that. But IMHO that's sacrificing one of the greatest advantages of IPv6 for no tangible benefit.
> It's a complete non-issue that nobody really cares about.
A significant number of people spend a significant amount of time trying to carve out and re-use address space in their existing IPv4 allocations and RFC1918 space. This becomes nightmarish the moment you start thinking about networks of any significant size and complexity. All of these problems go away with IPv6, and we care about that a lot.
Huh. IMHO it's the single most desirable feature, and the only reason I care about it at all.
If you're approaching this from the home networking point of view, than I suppose I agree: even the most complex home network is just too simple for anything like this to matter much.
As the network gets bigger, that sweet sweet global routability starts to make a lot of things a lot simpler... I'm lucky to have worked on an enormous deployment of V6-only servers, and it's downright magical in comparison to anything of comparable scale I've seen before or since.
But yes, my home network is three NAT'd /24's because I'm too lazy to figure out how to make prefix delegation work...
SLAAC scales really, really well, and is fairly stateless compared to DHCPv4 or V6.
Also, slaac allows one to easily change the global prefix of a vm/host if it lives on another layer 3 network.
A good example of this:
you have two seperate datacenter networks based on an EVPN-VXLAN solution, and you do no want to stretch layer 2 across both datacenters because stretching layer 2 is a terrible, terrible idea[0].
Before IPv6, moving VM;s across datacenters which have different public ip space was a major pain for two reasons:
- IPV4 has no concept of using multiple addresses per interface without it having unexpected bahaviour on a host. - address management at scale is a major PITA because DHCP is not scalable.
How to solve this with IPv6? It's fairly easy:
- Use slaac + prefix delegation of your globally unique address space (which is different per Datacenter). - Use a different (site local) address to reach the VM for management purposes. Because this address is not globally routable, you are sure it will never leak into the greater internet and be reachable from the outside world. - If you are using anycast, you can easily announce this prefix to upstream BGP neighbours because you can use BGP Neighbour Autodiscovery[1].
Trying to do this with Ipv4 will result in a mess of administration, not to mention have to do some clever technical hacks to make it work on some operating systems.
With IPv6 solving these issues becomes quite manageable.
[0] https://blog.ipspace.net/2021/06/stretched-vlan-define-probl... [1] https://www.juniper.net/documentation/us/en/software/junos/b...
Fair enough. For me, this is a thing I literally could not care less about.
The availability of IPv4 addresses is something that more people will care about, and getting IPv6 going may help folks. From another comment in this sub-thread:
> I've actually run into this [CG NAT] helping a friend host a game server on their residential internet in a more rural part of Texas. They had to call their ISP and request a static IP address at an extra cost of something like $5/mo.
* https://news.ycombinator.com/item?id=35046929
They can infer that one IPV6 address matches to exactly one device. (reverse is not true, one device may have multiple addresses per privacy extensions)
Once device is identified all its past traffic is discernible.
Changing addresses means identification needs to be done again but once done it can be associated with past addresses and again, all its history is visible.
Identification might just mean querying a data broker with HTTP headers.
NAT does not have this issue.
No they can't: the whole point of RFC4941/8981 is to prevent that. The source address for external connections is effectively randomized.
All that can be inferred is that it came from your network, but even with NAT you know that anyway.
It's still unique to one device right?, even if random my argument still holds.
Or do you mean to say multiple devices can use the same address?
note: I've read the RFCs and they just mean - initial address is random but unique to a device. Each day the address will likely change but new address is still unique to the device (otherwise how would routing work).
This is what I structured my inital argument on. Do you see any fallacy in logic?
Once identity is known for address X you know its traffic for the day, including past traffic for the day.
once address changes you do the whole identification again.
All these logs where address is identified goes to bucket X.
On addresses where you couldnt identify that day you put them in unknown bucket.
Once you have a profile of the network, you can do exclusion (Only 4 people in household, 3 active with known addresses, not X, one unknown address, you can assume its X)
The “I don’t care if they track my household but it’s critical that Daddy’s activity not get disambiguated from my dealing daughter” is just not a valid reason to abandon the benefits of IPv6.
Please stop with this line of argument.
If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT.
That's a broad assumption, and I can assure you they will due to lower costs (no need to pay data broker if you already know target, no need for extra traffic, load, etc). Also due to better targetting you get better prices per ads served.
> just not a valid reason to abandon the benefits of IPv6
What are the benefits to allow each device its own address if I'm going to firewall them anyway?
> Please stop with this line of argument.
Why?, my concern is valid, all you've said so far is nobody cares. I disagree.
> If you’re really desperate to ensure that the ads shown to your daughter are based on your porn viewing habits, then just set up IPv6 NAT
That says a lot about yourself if you resort to this sort of snarky comments, I have no wish to continue this conversation.
Note: I said in another comment I have set up IPv6 NAT and it works great.
If I told my security information officer "We don't protect against foreseeable threat X because we assume no one will bother to try X" she would not be very happy with me.
When a valid data concern has been expressed and described, putting your head in the sand is the incorrect response. I want IPv4 to die as much as the next person but at a minimum organizations such as hospitals and government installations will not accept that sort of outside visibility into their network.
I don’t quite feel convinced yet by this argument.
For example, one essential difference is that while it’s true that my web browser does have those leaks, I can be reasonably sure that it’s only leaking to specific hosts, i.e. the one I’m visiting and its embedded resources.
Tracking on the IP source address level, however, would be a whole other thing: that means that whoever happens to see the byte stream can now track who is visiting what. That includes, for example, my ISP, all large Internet exchanges, and anyone tapping into those.
If you set up your device to spin up a new IPv6 address every hour (or even every minute), how will they track you using IPs?
On macOS it's 24h, but it doesn't have to be:
Minutes or less I guess would defeat tracking, but then what's the point?, it's almost equivalent to NAT it still breaks reverse connectivity? and does it actually work?
It also feels like a workaround for an oversight.
But how would they know it is to the same node?
I have my DSL router-modem reboot every night, and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
Similarly with the reboot I get a new /64 prefix delegation (actually /56), so I would hazard to guess if IPv6 starts getting tracked, I'd get the same crazy results.
No one cares about tracking by port. Folks are tracking by IP(v4) address.
I know this first hand because I have my DSL router-modem auto-reboot every night (built-in Asus functionality), and I get all sorts of crazy results for ads: I'm in southern Ontario, as is my ISP, but they service folks in Quebec, and so sometimes I get Youtube ads in French since (per my IP) I'm "in" Quebec.
And given that I have IPv6, most OSes generally use that as a first preference for connectivity, and so my IPv6 address/prefix is "in" Quebec.
And this is even with cookies enabled, which should make tracking by browsing easier (esp. since I get decently-accurate recommendations based on viewing history), but yet I still get French ads because my IPv4/IPv6 address is "in" Quebec.
So I have no idea what people are talking about when they say IPv6 will make tracking easier than IPv4. With RFC 4941 it's a solved problem IMHO and no worse under dual-stack than it is under single-stack.
With IPv6 chances are your ISP has a single large address block, and then they split out parts of that address space to users in ontario and quebec. Unless the ISP publishes details of where they've allocated those blocks, any external site is just guessing.
With legacy IP chances are they have multiple small fragmented blocks, some of which are routed to ontario and some of which are routed to quebec so they're a bit easier to keep track of unless the ISP decides to move them.
Also when you address changes, the legacy address space is probably quite close to full so your previous address is released and probably taken by another customer fairly quickly. The IPv6 space will be much larger, and so recycling occurs far more slowly.
Either way youtube is just guessing, it only knows that the address space belongs to a canadian isp and it has to use the behaviour of whoever used those addresses last. If the previous user set their browser language to french and searched for french sites, youtube will remember that and is more likely to serve you french ads.
Yes there is. I sure as fuck don't want random people from the Internet to know how many devices and what kind populate my home LAN.
Security through obsecurity is not security.
Yes, let's just flash a giant "welcome, nobody is home right now" sign to burglars whenever you leave the house unlocked.
You're going to have a minimum of a /64, noone is going to scan that looking for devices.
Even if they do, your firewall is not going to allow the traffic unless you've explicitly configured it to do so.
The only way someone will discover devices, is by analysing outbound traffic you make. Outbound IPv6 traffic will come from randomised addresses so the addressing information is useless. Other things disclosed by the devices (eg user-agent headers on web browsers and other fingerprintable data) are protocol agnostic.
That should be enough for all your devices to randomly rotate IPs for a lifetime or a few without any NAT.
Shitty ISPs do exist, or at least they existed two years ago.
Globally routable ≠ globally connectible.
Your (stateful) firewall will still by default block any incoming connection attempts if they are not replies to an initial outgoing connection. It's just that it will no longer be necessary to go through the rigamarole of STUN, TURN, ICE, etc, that goes along with non-global addresses:
* https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
Your end-user device knows its address and the address of the other connection point, and can tell the firewall to open a rule between only those two IPs:
* https://en.wikipedia.org/wiki/Port_Control_Protocol
* http://www.upnp.org/resources/documents/AnnexA-IPv6_000.pdf
Further, because you don't have only one external IP, you don't have to futz around with non-default ports if you want multiple instances of the same service (e.g., Minecraft), because each instance can have its own IP.
Further, if you want certain devices to not able to get outside: (a) give them static assignments and block them at the firewall, (b) don't give them a default route so they are subnet-local, or (c) give them site-local addresses via ULA and do not set up NTPv6 translation.
It's been available for some time: https://www.internetsociety.org/resources/deploy360/2014/pri...
On my macOS system, I currently have four IPv6 IPs (excluding the link-local IP), all of which are random.
For decades we have generally allowed all outbound and worried and fretted about and filtered inbound. I think it is time for us all to get a grip and do the job properly. However, with the delights of DNS over http and the like, the horse has not only bolted but has a new paint job, far better shoes than you can afford, eats grass that was prepared by a Michelin starred chef and belongs to someone else now.
We all need to be far more sophisticated about how traffic (knowledge/ideas/data) flows in and out of our networks/lives. Packet filtering is just one tool in the box and worrying about an addressing scheme being global (IPv6) instead of a weird hybrid (IPv4) is completely missing the real issue stabbing you in the nadgers.
They’re obviously doing recommendations based on IP address. (And this is purely over ipv4).
I have IPv6 at home and connect to Youtube over IPv6 (that's generally the default behaviour on macOS and many other OSes). I reboot my DSL modem-router every night and get a new IPv4 address and new IPv6 prefix every day.
Now: I live in Ontario, and my ISP is based in Ontario, but they serve clients in Quebec. Every so often, when surfing Youtube, I get served ads in French because according to my (IPv6) address I am "in" Quebec.
And, while I am not logged into any Google service, I do not block cookies. So even with cookies, Youtube seems to be fairly dumb about serving ads correctly just based on IP addresses (or at least IPv6 addresses and/or IPv6 prefixes), since cookies don't seem to be useful.
So I'm not quite sure about what people are talking about when they say "IPv6 tracking" if even Google/Youtube can't get their act together.
Iechyd Da!
eBay uses IPs showing content, too. I see 'items you've viewed recently' show items I've never looked at, since when on a mobile connection my IP changes fairly frequently and eBay carries over the recently viewed state from whoever else was previously using that IP.
It had puzzled me until I came across this[1] eBay topic where others had experienced this, from shared offices to spouses, etc.
[1] https://community.ebay.com/t5/Share-eBay-Technical-Issues/Re...
the only thing you'd "leak" is the prefix, which is no different than a IPv4 WAN address that you'd get with a v4 NAT.
Assuming you block unsolicited packets (that is, packets not related to existing connections/streams) at your border (the connection to your ISP), then outsiders won't be able to use tools like traceroute to learn anything. All that an outsider has is an IPv6 IP, and since you're not doing BGP with anything, all they'll know to do is to send the traffic to your ISP.
I'm curious to know: what (attack) do you hope to protect against?
I would think that most attacks come in two fashions: the first being that you run a service of some kind and that there's some JSP/PHP/whatever exploit for a public facing service, and someone does a 'magic' PUT/GET that has the application server execute some code, which downloads a larger malware attack package. After which point the black hats start scanning from the inside.
The second being that someone clicks on a link in a phishing e-mail or executes some attachment, after which malware code starts scanning from the inside and phones home.
(A third being an insider attack, who presumably know about internal topology.)
What attack are you thinking to protect against by hiding subnet and VLAN topology?
And what are those vector(s)?
Besides compromising a machine that is already inside per the above (which can then do scanning / lateral moves), or perhaps physically getting inside the premises (in which case a scanner can be physically installed to examine the network), what attack are you protecting against?
Can you give me a link about an attack that knowing the topology of the network ahead of time would allow, but that not knowing would prevent?
Seems intellectually dishonest not to acknowledge that making things easier, just y'know, makes things easier. Keeping attackers, who want to do you harm, in the dark as much as possible seems important to me.
An attacker looking to be stealthy is not going to blast the network with nmap...
ARP is broadcast, NDP is solicited node multicast so simply by passively listening on the network you will discover nodes in the same layer 2 segment, with v6 and properly configured switches your passive discovery will be a lot more limited.
Other passive techniques would be monitoring things like DNS, and things the host you've compromised is actively communicating with. This isn't any different regardless of the protocol used.
You can also actively communicate with services like DNS or Active Directory and query information about the network, depending on your level of risk.
Just knowing the in-use IPv6 block is useless, the blocks are massive so even just identifying active hosts in a single known IPv6 block is a lot harder than simply scanning the entire RFC1918 legacy address space.
For active discovery, IPv6 is harder to attack - you can't scan the entire address block looking for hosts. The fact that such scans should be detected is exactly the same for either protocol. You also have to consider response time and what an attacker may be able to achieve before your response kicks in.
IPv6 makes it harder for attackers, not easier.
Tell us with the next 0 day, because that big problem exist, and unfortunately happens every days.
IPv6 == All your devices are globally ROUTABLE and CONNECTIBLE from Internet, your home network is part of internet. It is an additional rule in the router's firewall what temporarily avoids it. Remark in temporarily, as one day the gifted packet will arrive to the router. This is not cool.
So much so -the home network is part of internet- that if you want to create a simple Video NAS or whatever, one have to use external DNS services, as no one have control over its own local IPs... what are served by the ISP. This is not cool.
Even if it was not designed for it, NAT has been helping to secure and giving flexibility to our local networks along decades, but someones decided to reject it from the specification. Bad decision.
Regarding firewalls bring prone to accepting by default, either way the packet has to go through the CPU to be routed. I don't believe there's any inherent bias in the design. You could argue that routers that use a single switch and vlan isolate the wan port are inherently biased, though.
Regarding local hostname resolution, there are several options that don't require your ISP. There's mDNS, DHCPv6 and DNS on your router, ULA prefixes, or you can continue using IPv4 for local traffic.
Firstly one ceases to have control of its own home network, what now have to rely on the ISP for to receive the "local" IPs, what are part of internet. And in addition each machine leaves a trace of its "local" ip on the Internet. This if one want internet access in the device, due the absence of NAT in the router's protocol.
Secondly one have to rely on a buggy piece of code called firewall for to make "local" those IPs, due the absence of NAT in the router's protocol.
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
https://www.cvedetails.com/google-search-results.php?q=firew...
We are talking about millions of routers provided by the ISPs in each country, barely maintained and updated, what little by little will become exposed. And this without taking in account the unpublished firewall bugs that each artist keeps for themselves and takes 3 to 5 years become detected and fixed by the mainstream. I do not know how to express the negligence is going on, but I can see that Crackers, Advertisers (privacy) and "others" are in good time because things are getting more easier for them than it should be.
Why people keep down-voting the message is a mystery for me. If it is due the local hostname resolution, mDNS, ULA prefixes, etc, all are workarounds due it is a network one does not control, what is one of the main points I exposed (it also needs filters/rules what needs be manually added in the firewall, each user has to make efforts to try to protect the supposed "from internet" separation).
One could create another network as you said, but the main problem keep existing without NAT.
IPv6 has link-local addresses that aren't routable, so you can't really get more local than that. Unlike a typical IPv4 setup, typical IPv6 hosts have multiple addresses, and you can make your own for local traffic and only rely on ISP prefixes for internet access if you want to.
Sure, the internal host's internet routable IP address is visible rather than being masked behind the router's IP address. Pretty much all operating systems periodically randomize the bottom 64 bits, making it effectively as opaque as NAT. You could call that a hack, but people call NAT a hack. There's tradeoffs.
The CVE links you provided are just lists of vulnerabilities with "firewall" in the name. Skimming through them, I don't see how they're specific to IPv6? Most of the vulnerability descriptions I read seem equally problematic for NAT setups. The one IPv6 specific one I saw had to do with a bad firewall rule allowing access to LAN facing services running on the router; it could have just as easily been a bad IPv4 rule.
I agree, consumer network gear all sucks. IPv6 is bolted on as an afterthought, and is probably buggy in a lot of them. More features means more opportunity for bugs, but that's true of anything. IPv6 isn't being deployed for no reason; there's limited IPv4 addresses to go around. I still don't follow why IPv6 is fundamentally riskier than IPv4 when traversing a router. Sure, with NAT an incoming packet needs to have a port number that's been dynamically mapped back to an internal host and port, or have a static port forward. In IPv6, an incoming packet needs to have a destination address and port that's been dynamically mapped back to an internal host and port, or have a static firewall rule. It's basically the same, but also less complicated for the router because there's no translation involved. In time, less complexity is good for software hardness.
I also get anxiety from trying to wrap my head around IPv6 address assignment. It is nuts. It's very comforting to work in the effectively 8-bit address space of a /24 IPv4. I suppose it's true that you can't control internet routable IPv6 addresses in that they are dynamic and ephemeral in their nature. Coming from IPv4, it feels messy. I've experimented in detail with configuring my own ULA, DHCPv6 configuration, and SLAAC. I've tried to embrace the benefits of IPv6, and having used a few of the features I can appreciate them for what they are.
I put the CVE links with the generic word "firewall" because it is the point where the "local" vs "internet" resides with blind faith within IPv6 (without indicating an specific exploit, just vulnerabilities exist). For this case, the DDOS and buffer overflows that force the firewall to shut down, or code execution, what are periodically discovered, is what I wanted to show for being considered as a serious problem. Not everyone reports firewall bugs, and others I guess even wickedly insert them.
With NAT setups, the local and internet networks are different between them, what requires the packets to be filtered and rewritten by NAT for the address what solicited it, while unsolicited packages are discarded. The NAT in consumer gear is run mainly by software, but a poisoned packet will not aim to shut it down for network penetration because it would be the end. If the NAT stops working, the doors close for everyone.
It is about the double checking,
-IPv6 without NAT: If the firewall stop working, opened doors. Feast.
-IPv6 with NAT: If the firewall stop working, many rules get unfiltered, wild. But NAT keeps the local/internet separation besides filtering unsolicited packages. Not absolutely secure, nevertheless keeps being a complex target.
Like all of we, I suffered some problems that NAT can bring losing countless hours trying to make work some specific services, but when I first read IPv6 didn't implemented NAT nor something similar in the protocol (for whom whish to use it at least...) and what the supposed local IPs are merely part of internet (link-local addresses that aren't routable as first target, devices with internet connection are), each device with its own public address, I doubted seriously about what was going on.
Given that even Mikrotik RouterOs periodically have security vulnerabilities related with the firewall, I can't conceive the idea of people relying on firewalls rules to do the home/internet separation within IPv6 (plus the public address of each device gives me also anxiety), as it is a matter of time before such separation ceases to exist; it is like the crossing of fingers.
I mean, it is not a matter of misfit, it is more like the users will not even notice the router's firewall was shut down.
RFC1918 address space IS routable, it just doesn't have a global route. There is nothing to stop devices adjacent to your wan interface (ie other customers) from manually adding a route to your RFC1918 address space via your firewall. Will that traffic be allowed? that depends on the device and its configuration, have you ever tested this scenario? probably not.
NAT is a hack to get around a shortage of address space, nothing more. Once the shortage is gone there's no more need for NAT. That's why although NAT with IPv6 is possible, it's very rarely used because you no longer have any valid reason to use it. If you are think there are any other reasons to use NAT then you need to brush up on your network knowledge because a lot of smarter people than you or I are saying to avoid NAT and designing systems (eg IPv6) to fix the problems it causes.
US government advice is to avoid the use of NAT because of the extra complexity it introduces, which actually reduces security:
https://media.defense.gov/2023/Jan/18/2003145994/-1/-1/0/CSI...
I really don't understand the fearmongering. Your home router likely runs some flavor of Linux which uses Netfilter/iptables to perform both NAT and filtering. Do you believe that the filtering/firewall modules are inherently flawed, yet the NAT modules are infallible?
I see them as two sides of the same coin. If we're theorizing about a magic packet that not only removes your firewall rules, but also flips the default policy to ACCEPT, the very same packet could also sneak in a few NAT rules into your IPv4-only router.
This is an interesting point though personally I love how easy container technologies made exposing arbitrary ports, without trying to configure the software itself, or checking whether it even supports customizing the port.
For example, I could have 3 database instances, each using 3306, but expose them on 30000, 30001 and 30002 or whatever I want.
The Gods intended for each database service to have its own IP address and I curse the market forces that have trapped so many of us in the quagmire of NAPT!
Of course I do. Why would you not want the option of easily allowing a device to be globally routable if you need it to be?
I think routers should be more explicit about how you set up each new device on a private network anyway. Guest wifi can have a sane default. Private wifi could make a notification pop up on your trusted device, asking you if you want the now device to have access to the internet, and if the internet should have access to the device, and if so, which subnets/countries should be able to access it through which ports.
A lot of would-be P2P applications end up using a relay server to get around that restriction, which adds significant cost and latency. Sure it's a well-established workaround by now, but it'd be nice not to rely on it.
As the parent suggests, IPv6 creates more work to prevent more exfiltration. It is already difficult enough with IPv4.
Could IPv6 fix a web infested with "tech" company intermediaries and return it to one where all participants can connect directly and if desired publish to audiences (without "tech" interplopers). That sort of proposal would make an interesting read for end users.
Even if you never allow anything in from outside that wasn’t established from the inside first, it still removes an added layer of complexity from things.
If we had networking protocols that took into account the complexities of private addresses it could probably work - but we don't have such a luxury. The entire TCP/IP stack assumes peer to peer connections, and NAT is literally a spanner in the works for all that.
The whitehouse has a public address, everyone knows its address and yet random people can't just walk in through the front door.
I'm fully ready to start using IPv6 but my packets won't get past my antiquated ISP. That seems like a pretty big hurdle, no?
- Our ISPs support IPv6 but routing quality is way worse than IPv4 including occasional inability to connect to some networks or greater latency than IPv4. I had to create tickets with such issues understood that most probably they just don't have IPv6 BGP sessions to all their upstream providers they connect.
- How the VPN (an employee / road warrior setup) should be configured since from the routing perspective you don't need a VPN to connect from your home to the office? Assuming both have proper IPv6 connection and all devices in the office and your laptop have a globally addressable IP address. Employee can have IPv4 or dual stack at his home, where is dual stack in the office. Very confusing. Looks like Fortigate also don't have an idea and decided to not support such case.
- You have to be careful with site-to-site VPN since even your internal services like database are now globally addressable. You really need proper firewall rules / routing policies to not leak unencrypted packets over internet.
- SLAAC is cool but doesn't provide DNS configuration. (there is RFC8106 but is it supported by all OSes?). You need DHCPv6 for that. You have to choose: use only DHCPv6 or SLAAC + DHCPv6 or just relay on the vast that DNS will be proviedd by DHCP IPv4 in a dual stack setup.
- The way of providing high availability gateway address in a network is different. You need router advertisement where you can provide priorities. That actually is much better than any other VIP mechanisms (no issue with MAC table updates, etc.) but you need to know that.
- OSPF works a bit differently. For example: there is no authentication in router communication in OSPF itself, you are supposed to use IPSec.
The list is longer unfortunately...
I’d bet that this will be the source of some gnarly leaks in future. If it does my bet would be it’s going to follow the “API keys on GH” trajectory.
For the most part, yes it's supported by major OSes. (ND RDNSS) https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...
Uhmm I might be wrong here, but can’t you just not assign global IPv6s then? Keep your local network on ULAs (https://en.wikipedia.org/wiki/Unique_local_address) for network-internal routing
SLAAC can provide DNS configuration, see RFC6106 for instance.
You can do HA in the same way with VRRP or whatever too, as you point out the built in mechanisms are generally better but you don't necessarily have to use them.
The chance of traffic leaking still exists, and does happen a lot with legacy IP too. The difference is that with v6 the traffic will be routed back to you, so you will be able to see it on your border firewalls. With legacy IP, the traffic will be dropped by the ISP or absorbed by the local network so you don't know it's happening and consequently you probably won't try to do anything about it.
I hate this attitude. This is isomporphic to saying "stop thinking of system call interfaces as a security mechanism and think of them as an address space sharing mechanism". It's not technically wrong, but it's wrong in practice.
Even the most naive NAT can't misroute an inbound packet. If you have an internal host and it doesn't talk to anything outside the firewall, then no one else can reach it. They have no name for it, the packets won't go. You get this even if you don't understand how it works. You get this even if the router has no idea about the host.
Give everything a unique address and now the router needs to know who is safe and who isn't. That's a decision point that requires configuration by human beings, and human beings get stuff wrong.
No, NAT is your friend. Use NAT. Use it even if you're an IPv6 nut.
heck, they even inventend protocols to do automatic NAT setup (UPNP) because configuring NAT by hand confuses people a lot.
All the 3 ISPs I dealt with in Hungary in the last 10 years provided 0 firewall capability for IPv6 in their integrated router/modem.
Once you start assigning the addresses, every compatible IoT gadget you have is reachable from the public web.
In this state, IPv6 is a pure security stepback for average residential users with 0 upside.
I can't take any comment seriously who is speaking of configuring a stateful firewall in a residential environment.
There aren't enough IPv4 addresses, so any ISP using IPv4 addresses is going to give 99.999% of their customers exactly one IPv4 address. Not ten. Not two. One.
So NAT has to work. Grandma has nothing to configure because either NAT works or grandma is calling her ISP to ask why her tablet ain't working.
So when the customer gets exactly one IPv4 address, the ISP is forced to hand a router doing IPv4 NAT. They have no way around it.
While if you take an ISP handing out hundreds of billions of IPv6 addresses to each customer, well... They are not forced to hand a router which does proper firewalling.
It's not a question of whether it'd be easier for the ISP to give a correctly configured IPv6 router firewall vs handing an IPv4 correctly doing NAT.
It's that when they hand one IPv4 address, they don't have the choice. NAT must work and there's no way around it.
That would be full cone NAT, right? Can't think of anything more naive... :)
And that can definitely bite you in the ass.
I don't expect them to move forward on it until significant sites become ipv6 only as they've admitted that they have more than enough ipv4 addresses for their subscriber base, so there's very little incentive for them to do anything atm.
I think I've still got my HE IPv6 t-shirt somewhere, from when I completed their readiness quiz so years ago!
Edit: I actually decided to set up a tunnel, just to see how well it worked, and it turns out my ISP supplied router won't forward the protocol 41 packets anyway, so that's a total no-go.
I suppose I could probably set up a small VPS and Wireguard vpn, then forward the IPv6 packets that way?
Let's say I have a very small home lab. I have a handful of hosts that get their IP addresses via DHCP from my router. In the router, DHCP and DNS are tightly coupled such that the router essentially always knows the MAC address, IP address and hostname of each device.
Now I want to run IPv6 on this network as a first-class citizen. Since DHCPv6 is apparently frowned upon by v6 purists, and not all devices on my network support it, that leaves SLAAC. My understanding of SLAAC is that each node essentially picks its own globally unique IP instead of asking a router for the IP. My question then is: is there some standard for the DNS server on the router to somehow know the v6 IPs of the hosts on the network so that it can automatically create the right A records?
The point GP had that it won't work, then DHCPv6 is not used.
- I’m never going to remember MACs
- Even when IPs are carefully thought out, if something happens to the DHCP server and it needs to be rebuilt, IP no longer tells you anything about what device it is
Whereas hostname/DHCP client name shows up in almost every router UI, is viewable from any *nix machine on the network (when DHCP and DNS work together), and is typically a first-class citizen in the DHCP lease settings themselves. Super handy. As a side bonus: rogue hostnames are immediately obvious, but rogue MACs or IPs require investigation before you know whether they are benign.
I believe there is another way, but the router has to support it and I forget what it's called.
Configure your ntp clients to use the name, and maybe add a pool.ntp.org entry or two into your configs.
So how do you do this hands-off, ie without manually changing things on the clients, without DHCPv6?
There are options for IPv6: PFSense, as an example, has "Assisted" RA mode where devices can use SLAAC or DHCPv6, so you have SLAAC for general clients that don't need more (e.g: phones that don't support DHCPv6), but clients that want more can use DHCP to provide specific reserved addresses and DNS names, etc...
I ended up with bind and rfc2136 dynamic updates. Not all devices are capable of doing it, but it is what Active Directory does by default.
The main hold out against DHCPv6 is Android:
* https://issuetracker.google.com/issues/36949085
Complains by them? Won't fix (Intended behavior)
It's not a dichotomy between DHCPv6 and SLAAC. You can hard-coded addresses too. Since it's your homelab you presumably already know all the devices that will be connected. It's what I do.
You may not even need to hard-code the prefix everywhere. Eg with systemd-networkd you can configure the device as:
... which will give that interface the address $prefix::1:2:3:4 based on whatever $prefix was advertised by radvd. So the only place where you'd need to hard-code $prefix is in your DNS server.>My question then is: is there some standard for the DNS server on the router to somehow know the v6 IPs of the hosts on the network
NDP discovery (`ip -6 neigh show`) will let you know about other IPs (and corresponding MAC addresses) on the link. It won't do anything for matching them up to DNS names.
Stateful DHCPv6 is the bad one. It assigns hosts specific addresses.
> the router essentially always knows the MAC address, IP address and hostname of each device.
You can still have this with ipv6 addresses. They easiest way is to use eui64, the original ipv6 addressing scheme where the address is calculated from the subnet + the MAC address of the interface. That way server VMs get deterministic addresses. If you use network-manager you can configure eui64 with the "add-gen-mode=eui64" setting.
In my homelab, I have a few server VMs that use eui64 addressing whereas the end user devices use privacy addresses randomly selected from the subnet.
RFC6106 ? You're right that works. I was just trying to communicate the unobjectionable nature of stateless DHCPv6.
Stateful DHCPv6 is bad because it undermines the concept of hosts selecting their own addresses as needed for privacy, tethering, etc.
The decade old Android issue where Google refuses to implement stateful DCHPv6 provides some good background: https://issuetracker.google.com/issues/36949085#comment53
Everyone is always so quick to jump to how _they_ don't need IPv6. The truth is that we _all_ need it. Eventually, there will become a day when services will start to migrate to IPv6 because the cost and limitations of IPv4 addressing will become prohibitive. Then you'll no doubt care when it affects you personally.
Don't really understand networks yet, but I guess it was because my isp doesn't support ipv6, but linux kept defaulting to ipv6 before trying ipv4.
I think it was an ISP issue. At the time IP6 was in beta. Now it's enabled for everyone and the issues stopped happening.
My public v6 would be like 2345:0425:2CA1:2020:1100:0567:5673:23b5, private is fc00::::903A:1C1A:E802:11E4, DNS 2606:4700:4700::1111 (don't forget those consecutive colons).
It's not that I don't like change, it's that I don't like changes that make things plainly worse for me.
Change is about more than just "how many numbers do I have to remember".
There were proposals back in the day (early 90s) for IPng (IP Next Gen, as IPv6 was called back then) to be a hierarchical routing algorithm, that could have kept backwards compatibility with IPv4 and transparently allow seamless operation and routing of IPng islands over IPv4 infrastructure, taking full advantage of the address space expansion.
Think of a sort of CGNAT that instead of stateful hacking with port numbers and the like, would have dedicated fields in the IPv4.x packet, allowing the gateway to statelesly route between the two domains (public IPv4 internet and internal 10.x.x.x network), while maintaining end-to-end connectivity.
Alas, the ITEF guys really wanted a clean slate design and willfully ignored the economic problem, that IPv6 is only useful when everybody upgrades, and as a consequence nobody upgrades. It's probably one of the most costly failures in the history of computing, along with the NULL pointer, 640kB and the likes.
But IPv6 is not an alternative to CGNAT. If you don't provide either a routable IPv4 or CGNAT, your customers will ask their money back because their internet is broken. The fact that you provide IPv6 or not is completely irrelevant to the vast majority of consumers or businesses.
This here is the major failure of IPv6 design, confusing what "the internet as a whole and the ISP community" need, with the individual incentives that make a single ISP provide for those needs.
It’s clear to me that IPv6 won’t reach critical mass (e.g. 80% of connected devices/servers using IPv6 addresses).
I’ll just wait for a new IP with an actual transition plan.
I'm holding out for a new protocol/architecture to come along and supplant IP by recognising that it needs to be fully interoperable with 4 before it can supersede it.
Another nail in the coffin of a graceful upgrade from IPv4 is the widespread filtering of IP options in the backbone, the only practical way I know you could craft an extended IPv4 packet that is still routable by the legacy infrastructure while forwarding and maintaining all the extra header data required for routing in the IPng realms. This was not necessarily true in the early 90s, and many hardware generations would have had the ability to fix it.
So I somewhat disagree with the GP that IPv4 was not forward compatible: it included a mechanism for just that in the form of IP options that seemed like a good idea in 1983, but which proved technically inappropriate for the future needs of the internet. So you can't really fault IETF for wanting to break away from that and earnestly thinking people would just upgrade.
Because that's what's required to make it fully interoperable. Anything else and it's not a pure IPv4 network anymore and you are in the exact same situation as we are with IPv6.
The article mentions NAT64, which works well for IPv6-only computers to talk to IPv4 servers. There is enough space in IPv6 to encode the whole IPv4 connection which makes stateless NAT possible.
The other mechanism is 464XLAT and MAP, where IPv4 isn't tunneled over IPv6 network, but encoded in the IPv6 address. 464XLAT is used heavily on mobile phone and uses software on the device. MAP requires support on gateway. MAP is stateless which is savings over carrier-grade NAT.
https://httpbin.dmuth.org/ip/v6
If you run a mailserver adding ipv6 support is far more risk to your domain's mailserver reputation than it is worth. And if you're just a human person and not a megacorp that new ipv6 address, even if it it doesn't immediately hurt you, will take a very long time to get accept, longer than an ipv4.
I also have all my IPv4 addresses memorized, and IPv6 addresses are too long to remember with all the hex-double-colon nonsense.
If they could have turned
1.2.3.4
into
1.2.3.4.5.6
I'd probably use it, but instead they opted for some scary stuff that looks like
d0ff::eefa::0010::faff:::://::92::0
which I'd rather not look at. Product management fail.
Anyhow, IPv4 still works for me, so I have no pressing need to even try to understand these hex-colon monstrosities.
My DNS server is 8.8.8.8.
Why the hell isn't the IPv6 DNS server
8888:8888:::8888:8888?
Instead it's 2001:4680::... wtf?
I mean look, a few days ago Comcast had an outage and I plugged my phone into my USB port to tether it for internet access. It hijacked my DNS entirely, and I couldn't turn on my damn lights or change my thermostat which were on my LAN. Thankfully I know their LAN IPv4 addresses from memory, 10.10.10.x and 10.10.10.y, and I was able to issue CURL commands directly to their local, non-cloud APIs to manipulate them. With IPv6 hell knows what their hex-colon monstrosities would be.
You would know exactly, because every IPv6-enabled interface has a link-local predictable IPv6 address derived from its MAC address.
The reality is with IPv4 I can memorize all of the IPv4 addresses of every light bulb, every robot, every thermostat, every plant watering device in my residence, and I can hammer out CURL commands to control everything almost from muscle memory in the event of a DNS hijacking.
Yes but my phone hijacked all the LAN DNS when I plugged it into a USB port for tethering when Comcrap went down for a few hours
Also separately, when Comcrap is working, my phone on Wi-Fi refuses to ever use the router DNS, http://xyz.local addresses are only available on desktops/laptops and not phones, therefore IPv4 addresses it is when trying to visit a LAN site on a phone.
If the problem wasn't obvious, the problem is that IPv6 addresses (and also MAC addresses) are not human readable. IPv4 addresses, on the other hand, are.
IPv6 adoption might be farther along if the addresses were human readable instead of eye-rolling machinations of a small subset of people who speak strictly in hexes.
Sometimes we need to deal with raw IP addresses instead of abstraction layers, and IPv6 fails hilariously because it clearly goes beyond the realm of direct human consumption.
You saying a non-human readable thing is human readable if it's passed through an abstraction layer to make something human readable only reinforces the argument IPv6 is not human readable.
Windows and many Linux distros by default enable the privacy extensions on the link local address; it's randomized for a period of time. This is right off a Windows 10 VM:
ipconfig:
Notice that there's no ff:fe in the middle of the address?RHEL 9:
Fedora Core 35: Ubuntu 22.04: I don't have a Debian right on hand but IIRC they do the same thing. Alpine uses EUI64 I think though.Linux will use EUI-64 if left to its own devices, or privacy extensions if you're using something like networkmanager. This makes sense because a desktop oriented distro will typically use networkmanager while a server oriented distro will not, and having a predictable eui-64 address is usually beneficial for a server.
dns: maniacal laughter
The :: only expands to fill all-zero hextets.
Oh and I'd actually prefer the 65520.
The huge prefixes allow for a simple hierarchical network structure and gives us room to redo the address scheme if we end up wanting to (only a portion of addresses space is currently allocated right now) without having to go through this entire upgrade the internet again.
[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism
As an end user who has a choice, they have to give me something that's not harder to use than before. I think they could have managed that if it were a priority.
I'm not an IT admin, but I disagree the world is not moving forward.
If I need to use IPv6, I would switch. But the reality is people are able to still build rocket ships, electric cars, and large language models with IPv4. The world is moving forward just fine.
The person who's comment I was responding to, is in denial 20 years later because they feel comfortable with IP addresses they can remember.
[1] https://en.wikipedia.org/wiki/6bone
I think the other commenter and I would both happily adopt v6 if it gave us v4-style addresses.
I wouldn't mind a simpler DNS server IP though seeing as it's one of the few locations you need to treat as an address regularly. Sprint/T-Mobile has 2600::, which is not only short but seemingly a phreaking reference, active so why can't something similar be active for DNS. I get not wanting 8888 or whatnot, those blocks aren't assigned and advertising random bits for vanity can be annoying, but there are plenty of short IPv6 addresses that could be in use for the most common DNS servers on the planet. Even I have my personal DNS server running on an XXXX:XXXX:: public IPv6 address!
Consecutive colons aren't readable or easy to remember.
First step of dual-stack networks should've been, every device's IPv6 address is the same as the IPv4 address, just padded technically, and represented textually the same. If I put in 8.8.8.8 and the systems want to speak IPv6 instead, go ahead. A little hacky but addresses (no pun intended) both technical and marketing problems. You could even use a v4 DHCP server and DNS but speak IPv6, instead of trying to sell people on a whole stack change at once.
New technology has benefits, if you don't know what they are then you need to learn about them properly. Sticking with old technology because you fear the new is not a good plan.
IPv6, however, is not more convenient than IPv4, so the analogy breaks.
In an organisation of any significant size, remembering legacy IP is much worse than v6.
Chances are you will have lots of disparate legacy blocks, some starting 1.x, some starting 80.x etc. Then you have all the RFC1918 space, and the possibility of overlapping address space in different areas of the business. Then you have to keep track of translations, so an internal address 10.1.1.1 could have an external address of 80.1.1.1 but only on port 25, if you're talking over port 443 then actually the traffic is forwarded to 192.168.1.1 instead.
IPv6 is simpler. You have a single prefix for your company, eg 2001:db8:: Then you split it out in a sensible hierarchical way, for instance 2001:db8:1:: is your facility in the US, 2001:db8:2:: is your facility in Canada etc. Beyond that you go down to VLANs and hosts as needed.
So 2001:db8:2:25::1 is a device in your toronto data center... 80.1.1.1 is where?!?!? 192.168.1.1 is where?!? and which one did you mean?!?!
Then there's no NAT, no address overlap, much simpler. 2001:db8:2:25::1 is the same device wether you're talking to it on port 1 or port 65535. Your firewall rules are simpler and more secure as a result.
Microsoft had a presentation about this, and they are a bigger organisation than most.
If you're only small then you don't care, technologies like SLAAC and MDNS exist for exactly this reason.
I was illustrating why there is zero incentive for 99.99% of people to not care, which is the reason why it isn't getting adopted.
If moving my home network to IPv6 came along with some incentives -- e.g. significant tax breaks, free symmetric gigabit for a year for IPv6 traffic, discounts on rent, tax-free early IRA distributions to buy networking equipment, free electric car charging for 5 years, I'd move to IPv6 in a heartbeat.
For a small network it makes no difference, everything is auto configured, mdns is used to lookup names, you can makes your hosts ::1 ::2 etc if you want to. Many ISPs around the world provide IPv6 by default, and users are using it without even realising, so it is being adopted just not fast enough. Global usage is around 42% based on published stats, and is well over 50% in many countries, as high as 80% in some.
IPv6 does provide benefits to end users, it reduces cost for the ISP and makes end to end connectivity viable which opens up a whole new set of opportunities. End to end is immensely beneficial for gaming, voip etc. Having everything centralised because users are encumbered by NAT is a big problem - increased latency, high costs (recouped from the users somehow - eg selling their data), single point of failure, applications which become useless once the central servers are shut down etc.
For example: d0ff:eefa:10::faff:92:0 (though there are currently no addresses in use that start with d.)
Vanity IPv4 addresses like 8.8.8.8 exist because most addresses have been allocated, so companies with money can go hunting for nice ones. There aren't many IPv6 addresses like 2600:: because internet registries don't allocate them on purpose, and I'm not sure if anyone's cared enough to bribe them.
OK I challenge you to rewrite the IP address you wrote without looking in 5 hours.
Then go try it again with something like 10.10.53.24.
See which is easier.
If I wanted a memorable local address like 10.10.53.24, I'd pick fd53::24 or something.