|
|
|
|
|
by Borg3
697 days 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. |
|
>>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
>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.