Slightly related to the issue of remembering addresses, I think the main issue is with the fact that local nameservers are pretty much non-existent if you're not running OpenWrt or OpnSense. Which is shameful because the local nameserver is an amazing quality of life tool.
Also the fact that officially there are no local TLDs except for ".arpa" while browsers won't resolve one word domains without adding http://
And don't get me started on TLS certificates in local networks... (although dns01 saves the day)
Well, there is Punycode, which, if I understand correctly, is a layer before DNS, which translates a Unicode string into a DNS-compatible ASCII string.
I don't actually recommend using that, though. Every so often, the ugly ASCII string shows up in places, because Punycode translation isn't implemented there. Certainly increases administration complexity.
Yeah I've heard about punycode. Personally, I'm well against it because it puts down non-MURRICAN English domain names as second-class citizens on the internet. If I have a website about Copiapó, a perfectly legal town, there's no good reason why the domain name should not be copiapó.cl rather than copiap-xcwhngoingohi4oleleiyho42yt4ptg4ht4.cl, making it look "suspect" and "malware-y".
There were quite some complains back in the time about Firefox choosing not to "flag" internationalized names as potentially dangerous, and pretty much all those complaints that I know of likely came from English speakers who simply can't understand other countries in the world even can have different alphabets.
I mean, there is some legitimate concerns. For example, in theory, someone could register a domain "αpple.com" and use that to send phishing mails. That "α" is an alpha. The more alphabets and letter variants you allow, the more lookalikes there will be.
But yeah, in practice, domain registrars check that you're not registering such a lookalike domain and then that's not really a problem, as far as I'm aware.
I would love to start using ipv6 but my ISP decided that their devices won't support prefix delegation because "nobody uses ipv6 and nothing works with it"
IPv6 = second system effect. It's way too complicated for what was needed and this complexity hinders its adoption. We don't need 100 ip addresses for every atom on the earth's surface and we never will.
They should have just added an octet to IPv4 and be done with it.
Every time there's a "just add an extra octet" argument, I feel some people are completely clueless about how hardware works.
Most hardware comes with 32-bit or 64-bit registers. (Recall that IPv6 came out just a year before the Nintendo 64.) By adding only an extra octet, thus having 40 bits for addressing, you are wasting 24 bits of a 64-bit register. Or wasting 24 bits of a 32-bit register pair. Either way, this is inefficient.
And there's also the fact that the modern internet is actually reaching the upper limits of a hypothetical 64-bit IPv5: https://lemmy.world/comment/10727792. Do we want to spend yet another two decades just to transition to a newer protocol?
You're not "wasting" them if you just don't need the extra bits, Are you wasting a 32-bit integer if your program only ever counts up to 1000000?
Even so when you do start to need them, you can gradually make the other bits available in the form of more octets. Like you can just define it as a.b.c.d.e = 0.a.b.c.d.e = 0.0.a.b.c.d.e = 0.0.0.a.b.c.d.e
Recall that IPv6 came out just a year before the Nintendo 64
If you're worried about wasting registers it makes even less sense to switch from a 32-bit addressing space to a 128-bit one in one go.
Anyway, your explanation is a perfect example of "second system effect" at work. You get all caught up in the mistakes of the first system, in casu the lack of addressing bits, and then you go all out to correct those mistakes for your second system, giving it all the bits humanity could ever need before the heat death of the universe, while ignoring the real world implications of your choices. And now you are surprised that nobody wants to use your 128-bit abomination.
You're not "wasting" them if you just don't need the extra bits
We are talking about addresses, not counters. An inherently hierarchical one at that (i.e. it goes from top to bottom using up all bits). If you don't use the bits you are actually wasting them.
you can gradually make the other bits available in the form of more octets
So why didn't we make other bits available for IPv4 gradually? Yeah, same issue as that: Forwards compatibility. If you meant that this "IPv5" standard should specify compulsory 64-bit support from the very beginning, then why are you arbitrarily restricting the use of some bits in the first place?
If you're worried about wasting registers it makes even less sense to switch from a 32-bit addressing space to a 128-bit one in one go
We are talking about addresses, not counters. An inherently hierarchical one at that. If you don’t use the bits you are actually wasting them.
Bullshit.
I have a 64-bit computer, it can address up to 18.4 exabytes, but my computer only has 32GB, so I will never use the vast majority that address space. Am I "wasting" it?
All the 128 bits are used in IPv6. ;)
Yes they are all "used" but you don't need them. We are not using 2^128 ip addresses in the world. In your own terminology: you are using 4 registers for a 2 register problem. That is much more wasteful in terms of hardware than using 40 bits to represent an ip address and wasting 24 bits.
I have a 64-bit computer, it can address up to 18.4 exabytes, but my computer only has 32GB, so I will never use the vast majority that address space. Am I "wasting" it?
You are using the addressing bits in the form of virtual memory. Right now. Unless you run a unikernel system, then in that case you could be right, but I doubt it.
Anyway, this is apples and oranges. IP addresses are hierarchical by design (so you have subnets of subnets of subnets of ...), memory addresses are flat for the most part, minus some x86 shenanigans.
Yes they are all "used" but you don't need them. We are not using 2^128 ip addresses in the world.
But we do need them! The last 64 bits of your IPv6 addresses are randomized for privacy purposes, it's either that or your MAC address is used for them. We may not be using those addresses simultaneously but they certainly are used.
Despite that, there still are plenty of empty spaces in IPv6, that's true. But they will still be used in the future should the opportunity arise. Any "wastage" is artificial, not a built-in deficiency of the protocol. Whereas if we restricted the space to 40 bits, there will be 24 bits wasted forever no matter how.
That why we should adopt my ipv12. Its three levels of addresses rach 512 bit longs. One for host one for network and one what ever the heel else need. Planet that's it we asogn each planet a 512 bit address
And it took a lot of hard work by a lot of people to adopt new date standards to avoid that problem. Now it's time to adopt new IP standards, and it's going to take a lot of hard work by a lot of people.
I felt dirty! and broke so much shit when i had to implement NAT on networks in the mid 90's. Nowdays with ipv6 and getting rid of NAT is much more liberating. The difference is staggering!
you do not need NAT any longer, firewall is the security, just like on ipv4, just less obscurity.
you do not need dns views, to workaround NAT any more
you do not need hairpin NAT to workaround NAT any more
you do not need to renumber to resize a network. they are always /64, and the answer to how many hosts can it fit is: ALL of them!
many ALG's will be unnecessary since there is not NAT.
vpn's are easier, since it can be the same address both inside and outside the vpn, the firewall (or host even) enforces the encryption.
vpn's are MUCH easier since you will have less rfc1918 collisions due to some other network using the rfc1918 of the vpn's network
vpn's are MUCH MUCH easier since you will have less rfc1918 collisions due to you using the rfc1918 of the vpn partner network, to 1:1 nat a previous vpn network you collided with some months ago... ARGH!!!
vpn are generally less required, heck i swear 95% of the time the VPN are just to workaround the NAT problem and the data is pointlessly double or triple encrypted.
you can make more granular firewall rules (eg the spesific host, or network of the source address, instead of the whole enterprise's public ip) this is real tangible improved security, where any random machine in a network you do not control. do not automatically have openings into your own network.
firewall objects can if it is suited easily use and depend on FQDN DNS objects when allowing traffic. reducing the need of coordinating firewall object ip address changes between 15 companies.
firewall rules are easier, more readable, and much more predictable how they will work. All the hairpin nat, public to private nat, private to public nat for a thing that need a different public ip, 1:1 nat for a separate zone, NAT to a vpn or 50 (where 10 of them are 1:1 nat due to collisions, making you require 4 dns views of the same ip space!! ) very quickly gets messy and unreadable. this is probably the largest security benefit. just to reduce the complexity.
much easier to get people to use dns, since nobody wants to remember ipv6 addresses :D
nibbles in the ipv6 address can have meanings you assign to them, making the networks and structure both easy to remember and logically structured.
aggregating routes becomes very easy if you design your network that way.
firewall policies can become easier if you design your network that way.
your routing tables is leaner and easier, and of a better consistency. We have 1 large public ipv6 prefix, but 25ish ipv4 prefixes of all kinds of various sizes.
no need to spend $$ to buy even more ipv4 prefixes.
no need to have spent hundreds of $$ on a new ipv4 prefix only to be unable to use them for over a year because you need to sanitize the addresses from all the reputation filters. and constantly hound geo ip database providers to update the new country of the prefix. (i am bitter,, can you tell..)
did i mention no need to renumber since you need to grow the /24 to /23 due to to many hosts in a network ?
did i mention no need to renumber 2 /24's to /25's to make space for that larger /23.
you do not even need any ipv4 addresses any more, use a public NAT64 service, for outgoing. and for incoming just use one of the many free public ipv4 to ipv6 proxies for your services online. for a homelab i really like http://v4-frontend.netiter.com/ (go support them) But most large business l networks use cloudflare, or akamai
since you do not need your ipv4 address space any more, you can ~~sell them for a profit $$$ ~~ return them to the RIR and give some address space to one of the thousands of companies struggling because they do not have any IPv4 : https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list/
much lower latency on ipv6, since you do not go across a cloud based ipv4 to ipv6 proxy in order to reach the service ;)
Now the greatest and best effect of ipv6 is none of the above. It is that with ipv6 we have a slim hope of reclaiming some of what made the Internet GREAT in the first place. When we all stood on equal footing. Anyone could host their own service. Now we are all vassals of the large companies that have made the common person into a CGNAT4444 using consumer mindlessly lapping up what the large company providers sees fit to provide us. with no way to even try to be a real and true part of the Internet. Fight the companies that want to make you a eyeball in their statistic, Set up your own IPv6 service on the Internet today !
i got like a third through it before scrolling to the bottom to see how long it was. omg! should be the canonical example of the opposite of a shitpost ha
But DNS rarely break. The meme about it beeing DNS's fault is more often then not just a symptom of the complexity of IPv4 NAT problem.
If i should guesstimate i think atleast 95% of the dns issues i have ever seen, are just confusion of what dns views they are in. confusion of inside and outside nat records. And forgetting to configure the inside when doing the outside or vice verca. DNS is very robust and stable when you can get rid of that complexity.
That beeing said, there are people that insist on obscurity beeing security (sigh) and want to keep doing dns views when using IPv6. But even then things are much easier when the result would be the same in either view.
I broke DNS plenty of times in my homelab independent from NAT. In the last few months:
didn't turn off DNS server in a wifi router set up as bridged access point
dnsmasq failing to start because I removed an interface
dnsmasq failing to start because the kernel/udev didn't rename an interface on time
dnsmasq failing to start because hostapd error didn't set proper interface settings
forgot to remove static DNS entries in /etc/hosts used for testing
forgot to remove DNS entries from /etc/resolve.conf after visiting a friend and working on his setup
Yes, most of them is my dumb ass making mistakes, but in the end it's something that constantly breaks and it helps knowing the IP addresses of my servers and routers.
Aditionally, obscurity is a security helper. The problem is relying only on obscurity. But if I have proper firewall rules in place and strong usernames and passwords I still prefer if you don't even know the IP addresses of my servers on top of that (in case I break some of the other security layers).
There's one practical thing. Routers have had years to optimize IPv4 routing, which has to be redone for IPv6. Same with networking stacks in general.
In theory, IPv6 should be faster by not having to do bullshit like CGNAT. There's every reason to think it'll match that advantage if we just make it happen.
In the USA, around 50% of Google traffic and 60% of Facebook traffic goes over IPv6. The largest mobile carriers in the US are nearly entirely IPv6-only too (customers don't get an IPv4 address, just an IPv6 one), using 464XLAT to connect to legacy IPv4-only servers. I'm sure we'd know if routing with IPv6 was slower. Google's data actually shows 10ms lower latency over IPv6: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
That is not how it works. You can have a home network on ipv6. And it can reach all of ipv4 via nat ( just like ipv4 do today). A net with only ipv4 can not reach any ipv6 without a proxy that terminst the v4 connection and make a new v6 connection. since ipv6 is backwards compatible. But ipv4 is naturally not forwards compatible.
Also it is the default deny of the stateful firewall that always coexist with NAT, since NAT depends on that state, that is the security in a NAT router.
That default deny is not in any way dependant on the NAT part.
If there is a ipv6 service online. That you want to reach from a v4 only client. You can set up a fixed 1:1 nat on your firewall where you define a fake internal ipv4 address -> destination NAT onto the public ipv6 address of the service. And SRC NAT64 embed your clients internal v4 into the source ipv6 for the return traffic.
And provide a internal dns view A record pointing to the fake internal ip record. It would work, but does not scale very well. Since you would have to set this up for every ipv6 ip.
A better solution would be to use a dualstack SOCKS5 proxy with dns forwarding where the client would use the IPv6 of the proxy for the connection. But that does not use NAT tho.
Yeah, here in Russia the ISPs and IT infrastructure guys seem to be treating IPv6 like it has cooties. I can't find an article (and it'd be in russian anyway) but as far back as 2022, if you get IPv6 you can expect a variety of issues with it, ranging from "you need to reboot your router every once in a while" to "you technically have v6 but good luck actually browsing v6 internet".
And of course, why would they give you a stable IP when they can charge for it :T. At least it's only a third the price of a stable IPv4.
My current ISP technically provides v6 according to their site - but my connection doesn't have it, and since there's nothing about it in the years-old contract, I'd need to redo that if I want to complain.
There are usually plenty of choices for ISPs here, actually. But switching between them isn't likely to give me IPv6 since either they share a magistral or the hardware is just plain old. That, and IPv6 is just not a thing anyone markets.
...and with the current fuckery going on, I doubt many of them have budget for big upgrades. Or maybe even access to hardware to buy.
IPv6 is already backwards compatible though. There's a /96 of the IPv6 space (i.e. 32 bit addresses) specifically for tunneling IPv4 traffic, and existing applications and IPv4 servers Just Work™ on IPv6 only networks, assuming the host operating system and routing infrastructure know about the 6to4 protocol and are willing to play ball.
Oh nice. Does your system FINALLY provide enough addreses for every Planck volume in the observable universe? It’s been frickin amateur hour, this internet thing.
No, because there's use cases for systems that aren't connected to the internet. Also, public IPs can be dynamic, so you might not want to rely on them internally.
If you want to be able to write practically anything on mobile, including ≠, ≈, ‰, ℝ etc., have a look at Unexpected keyboard. No spellcheck or autocomplete, though.
Because 48 bits over 32 bits does not really solve the problems with ip4. 128 bits basically gives one ip4 address space to each square meter of earth. Ip6 also drops all the unused and silly parts of ip4 too.
I can see that, but surely there wouldn't be much difference matching the first 4bits (0x2XXX, 0xfXXX) vs the first 16 (0x0001)?
0:: is presumably all for loopback-type stuff, but I don't see a reason not to use 1:: through 1fff:: and they would be much easier to type/remember/validate for public DNS servers which are needed before name resolution is available.
IPv6 is big enough to give 10 billion unique addresses for every grain of sand on earth and still have some left over. Just in case we need to, I guess.
It's great that the address space is so large. When designing a new system, you want to make sure it'll hopefully never encounter the same issue as the old system, to ensure you don't have to migrate yet again.
Sure. But the IPv6 implementation is a bit like if we went "you know the y2038 problem of 32 bit numbers, and how goin under 1970 is sometimes hard? Lets solve it by making it start from the big bang and store time as a 256 bit integer so we don't run out until year 3.1 x 10^69".
IPv6 is big enough for 340,282,366,920,938,463,463,374,607,431,768,211,456 unique addresses. Are we expecting to create an universe consuming army of exponentially replicating paper clip converting robots that each need an IPv6 address or something?
Having a large range has a number of benefits though. Companies that have dozens of IPv4 ranges may be fine with a single IPv6 range, which simplifies routing rules.
A lot of features in IPv6 take advantage of the fact that networks have at least a /64 range (at least if they're built correctly according to RFC4291 and newer specs). SLAAC is a major one: Devices can auto-configure IP addresses without having to use something like a stateful DHCP server.
I think it’s worth taking the time to learn IPv6 property. If you have a good understanding of IPv4 it shouldn’t take you more than an afternoon.
Eliminating NAT and just using firewall rules (ie what NAT does behind your back) is incredibly freeing.
I don’t get people complaining about typing out IPs. I like to give all of my clients full FQDNs but you don’t have to. Just using mDNS would be enough to avoid typing a bunch of numbers.
Maybe I have Stockholm Syndrome, but I like NAT. It’s like, due to the flaws of IPv4 we basically accidentally get subnets segmented off, no listening ports, have to explicitly configure port forwarding to be able to listen for connections, which kinda implies you know what you’re doing (ssshh don’t talk about UPnP). Accidental security of a default deny policy even without any firewalls configured. Haha. I’m still getting into this stuff though, please feel free to enlighten me
Anything connected to an untrusted network should have a firewall, doesn't matter if it's IPv4 or IPv6.
There's functionally no difference between NAT on IPv4 or directly allowing ports on IPv6, they both are deny by default and require explicit forwarding. Subnetting is also still a thing on IPv6.
If anything, IPv6 is more secure because it's impossible to do a full network scan. My ISP assigned 4,722,366,482,869,645,213,696 addresses just to me. Good luck finding the used ones.
With IPv4 if you spin up a new service on a common port it usually gets detected within 24h nowadays.
Ahh, woah, I never thought about the huge address space would affect network scans and such.
With NAT on IPv4 I set up port forwarding at my router. Where would I set up the IPv6 equivalent?
I guess assumptions I have at the moment are that my router is a designated appliance for networking concerns and doing all the config there makes sense, and secondly any client device to be possibly misconfigured. Or worse, it was properly configured by me but then the OS vendor pushed an update and now it’s misconfigured again.
With NAT on IPv4 I set up port forwarding at my router. Where would I set up the IPv6 equivalent?
The same thing, except for the router translating 123.123.123.123 to 192.168.0.250 it will directly route abcd:abcd::beef to abcd:abcd::beef.
Assuming you have multiple hosts in your IPv6 network you can simply add "port forwardings" for each of them. Which is another advantage for IPv6, you can port forward the same port multiple times for each of your hosts.
I guess assumptions I have at the moment are that my router is a designated appliance for networking concerns and doing all the config there makes sense, and secondly any client device to be possibly misconfigured. Or worse, it was properly configured by me but then the OS vendor pushed an update and now it’s misconfigured again.
That still holds true, the router/firewall has absolute control over what goes in and out of the network on which ports and for which hosts. I would never expose a client directly to the internet, doesn't matter if IPv4 or IPv6. Even servers are not directly exposed, they still go through firewalls.
I wouldn't rely on the size of the address space to provide security. It's possible to find hosts through methods other than brute force scanning. I remember seeing a talk from a conference (CCC? DEF CON? I can't remember) where they were able to find hosts in government IPv6 address space (might have been DOD?) through stuff like certificate transparency logs and other DNS side channels.
Will take a look at the talk once I get time, thanks. If you can find the original one you were talking about, please link.
For servers, there is some truth that the address space does not provide much benefit since the addressing of them is predictable most of the time.
However, it is a huge win in security for private internet. Thanks to the privacy extension, those IPs are not just generated completely random, they also rotate regularily.
It should not be the sole source of security but it definitely adds to it if done right.
Could a hypothetical attacker not just get you to visit a webpage, or an image embedded in another, or even a speculatively loaded URL by your browser. Then from the v6 address of the connection, directly attack that address hoping for a misconfiguration of your router (which is probable, as most of them are in the dumbest ways)
Vs v4, where the attacker just sees either your routers IP address (and then has to hope the router has a vulnerability or a port forward) or increasingly gets the IP address of the CGNAT block which might have another 1000 routers behind it.
Unless you’re aggressively rotating through your v6 address space, you’ve now given advertisers and data brokers a pretty accurate unique identifier of you. A much more prevalent “attack” vector.
There is this notion that IPv6 exposes any host directly to the internet, which is not correct. When the client IP is attacked "directly" the attacker still talks to the router responsible for your network first and foremost.
While a misconfiguration on the router is possible, the same is possible on IPv4. In fact, it's even a "feature" in many consumer routers called "DMZ host", which exposes all ports to a single host.
Which is obviously a security nightmare in both IPv4 and IPv6.
Just as CGNAT is a thing on IPv4, you can have as many firewalls behind one another as you want. Just because the target IP always is the same does not mean it suddenly is less secure than if the IP gets "NATted" 4 times between routers. It actually makes errors more likely because diagnosing and configuring is much harder in that environment.
Unless you’re aggressively rotating through your v6 address space, you’ve now given advertisers and data brokers a pretty accurate unique identifier of you. A much more prevalent “attack” vector.
That is what the privacy extension was created for, with it enabled it rotates IP addresses pretty regularily, there are much better ways to keep track of users than their IP addresses. Many implementations of the privacy extension still have lots of issues with times that are too long or with it not even enabled by default.
Hopefully that will get better when IPv6 becomes the default after the heat death of the universe.
Since you can have multiple IPv6 addresses on one machine, you can use a rotating address for all outbound connections and a permanent address for inbound connections. If you visit a malicious website that tries to attack the IP that visits it, there will be no ports open. They would have to scan billions of addresses to find the permanent address. All of that scanning would be easily detected and blocked by an IDS.
There is this notion that IPv6 exposes any host directly to the internet, which is not correct.
TP-Link routers used to actually do this. They didn't have an IPv6 firewall at all. In fact they didn't add an IPv6 firewall to their "enterprise-focused" 10Gbps router (ER8411) until October 2023.
That and the IPv6 address on client systems will periodically rotate (privacy extensions), so the IPs used today won't necessarily be the ones used tomorrow.
(you can disable that of course, and it's usually disabled by default on server-focused OSes)
I don’t think you have Stockholm syndrome. You just like what you already understand well. It’s a normal part of the human condition.
All those features of nat also work with IPV6 with no nat in the exact same way. When I want to open up a port I just make a new firewall rule. Plus you get the advantages of being able to address the ach host behind the firewall. It’s a huge win with no losses.
Instead of nat and port forwards that rewrite, your firewall is set to only forward specific traffic, exactly how'd you'd configure outbound forwarding on a nat network (but opposite directions)
Every time I see a defense of IPv4 and NAT, I think back to the days of trying to get myself and my roommate to play C&C: Generals together online, with a 2v2 game, with one of us hosting. Getting just the right combination of port forwarding working was more effort than us playing C&C: Red Alert on dial up when we both lived at home.
With IPv6, the answer is to open incoming traffic on the port(s) to the host machine (or just both since the other guy is might host next time). With IPv4, we have to have a conversation about port forwarding and possibly hairpin routes on top of that. This isn't a gate for people "who know what they're doing", it's just a bunch of extra bullshit to deal with.
