I get how this isn't good. But how else would you handle multi-field filtering, keep all the ANDs and use (product_id = $1 OR $1 IS NULL) so the unset filters are no-op? That's ok as long as the query planner is smart enough.
Yeah, so often do I have an EXPLAIN ANALYZE query.txt file I'm repeatedly editing in one window and piping into psql in another to try and make something faster. So I put WHERE true at the top.
I feel like residential ipv6 would be at least a little further along if routers simply always enabled NAT by default for it, like what cell providers do. Solves all these questions and problems for inexperienced users. Instead, you gotta ask, is the firewall enabled and default-deny, are ULAs enabled...
RFC 2765 isn't about keeping ipv4 blocks in ipv6, if I understand correctly. It's about translator boxes for ipv6-only hosts to talk to ipv4-only ones by acquiring temporary ipv4 addresses.
I'm not saying we can avoid updating routers/hosts/DNS/etc, but it's only one piece of the migration puzzle. Otherwise we'd be done already. I elaborated when responding to a similar question: https://news.ycombinator.com/item?id=41603782
The second thing is the problem with not having NAT. On a home or corp network, I like NAT. I'm not trying to host 20 servers there. Sure ipv6 can use it too, but it's never default and often not supported on the router.
So yeah, 192.168.1.55 is my Mac's local ip, it's easy to remember.
You still make the same big changes, but the difference is you don't have to do them all at the same time. You also skip the complicated add-ons of ipv6 and don't reassign everything.
Ipv5 as you call it: Phase 1 is getting routers/hosts to understand v5 headers, while users enable v5 and change nothing else. Phase 2 is the transition where people keep using padded addrs while things* are updated in-place to just support longer ones, which doesn't affect users**. Once that's done, we get to use the full space, which some users may ignore and some may use. For better and worse, the existing /32 blocks would still be around initially. Maybe this would appeal to previous ipv4 holders better; they still own the same % of the pie. Maybe 8.8.8.8 would stay forever.
What makes me kinda sure would've worked? Right now, the world has mostly already completed the equivalent of phases 1 and 2 for ipv6. There might even be a way to reuse the ipv6 protocol as-is for ipv5.
* DNS, NAT, DHCP, ARP, routers, VPSes, OSes...
** "User" includes corp network admins, cloud/datacenter operators, ISPs, and simple home customers.
Yes, everything has to be updated eventually, but going forward doesn't have to be this hard. A network and its hosts could start supporting ipv6 without changing anything else. Same addr and routes as before, same NAT, and no DNS6/DHCP6/etc, so very low effort and risk to turn it on. If a peer only supports v4, talk v4 to it for now.
Then once there's sufficient v6 adoption, you can disable v4 entirely and start using /40, /48, etc..
Yeah, the route fragmentation a disadvantage of what I've had in mind. My focus is just on getting things to speak v6 to fix the scarcity problem first. Maybe at some point the owners could've swapped addresses back to defrag things.
That's my proposal, ipv6 with extra steps. As in, incremental steps instead of one impossibly big change. tl;dr keep the pre-existing v4 /32 blocks day 1, and the rest follows.
Edit: I said "my" proposal, but pretty sure the same idea has been brought up many times.
Not so. IPv4->6 removes all existing v4 address blocks and redoes the addressing scheme. Those changes weren't necessary for expanding the address space. This implies that day 1 of using ipv6, all your addresses are different (and way longer), all your routes change, DNS DHCP etc all need to be swapped out, and bans/reputation are all reset with no clear replacement. And there were a bunch of smaller changes / new features.
Whatever you do to get more addresses, it will look similar in the end, but the steps could've been very different.
IMO the separate-stack nature of ipv6 was a mistake. I can see why they did it, but the changes could've been a lot more incremental otherwise, and we might've been done already. Everyone talks about the biggest change being the 128-bit address space, but the real leap is that pre-existing ipv4 blocks weren't preserved in ipv6.