IPv6 Is a Nightmare
teknikaldomain.me
teknikaldomain.me
The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well.
Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address):
When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?
I still have to mess with the firewall to open ports, not much different from doing IPv4 NAT as my router software (pfSense) automatically creates firewall rules tracking the port mapping. Except it is worse, because my firewall software don't track IPv6 changes so breaks whenever the device gets a new IP (say new prefix).
When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.
IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Yeah I guess I could just use the local address space but what does that really bring over the IPv4 that I know?
And then there's the software that just doesn't follow the times. My router just doesn't handle getting a new prefix. Yeah OK the initial IPv6 wet dream was for an eternal prefix. But clearly that's been unrealistic for quite some time, and sadly not all software has caught up.
I will admit that some of it is probably down to me learning more. But I struggle to find the motivation. There's no "killer app", just a lot of pain so far.
Presumably because you configured the forwarding on the router? I mean, that should still be possible, right? Set up a name for the routers IP, and have it forward the connections statically.
IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12.
Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own. My Synology is nas.local, Linux boxes are reachable using their configured hostname, even my elderly printer shows up as vigor2.local.
If you mean NAT, then what does that buy me over what I got? If you don't mean NAT then how would that work?
> Or just use the hostname?
Right, but that requires the DNS to register the host names, and for it to respond. Or since you mention .local I guess you mean mDNS, which requires a service to run on each device and seems to be hit and miss at least for me (I just tried, several of my devices do not respond).
Nothing. But you can just keep doing what you are doing now, even with IPv6. That's what I meant.
I just tried, several of my devices do not respond
Ok. Like I said, it Just Works for me.
Do you mean keep using IPv4 or use NAT with IPv6? If the former then well, so much for that IPv6 future. If you mean the latter, the whole point of IPv6 was death to NAT no?
That highly depends on what router you have. For mine, the actual suffix is Speedport_W_123V_2_34_000, which is complex and/or invalid enough that a lot of software refuses to resolve it.
Prefixes shouldn't change, that's the whole point. And you can use fixed addresses for IPv6 just as you had for IPv4.
> each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.
Sure, but if you're doing that at an industrial size, you should consider buying/renting a fixed IP (range). You don't do production at home now, do you?
> IPv6 on the LAN is quite a pita due to the massive "random" prefix
You probably mean suffix? Anyway, your systems can be configured to either not have that random suffix, and they can also be configured to still reply on their fixed address (the one that's not random). Maybe try using the fe80:: address if your prefix does change.
Well that's not the world I live in. And even if they didn't by default, I might want to change my prefix from a privacy point of view.
> You don't do production at home now, do you?
Not for paying customers, but I have plenty of services that I would like myself, my gf, my buddy etc to be able to access from the internet.
> You probably mean suffix?
No I meant the prefix, see above.
Tell that to my residential ISP!
They shouldn't, but they change all the time. I gave up on Ipv6 in my last house because of this reason: my prefixes were changing every few weeks. In my new household, my ISP doesn't even off IPv6.
If only the software worked with it, which it doesn't for me.
My home router does something even better out of the box: Every device that's hostname.local or hostname.my.router locally is also globally resolvable through hostname.myusername.routervendor.com.
This is basically DnyDNS at the router level, rather than the device level (which has many downsides as you describe), and it's been a game changer for my IPv6 home use.
So I guess I either have to switch (to who?) or I set up some alias and run my own bind (another service to admin, yay). Or am I missing something?
I find it super frustrating that most dynamic DNS providers use their own custom API rather than just using the update mechanism that's in the protocol itself. That said, if they support v6 then you can probably use them by installing their update client on each machine that you want a hostname for. It just won't integrate with pfsense.
- There's no caching DNS and I can't set static DNS entries for IPv6
- There's no way to use DHCPv6 to give out addresses.
- Because of lack of DHCPv6, there's not way to give out static addresses to devices on LAN and manage them centrally.
- Because of lack of DHCPv6 and static addressing, it's really annoying to configure firewall to allow outside access to services on LAN devices (on IPv4 you either have static entries or NAT-PMP).
- There's no fasttrack functionality so IPv6 traffic will max out CPU and prevent me from fully using my Gbit fiber line.
- There's no UI way of announcing DNS to clients via DHCPv6 - you can set some option amanually but it's far from setting a nice UI entry like for DNS.
And yes, those are all holes in my routers Firmware, but it's been YEARS and they're still lacking. Other SOHO routers aren't faring any better, I haven't seen these features configurable on any of them.
I have a LAN which has a PiHole and a Synology NAS at home + some entertainment devices. Configuring IPv6 to allow access to same services as IPv4 from WAN via public DNS has been practically impossible, undocumented and huge pain. For pretty much no gain and loss of bandwidth.
I've never seen this features out of the box on SOHO equipment like ASUS routers, TP-Links, FritzBoxes, Apple routers and other equipment that actually ends up in peoples homes. And again, we're YEARS after the standard and there still doesn't seem to be feature parity between the two stadards on even basic home equipment.
As for routers with random vendor firmware, I'm not familiar enough with all of the vendors out there to give an authoritative answer but I've seen or helped with plenty of routers that support many of the things on your list.
It's a shiny toy to play with. However, it has so many weird bugs that never get addressed that it's just not worth the grief.
Why can't the wired ping the wireless but the wireless can ping the wired? Why can I connect every device except my Samsung phone? Why is my throughput so much worse than the manufacturer firmware? Why are the LED's doing weird things that correspond to nothing useful?
I've never even tried IPv6 on a <Foo>WRT because it's handling of basic IPv4 stuff is so dreadful.
(Please don't read this is as dig on the <Foo>WRT developers--they're doing their best. However, the sheer variety of platforms, the lack of documentation, and the small number of developers simply creates an impossible situation.)
This works for both IPv4 and IPv6.
As far as I remember, OpenWRT's default setup (probably using dnsmasq?) provides something very similar.
It definitely supports at least the "client" side of it, i.e. resolving host names and discovering services (Chromecast is based on this, after all), and it looks like broadcasting services is supported as well: https://developer.android.com/training/connect-devices-wirel...
Interestingly, this is the primary reason it hasn't been adopted universally.
> The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad".
DHCP servers like dnsmasq can already serve lan hostnames even for ipv4.
"IPv4 is great as it is, I don't want to change"
They tried to do the same thing with IPv6, and nobody wanted to move over to it until the warning "We're running out of IPv4 addresses".
HE.net works and was relatively nice experience to learn how IPv6 work, although both SixXS and HE you still had the disadvantages of tunneling like low speeds, outages etc.
It's nice to test if your application can work on IPv6, but you still won't get benefits of natively using it.
> "It's hard to memorize or type plain IPv6 addresses"
We should create a system to translate IPv6 address to a phrase in English or user language, which is easy to memorize and type. E.g. "hoards of sleepy beefs" is much easier to remember, dictate over phone, or type (maybe even with autocompletion), than raw IPv6 address.
IPv6 is designed for computers. Humans need an adapter.
The problem is that an ipv6 address is not something you can pronounce, recognize at a glance, or remember. All of these are unfortunately still things one has to do, despite there being name servers. The (proposed) solution is to have a 1:1 algorithm that translates an ipv6 address into a value that a human can work with.
If I'm troubleshooting an issue on an ipv6 network, and my colleague asks me for the IP of a machine, I have no choice but to either text it to him, or painfully, tediously and error-pronely spell it out.
In fact, "IPv6 sucks because it's not broken in the same ways as IPv4". NAT, for example, was only ever a hack to get around limited address space, and the fact that it 'hid' your internal network was an accidental side effect. People started architecting their networks around that, and now are annoyed that IPv6 isn't broken in the exact same way.
Saying that IPv4 gave you network privacy for free is like claiming that old-school single-line home phones were an advantage over personal cell phones because they gave you some amount of extra privacy 'for free'.
But I don't want mDNS
I feel like maybe firewall based security is a bit of an outdated model. It’s going to take a while to figure out how to secure our networks/devices well, but it feels like a model that pushes more of the configuration to the device will be more secure and more universal (since more and more devices will be LTE connected)
The model where you by default have access to everything inside the network if you can just get a connection behind the firewall never seemed all that great to me. If we can’t assume that any connection from the local network is authorized anymore, maybe it’ll push us to make servers/services more inherently secure, and accept/reject connections based on actually authenticating the user/device connecting to it. But then again, I’m not a professional so I may be wrong.
The notion I get from the article is that security becomes a huge problem when every node is exposed to almost every other node by design intent. That's why NAT is mentioned several times.
...which a lot of people haven't, because they falsely believe that NAT by itself is enough to stop all inbound connections to their network.
It's very very easy to replicate the filtering behaviour of NAT for situations where its being used that way. Simply block connections into the network that weren't initiated by clients in the network itself. Every stateful firewall can easily handle that and it doesn't come with the security loopholes of NAT.
- compute clusters / rendering farms: people pay for performance and aren't necessarily willing to sacrifice it for increased security (be it local firewall or SPECTRE mitigation) there
- engineering sub-divisions in large enterprises: its not unheard of that equipment in those is maintained by the engineers themselves (who are not necessarily well versed in network security matters and have other priorities) rather then the enterprise's IT team (this can coincide with the MS Windows / Unix schism)
However it's also true that ipv6 does not give many advantages to a team that already has a 10.x.y.0/24 inside the corporate network.
With IPv6 this is a non-issue.
I love NPT. Complex NAT over tunnels and shit is an absolute disaster. NPT makes everything easy to troubleshoot and enables many solutions that IPv4 just cannot even touch.
And also, if you really want IPv6, it's there. IPv6 works just fine with NAT if you believe that's best for you.
"I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. What's your alternative? Just run IPv4 forever? Ugh. Awful.
Bit of a straw-man argument here.
IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it.
IPv6 solves some real problems with IPv4, but also adds a lot of non-intuitive standards to an already complex system.
On your point about "NPT better than NAT, so IPv6 = superior!" - which I don't instinctively agree with, it's just different. The fact is, NAT still exists and will for a long time. It's so commonplace that almost every house and office in the modern world that has internet uses a NAT gateway. People generally understand what a LAN is and can differentiate between a LAN and a WAN (or "the internet"). Even high school kids can set up LAN parties with little difficulty.
Telling people that "Hey, all that stuff you've know about the internet, well, it's still going to exist, but also we are going to throw a new standard on top of it that is suuuuper non-intuitive to work with but it makes things awesomer because, just take my word for it!! If you don't like it, you're just closed minded" is extremely closed minded...
Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind"
IPv6 is awesome in many ways, but it comes with a lot of frustrations to work with. Which I believe the author covered pretty well.
IMO ipv6 would have gotten far more adoption had they used a different assignment scheme:
* Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142
* New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly.
In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today.
Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now.
Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.
In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network. Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough?
In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP. Compare this to the IPv4 case where each ISP will have hundreds of /24s. Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.
You can modify my proposal to have multiple 16-bit prefixes to the 32-bit range syntax, and from that /80 range you give ASs depending on size a /104, /96, or /88, or something in between. That would still leave plenty of room for the ASs to distribute addresses to customers. Maybe customers could get /8s or such, with the option for bigger customers to get larger assignments. NAT on the router could be enabled by default, reserving the range for devices which explicitly request a publicly reachable address. Usually in most networks that number should be small.
The thing with IPv6 is it very different than IPv4, as such how we use it should not be compared with IPv4.
My ISP gives /64 for CPE and the internal routing is very easily setuped. My devices in the hotspot has different IPv6 address, VMs have different IP address. The communication between the devices happen locally without any NAT.
Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.
This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.
And even if you don't do such measures, the rest of the address space won't be a "complete waste forever", one will just have to identify the implementations which have problems with these addresses and change them. It's a solvable technical task like any other.
> one will just have to identify the implementations which have problems with these addresses and change them
Isn't that what converting from IPv4 to IPv6 is? It's really hard.
No, it's not. It has been around, in production, for TWENTY YEARS. If you didn't learn about it when you were learning IPv4 you're either old and should already have enough experience to know that new things come up, or you should've listened when everyone told you that attending ITT wasn't a good idea.
"But MY company never deployed it!" Bad excuse. Your phone started using it years ago. If you're a network engineer and didn't realize that, nobody is going to feel bad for you.
Not intuitive? The same can be said about most technologies. Without real examples, this means little.
Can't phone a friend and give an IP address? I've literally never done this. We all use SMS, Messages, email, whatever, and anyone who does anything like run gaming servers knows about dynamic DNS services.
Come up with some better complaints, please.
Apparently it is if we are still having this conversation after "TWENTY YEARS".
Is there a particular reason that every aspect of your comment is toned with subversive rudeness and you made zero actual good points? Making snide comments about being "old" or how I "should've listened" and "no one is going to feel bad" really doesn't help anyone understand why IPv6 is all that great.
> Come up with some better complaints, please.
The author already listed several frustrations with the protocol. Feel free to read the article again if you'd like some examples.
Twenty years of poor adoption world-wide demonstrates its lack of easy integration. I don't need to argue this, you just did.
Also, mentioning dynamic DNS services at all in regards to trying to send an IP address to someone is yet another point to support why IPv6 is not an intuitive protocol to work with, even for something as simple as setting up a gaming server with a few friends.
This isn't down to the design of v6 though, it's down to two things: the design of v4, and human laziness.
v4 isn't forwards compatible with a larger address space, so there's no way to magically integrate a larger address space with existing v4 nodes. All of the possible ways to make cross-compatibility easier are already available in v6. Updating the internet's L3 protocol is simply a hard problem with no real shortcuts.
As for human laziness: v6 deployment didn't really start until 2013. Deployment was at 1% in 2013, and is at 30-35% today. People put it off until after the RIRs started running out of addresses to allocate, even at the cost of paying extra money to keep v4 working. This isn't a technology problem, it's a human problem.
> even for something as simple as setting up a gaming server with a few friends.
This isn't even possible in v4 for a lot of people today, due to v4 exhaustion. It's going to become less and less possible over time, as v4 exhaustion gets ever more acute. Even if we took at face value your claims that v6 is unintuitive (which I would disagree with), surely it's better to be able to set a gaming server up with v6 than to not be able to do it at all?
The fact that IPv4 is reasonably usable by itself and IPv6 is not (it basically requires DNS) is a completely valid point against IPv6. Also, the joke about "it's always DNS" is there for a reason; depending on that makes it less resilient.
But I hate my phone.
You're both using computers at the time. Why not send a message and copy/paste the address instead?
Sure, 10.0.0.1 is convenient, but my router changed from 10.0.0.1 to 10.1.1.1 with a firmware update. Not relying on remembering that IP would've been better.
Also remembering IP address does not get you so far. the last company I worked at had a spreadsheet of IPv4 address of the Jenkins boxes that we managed.
Try telling your friend a URL over the phone! They were designed to be human readable but they're usually far more impossible than IPv6 addresses.
If you're going to complain about something, you should have an alternative solution in mind. Otherwise it might be possible that there really is no better way and nature just hates humans. Then your real complaint might be that humans are bad at long strings or there are too many devices on the internet or too many people in the world or whatever.
But also NPT is so much better. And/or enables several architectures with so much easier topology.
> Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade
Why would you not use DNS?
And even more: why would you use a phone? People don't call, anymore.
See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand.
My personal opinion is that complexity in computing will evventually kill everything: security dies first, innovation comes last.
Sorry for this rant. I assume the IPv6 design was carefully crafted by gifted and highly skilled people. We'll use it anyway, some day :-)
The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well.
In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases.
The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc.
And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)
The comparison of HTTP1 vs. HTTP2 is in fact only valid on a level of complexity.
As an hobbyist, I'm actually quite excited of finally abandoning NAT and being able to reach my Raspberry at home from anywhere in the net. This dream is still far away, given that many places don't have access to IPv6 (without a tunnel).
Default global reachability is definitely not advisable, but having the option for individual devices and/or ports is just great, and doubly so with not having to resort to using non-standard ports.
I've always despised the pattern of having device 1's SSH exposed on port 22001, device 2 on 22002 etc., especially for protocols/applications not supporting SRV records.
And for many client to client use cases these days, port forwarding isn't even necessary: UDP hole punching is just a breeze with IPv6 and works consistently and reliably without any STUN/ICE guesswork, as long as UDP is not outright blocked.
If a bug is found in a non-NAT firewall that prevents it from blocking a packet for some reason, you have a routable address from the outside that you can send packets to. If a bug is found in a NAT firewall that prevents it from blocking a packet, it's very difficult to tell the router which internal address to route the packet to since the IP header only holds 1 "TO" address and by necessity, that's the public address of the NAT firewall.
There are of course some edge cases (double-headers, being on the same L2 network as the firewall, etc), but for most cases, the fact that the internal network is on IP addresses that won't route to their public interface (the NAT firewall) is in and of itself a layer of protection.
Personally, I think this trade-off is worth it in the long run, but it's simply not correct to claim they are equivalent when router firmware bugs are still discovered on a regular basis and consumer network equipment rarely gets security updates (and it's even rarer for consumers to install them).
If you approach IPv6 as "oh so this is how IPv6 does X" or "this is the IPv6 name for Y" then it's going to be confusing. It's not just IPv4 with bigger addresses, its a new approach to addressing and sending information between endpoints.
That's not really the real internet, though. How much did you learn about MPLS and BGP and ISIS from working at home as a hobbyist? I didn't know much of anything about that stuff before I started programming routers and switches (real switches - like the ones your ISP uses).
IPv6 is so ridiculously similar to IPv4, it's a bit funny reading about people complaining about how different they are. Seriously - go to wikipedia and read about something like ATM and how crazy different that is. Compared to the stuff you actually need to know and should know about if you're a network admin, IPv6 is easy-peasy.
It's even sillier in Windows Explorer where UNC IPv6 paths are the IPv6 address "with the ':' characters replaced by '-' characters followed by the '.ipv6-literal.net' string": https://docs.microsoft.com/en-us/windows/win32/api/winnetwk/...
For example, I mount my NAS as "\\fd13-c001-7232-1-13--36.ipv6-literal.net"! https://i.imgur.com/waLJRFf.png
The same is true for all modern computing. Intels CPU has several prefetch queues, some with more than 200 entries. Who can handle this? Well, not even Intel's engineers as Meltdown and the later discoveries have shown. Have you looked how a GPU works? Recently there has been discussion that Kubernetes depends on 200 libraries. The list goes on and on.
That said, he might or might not have some point in the address translation section. But not being an expert in IPv6, he has wasted his trust by useless complaining before he gets to the possible beef.
IPv6 hosts have lots of addresses. v4 needs to scrimp, v6 doesn't.
Take every known star in the sky today, give each of them a full IPv4-sized /32 address space, and you'd still have IPv6 space left over.
No need to scrimp, indeed!
I calculated the number of IPv6 addresses per square meter of the earth's surface and got a similarly large number.
Does every cold virus need an IP address, no. But on the other hand it might make sense to give every planet and asteroid in the solar system one.
The central concept in v4 is an interface, which has a 32-bit address and of which a host tends to have one. The central concept in v6 is a network, which has a 64-bit address and which may be populated by one or many hosts.
The number of /64 network addresses per m² of the planet is also a large number, I'm sure. (That it is a large number is intentional, in order to permit simple routing even when that simplicity leads to lower addressing density.) But counting that is honest in a way which counting /128 addresses isn't.
Yeah it's the weakest critique against IPv6. There's plenty to complain about, this is just pointless.
Yes it is.
Is this a beneficial trend? If not, is it not worthy of critique?
But losing that many words about addresses not to be used by humans anyway seems out of proportion for relevant critique.
As an example, if an interface’s MAC address was `01:23:45:67:89:ab`, the lower 64 bits of the SLAAC assignment (the “host” part) results in an IPv6 address of `:123:45ff:fe67:89ab` (the extra `ff:fe` bytes are constant, making it more obvious the surrounding bytes are likely a MAC address). This has huge implications to privacy, since even as you roam and change networks (and thus the upper part of the address changes), the lower 64-bits stay exactly the same, making it easy to “follow” a device from session to session and site to site.
This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis.
A great thing about this feature is that these random, private addresses timeout and become “deprecated” (and a new random address gets assigned to the interface and used for new connections), making it harder for third-parties to track connections over the long-term.
Unfortunately, address privacy is a SLAAC thing, so if you want the benefit of registering a device on your network (via DHCPv6, so you can actually correlate IPv6 traffic on your network to a device), you don’t get the benefits of SLAAC’s privacy extensions.
That's not really a problem with ipv6 so much as a problem with defaults. Nothing stops distributions from enabling the privacy extensions by default, and I'm sure many already do.
DHCPv6 does actually implement temporary addresses too. Support for that is legitimately rare though.
There used to be a bug though that it only works for hotplugged interface cards, not for coldplugged ones (present during boot already). Don't know when it got fixed exactly, but I have one Ubuntu 16.04 machine (even with HWE kernel) and it still has the bug.
"But that's so hacky", you say. "We need to fix the old standard." This is what Intel said with its Intel 64 Itanium processor. Break with the old instruction set and make it better. AMD came out with Opteron[1], a hacky extension of the x86 ISA but for 64 bit. Backwards compatible. Swept the market. It's why your binaries are compiled to "amd64" now.
Yes, IPv4 has quirks, and those quirks are well understood and lots of code exists now to deal with them. Let's not find out all the quirks of a new system the hard way for seemingly little benefit.
I'm sure Dart would be absolutely over the moon to have 33% adoption.[0]
You can't just slap some zeros onto the start of a v4 address and come up with a bigger address space that somehow works with v4 networking code. The problem isn't backwards compatibility, it's forwards compatibility: v4 isn't forwards compatible with larger address spaces, so it's not possible to do what you're suggesting.
There are various ways of making a bigger address space with backwards compatibility to v4 though -- and all of the ways which are actually possible and work are already implemented by v6.
The majority of packets on the internet pass through fairly hard-coded switching chips that probably couldn't be updated to handle this. They can handle IPv6, though.
If it were made truly backwards compatible
It can't be made backward compatible. Every switch on the internet needs to understand your new extended address scheme otherwise they'll send your packets to a dead-zone somewhere in Uzbekistan. Backward compatibility was never an option. As soon as you add new bits to the address, old routers won't send them to the right place.
What actually matters is the packet format.
You cannot make it backwards compatible because it is impossible to expand the IP header's address space without it becoming unparseable to existing network equipment.
"Ah" you say, "but we could put the extra bits after the end of what is basically an IPv4 packet"
Well no, you can't do that either because it would require executing a global seizure of existing IPv4 space and reorganising the entirety of the IPv4 internet into a hierarchical manner where your "IPv7" extra bits can be processed prior to the final destination.
IPv6 works fine and is well-designed. Hardware and software implementations have been in-production for decades now; Google alone see 30% of their total traffic over v6.
Fundamentally, support of any network protocol is subject to Internet participants having compatible kit; x86-64 wasn't immune to this; if you didn't buy the chips, you couldn't use the software. The reason it actually won is that the Itanium architecture was completely different and resorted to translating x86 instructions which, unsurprisingly, ran like treacle and never made it to the consumer market either.
The idea of inventing yet another internet protocol is patently absurd when you consider it would require yet more upgrades across the globe to hardware and software in order to support it.
"The reviewers generally felt that the most important thing that TUBA has offers is that it is based on CLNP and there is significant deployment of CLNP-capable routers throughout the Internet." [0]
[0] https://www.potaroo.net/ietf/idref/draft-ipng-recommendation...
Of course these days nobody remembers either TUBA or CNLP...
What? No, NPT is a nonstandard experimental hack that's in no way part of IPv6 or supported by any standards track IETF protocols.
"IPv6 was a draft in 1997(!), and became a real Internet Standard in 2017"
The draft part of the claim is false, the basic IPv6 RFCs came out of draft and were published as standards track RFCs in 1995 eg https://tools.ietf.org/html/rfc1883 / https://tools.ietf.org/html/rfc1884 and then subsequent revisions in 1998 and 2017.
The "request for comments" title of the series does remind us of the collegial and unbureucratic roots of the IETF, vowing to reject kings, presidents and voting & believing in rough consensus plus running code etc :) however in the standards track case there is no rfc number assigned to the doc in the draft phase, it's instead published in the separate internet-drafts directory by the working group and goes through all kinds of process and iteration before getting published as a proposed standard RFC.
This is mostly incorrect. Yes, NPT can't do this. No, you don't need an additional proxy. All the usual methods work, they're just not called NPT. On linux MASQ and REDIRECT targets work on ipv6. You can change addresses and ports exactly the same way you'd do it for ipv4.
There are other wrong things in this rant too. I'm curious if the author ran into many issues while implementing ipv6 or just doesn't like the idea in general. The problems and some solutions seem very contrived and there are better ways to solve them.
- Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this).
- My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change).
- Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either.
- Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses.
- Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.
Do you mean your ISP does not give you a larger block than a /64 ? If so, name and shame please. Otherwise, you don't need your ISP to support prefix delegation. If they give you a larger block than a /64 then your router is the one that delegates prefixes within your LAN.
The big advantage to Wave G is that they have symmetrical gigabit download/upload rates. Comcast, on the other hand, provides gigabit download rates but ~30-40Mbit upload rates.
NAT, network address translation, means an artificial address space. That is all it means and it is limited by network size, even if that network is artificially addressed with nonrouteable addresses, which is small compared to PAT (port address translation).
NAT is great if you want to hide from the world. It doesn't mean you have privacy. Everything can still leak out. It just means the outside cannot see you without a tunnel. In many way that actually hurts privacy because you cannot establish a point-to-point tunnel without a third party and that third party must have access to the transmission headers. NAT was never created for privacy or security. NAT and PAT were only created to extend the range of IPv4 addresses.
In the web there is no point-to-point communication such as client-to-client. The web is only client-server. You make a request to the server, which establishes a tunnel and the server talks back with a response that follows the request in reverse. If you wanted to talk with a peer you would do so through a server. For example if you use iMessenger, Signal, or whatever you aren't directly talking to people. You are talking to a server and that server shares your messages with your friends. The server sees everything... no privacy. Even with end-to-end encryption you still relay everything through a server that knows half of every conversation.
IPv6 does not have NAT. That is great. The security benefits of an artificial address space that isn't routed are still available in IPv6. This is from a range of addresses called link local that do not route.
Since there is no NAT in IPv6 if you can see an outside computer that outside computer can see you equally. That means you don't need a server to chat with your friends. Just directly talk to your damn friends. No tunnel needed. End-to-end encryption can be as simple as HTTPS. You cannot get that with IPv4, largely due to NAT.
Yes, only nerds care about privacy.... Well, no. If privacy is the default and end-to-end encryption is always the default you can do things and share things you would NEVER in a million years put on Facebook, because its actually private, like giving a USB hard drive directly to your life partner. That is a massive new set of business opportunities that scares the shit out of people on today's web (for good reason).
So what? The whole point of IPv6 is that wasting address space like that is irrelevant - there is going to be enough space regardless
https://pca.st/episode/a1df7379-853f-4b5b-af5d-fcb6ad7e1390
Can anyone let me know if he is wrong? It really challenged my perception that IPv6 seriously future proofed the need for a larger address space.
"By the time we run out of v4 with NATs, v6 will offer us no more bits"
If all you want to do is to watch YouTube and check out Instagram, and Google and Facebook have servers in a rack "nearby" (in the network sense) ala what Netflix does, then you don't need a globally unique IP to talk to them.
But there are advantages to having a computer. Similarly, there are advantages to doing your networking right, and that means globally-unique IPs.
On a personal note, I used an ISP with CGNAT for a very short while, and it was despicable. It completely, utterly breaks any possibility of peer-to-peer stuff, in million little ways like UPnP being insufficient to make online gaming work as expected. It was just awful.
A "consume only" internet sounds like a second rate dystopia, doesn't it? (Where does the next YouTube/Instagram/Google/Facebook come from when the hurdle is they need to install lots of middle boxes to small, more siloed networks?) Not to mention the name "internet" itself comes from the global joining of a lot of individual networks. A re-balkanized "internet" with a lot of mostly disparate networks that don't really talk directly to one another hardly deserves the name "internet" at that point. (From that perspective CGNAT is an attempt to murder the internet from the inside.)
> the lower 64bits of the 128bit addresses doesn't count (due to privacy)
That's not how that works? For privacy a device is picking a 64-bit random number, sure, but that's still 64-bits of random numbers for a lot of devices to roll before collisions. It's not like it is just one device per lower 64-bits of address space. (Sure, maybe for "privacy" to avoid easy/obvious port scanning you superstitiously avoid "unlucky numbers" like ::1 or ::ffff:ffff:ffff:ffff, but that's still a lot more random numbers to roll than anything "the lower 64bits doesn't count" implies.)
(ETA: And of course, that assumes you are using privacy-focused SLAAC. There's still the power to micromanage a prefix with DHCPv6 and allocate every single one of those lower 64-bits if you really must.)
I don't have billions of devices in my home network, yet they eat 2^64 worth of addresses cause my ISP hands me a /64.
(Actually, if that's all you can get then it's not fine. Your ISP should be handing you, perhaps not by default but certainly on request, at least a /56 so you can have multiple networks.)
He says that because things has to work behind NAT these days ("or it won't get deployed"), then the effective address space of IPv4 is much larger.
For one it includes the source/destination ports, but in addition those ports can be time-multiplexed, so you get more effective bits out of that. He suggests the effective address space of IPv4 is closer to 52 bits.
On the flip side, in IPv6 the recommendation is for ISPs to hand out /48's. Add a few hosts inside there, and you got an effective address space that's roughly the same as the effective IPv4+NAT address space.
Don't shoot the messenger, listen to the podcast.
I don't believe that's correct because IPv6 could have time-multiplexed ports, too, which would vastly extend the IPv6 space if the podcaster wants to compare apples to apples.
His other points seem stronger, like how IPv6 is a mess for backbone router hardware due to variable length headers, how to get IPv6 working really well requires you to control the entire network and how it might not matter much since we're moving towards a naming-oriented network. Overall interesting podcast IMHO.
Plus, the idea of waiting until we "run out of v4 with NATs" is getting it wrong. NAT starts causing problems long, long before it gets to the stage where the very last person says "I give up".
Is this correct? Has anyone put this into practice?
Imagine that we lived in such a world: wifi repeaters would just be IPv6 routers. So would wifi access points. So would ethernet switches. So would SDN. ARP storms would be gone. "IGMP snooping bridges" would be gone. Bridging loops would be gone. Every routing problem would be traceroute-able. And best of all, we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet, and 18 bytes (source/dest/AP addresses) from every wifi packet. Sure, IPv6 adds an extra 24 bytes of address (vs IPv4), but you're dropping 12 bytes of ethernet, so the added overhead is only 12 bytes - pretty comparable to using two 64-bit IP addresses but having to keep the ethernet header. The idea that we could someday drop ethernet addresses helped to justify the oversized IPv6 addresses.
It would have been beautiful. Except for one problem: it never happened.
- The world in which IPv6 was a good design: https://apenwarr.ca/log/20170810
- IPv4, IPv6, and a sudden change in attitude: https://apenwarr.ca/log/20200708
http://[fe80::1ff:fe23:4567:890a%eth0]/
Because of the ambiguity around '%', the browser may require:
http://[fe80::1ff:fe23:4567:890a%25eth0]/
I'm not sure how common this would actually be—neither of these URL forms are valid in Firefox or Chrome on my machine today.
(Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.)
(Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)
Uhh no they don't. They're all unique addresses that can be explicitly listened on and connected to.. they just have to be routed to your lo interface by spec.
Good lord, is this really still the case 1/5 of the way through the 21st century?
For this to work, L4 protocols would need to be completely redone to consider and work with this concept.
Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size.
Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU.
For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Short version:
echo "2">/proc/sys/net/ipv6/conf/eth0/use_tempaddr
On servers, not using a temporary address is a sane default.
IPv6 version NAT - NPT
``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through. ```
This seems like a great security concern Would be good to know if this statement is accurate
I might consider disabling IPv6 if this is true
I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare.
The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying.
I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions.
[1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.
Why?
DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
> DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
How does RA/ND solve the problem of client auto-configuration of services? Rightly or wrongly, DHCP has been traditionally used for service discovery ("Hey! Here's some NTP servers, a TFTP server and a SIP server") as well as config discovery (useful for autoprovisioning of many devices) and I didn't think you could achieve that just with RA/ND.
Has anyone managed to get netboot or PXE working on IPv6 without DHCP?
Edit just saw a sibling thread about DNS adverts in RA. I guess RA could do all these things, but if it doesn't support it today, DHCP is going to fill the gap.
I don't know if DHCPv6 will win the day, or the vision of a leaner, more distributed addressing and routing infrastructure will prevail. And I don't have any opinions on which is better. I just know it's all rather confusing and still in flux.
Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together.
I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply.
If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.
At this time of writing the issue is 8 years old and it is still spurring discussion.
I'm one of those. Say I connect my new Pi Zero to the network, and I want it to be a server of some sort.
In a IPv6-without-DHCPv6 world, how do I make sure I can always reach my Pi server?
With DHCP it's easy, I can assign it a fixed lease in the DHCP server and the DHCP server automatically registers the name in the DNS server for convenience.
How do I get the same when using IPv6-without-DHCPv6. Keep in mind my IPv6 prefix changes frequentl, sometimes multiple times a day, and this is out of my control (changing ISP is not an option).
Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.
Are you IPv6 fanbois?
Have you audited all the firmware and software on your firewalls and routers?
Your comment contained no information above "I don't trust it".
Are you for real?
There's been decades of production experience with IPv4 and does mostly what's expected.
Of course IPv6 shouldn't be trusted.
New software has bugs. That applies doubly for networking code.
Get your fuzzers started ...
The tech support team even confirmed that ipv6 firewall support is coming ‘soon’.
Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration.
So, yeh it is still early days for consumer ipv6 adoption.
I was actually referring to rack gear, but hey.
I feel like I should point out that in IPv4 NAT you also still have a firewall to drop incoming traffic unrelated to anything.
Specifically I'm referring to:
- RFC4864 | Local Network Protection for IPv6,
- RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and
- RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference.
In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world.
[RFC4864]: https://tools.ietf.org/html/rfc4864
[RFC6092]: https://tools.ietf.org/html/rfc6092
[RFC7084]: https://tools.ietf.org/html/rfc7084
Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do.
Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem.
Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.
I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.
NAT just happens to serve as a form of firewalling in IPv4 land because usually, the stuff behind your router has a private address.
Proper firewalling is a matter of policies; it's completely orthogonal to whether your devices have a globally routable address or not.
I understand a lot of the pros of it, and I like them, but...
The protocol is certainly much less human-brain-friendly, which gives points for security, but kills in the area of convenience - even for experienced engineers. As someone who frequently manages networks professionally and personally, I constantly need to look up information on the how the address hashing works, CIDR block ranges, short-hand notation, etc, etc...etc (because there is a lot). It's really added a hinderance to my workflow and makes typical network configuration take much longer than it would have before.
It was easy for me to differentiate between LANs and WANs, subnets, etc in IPv4-land because the address space is much more intuitive to work with. CIDR block notation for IPv4 takes a minute to get used to (for new people), but it's easy to learn quickly and understand the ranges of your networks, or at least get a feel for it.
Even after working with IPv6 for over a year, I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains - which is extremely useful for debugging issues. If I can look at an IPv4 address in a log, I can immediately track down what subnet/machine had the issue and dig into the issue. IPv6 requires extra steps, and a lot of them.
Naturally, NAT became a thing for IPv4. I don't know if it was originally introduced as a firewall mechanism or to cut down on publicly used IPs, but it works well for both. IPv6 circumvents the need for NAT, but then we have NPT, which is also unintuitive.
Numbers are much more human friendly, as time has shown. It's easy to understand 127.x.x.x and 192.x.x.x are common prefix to local networks and I think that most people who have worked with computers at all have some understanding of what a "local" network is, but even after reading the article, my brain says "any IPv6 address that starts with an f is probably a special one, but I don't know why, just assume it means something and I'll have to do some Googling about 'prefixes' to figure it out".
I like some of the pros of IPv6, and maybe after another year of usage it might feel more intuitive, but right now it comes with a serious learning curve and anytime I need to work with it, I get an instant headache.
Also, have you ever looked at one screen to mentally grab an IP address and then needed to type it into another? Or asked a coworker for the machine's address so that you can take a look? Get used to using copy-paste a lot, because there's no way that you can glance at a screen for 2 seconds and mentally go, "aaah. Just need to ssh user@aksj:dfja:skja:sviw:eijf:000i:hate:00my:life....easy peasy"
When you've got a host whose address is 192.168.2.42, but it shows up as 203.0.113.8 to internet hosts, but you had an RFC1918 clash on a few of your acquisitions so some parts of your company access it via 192.168.202.42 and other parts need 172.16.1.42 and your VPN sometimes can't reach it because some home users use 192.168.2.0/24... how is that easier than "the IP is 2001:db8:113:2::42"?
> I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains
This is just lack of practice, not an issue with v6. Also, v6 subnets are basically always /64, so the answer to the question of how many addresses are in them is always who cares it's enough. I find v4 and its fiddly /27s and /21s much more of a pain (partly because, yes, I'm out of practice dealing with them).
Same deal with knowing the prefixes. 'fd' is "RFC1918", 'fe' is link-local, 'ff' is multicast. This isn't hard stuff.
> 192.x.x.x are common prefix to local networks
This is 99.6% wrong. I guess v4 isn't _that_ simple, huh?
> This is 99.6% wrong. I guess v4 isn't _that_ simple, huh?
Apologies for not being concise enough, I thought my point would have stuck regardless... 192.168.x.x
You are correct though. Mistakes also happen with v4 and it's not simple to a laymen, but it is certainly simpler than v6.
If it is too complex to readily use it and easily debug it, then it is bad. It is bad not because it is complex, but because it inserts overhead, and overhead in time spent solving problems is always exponential.
I am for the idea of using ipv6 as a sort of nation-level NAT for big corporations and countries to expose part of a private address space over a section of ipv4, while each country gets most of ipv4 to itself along with a section where you can route to other countries, in exchange for a small fee. Say 30% of the ipv4 space is globally shared by everyone and the rest is local to your own country. Also IOT local mesh networks all would be on auto configured tunnels with only certain gateway systems hard coded- systems you can block at your router.
That’s the most sensible solution. It will be a real shame if it is not the reality. Arrogance and “hurr durr i’m so smart and i spent 40 hours this week setting up this brilliant ipv6 network topology for my company that will require five manuals to fully explore and retain me in my job for a minimum of 10 years to keep it all working”- meanwhile the rest of us will suffer.
The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. If you want any kind of blocking you will have to go with curated WHITELISTS, instead of blacklists. And that may be more secure but it will also be a lot more work, which, again, the ipv6 nerds will love to do but will present a hassle for the rest of us. You won’t be able to manually check the dns list anymore. you will simply have to accept that the overhead and the security risk of trusting all of the 35 million addresses in the whitelist is a cost you are willing to accept.
Say no to ipv6. I have already blocked it on everything and will never adopt. it is the ethanol of internet addressing.
> The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past.
This claim is completely nonsensical. DNS-based ad blacklisting works just fine in v6. None of the problems you list with it exist.
I suggest you unblock v6 and use it. You'll find it works the same as v4 does, just without the added complexity of NAT.