Re: [44net] The utilization of 44/8

Well, IPv6 does not only bring more addresses. It’s a different protocol with some changes that would be interesting to have. It’s also the current IP version, with IPv4 being the legacy one. Even though we have enough address space in the 44/8 block, I see these two as completely separate protocols. If we, as a community, choose to focus on IPv6, we also benefit all the others out there that are not in the fortunate position to utilize 0.33% of their space. If we use more IPv6 then content providers and eyeball networks have much more benefit from spending the resources to deploy it, and the entire Internet benefits from a move to the new protocol, where everyone has more address space than they need. This helps “democratize” the medium and provide equal access to everyone. End to end connectivity is not just about the people that can afford or already had address space. Everyone can get more IPv6 than they need, and for free, globally. When we deploy IPv6, we get operational experience. We can create guides and write posts about the problems we ran into, and how we solved them. We can produce valuable knowledge that applies to everyone. We can give talks about how we overcame certain difficulties, so people that find themselves in a similar situation in the future do not have to figure it out themselves as well. When we deploy IPv6 we find things that break. Maybe there are tools that only work on IPv4 or have hard-coded addresses, or simply were designed in an era where this may not have been as important. For example I found that Proxmox cannot operate on an IPv6-only host by trying to deploy that in such an environment. I wouldn’t have guessed otherwise. We now have an opportunity to fix these tools, or at least report the lack of support by filing an Issue on GitHub for example. That way progress can be tracked, even if support lands in 3 years. People who want to get started with OSS can now find a list of issues to get started with, which will help them get into the world of contributing easier. When we constantly bug our vendors (e.g. MikroTik) about IPv6 and feature-parity and we always request these features, and we use them, and we report bugs in them, we send a message that this “feature” is important to us (the users), we need it to consider the product functional, and it has to be tested, working, and released together (or before) with the IPv4-equivalent. This helps everyone else on the Internet deploy IPv6, because all their devices now support it easily and reliably, and it’s there already. I see many more reasons, such as learning. Maybe some of us work for an ISP, and if we learn IPv6 on HAMNET, we can then be more confident in applying this knowledge to our work. We have a great opportunity to not just run AMPRNet using the latest standard, but to also help the world get to it faster. I would be extremely happy to see more IPv6 discussion on the list and more IPv6-related projects. Even little posts such as “I added IPv6 support to my ham radio tool X” which could describe the process / obstacles or even “it was 5 minutes of work”. Yes, unfortunately the development is slow, but at least their Wiki and betas are here and you can monitor the progress and even help them test. I also have a number of IPv4 and IPv6 addresses and I receive this traffic as well. I just think it’s normal. It’s part of having public IPv4 addresses. Having 2 Mb/s for a /16 is minimal (given the block size) so I wouldn’t personally consider it disruptive. And about the types of scans, I am not worried either. The solution to not get your SSH access compromised is to have it secured (e.g. with keys, strong passwords, no root logins, etc.) and not by blocking some of the traffic to it. So I always considered this normal and part of “being online”. I understand the concept of “defense in depth” and that this is just another layer, but it seems to me that this is a layer that does not offer a lot in terms of security but instead creates more issues. Of course, every network operator can decide for themselves. I personally think that being able to carry out research is worth it and has more benefit than the cost it may have. Most client devices like IoT, etc. are typically behind an “Established, Related” type of firewall anyways (or should be). Thanks a lot for the pointers! Very nice, organized, and I assume also automatically updated. I may use them in the future if there’s a need for it. However, especially for scans of 44/8 or even more so for 0/0, it’s just impossible to try and find all the similar resources of all the different networks that exist and then also make sure they are up to date. For large scale operations, you typically just want to apply the same methodology to all your research space, not just for the reason above, but also for statistical accuracy. Maybe scanning 44.137 and getting the data from there could produce different results (e.g. if the cron stopped updating it, etc.). Kudos for transparency! Yes, of course, it’s not likely that we’ll ever allocate 44/9 + 44.128/10 completely and at this point 2-3 Echolink Proxy instances being released back to the pool will make a difference. A lot of times it is perfectly fine to do wasteful things. However, just because we can, does not mean they are still not wasteful ;) I do not have any problems with using /24’s for EchoLink, or anything else, we can clearly “afford to be wasteful” at this size. And maybe we should be for this instance. I don’t know, really. However, I was merely pointing out the fact that requiring a single IPv4 *per connection* instead of what the rest of the Internet does which is a single *port* per connection is indeed a lot. I am not blaming the operators of these proxies — again, we can maybe afford to waste it, and it can be the right choice, it’s just that in terms of software design, it seems… suboptimal.. I have not seen the code or delved deeper into the issue to express a more informed opinion, but it’s the only software I know that requires one IP address per client. It just reminds me of the early days of SSL where SNI did not exist, and you needed one public IP address per certificate. Still, it wasn’t one public IP address per connection to your web server.. Thank you Rob for the interesting points, Antonis