5 ms·

Because IPv6 is mistake. Thats why market does NOT want it. Unfortunately, we all start to feel the heat of IPv4 exhaustion. Anyway, remember IPv4 classes? The

by Borg3 2y ago

Because IPv6 is mistake. Thats why market does NOT want it. Unfortunately, we all start to feel the heat of IPv4 exhaustion. Anyway, remember IPv4 classes? Then they made it classless. IPv6 is not 128bit, its just 64bit with 64bit host address. So, first mistake. IPsec mandatory? pure stupidity. Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that? In 1997 IPv6 was seriously immature yet to start migration. Additionaly, it was very different from IPv4 so was mostly ignored. What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. As bonus, they should think about some basic IPv6 -> IPv4 interop so clients would NOT need to be dual stack. And that could work back then. Now we are fucked.

zokier 2y ago
The thing that you and all other ipv6 haters miss is that none of that matters. Ipv6 is happening, like it or not. And that had been the state already for 10-15 years. Maybe in the 00s there was window when there might have been true doubt if ipv6 was going to happen. But after that, it was just question of "when", not "if". Keeping on hating is simply not very productive. It's just much better to embrace ipv6, no matter it's possible flaws.
growse 2y ago
> What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. Tell me you've never had to seriously design and operate networks at scale without telling me etc... This is a bit like Chesterton's fence - until you understand why (for example) ARP is a hilariously bad design and a major problem when trying to design networks at scale, then you can't understand why someone might want to replace it with something more effective. IPv6 doesn't get a lot of stuff right, but the motivation behind replacing v4 was much more than simply "more addresses pls". IPv4 was the mistake, Vint Cerf is on the record as saying so. Should never have been let out of the lab.
- Borg3 2y ago
  Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. IPv6 took its ND and bring a lot of other problems that we are solving AGAIN. Pure waste of time and effort. Also, please cut the crap about IoT and Hyper IP networks centrally managed. Thats just serveral huge corporations. Majority is Internet is small/medium shops doing it completly different. Yet, big boys pop in and say you do it wrong, you must do it our way or go away. Not nice. Yeah, that motivation become overengineering. They provided protocol that does NOT fit the needs it seems. IPv6 will probably happen indeed. I doubt someone will popin with great protocol that will make IP obsolete. Also, I wish IPv6 would really took off, because even if I personaly dont like IPv6, it success would provide me IPv4 address space for my retro networking projects.
  - throw0101d 2y ago
    > Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. ARP poisoning is the least of ARP's problems. It can potentially have a blast radius that can bring down networks, and if it was actually sorted out, then things like BGP EVPN would not need to have been invented. One of touted benefits of BGP EVPN is reduced ARP and Layer 2 broadcasts. I've seen ARP storms bring down even 'small' company networks (dozen switches for ~200 people) because someone fed a simply desktop switch back in on itself and the access layer switch in the closest could not do STP with the simple switch.
    - Borg3 2y ago
      That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence. Thats why newer switches have STP, DHCP Snooping, ARP security and so on. Now take a look at ND tables exchaustion alone. Trival attack to do on IPv6 segment. Is it solved yet? I dont know. I do NOT track it. The whole PnP (I call it Plug and Pray) is terrible aproach imo. IoT created hella of security problems (biggest DDoS botnets are IoT). If someone need autoconfiguration, he can slap DHCP on segment. Easy and super old protocol on IPv4. (IoT connected directly to internet? thats stupidy.. but I will leave that to other talk). So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.
