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

On 16 May 2021, at 17:47, David Ranch via 44Net 44net@mailman.ampr.org wrote:

Hello Antonis,

Wow.. what an excellent read and the results are very interesting!

Whenever I see maps like this, I ask myself why do companies like Hp, Ford and the US Government continue to keep such huge swaths of address space that's unused. I'm 99% sure they could sell or even give away huge chunks of address space and never notice. One could argue that unless address block owners cannot demonstrate some level of real usage, they should be forced to release the blocks to communities that will. I doubt that will happen now that we really have commercially viable IPv6 but one can still wish.

--David KI6ZHD

On 05/16/2021 08:20 AM, Antonios Chariton (daknob) via 44Net wrote:

...

Hello fellow 44net users, Yesterday I posted an analysis of the utilization of 44/8 on my blog, and you can find that here: https://blog.daknob.net/mapping-44net/ https://blog.daknob.net/mapping-44net/

I thought you may find it interesting to read, and it also includes a map of the entire IPv4 and IPv6 Internet as a bonus so you can compare our usage to other parts of it.

A note is that currently Germany's 44.148/15 already has very similar utilization to that of one of the most dense networks, 185/8 (comparison with 185.148/15): https://blog.daknob.net/content/images/2021/05/44-de-185-eu.png https://blog.daknob.net/content/images/2021/05/44-de-185-eu.png . According to the ping data, HAMNET accounts for over 75% of the hosts alive during the measurement, so that's a great example of what is possible for the entire network!

I'll be happy to hear any thoughts and comments you may have on the topic.

Antonis SV2OIY _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 16 May 2021, at 19:31, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

Antonios,

Why would there be any urgency for amprnet to move to IPv6? We have an IPv4 allocation, currently about 0.33% of the total available IPv4 space, and as you have researched we are by far not using all of it. There appears to be no urgency to move to IPv6, to get a much larger space, and use even less of it. As long as there is no explosive growth of the number of used addresses (and I don't see a reason why there would be such a sudden growth), it looks like IPv4 is going to serve us well for a very long time! The situation with fragmented IPv4 allocation to users in the internet is what it is, and we as radio amateurs are not going to change that. And of course I do see the advantage of IPv6 on the internet, just do not see it why we as radio amateurs would be in the same boat.

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.

Sure it would be nice to experiment with IPv6, and we have discussed that on this list, and there appears to be some agreement on how we could best do that (i.e. not by applying for some contiguous IPv6 space for radio amateurs, as we did with IPv4), but as it is now a blocker is that the mostly used router in our network (MikroTik) is not capable of running a split network for internet and hamnet (policy routing).

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”.

For now I am waiting for RouterOS v7 to become sufficiently stable to deploy it in our network. Which could easily take one or two more years at the pace it is currently being developed...

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.

Then I plan to route an IPv6 /48 obtained from the ISP into the network with a 1:1 mapping of each assigned IPv4 address in 44.137.0.0/16 to an IPv6 /64. And hopefully by then we have a new backbone network where we can use private BGP peerings to exchange a list of IPv6 nets assigned to radio amateurs worldwide, so we can use that to setup some filtering of "friend or foe", just like we now filter on "44-net or not".

By the way, I am not a fan of "researchers scanning the network". We have a continuous data flow of 2 Mbit/s on our external gateway from self-appointed researchers. That is why there are automatic blocks for researchers who clearly do not know about the structure of our network. Whenever a scan is done from internet to addresses in a /26 range that does not contain any hosts (as registered in DNS), the "researcher" is automatically blocked for some time. There are usually about 60000-80000 entries in that list. So you are not alone!

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).

However, we do track the usage of our address space ourselves. E.g. here you can see what addresses are actively sending traffic at least past one of the two routers of the gateway (i.e. towards internet or between internet tunnels that terminate at our router): http://gw-44-137.ampr.org/cgi-bin/ipaddrs

There also is a view of the route table here: http://gw-44-137.ampr.org/cgi-bin/nlroutes And of course there is the list of allocated addresses (registered in DNS, not necessarily active) here: http://gw-44-137.ampr.org/hosts/

This is live information for which you do not have to scan.

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!

About Echolink: there no need for Echolink to use an entire /24, but to run an Echolink proxy you need one address per proxy, and one proxy can serve only a single user. I wrote software that facilitates the running of proxy farms (unlike the software from echolink.org which runs a single proxy only) and the use of a /24 network is just a convenient subnet size to run a reasonable number of proxies on a single site. So a couple of sites worldwide have chosen to deploy proxies in a /24 network. While it is unfortunate that the protocol was designed in this way, I do not see the use of a /24 out of our allocated /16 (or a couple of /24 out of the total /9+/10) for a purpose that serves amateur radio as "a waste". We can choose between leaving it unallocated or doing something useful for amateur radio with it, and I prefer the latter. Should we ever run out of space in our /16 I can always opt to stop the proxy service and use the subnet for something else. But I don't think that will happen.

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:

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.

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.

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 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".

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.

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.

Thanks a lot for the pointers! Very nice, organized, and I assume also automatically updated

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 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 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