Of course these ideas are not that new. IPv6 was supposed to give end-to-end connectivity to all, and originally IPsec was supposed to be mandatory part of IPv6, giving each internet host cryptographic identity. And so on.
replies(1):
IPv6 -together with WireGuard- gives privacy, security, and performance. The downside is the complexity to set it up.
Tailscale builds on the shoulder of giants. IPv4, WireGuard, Samy Kamkar NAT punching, OpenSSH, and probably many more. One of the upsides is the combination of these, and that the management interface in general is easy. But what counts for CA is also true for Tailscale: both are using FOSS to in the end deliver a (proprietary) service.
But because almost everything is build on top of FOSS and there's Headscale (and they're cool with it), this isn't a major issue to me. Like, it is a downside, but not a major one, as vendor lock-in is practically non-existent. In fact, it is likely an upside from a business/support PoV.
Well, T-Mobile US is 100% IPv6:
* https://www.youtube.com/watch?v=QGbxCKAqNUE
Facebook is IPv6-only on their internal infrastructure:
* https://www.internetsociety.org/resources/deploy360/2014/cas...
Microsoft has been moving to IPv6-only for their corporate network (so IPv4 address can be used for revenue-producing Azure):
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
So he better tell those folks that IPv6 is not a thing.
* https://www.rfc-editor.org/rfc/rfc1454.html
Here are the technical criteria for choosing the (then-labelled) IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
And finally the evaluation of the available candidates and why the winner was chosen:
* https://datatracker.ietf.org/doc/html/rfc1752
If someone doesn't want to use IPv6, then what they're effectively suggesting is that we create a new protocol, and role it out to every smartphone, tablet, laptop, desktop, server, (Wifi) router/CPE, ISP router, SMB router, enterprise switches, and IoT device. Meanwhile we've already effectively run out of IPv4 addresses (e.g., ARIN and RIPE pools are zero) and are just shuffling about whatever is left in auctions.
> There's one thing I forgot to mention in that big long story above: somewhere in that whole chain of events, we completely stopped using bus networks. Ethernet is not actually a bus anymore. It just pretends to be a bus. Basically, we couldn't get ethernet's famous CSMA/CD to keep working as speeds increased, so we went back to the good old star topology.
Except for 802.11 Wifi.
Although I've heard some ideas for a IPv4.1 that suffer from the obvious problem, I think the far more common view is rather that v4 is fine and its only problem is solved by NAT. Which I agree isn't actually a long term solution, but let's try to meet the stronger argument.
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.
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.
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.
The only reason why NAT is "solving" the problem is because IPv6 is taking some of the pressure off. T-Mobile US has 120M subscribers:
* https://www.statista.com/statistics/219577/total-customers-o...
And they went to IPv6-only:
* https://www.youtube.com/watch?v=QGbxCKAqNUE
There's no way that would work in a no-IPv6 / IPv4-only world. Comcast ran out of 10/8 address space to manage their cable modems: how would that work without IPv6?
Google says India is 74% IPv6:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
How would that work with only IPv4?
Even on smaller scales, without IPv6, supporting IPv4 with CG-NAT can get really expensive, real fast:
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
My laptop has an IPv6 address, as does the router that routes its traffic. There’s no NAT, that’s true, but there’s still a firewall — only inbound packets from a destination host and port that have been sent to are allowed in. And in enterprise environments, from what I’ve seen, there’s a symmetric NAT on IPv6 anyway — packet comes from a different IPv6 address and randomized port than the one client sent it from, making peer connectivity impossible, as the source port varies by destination host and port.
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.
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-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
And the evaluation of the available candidates and why the winner was chosen:
* 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.
[…]
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.
Google says India is 74% IPv6:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
How would connectivity for 10^9 people work with only IPv4? See also China. Each of those countries is 2^30 people, plus add another 2^30 for the continent of Africa, and you're already over 2^31. IPv4 is 2^32 addresses.
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.
It's a footgun. All footguns have ways to not trigger them, but saying you can't blow off a leg is also inaccurate. Reducing the number of footguns laying about is generally a good thing
> Now take a look at ND tables exchaustion alone.
No different than ARP table exhaustion (a finite L2-L3 mapping table). "First hop security" is a thing in both protocols.
> So, IPv6 should be simple, easy to implement and so less prone to mistakes. All extras should be put layer up.
I would argue that IPv6 is simpler to get going than IPv4: to start you don't need BOOTP/DHCP. In fact IPv4 later took some ideas from IPv6, e.g., 169.254.0.0/16 link-local addresses:
This document describes a method by which a host may automatically
configure an interface with an IPv4 address in the 169.254/16 prefix
that is valid for Link-Local communication on that interface. This
is especially valuable in environments where no other configuration
mechanism is available. The IPv4 prefix 169.254/16 is registered
with the IANA for this purpose. Allocation of IPv6 Link-Local addresses
is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
And yeah.. soft LL in IPv4 is good idea. You can use it. In IPv6 you are forced to use it. Oh thank you, OSPFv3 configuration is so cool on in IPv6..
The place that is behind are corporate networks.
Yes, and there are tools and procedures for that:
* https://datatracker.ietf.org/doc/html/rfc9099
But as the old saying goes: easy things should be simple, and hard things should be possible. I think IPv6 does that.
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.
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.
DHCP snooping, need I say more? Also, if you are operating on network that is high security risk, you just layer VPN on top of it. Thats why they got invented in first place..
NAT is not that bad after all imo. I like its feature that my LAN is decoupled from WAN. Im multihomed and I do not need to bother annoucing prefixes to both ISPs.
Yes, you still misinterpret my statement. I mean: take IPv4 and just extend its address space and create new protocol out of it. It will not work with IPv4 itself because its not possible to do. But why take old IPv4 instead creating something from scratch? Simple, IPv4 works very well, why to trash last 30 years of R&D put to it? Sure, if you can came up with something better, go ahead. IPv6 did not deliver the promise.
Security is not that simple like, slap encryption everywhere and we are done, its more complicated matter. Encryption, control, management, endpoints security, router security. Whats the point of encryption of your device can be compromised due to shitty mgmt and traffic MITM again? Or whats the point of encryption if it can be cracked within hour doing MITM again due to protocol got old.
Yeah, HTTPv3.. created yet another problems that needs to be solved now. Why every time something new pops in, it trash past protocol R&D put to it, bringing same on similar problems AGAIN. Thats pathetic.
IoT, thats good example actually. It have E2E encryption (mostly its all HTTPS) and yet its p0wned so easly creating huge DDoS networks. Im starting to wonder if you have any security clue at all.