throw0101d 2y ago
> Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that? Negotiation. IPsec using IKEv2 (RFC 4306/7296) started with (e.g.) 3DES when it was initially released, but now allows for AES (RFC 3602, 3686, etc), as well as other algorithms: * https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml https://www.iana.org/assignments/ikev2-parameters/ikev2-para... > What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. For anyone curious, the technical criteria for choosing the (then-labelled) IPng: * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 And the evaluation of the available candidates and why the winner was chosen: * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752 One of the IPng candidates, SIPP, indeed did extend addressing from 32-bits to 64-bits (RFC 1710, RFC 1752 § 7.2), but it was deemed that it may not enough and another transition would be even more difficult, so they went with 128-bits (RFC 1752 § 9). Adding mechanisms for auto-configuration was one of the criteria for IPng; per RFC 1726 § 5.8: CRITERION The protocol must permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is required. DISCUSSION People complain that IP is hard to manage. We cannot plug and play. We must fix that problem. We do note that fully automated configuration, especially for large, complex networks, is still a topic of research. Our concern is mostly for small and medium sized, less complex, networks; places where the essential knowledge and skills would not be as readily available. In dealing with this criterion, address assignment and delegation procedures and restrictions should be addressed by the proposal. Furthermore, "ownership" of addresses (e.g., user or service provider) has recently become a concern and the issue should be addressed. We require that a node be able to dynamically obtain all of its operational, IP-level parameters at boot time via a dynamic configuration mechanism. […] In a world of IoT, not having to have a BOOTP/DHCP(v4) seems like decent foresight.
ragall 2y ago
> Thats why market does NOT want it. What market are you talking about ?
- Borg3 2y ago
  Market as a whole Internet. Some ISPs adopted it, smaller fight hard. Enterprise networks are behind too. They all have they reasons.
MerManMaid 2y ago
>What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. This is literally what they did, except they made it 128 bit rather than 64. The thing you're missing is that literally every IPv4 protocol breaks the second you change bit count. Before you change the 32-bit header you need to (a) redefine bit for bit every IP protocol so it can be understood by each IP capable device (b) somehow send a full-proof update to every IPv4 device in the world redefining how they ought to interpret IPv4 headers.
- Borg3 2y ago
  I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. After all those years and R&D put into IPv4 to make it better, we ended up with decent protocol. The only flaw is too small address space. With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. And I will tell it again to be clear. Im not fan of some IPv4+ contraption ideas like lets extend IPv4 address space and try to keep it IPv4. Thats DUMB. Make new protocol, improve things that were bad in IPv4 (are they any?) and try to make it one way interop to IPv4 (IPv6 -> IPv4) and we are done. Remember that you are building protocol for entire planet. It have to be relativly simple and easy to implement. Any extras should be layer up. The whole IoT crap annoys me a lot. This stuff should NEVER ever be connected directly to internet. It creates huge security mess. There should be IoT GW to handle IP <-> (whatever IoT proto) and provide security.
  - MerManMaid 2y ago
    >I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. >>The only flaw is too small address space. >>>With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. ARP, DHCP, NAT, Lack of built in encryption are all huge problems that had to be addressed. - ARP: incredibly inefficient, prime vector for abuse by malicious actors via arp poisoning - DHCP: Man in the middle attacks, need I say more? - NAT: Literally breaks the whole concept of IP addressing, incredibly inefficient as it requires manipulating packets mid-stream, literally designed as a temporary band aid to smooth our transition away from IPv4 - Built in encryption: You say this makes this more complicated but I believe it is the opposite, better security is built into the foundation rather than having to build it into every protocol on top of it. (ssh instead of telnet, SFTP instead of FTP, HTTPs instead of HTTP, ect) The issue I'm having with your argument is that you're saying that "you're fine with a replacement IP protocol which ditches the bad" and then go on to deride IPv6 for doing exactly what you're asking for. (keeping it as close to IPv4 as possible while ditching the biggest sources of technical debt) >And I will tell it again to be clear. Im not fan of some IPv4+ contraption ideas like lets extend IPv4 address space and try to keep it IPv4. Thats DUMB. But you literally did suggest exactly this when you said: >What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. Did I somehow misinterpret this? >Make new protocol, improve things that were bad in IPv4 (are they any?) and try to make it one way interop to IPv4 (IPv6 -> IPv4) and we are done. IPv6 does provide a way to do exactly this, it's called NAT64 https://en.wikipedia.org/wiki/NAT64?useskin=vector https://en.wikipedia.org/wiki/NAT64?useskin=vector >Remember that you are building protocol for entire planet. It have to be relativly simple and easy to implement. Any extras should be layer up. Again, this really makes me think you don't work in networking. When you abstract security from the underlining protocols you essentially leave a gaping hole in your security. The only surefire way to communicate securely is to bake encryption into the protocol itself. (and even then it is hit or miss) This is why we moved from HTTPv2 to HTTPv3 This is why we stopped wrapping telnet into IPsec Tunnels and opted for SSH, this is why we stopped wrapping HTTPv2 in TLS tunnels and baked it into HTTPv3, and so on. I don't want to spend a lot of time on IoT but as a network engineer I can say that they exist whether you like them or not and make up a large portion of traffic so we can't just not consider them when talking about how network protocols ought to be designed.

