``` > ping6 google.com PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms ^C --- google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms ```
Networking is a lot more than being able to ping a single host.
As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, with no way of disabling this behavior, published its public IP as the DNS server for internal clients.
So each time I got a new prefix from my ISP, which happens about once a week or more often, machines stopped being able to perform DNS lookups for hours or until I rebooted them.
And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Another counter-example is that Android only supports SLAAC, and SLAAC only supports providing a few key infrastructure details like router and DNS. If you want to tell the Android client something else, like NTP server, you're outta luck. Also, if Android successfully gets an IPv6 address via SLAAC, it requires the DNS server IP to also be an IPv6 address. So your internal DNS server must then also serve on IPv6. If that wasn't the case, it would just silently use Google's own DNS servers, breaking any local configuration you had.
Another point is that a lot of us tried using IPv6 decades ago, and so we still have scars from that time. IPv6 today is a lot better, but I still have a lot of IPv6 frustration associated with it from 15-20 years ago.
Why would you have to reconfigure your firewall rules when you're getting a new IPv6 prefix?
Because the IP address of the target changes when you get a new prefix.
There's some discussion in this[1] old pfSense ticket.
With IPv4 you typically do address translation (NAT) and so the internal target address is not tied to the global address.
I mean, I have a router that is trash with IP4. Therefore IP4 is trash!
How pfSense works is fairly reasonable if every IPv6 deployment had been as the original designers intended, ie you have a static prefix.
It's just that the way IPv6 ended up getting deployed in practice was often not aligned with that original vision. And that has been a large source of IPv6 frustration.
I used to. When I had a home network I'd carefully assign `10.52.1.x` where `x` was the periodic number corresponding to the machine name! (I write from `lutetium`.)
Now, with Tailscale's magic DNS – `lutetium` being all I need – why on Earth would I give a crap about an IP address? I've gone from being obsessed to truly not caring at all.
So, give me IPv6. Auto-assign everything! All I want is a name.
But yeah. On my own LAN, everything is DHCP for IPv4 and SLAAC for v6. Everything uses mDNS and I connect to everything by name, not address. I can only remember the static IP of one of the servers; the rest are purely names.
The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.
From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.
fddd::7 is easier to type than 10.0.0.7
Introducing a more complex system without easing any of the cognitive load and making fun of it is just cruel at this moment.
Users need a simpler way to connect to their devices, and what tailscale did with magic dns shows that users don’t even care about IPv4 they just want to connect to their devices with something simple they can remember.
I agree with the sibling comment: crummy CPE is crummy CPE. This is a solvable problem, but people end up with junky routers and it causes them anguish.
Put in something more interesting, e.g. OpenWRT, or there are proprietary options too, that provides simple & reliable local LAN DNS, then the problem just goes away.
https://www.rfc-editor.org/rfc/rfc7084
It describes in detail what a home router needs to be doing to make all of this work seamlessly.
Things work so well that half the world has working IPv6 already.
Openwrt pretty much implements all of this out of the box.
If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.
Personally I have moved several times changing ISPs in the process and my IPv6 setup involving multiple LANs on my home network has just continued to work. IPv6 renumbering events just work seamlessly and completely automatically.
Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
[1] https://datatracker.ietf.org/doc/html/rfc7368.html#section-3...
And corporate networks: in Google's stats you'll see IPv6 usage jumps on weekends as people do stuff not using their work computer.
> ...
> Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
Yep, that's where I am. Frontier FTTH, IPv4 only. Because....I have no idea why. Because Frontier sucks, basically? They have at least started their rollout:
https://stats.labs.apnic.net/ipv6/AS5650?c=US&p=1&v=1&w=30&x...
...but it's going to be slow going. Don't get me wrong, I'd rather cut off my fingers than go back to Comcast, but at least Comcast gave me a /56.
1. IPv6 addresses are too long to remember
2. IPv6 doesn't need NAT and people are uncomfortable with their devices having a public address as they see NAT as an additional layer of securityIf you need to remember random WAN IPv6 addresses without being able to use DNS or at least a hosts file you've probably got a bunch of other more pressing problems.
Hey, how awesome you live in an area where you have a choice of ISPs and can dismiss one that doesn't meet your spec, rather than having to simply shut up and eat what you're served!
Sorry, IPv6 is absolutely not the hill I'm going to die on.
So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.
- How they would format the display of the bits
- Where in the bit pattern IPv4 mapped addresses should go
- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks
- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use
It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:
- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.
If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
Or:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
* https://en.wikipedia.org/wiki/Happy_Eyeballs
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
> If IPv4 were more painfully broken then the switch would have happened long ago.
IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?
UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.
Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.
If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
https://news.ycombinator.com/item?id=47355046
This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so.
I quote from the top comment:
>So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
and
>So you have to update DNS to create new resource record types [...] Just like with IPv6.
and
>You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
Found this visual breakdown of IPv4 -> IPv6 transition.
Dual stack and tunneling sections show how much complexity came from not having a clean migration path - https://vectree.io/c/ipv4-vs-ipv6-address-architecture-nat-a...
I have my own /24 that I registered back in the 90's. It is, in fact, routed and announced globally. I know several "early Internet" nerds with the same.
I know three local companies with /16's that aren't even announcing their blocks! Perhaps they use them internally.
I speak as someone who worked at an institute that had similar abundance of address space.
https://en.wikipedia.org/wiki/Unique_local_address
If your intranet has no IPv4 addresses, this is better than a NAT somehow?
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
[1] https://datatracker.ietf.org/doc/html/rfc7368.html#section-2...
I later moved and my current ISP does not have ipv6 support but my ULA setup kept working fine with some minor tweaks.
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
> When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally and use its additional globally unique IPv6 address as a source address for external communications.
But in substance, if you have several subnets, then using ULA may make sense depending on what you're trying to do. However most home networks don't subnet.
As addresses started running out, the NAT RFC was published in 1994 and described NAT as a "short-term solution". NAT was never meant to be an integral part of IPv4. https://www.rfc-editor.org/rfc/rfc1631
NAT broke a ton of things which required more and more hacks piled on, making it more complex to build services on top if it (e.g., a server in the middle to proxy all the traffic needed between peers is a 100% requirement, with all the maintenance and scaling headaches that come with it).
But yeah, SLAAC's paradigm of moving assignment logic into the node (away from network infra like in DHCP) is definitely a stumbling point.
But that should be a perfect playground for an IPv6-only network that has gateways to the IPv4 content; eventually the home-developed content will begin to drive demand elsewhere.
If India were to turn off IPv4, it would be a great incentive for IPv4-only sites in the US and Europe to add an IPv6 address.
PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.
$ ping6 github.com
ping6: github.com: Address family for hostname not supportedWe already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.
And still likely better than heavily regulated airwaves.
But at the same time there is a quote by Stanisław Lem...
"Until I used the Internet, I didn't know there were so many idiots in the world"
The "slow intellectual decline" has circular causality with advancement of mass media and convenience tech.
IPv4 is 32 bits. It has a hard cap of ~4 billion addresses. China and India alone have 2.85 billion people.
Add in the United States and Europe, and now nobody else gets an IP address. South America, Canada, Mexico, Australia, Africa, the middle east, the rest of Southeast Asia, etc. don't get to use the internet. That's 4 billion people who don't get to use the internet.
The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
>other
Well you just handwaved away the most significant difference between NAT and native IP, obviously there won't be any major difference to discuss about anymore!
No, we can't ignore port forwarding. The key thing to realize about NAT is that someone owns the NAT. Back then, the NAT lived inside each of the home routers, so even if you have a "strict" NAT (endpoint-dependent mapping NAT, i.e. one that doesn't allow for hole-punching), you can easily bypass it by setting up a manual port forwarding entry.
With CGNAT that's no longer possible, you do not control the NAT. If your ISP decides to screw you over, you essentially do not have a choice but to get a relay, which needlessly costs you money.
---
But if you really want to know what advantages native IP has over NAT, I'd say the lack of keepalive packets (to keep a holepunched NAT entry from being removed) is a pretty nice thing.
It's been in crisis for decades, but it's also getting increasingly worse every year.
Obviously. Anyone who does understand how networks work aren't going to spend any time talking about it. People don't talk about things they are certain about. They talk about what they don't know much about to feel out what they're missing. You will never find a discussion where pushing back reveals that you found the world's utmost expert. The world's utmost expert is bored with the subject and has moved on to talking about the things he has gaps in.
The people who have to make networks work need to know how IPv6 works - but there is no getting around that - they know how IPv4 works too.
Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.
I'll tell you that if you just think of it on its own, it's really no harder than IPv4 + ARP + DHCP, just one or two extra things to remember.
The difficulty of adoption is the featureset and the UX of operating systems and home routers in particular. It is really difficult to find a consumer router, or even home networking OS, that exposes sensible working defaults for IPv6. The problem extends to the ISPs.
The spec is fine.
I never use them on my web, chat, voice, IRC and other servers as I personally find blocking shenanigans on IPv4 and not having to implement the same checks on IPv6 is just easier for a lazy person like me. IPv6 just feels like an after-thought bolt on to me. Clunky, not well thought out. Some privacy gotchas that can be disabled but some will not. That's just my take. I doubt anyone will have the same take.
I think IPv4 will be fine for another 100 years even if we have to re-purpose some DoD/MoD ranges given they don't use them and maybe annex some /8's from a few greedy companies. But that's a problem for Gen Delta. Gen Foxtrot can deal with repurposing some multicast ranges.
IPv6 is for the people (countries, continents) who did not get in early on the IPv4 address gold rush. Your take is basically "got mine, F you".
In our exponentially growing world that wouldn't help. By the time we ran out of Class As we were allocating a new one every month. Reclaiming all the unused addresses would barely make a dent in demand.
Someone did the math on this:
> Now, average daily assignment rates have been running at above 10 /8s per year, for 2010, and approached 15 /8s towards the end. This means any reclamation effort has to recover at least 15 /8s per year just to break even on 2010’s growth. That’s 5.9% of the total IPv4 address space, or 6.8% of the assignable address space. Is it feasible to be able to reclaim that much address space? Even if there were low-hanging fruit to cover the first year of new demand, what about there-after? Worse, demand for address space has been growing supra-linearly, particularly in Asia and Latin America. So it seems highly unlikely that any reclamation project can buy anything more than a years worth of time (and reclamation itself takes time).
* https://paul.jakma.org/2011/02/03/why-dont-we-just-reclaim-u...
There are 'only four billion IPv4 addresses, and there are eight billion people on the planet. There are just as many smartphones (I have two: personal and work):
* https://www.weforum.org/stories/2023/04/charted-there-are-mo...
Even if you (CG-)NAT an IPv4 address for some number of people, you still need to have IPv4 addresses for public services (web, mail, NTP, etc).
There is no scenario where 2^32 addresses is enough for humanity's needs: as some point you need to go to a protocol with more that 32 bits of address space.
Err... you do realize that the number of humans currently living on planet earth is twice the number of IPv4 addresses... right?
We can't all have an IPv4 address for each of our devices. We can't all even have one IPv4 address, period. But maybe they should just try not being poor, eh?
The trouble is that 1) my employers do not have native ipv6 access; 2) neither does my mobile connection; and 3) really nor do a lot of my friends. Moreover, 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you. So, it doesn't really work for hosting, and I don't get any direct benefits from it.
Instead I have a vps with a public ipv4 address and have a router that creates a wireguard tunnel to it. The reverse proxy works great over ipv6 and I am now in a position where I can forward ports and have direct connections -- albeit with hugely increased technical complexity. Ipv6 has many great ideas in it. If it's universally used it might just catch on...
IPv6 privacy extensions exist & are enabled by default in most (if not all) operating systems today, which (this is my understanding; take it with a grain of salt) create what essentially are extra IPv6 addresses, used for outbound traffic, that aren't generated via your MAC address.
The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.
IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.
Per Google, quite a few countries (including the US) are at >50%:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Every handset on T-Mobile US's network gets IPv6 (and they're not the only carrier like that):
* https://www.youtube.com/watch?v=d6oBCYHzrTA
So I'm not quite sure where "failed" enters the equation.
And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.
IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.
Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.
It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.
Sure everything above IPv6 have, but it took years and years of screaming to get it.
All of those things exist in IPv6.
And it is physically impossible for DNS to be the same, as you have to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.
Even after reading about them many times and using them in (an albeit limited) fashion, they still just don't feel human friendly. Not like the more straightforward IPv4 addresses do. (Or even like a hypothetical "IPv5" that simply prefixes one extra octet).
Whenever I bring this up I'm told something like "Don't bother memorizing IPv6 addresses. Use DNS instead."[1]
That take completely overlooks the fact that if the numbers exist, you will inevitably wind up needing to deal with them at various points along the way. Eg. Debugging logs, sniffing network traffic, ruling out if DNS is down, etc. I'm a big fan of ergonomics to make things intuitive and reduce unnccessary cognitive overhead, and the new scheme is a regression in that regard.
If anyone has tips on how they became more fluent with IPv6 I'd love to hear.
[1] https://www.networkworld.com/article/934784/mission-impossib...
Here's some roughly equivalent IP addresses:
203.0.113.45+192.168.1.1 ↔ 2001:db8:2d4f:1::1
203.0.113.45+192.168.1.2 ↔ 2001:db8:2d4f:1::2
203.0.113.45+192.168.1.3 ↔ 2001:db8:2d4f:1::3
203.0.113.45+192.168.2.1 ↔ 2001:db8:2d4f:2::1
When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.
And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
> And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them.
I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too.
Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.
Regarding firewall policies:
just because most network OS are plain dumb, does not implies that's the fault of IPv6.
A zone based firewall solves that already. And for instance OpenWrt fw4 can make rules for suffixes in a zone too.
For 5€/mo additional I get a static /32 v4 (for NAT64) and a /60 v6 prefix.
All I want to do is give every machine on my network a friendly hostname like storage.lan, timsPhone.lan, etc without having to run BIND (if possible), or dhcpd.
I have heard of zeroconf for ipv4, but the catch is I want this to work across several different platforms like Windows , freebsd, Linux, etc. I also don't want to use static addresses, but I feel like that's asking too much.
mDNS supports IPv6 just fine/works on IPv6 only LANs.
IPv6 - still the same, but the space is large enough that any first-mover advantage is minuscule.
32 bits seemed practically infinite at the time IPv4 was created, and the whole thing started as a way for the American military-industrial-research complex to communicate with itself anyway. Why would you even want to assign addresses on your defense network to foreign adversaries?
Now that it's a commercial thing, a more equitable distribution would have, with hindsight, been a good thing.
Both IPv4 and IPv6 addresses are 'just' u_ints: one is 2^32 and the other is 2^128. The fact that we display them in a particular format (10.11.12.13; ff:ee::bb:aa) is only for human UX purposes.
Strictly speaking everything in a computer is 'just' a number represented in base-2 (binary digits: bits) that we affix certain labels to (char, int, float, struct).
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
[1]: https://en.wikipedia.org/wiki/Second-system_effect
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
Companies like Facebook can and do use 240/4.
How are you going to make v8 addressable from v4? Because you need to do this too for communication to work.
Also, you've made v4 addressable from v8, and you're about to explain how you make v8 addressable from v4... but that's just addressing, i.e. identifying the right host. How are you going to actually send packets from v8 to v4, and also from v4 to v8?
> The IPv6 critics shout out that this would be a viable solution.
But they never bother to understand enough of the problem to contribute anything useful. Either they can't come up with something that works, or they come up with something that they didn't realize v6 already did.
Winamp 3 -> Winamp 5 was closer to Winamp 2. Windows 8 -> Windows 10 was closer to Windows 7.
Though I don't expect this to happen with IP.
It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).
Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.
This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.
A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.
And the billion people in India? The billion in China? The billion on the continent of Africa? And even in the US:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
It's okay for the folks that got in early on the IPv4 address gold rush to tell them "fuck you, we got ours"?
10 years ago I was all gung-ho about IPv6, but it's annoying at every level.
Having to deal with the separate socklen_t is mildly annoying, but you can just make a little struct that holds both.