5 ms·

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes? And how would you propose making larg

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes? And how would you propose making larger addresses without making them longer?

hot_gril 3y ago
There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on. > And how would you propose making larger addresses without making them longer? Pre-existing ones don't need to be longer. If my IP before was 1.2.3.4, it stays that way. If a new ISP can't afford /32s for its customers, maybe it hands out /48s like 1.2.3.4.5.6, and if there are ever 282 trillion users, the next one is 1.2.3.4.5.6.7. At home on my LAN, ofc 192.168.1.2 is free and I keep it. IPv6 addrs are only long because they're spread out.
- orangeboats 3y ago
  >Special kinds of addresses 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.
  - hot_gril 3y ago
    > You have just repeated the current IPv4-IPv6 pain point without being aware of it 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, there's no way that making the address field bigger requires changing all existing addresses.
    - orangeboats 3y ago
      >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.

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes? And how would you propose making larger addresses without making them longer?

hot_gril 3y ago

There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on. > And how would you propose making larger addresses without making them longer? Pre-existing ones don't need to be longer. If my IP before was 1.2.3.4, it stays that way. If a new ISP can't afford /32s for its customers, maybe it hands out /48s like 1.2.3.4.5.6, and if there are ever 282 trillion users, the next one is 1.2.3.4.5.6.7. At home on my LAN, ofc 192.168.1.2 is free and I keep it. IPv6 addrs are only long because they're spread out.

orangeboats 3y ago
>Special kinds of addresses 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.
- hot_gril 3y ago
  > You have just repeated the current IPv4-IPv6 pain point without being aware of it 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, there's no way that making the address field bigger requires changing all existing addresses.
  - orangeboats 3y ago
    >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.