And how would you propose making larger addresses without making them longer?
> And how would you propose making larger addresses without making them longer?
Where's the problem with this? My street address number is 415. If the post office wants to migrate that number from 16-bit int to 32-bit, do I need a new address?
You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16.
So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
>Pre-existing ones don't need to be longer
We cannot do that even if we wanted to do so.
Think about this: computer A supports only the "shorter IPv4" and computer B supports both the "shorter" and "longer IPv4". Now computer B has the IP "1.2.3.4.5". How can computer A, which supports only the shorter IP address, connect to computer B? By the magic of having hindsight? No.
Therefore: Congratulations! You have just repeated the current IPv4-IPv6 pain point without being aware of it. Which is fine, but note that in your comments you have tended to act like your solution is better than IPv6's.
The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier transition. Then once everyone's on v4.1, people could start using longer addresses.
> It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
They're mere addresses in ipv4, but not so in ipv6. ULAs are routed specially, basically as a replacement for NAT. See, I can use jargon too, but it doesn't matter here. From a common sense standpoint, making the address field bigger doesn't require changing all existing addresses.
>If all the addresses, routing, etc were kept the same as before
It is a natural consequence of having a greater address space.
If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers.
Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.
But even so... your point that:
>Then once everyone's on v4.1, people could start using longer addresses.
...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
>ULAs are routed specially, basically as a replacement for NAT.
For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
Like I said, you really don't understand IPv6 at all, stop pretending that you are, lest you repeat all the same so-claimed "mistakes of IPv6" in your own solution.
>no way that making the address field bigger requires changing all existing addresses.
Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.2.3.4/32 traffic to my router; they don't care what addresses it forwards to underneath that. The ISP could support more customers by handing out /40s, but that's a gradual increase.
Unless you're saying that just supporting the longer field means more memory is used for the existing addresses (true), but idk if that means you have to re-optimize all your routes.
> ...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
Most sites are HTTPS-only because it's safe to assume every client will support it. Now how many big websites are ipv6-only?
HTTPS is the networking migration success story I like to point to, in fact. Just the right amount of force was applied, including banning old TLS versions later.
> For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
I didn't say they are for literal NATs. They are replacement for the private networking feature of NAT, where your LAN hosts aren't reachable from WAN.
> Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
If you're moving pre-existing machines out of a NATted network. Not everyone has to.
Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes.
If you increase your address space by 8 bits, your routing table must necessarily increase its size.
>I didn't say they are for literal NATs.
Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
>If you're moving pre-existing machines out of a NATted network. Not everyone has to.
Now here is your very fundamental misunderstanding of any next-generation Internet Protocol! If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
So you're talking about the second thing I mentioned. Supporting N users requires storing at least Nlog(N) bits of addresses in total. Going to /40 doesn't seem like a huge increase. And even if it is, an ISP could even roll out v4.1 sticking with /32s for now, keeping their routing tables exactly the same and leaving the expansion effort for later.
> Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
In IPv4, practically the entire reason you'd have a private network is because of a NAT. To help get rid of NAT in IPv6, they added ULAs. That's all I mean.
> If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
The point is that we're running out of addresses, like ipv6 proponents keep saying. Everyone who needs public IPs for any reason should be able to obtain them cheaply. This doesn't mean that NAT needs to disappear everywhere, though some users (like ISPs running CGNATs) might be happy to either ditch their NATs or split them up later on.
And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).
Extra goals? Removing NAT? Come on now... Don't act like NAT was invented along with the Internet itself, you know it wasn't.
And again, never ever conflate NAT with private networks.
NAT is a packet-modifying technique that is closely associated with stateful firewalls, but it still ain't firewall. If you want private networks, you would actually use a firewall, not NAT.
What's the big problem with NAT existing anyway, especially when you're free to ditch it on your own network? Maybe because the main point of getting rid of NAT in v6 is to allow any device to claim a public IP on default networks, for p2p applications. NAT's default behavior would get in the way of that. So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
Don't forget the context: we were talking about "removing NAT as an extra goal of IPv6," not "does it matter when was NAT invented".
So here I am reiterating my point again: It was never an extra goal, considering that IPv6 was designed in an era when NAT never predominated the internet.
>What's the big problem with NAT existing anyway,
Oooh no biggie other than breaking all sorts of P2P communication? It's so bad that we have to implement literal hacks like TURN and STUN on top of the hack that is NAT itself.
Or maybe we can talk about how it broke all sorts of protocols so badly that we to this day need application-level gateways[1] to help those protocols transverse NAT?
Or let's have some time to talk about how inefficient NAT is. You should know it requires computing power to track each connection flow and to maintain a state table for those flows.
>So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
What are you talking about? Default-allow and default-deny are both firewall rules. Even NAT (the "full-cone" or "endpoint-independent" ones) is prone to this, if a port is open everyone can connect to you through the IP:port.
I would say removal of NAT and addressing space is closely intertwined, but alas you seem to have pretty amateurish understanding of it.
Also, just in case you bring up your IPv4.1 again: all address space enlarging efforts will inevitably face incompatibility issues.
[1]: https://en.wikipedia.org/wiki/Application-level_gateway
I keep hearing this have your cake and eat it too kind of argument. "It supports P2P" and "just default-deny if you're worried about security" do not mix. We get one or the other as the assumed default. IPv4 + NAT is the default-deny. IPv6 seems to be about default-allow even if that's not inherent to it.
That's why you have the PCP protocol to help you setup a hole in your firewall, you default-deny until some host in your network says "I can handle port 12345". If your router doesn't support that, in the worst case scenario you can fallback to manually setting up firewall entries much like NAT.
Sure, PCP works in NAT cases too, but not always - especially in double-NAT or CGNAT scenarios. And we already know how prevalent CGNAT is, don't we? I don't know where do you live in, but here all ISPs have deployed CGNAT.
By the way that's one of the disadvantages of having NAT, you are forced into a centralized architecture where the central node in the ISP (the CGNAT device) decides what kind of niceties you could get.
IPv6, the ISP only carries traffic around and it does not meddle with layer 4 activities.
Another thing about humans, addresses like 2001:4860:4860::8888 look awful. You gonna tell me that's an upgrade over 8.8.8.8? And 192.168.1.2 becomes fe80::1c03:b6d1:9222:3a02. Why can't I keep 192.168.1.2?