There is no "just" in this.
Copy-pasting from my other comment:
--
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
--
So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.
The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready.
By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
When who is ready? Different people/organizations will be ready at different times.
Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only.
Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure:
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
And once that happens, which it would inevitably too with IPv4.1, we're at:
If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.
And who gets to decide when "enough" devices support it? Who decides on that flag day?
* https://en.wikipedia.org/wiki/Flag_day_(computing)
The Tier 1s?
* https://en.wikipedia.org/wiki/Tier_1_network
Good luck coördinating that with the global Internet.
ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.
You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.
Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.
Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage.
Again, nothing changes - if you do anything to change the structure of the packet header the same problem happens, no matter what.
If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.
Except you're wrong on all of the above.
We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup).
DNS would still need changes, because the struct for an A record still contains a 32-bit address.
Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it.
There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).
Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.
That's not the problem.
Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you leave v4 on... but then you're just doing dual stack, and v6 can do that too.
The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.
Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?
The only difference seems to be that some people are already making use of the bigger address space, rather than waiting. And that's surely a good thing? If you told everybody to wait until absolutely everything supported it, you'd be waiting forever, and you'd be giving up the benefits of having a larger address space available the entire time... and you don't have a way to force people to wait anyway, so that idea wouldn't even implementable in the first place.
There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.
I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding).
NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network.
NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
> IPv6 just exposes such poor configurations more readily.
Yes, that's the exact dealbreaker for me and many corp environments.
Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this:
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 1.1.1.1 1
DAc 1.1.1.0/24 wan1 0
DAc 192.168.0.0/24 lan1 0
> Yes, that's the exact dealbreaker for me and many corp environments.
My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.
Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you.
> How often does this kind of attack occur?
Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.
???
Firewalls generally have inside and outside: default-deny any new connections from the outside and you're done. This is how all CPE gears ships out of the box.
> Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults.
For this you need hole punching, with on CPE gear is done with UPnP and/or PCP, the exact same protocols that are used with IPv4 NAT. (But of course applications also have to futz around with TURN/ICE/STUN if there's NAT.)
> No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports.
When I was still with a residential ISP that did IPv6 this was the exact same with all of my home devices behind my ten+ year old Asus.
Further, because you only have one public IPv4 address, someone can scan just that address to see which ports are forwarded. People regularly scan the entire IPv4 address space: 2^32 addresses is not a difficult task.
With IPv6, they'd have to know the IPv6 address of your service that you had opened to the public. If you hadn't advertised the address publicly, an Internet rando is not going to find it: good luck remotely scanning a single /64 (never mind a /60 or /56 that many ISPs hand out).