by Borg3 2y ago

zokier 2y ago

The thing that you and all other ipv6 haters miss is that none of that matters. Ipv6 is happening, like it or not. And that had been the state already for 10-15 years. Maybe in the 00s there was window when there might have been true doubt if ipv6 was going to happen. But after that, it was just question of "when", not "if". Keeping on hating is simply not very productive. It's just much better to embrace ipv6, no matter it's possible flaws.

growse 2y ago

> What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. Tell me you've never had to seriously design and operate networks at scale without telling me etc... This is a bit like Chesterton's fence - until you understand why (for example) ARP is a hilariously bad design and a major problem when trying to design networks at scale, then you can't understand why someone might want to replace it with something more effective. IPv6 doesn't get a lot of stuff right, but the motivation behind replacing v4 was much more than simply "more addresses pls". IPv4 was the mistake, Vint Cerf is on the record as saying so. Should never have been let out of the lab.

Borg3 2y ago
Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. IPv6 took its ND and bring a lot of other problems that we are solving AGAIN. Pure waste of time and effort. Also, please cut the crap about IoT and Hyper IP networks centrally managed. Thats just serveral huge corporations. Majority is Internet is small/medium shops doing it completly different. Yet, big boys pop in and say you do it wrong, you must do it our way or go away. Not nice. Yeah, that motivation become overengineering. They provided protocol that does NOT fit the needs it seems. IPv6 will probably happen indeed. I doubt someone will popin with great protocol that will make IP obsolete. Also, I wish IPv6 would really took off, because even if I personaly dont like IPv6, it success would provide me IPv4 address space for my retro networking projects.
- throw0101d 2y ago
  > Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. ARP poisoning is the least of ARP's problems. It can potentially have a blast radius that can bring down networks, and if it was actually sorted out, then things like BGP EVPN would not need to have been invented. One of touted benefits of BGP EVPN is reduced ARP and Layer 2 broadcasts. I've seen ARP storms bring down even 'small' company networks (dozen switches for ~200 people) because someone fed a simply desktop switch back in on itself and the access layer switch in the closest could not do STP with the simple switch.
  - Borg3 2y ago
    That is not ARP problem. Its called broadcast storm and its problem of stupid people and/or bad equipment. You can bring any network down with incompetence. Thats why newer switches have STP, DHCP Snooping, ARP security and so on. Now take a look at ND tables exchaustion alone. Trival attack to do on IPv6 segment. Is it solved yet? I dont know. I do NOT track it. The whole PnP (I call it Plug and Pray) is terrible aproach imo. IoT created hella of security problems (biggest DDoS botnets are IoT). If someone need autoconfiguration, he can slap DHCP on segment. Easy and super old protocol on IPv4. (IoT connected directly to internet? thats stupidy.. but I will leave that to other talk). So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.

throw0101d 2y ago

> Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that? Negotiation. IPsec using IKEv2 (RFC 4306/7296) started with (e.g.) 3DES when it was initially released, but now allows for AES (RFC 3602, 3686, etc), as well as other algorithms: * https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml https://www.iana.org/assignments/ikev2-parameters/ikev2-para... > What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. For anyone curious, the technical criteria for choosing the (then-labelled) IPng: * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 And the evaluation of the available candidates and why the winner was chosen: * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752 One of the IPng candidates, SIPP, indeed did extend addressing from 32-bits to 64-bits (RFC 1710, RFC 1752 § 7.2), but it was deemed that it may not enough and another transition would be even more difficult, so they went with 128-bits (RFC 1752 § 9). Adding mechanisms for auto-configuration was one of the criteria for IPng; per RFC 1726 § 5.8: CRITERION The protocol must permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is required. DISCUSSION People complain that IP is hard to manage. We cannot plug and play. We must fix that problem. We do note that fully automated configuration, especially for large, complex networks, is still a topic of research. Our concern is mostly for small and medium sized, less complex, networks; places where the essential knowledge and skills would not be as readily available. In dealing with this criterion, address assignment and delegation procedures and restrictions should be addressed by the proposal. Furthermore, "ownership" of addresses (e.g., user or service provider) has recently become a concern and the issue should be addressed. We require that a node be able to dynamically obtain all of its operational, IP-level parameters at boot time via a dynamic configuration mechanism. […] In a world of IoT, not having to have a BOOTP/DHCP(v4) seems like decent foresight.

