3 ms·

>doesn't suddenly mean you have more routes to deal with. Routing tables don't magically change their structures according to the routes either. Think about th

>doesn't suddenly mean you have more routes to deal with. 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. After all, the router cannot tell what routes you are putting in when it is manufactured. If you increase your address space by any number of 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.

hot_gril 3y ago
> If you increase your address space by any number of bits, your routing table must necessarily increase its size. 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 big enough increase to require redoing all the routes. 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, a very common reason you'd have a private network is because of a NAT, even though they aren't the same concept. 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).
- orangeboats 3y ago
  >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.
  - hot_gril 3y ago
    Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now. And even if it wasn't their original purpose, NATs are used as firewalls. Functionally they're similar except NATs also rewrite addresses, which is actually a nice feature too. There's some reassurance in having such a clear default-deny behavior, with local IPs that aren't globally unique to begin with. 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.
    - orangeboats 3y ago
      >Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now. 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 https://en.wikipedia.org/wiki/Application-level_gateway

hot_gril 3y ago

> If you increase your address space by any number of bits, your routing table must necessarily increase its size. 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 big enough increase to require redoing all the routes. 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, a very common reason you'd have a private network is because of a NAT, even though they aren't the same concept. 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).

orangeboats 3y ago
>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.
- hot_gril 3y ago
  Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now. And even if it wasn't their original purpose, NATs are used as firewalls. Functionally they're similar except NATs also rewrite addresses, which is actually a nice feature too. There's some reassurance in having such a clear default-deny behavior, with local IPs that aren't globally unique to begin with. 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.
  - orangeboats 3y ago
    >Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now. 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 https://en.wikipedia.org/wiki/Application-level_gateway