3 ms·

>But going v6 means redesigning your network. >If all the addresses, routing, etc were kept the same as before It is a natural consequence of having a greater

>But going v6 means redesigning your network. >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.

hot_gril 3y ago
> 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. 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.
- orangeboats 3y ago
  >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).

hot_gril 3y ago

> 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. 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.

orangeboats 3y ago
>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).