ragall 2y ago

> Thats why market does NOT want it. What market are you talking about ?

Borg3 2y ago
Market as a whole Internet. Some ISPs adopted it, smaller fight hard. Enterprise networks are behind too. They all have they reasons.

MerManMaid 2y ago

>What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. This is literally what they did, except they made it 128 bit rather than 64. The thing you're missing is that literally every IPv4 protocol breaks the second you change bit count. Before you change the 32-bit header you need to (a) redefine bit for bit every IP protocol so it can be understood by each IP capable device (b) somehow send a full-proof update to every IPv4 device in the world redefining how they ought to interpret IPv4 headers.

Borg3 2y ago
I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. After all those years and R&D put into IPv4 to make it better, we ended up with decent protocol. The only flaw is too small address space. With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. And I will tell it again to be clear. Im not fan of some IPv4+ contraption ideas like lets extend IPv4 address space and try to keep it IPv4. Thats DUMB. Make new protocol, improve things that were bad in IPv4 (are they any?) and try to make it one way interop to IPv4 (IPv6 -> IPv4) and we are done. Remember that you are building protocol for entire planet. It have to be relativly simple and easy to implement. Any extras should be layer up. The whole IoT crap annoys me a lot. This stuff should NEVER ever be connected directly to internet. It creates huge security mess. There should be IoT GW to handle IP <-> (whatever IoT proto) and provide security.
- MerManMaid 2y ago
  >I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. >>The only flaw is too small address space. >>>With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. ARP, DHCP, NAT, Lack of built in encryption are all huge problems that had to be addressed. - ARP: incredibly inefficient, prime vector for abuse by malicious actors via arp poisoning - DHCP: Man in the middle attacks, need I say more? - NAT: Literally breaks the whole concept of IP addressing, incredibly inefficient as it requires manipulating packets mid-stream, literally designed as a temporary band aid to smooth our transition away from IPv4 - Built in encryption: You say this makes this more complicated but I believe it is the opposite, better security is built into the foundation rather than having to build it into every protocol on top of it. (ssh instead of telnet, SFTP instead of FTP, HTTPs instead of HTTP, ect) The issue I'm having with your argument is that you're saying that "you're fine with a replacement IP protocol which ditches the bad" and then go on to deride IPv6 for doing exactly what you're asking for. (keeping it as close to IPv4 as possible while ditching the biggest sources of technical debt) >And I will tell it again to be clear. Im not fan of some IPv4+ contraption ideas like lets extend IPv4 address space and try to keep it IPv4. Thats DUMB. But you literally did suggest exactly this when you said: >What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. Did I somehow misinterpret this? >Make new protocol, improve things that were bad in IPv4 (are they any?) and try to make it one way interop to IPv4 (IPv6 -> IPv4) and we are done. IPv6 does provide a way to do exactly this, it's called NAT64 https://en.wikipedia.org/wiki/NAT64?useskin=vector https://en.wikipedia.org/wiki/NAT64?useskin=vector >Remember that you are building protocol for entire planet. It have to be relativly simple and easy to implement. Any extras should be layer up. Again, this really makes me think you don't work in networking. When you abstract security from the underlining protocols you essentially leave a gaping hole in your security. The only surefire way to communicate securely is to bake encryption into the protocol itself. (and even then it is hit or miss) This is why we moved from HTTPv2 to HTTPv3 This is why we stopped wrapping telnet into IPsec Tunnels and opted for SSH, this is why we stopped wrapping HTTPv2 in TLS tunnels and baked it into HTTPv3, and so on. I don't want to spend a lot of time on IoT but as a network engineer I can say that they exist whether you like them or not and make up a large portion of traffic so we can't just not consider them when talking about how network protocols ought to be designed.