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.
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.
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!
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.
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.
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.
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.
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.
Security through obsecurity is not security.
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.
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?
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.
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.
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.
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 will fix that.
What's wrong with a firewall that blocks everything by default, yet all your devices have a public IP?
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).
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.
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.
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.
The whitehouse has a public address, everyone knows its address and yet random people can't just walk in through the front door.
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.
That should be enough for all your devices to randomly rotate IPs for a lifetime or a few without any NAT.
- 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.
Biggest one for me personally is that my current ISP doesn't give stable prefix. Power outages or firmware updates requiring a router reboot thus can cause the PD to be changed and potentially break firewall rules that are sensitive to the PD. In an absolute worst case, it also means that none of your hosts can reach the internet anymore if for whatever reason they're not updated of the prefix change.
No, the ISP is not supposed to that. But I don't see them changing this behavior any time soon. Yes there are ways to mitigate (ULA, mDNS, DNS, DHCPv6, etc) but now you're introducing additional complexity that didn't exist before into the network when I keep hearing how Ipv6 is supposed to reduce complexity. And IPv6 is complex enough to make my head spin without considering those workarounds.
Other issue I can think of off the top of my head is how to deal with an organization that would requires multi-WAN fail over or load balancing? The only solutions I've see thus far are far beyond my level of skill and budget. I assume also that there's similar problems when asking about a load balancer between multiple gateways to the internet.
I wish there was something in the ipv6 standard that allowed referencing an ipv6 without the prefix on your local subnet (ie: :::10a1:da35:2f4d:3cfc). So you could do all your internal networking with the consistent suffix and just deal with the changing prefix the same way we do with a dynamic ipv4 addresses, dynamic DNS. I'm certain there's a reason something like this couldn't be possible but it just seems like something along these lines is missing.
That's what the link-local address on your interface is for.
Tie all your network config to your IP space provided by your ISP and now suddenly it's a pain to migrate to a different ISP
Or, if you want to carry your own IP space, now you have the administrative overhead of managing that (and, now you have to go with higher-end business internet service that may be more than you need, just to support bringing your own IPs)
Or, if you want to keep things local, run a lightweight nameserver on your LAN to resolve .home or .lan domains. Much nicer to type fridge.home in your browser than 192.168.1.57 or some such.
ULAs are neither "additional complexity" nor "reduced complexity" compared to IPv4 NAT - they're the exact same. Both require you to decide on a private prefix, set up DHCP / DNS / static IPs within that prefix, and set up translation for that prefix.
>Other issue I can think of off the top of my head is how to deal with an organization that would requires multi-WAN fail over or load balancing?
Exactly the same, ULAs.
This is the situation I settled on for my home, because having redundant ISPs means a lot of headaches and I obviously do not qualify for a PI allocation. Every machine on the network gets a ULA address that remains stable, and to deal with ISP failover I have a script on my Mikrotik router to change advertised prefixes when the primary ISP goes down.
Took more work than my v4 NAT setup, and I hope more network vendors build-in support for the WAN failover bit in particular because every consumer/prosumer kit I've used does absolutely nothing for v6 traffic (I literally could not have done it without Mikrotik scripting or rolling my own router because no off-the-shelf distro like opnsense/m0n0wall/etc have support for this).
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?
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
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:
[Network]
IPv6AcceptRA=yes
[IPv6AcceptRA]
Token=static:::1:2:3:4
>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.
The main hold out against DHCPv6 is Android:
Complains by them? Won't fix (Intended behavior)
- 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.
The point GP had that it won't work, then DHCPv6 is not used.
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.
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 believe there is another way, but the router has to support it and I forget what it's called.
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.
I understand the support of new technologies but IPv6 is 27 years old.
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.
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.
For networks (order of preference): IPv6 only > IPv4 Only > Dual Stack.
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?
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.
208.255.238.250.0.16.239.109.89.54.222.189.74.21.22.9I 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.
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.
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.
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.
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.
The fight between your average video game and NAT has caused me so many problems over the years (including port forwards to receive traffic because whatever NAT punching mechanism the game used didn't work).
Running dual stack does cause some weird debugging ("why can't my laptop connect to github while everything else works? Oh, DHCP broke") but that's mostly because of problems with the IPv4 part of the network.
I think going IPv6 only isn't the way, not yet anyway. DS-Lite seems to be working fine as a replacement, though: CGNAT for IPv4 and normal IPv6 for real connectivity. Full fat dual stacks would be better, but realistically I don't think that's going to be brought to the masses.
For hosting stuff, not having to remember what SSH port maps to which server in my home lab is a nice addition. Being able to directly reach LXC containers is also quite useful, as is using separate addresses for individual hosted services.
I don't know why everyone here has such terrible ISPs. Unstable IPv6 prefixes, broken routing, weird custom allocations, your ISPs all seem so cursed! No wonder people are so mad at IPv6, your ISPs are sabotaging your internet.
Dual Stack doesn't "solve" anything. You still run IPv4. With all the downsides, especially every machine will still need an (RFC 1918) IPv4 address.
(Microsoft is running out of their internal 10.0.0.0/8: https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...)
The goal of the IPv6 transition is to disable IPv4. NAT64+DNS64 or 464XLAT allows us to disable IPv4 on devices before the entire internet is ready.
For internal networks, IPv6 seems like an obvious choice. If you already have company wide subnets, you may as well set up some ULAs/GUAs and use IPv6 internally. Full IPv6 may be better but people worry about adversaries mapping internal networks for some reason so NAT66 may be necessary to placate those fears.
The problems you still keep around by using some kind of dual stacking (DS-Lite being the cheapest) ensures compatibility with servers and entire countries that haven't even begun upgrading their networks yet. You incur the IPv4 penalty, for sure, but only towards services that don't have IPv6. This provides an incentive for the world to move on without breaking existing infrastructure entirely.
Add that to the list of thousand cuts.
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?
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.
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!
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.
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.
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.
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...
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.
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.
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, 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.
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
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...
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
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!
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.
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.
I don't know of a single game that supports IPv6, although some consoles might?
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?
[citation needed]
>That's why gamers push for IPv6.
[citation needed]
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.
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.
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.
fast.com says 50 "Mbps". Whatever that is.
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.
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.
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?
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.
That would be full cone NAT, right? Can't think of anything more naive... :)
And that can definitely bite you in the ass.
heck, they even inventend protocols to do automatic NAT setup (UPNP) because configuring NAT by hand confuses people a lot.
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.
Yup. I work at a large, complicated infrastructure organization. Our firewall guy has a lot on his plate. Having him manage the security concerns for IPv4 and IPv6 is a bad idea when considering the tasks we have and the labor available. Similarly, having the networking team implement IPv6 on top of their already significant projects results in less time available to do other things.
I look forward to the day when IPv6 is easy and universal, but I can completely understand why many admins aren't bothering.
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 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.
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?
So any address of the current length you just treat it as if it has zeroes in front, otherwise you use the longer length which allows for many more addresses. Problem solved.
If you manage to solve that problem, you'll probably have invented something a lot like NAT64, which TFA talks about.
Something like, I'll-sell-you-my-v4-blocks-at-a-later-date-forfreeipv6-bandwidth-today-as-a-service ...
Re-Send them nostalgic AOL CDs as the advertising...
ping6 news.ycombinator.com
ping6: news.ycombinator.com: Address family for hostname not supported
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?
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.
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.
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.
- Designers think globally routable internet is a huge achievement
- Users just want to hide their devices from the hellscape that is modern internet, with all its threats
These are fundamentally different approaches
The alternative, having ambiguous addresses, makes systems hard to reason about and monitor, and add compplexity - eg when inevitably "internal" networks end up connected to each other in various kinds of reorganisations resulting in misconfigurations because nobody can tell anymore what the ambigous rule about a 10.xx address meant. Complexity and anbiguity are main enemies of security because you can only secure what you can understand well.
NATs are also hard to reason about in that there's no real spec about what kind of incoming traffic they allow and when. The NAT function is designed to facilitate communication in face of connectivity hurdle presented by the addressing, not limit communication.
Secondarily, to many users both ipv6 routing and NAT are both incomprehensible. I think most home/sme IT admin people who have to maintain everything in their home/company are not in a position to learn everything about ipv6. Having a solution like NAT where you just cant connect from the outside (unless forwarded) really simplifies many things.
Many people are not in a position where they can understand networking fully.
With attacks like NAT slipstreaming your devices are already globally reachable in any real network anyway. That, or FTP/SIP doesn't work, because ALG exploitation can be mitigated by just disabling those protocols.
Just ask the average gamer behind CGNAT how they feel about the security NAT provides them (and what kind of NAT they need), or your average network application developer about the joys of setting up handshake servers to punch holes through NATs.
The curse that is NAT has led to ridiculous workarounds like Nintendo telling people to put their Nintendo Switch in the DMZ if multiplayer doesn't work.
Only way around that is sniffing the communication (say some cloud service that some IoT device connects to) - which would also give you enough information to send your own packets through the NAT/firewall too. Not very feasible for the average attacker and assumes that the device initiates connections in the first place. If it doesn't, good luck finding it remotely.
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
In other words, no.
Who's fault is this again?
-------------
"- IPv6 is absolutely ready for prime-time and has been for awhile
BUT
"- About half of the internet sites I rely on support IPv6 natively, so there needs to be more pressure on site admins and CDNs to support IPv6 natively"
That is a contradiction.
-----------
"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"
Again, who's fault is it that its so hard? What is the payoff for the extra work?
-----------
- Networks should be designed IPv6-first instead of IPv4-first, and this design approach largely solves most of the major issues
K thanx, but that's not the way virtually every company works. Mayyyyybe a startup? This is unrealistic.
-----------
"Other operating systems are bit of hit or miss"
so... IPV6 is NOT NOT NOT ready for prime time, is that what you are saying?
-----------
What dream world are the ipv6 people living in?
I love this. Who should be implementing ipv6 stacks in OS's? Probably ipv6 people, but ... where are they again? The amount of blame is crazy.
A protocol switchover of this magnitude is about outreach and assistance. The ipv6 crowd has NEVER displayed that, just arrogance, dismissal, and waited for things to get "so bad" in ipv4 that it transferred.
Which is why ipv6 people HATE HATE HATE NAT. It has delayed their grand moment by decades.
...
In an ideal world, the ip++ protocol would have been easier, not harder. BLog posts wouldn't be victim blaming, throwing around NAT64, 464XLAT, DNS64
DNS64 kills me. WHy is there a totally different service for ipv6? Isn't DNS just a key-value store? People put all types of crap into DNS, including, I believe, ipv6 addresses.
Why isn't there a DNS record type that basically lists both an ipv4 and ipv6 for a name, along with negotiation information? Might that make transition a lot easier? Maybe it does, but it isn't in this article.
Just ... all the same problematic attitudes, no progress on issues, my way or highway, and denial.
Many of the companies/organizations in the IPv6 space are some of the most friendly and easy to work with in the industry
I suspect you mean "e.g." rather than "i.e."
Other operating systems are bit of hit or miss"
My iPhone works, what's wrong with the rest of you for not doing this??!!
But in all seriousness, I think this will be a security nightmare for quite a while if there is some forced conversion to ipv6. I realize IPv6 wasn't created yesterday, but I assume it's got plenty of security holes waiting to be discovered until I see otherwise. The only way you are going to see it be used by end-users is if the various *nix distros roll out IPv4-less images. Same for Windows/etc. Otherwise you are begging for a security nightmare of epic proportions with software that is accidentally using the wrong stack by default, firewalls not filtering anything as expected, etc.
And who thinks it's a good idea to make all the things globally accessible? It's an internet of shit out there already, this would make it even worse.