Thank you for the kind words David! The U.S. DoD owns 13 /8 networks and according to a blog post in an IPv4 broker ( https://ipv4.global/blog/u-s-department-of-defense-ipv4-address-space/ <https://ipv4.global/blog/u-s-department-of-defense-ipv4-address-space/> ) they want to sell it all off by 2030 or something like that, as they’re going IPv6-only. That’s > 213M IPv4 addresses and I personally think that if it were to enter the market, it could cause more supply than demand. I don’t know whether or not they’ll actually do it but it’s about as many addresses entering the market as the current amount that changes hands in 7-8 years. I think that focusing on IPv6 and IPv6-only networks is the right path forward, and if you see the IPv6 map of the blog post, we are giving out IP space “wastefully” and we still haven’t even allocated a /10 out of the /0 (or more accurately the unicast /3). I would really like to see more and better IPv6 support in modern tools, especially in ham radio, with the goal of having them work fine in an IPv6-only environment (even with NAT64). Maybe people want to work on OSS software and improve its IPv6 situation and apply for grants from ARDC to do so? I don’t speak for the GAC/TAC/Board but personally I think it would be a good idea that could benefit the entire Internet. Antonis

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

On 5/16/21 8:33 PM, Antonios Chariton (daknob) via 44Net wrote: Ok but I *do* use IPv6 on internet, and manage it both on my home and at work.  For a long time already. And I know well about the problems, e.g. the issues with sites and services that claim to be on IPv6 (in DNS) but it does not really work. That has become much less of a problem these days, but up to ~5 years ago it was relatively common to find a server not working or sending a "Apache is installed correctly" page when accessed via IPv6 while the same service worked OK with IPv4. That has caused me helpdesk tickets, and brought me in the situation of "when we would not have IPv6 we would not have had this issue"... I think that is also what holds many ISPs back: deploying IPv6 can "only cause new problems" and it rarely ever brings any new functionality yet. So they have to weigh the disadvantage of causing a new problem and bad reputation against the benefit of going with the times. Apparently many choose to postpone it. I have been bugging MikroTik for several years now.  On the forum, on their email, and also in personal talks to their personnel at their MUM events. A couple of years back, I got the reply "well, rarely any of our customers asks us for IPv6 support" and that may well have been true in their market of pop-and-son wireless ISPs serving some rural community with low-cost equipment. At the moment they are less negative about it but their development of RouterOS v7 is in progress for many years already, and while the current beta (which I download and run in a VM) has some new features that look promising, they also did a complete rewrite of some subsystems (like BGP) leaving them in a currently unusable state. So we cannot test it in real life yet, we have to wait for some more betas to even be able to beta-test it, and then it might take more time before the test outcome is "we can migrate some or most routers in our network". Well we cannot afford to route that over our network.  So we have a firewall at the perimeter that blocks this incoming traffic. Of course in fact we block ALL incoming traffic unless the user of an IP address has explicitly requested to allow it, but that could become impossible when we ever get redundant gateways. So the generic filtering of this research traffic remains a requirement. The data is collected in different ways, some of it is live data (address lists), some additional data is added hourly using scripts that do SNMP polling etc. Of course (some people did not understand that) the info is only available to AMPRnet users. I am not the developer of Echolink and I have no influence on their protocol and software decisions. Echolink uses RTMP/RTCMP and their protocols are not NAT friendly. They also cannot easily be extended to use IPv6 because IP addresses and port numbers are embedded in the packets. Rob