On 28 Jul 2021, at 10:08, Antonios Chariton (daknob) via 44Net <44net(a)mailman.ampr.org> wrote: Hello Tony, thank you very much for your e-mail! Indeed, some users will have to renumber under the proposed scheme. This is why we included the statement to the Board that they will support these users in doing so. As a side-note, most of the TAC will have to renumber to some degree and ARDC will have to renumber its infrastructure as well.

Hello Tony, thank you very much for your e-mail!

Indeed, some users will have to renumber under the proposed scheme. This is why we included the statement to the Board that they will support these users in doing so. As a side-note, most of the TAC will have to renumber to some degree and ARDC will have to renumber its infrastructure as well. We hope that we will give everyone adequate time to do that, so it will be as painless as possible, but this depends on the people doing it as well, how early they will begin, etc.

For a renumbering of BGP space where Geolocation is important I think it will slightly increase the time it takes, but probably not the effort. What I would do is to get an allocation from 44.31/16 right now and change its geolocation by notifying all the providers as soon as I begin advertising it. From my personal experience, most providers will have updated their location within 2 weeks, but the tail end of them will need up to three months. If geolocation is important, you can wait for 3 months, or however much it takes for the provider you rely on to update it, and then perform the migration within e.g. 1 or 2 months. After this is done, you can release back the 44.190/16 space back to the pool. The TAC proposal will likely cause a lot of changes in the geolocation landscape of the IPv4 Internet, so if there are some particularly slow providers there, we could definitely reach out to them, inform them of this change, and request that they update more frequently if possible.

Also, in case it wasn’t clear, we don’t expect people to migrate immediately after the Board approves this. There will be a transition period of O(months) definitely. However, it will not be a “flag day” where we go at a specific date and time and change everything, globally. People will have to slowly migrate at a pace they can be comfortable with. We don’t want to cause any more trouble than we have to. The only reason to accelerate the transition is that as more and more people migrate to their respective use case, they may adjust their routing and firewall rules, which means that you will slowly lose reachability if you are on the “wrong” use case.

Finally, for the record, 44.190/16 was a space that concerned us a lot, as it’s exactly what you describe. However, most Direct BGP users were in 44.0/10, and 44.128/10 already had multiple /16’s worth of Intranet users. About 80% of the IP addresses that respond to a ping and are exclusively available via an Intranet reside in this block. I hope the above answer is adequate, but I will be happy to provide more information if needed.

Yes not painless for me. One of my use cases for a BGP advertised network in the 44.128/10 is that a DMR master sits within the range.

It was specifically chosen rather then a ISP's  IP as the master address would not change as it had a bit more autonomy then one provided by an ISP which was out of our control if we wanted for example to change ISP.

The result is a very large number of repeaters spread around remote locations in Australia most requiring 4WD access some not even accessible until the dry season that would need to be visited to update the repeater config via laptop.

I can do it but it's in no way painless.  I might be in the minority but for us it's not just a couple of web sites.

On 28 Jul 2021, at 11:40, Tony Langdon via 44Net <44net(a)mailman.ampr.org> wrote: On 28/7/21 7:08 pm, Antonios Chariton (daknob) wrote: Arrrgh, your use of Reply All and not deleting the direct email disabled my Reply List function, it seems. :(

Hardly painless! I have a VPS with approximately 200 active IPs on it. A number of the services are tied to a specific IP, requiring third party intervention to get working again, which requires a degree of coordination One of the reasons I switched from provider commercial IPs to 44.190.x IPs was to avoid that, as my service provider has had to renumber a few times over the years, as his commercial arrangements changed. This would be the most difficult transition, as I'll have more IPs than ever before to manage, unless I do it in a few stages. I'd also be hoping I can parse some configuration files through sed (hand editing 200 entries is error prone!). Does anyone know how many IPs a Linux box can have on an interface?

Seems the provider Echolink uses is near the longer end of that range. :(

I can see why you're doing this, and on paper, it's a good idea. Ironically, for me, the IPIP tunneled space on my LAN would be easier to renumber!

It's going to be a nightmare scenario this time, the last time put my D-STAR reflector (REF023) offline due to unanticipated complications. I think I can avoid this one, however. Luckily, my DVSwitch and other digital reflectors aren't in this space. Off the top of my head, the IRLP and D-STAR reflectors require external administrative intervention to change. The Echolink infrastructure doesn't require outside help, just a LOT of reconfiguration, as every IP involved has to be explicitly configured. The easiest part is the web and normal Internet services, which just require DNS changes (a dozen or more A records is about the size of that). Luckily I never trusted the geolocation enough to register an Echolink relay server, otherwise I'd have to contact them as well.

I think I've covered everything. ;)

On 28 Jul 2021, at 12:57, g4ugm via 44Net <44net(a)mailman.ampr.org> wrote: Fellow Hams, I don't see how this helps amateurs with ISP provided routers. All the ones I have encountered supply a single gateway via DHCP and do not permit additional routing options. So anything on the routers ring fenced LAN will route any "routable" packet, and all packets starting 44.x.x.x are routable to the ISPs router. So if you start splitting the 44 range then you are you going to have to manually add routing entries to each device on your network? Surely routing should be done in a router not spread round individual devices? If you want to get involved in networking you should get a decent router. Dave G4UGM

So for me, the static routing capabilities of the ISP router are irrelevant, I've designed my network to ensure that's the case.

On 28 Jul 2021, at 14:02, Tony Langdon via 44Net <44net(a)mailman.ampr.org> wrote: On 28/7/21 9:51 pm, Rob PE1CHL via 44Net wrote: I agree. I like to have control of the capabilities of any specialised routers that I use, and a separate Raspberry Pi is one way to do that. My network also ensures that only devices which need 44net access get it. If I ever have a need for a wifi device like a phone or laptop to get such addresses via DHCP, I'll work something out, to physically or logically separate the networks enough to allow 44net DHCP. That's not a problem I currently have. More flexible that way, and works for me. I also have a /28 of commercial ISP space routed here via VPN, which is used by a select few hosts. I could never run my network entirely on standard end user routers.

On 28 Jul 2021, at 19:15, Pedro Converso via 44Net <44net(a)mailman.ampr.org> wrote: Thanks for answering Antonis, but I don't quite understand. Argentina has many hundreds of 44.153.x.x hams your can see on http://amsat.org.ar/amprhost.txt Many of these users have 44.153 gateways portal registrered, installed and operational thru ip encap, with tcpip services protocols and aprs radio and/or over internet using Rasbperries, Linux PCs or routers. As for now no BGP are in use, that doesn't mean BGP won't be used in the future. This network has been in succesful operation since the eighties, and keeps on growing. Question again is, this proposed change will afect or impair our operation ?. Please be specific as yes or no. Thanks, 73, lu7abf, Pedro 44.153 Coordinator _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

From the description of your use case it seems that you will not have to do any modifications if this proposal is approved. If you want to use this address space with BGP in the future (or through the PoPs), we can look at it at the time, as I don’t know in which state everything will be by then. So the answer is “No, you won’t have to do any modifications”. Antonis

A lot of people out there not only don’t want, but also can't use the equipment that you use, for whatever reason. A lot of people out there don’t know what a VLAN is, or what DHCP is, or what a VPN is. They are also not interested in learning that, just so they can access X’s EchoLink Proxy or Y’s webSDR..

What we want is to make sure that the network we create is open to as many people as possible, regardless of knowledge, background, location, financial status, etc. By definition, this means that the bar must be as low as possible to join. That’s what we’re trying to do. Decrease this barrier. We don’t want to enforce static routers, or brands, or routers, we only want to decrease the barrier, as much as we can.

On 28 Jul 2021, at 13:45, Tony Langdon via 44Net <44net(a)mailman.ampr.org> wrote: On 28/7/21 9:18 pm, Antonios Chariton (daknob) via 44Net wrote: For me, the router's capabilities are actually irrelevant. Talking about my tunneled /24, I use static IPs for hosts that I want on this network, and these have a single static route (2 actually) to route 44net IPs to the Pi that runs as an IPIP mesh router, which makes the final decision as to where to send the packet. Other hosts on the LAN don't know about these addresses or routing, and ill attempt to use the ISP (as appropriate), where only those ranges announced via BGP can be reached. So for me, the static routing capabilities of the ISP router are irrelevant, I've designed my network to ensure that's the case. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 28 Jul 2021, at 15:16, g4ugm via 44Net <44net(a)mailman.ampr.org> wrote: No it doesn’t.

In the UK NO ISP (That I know of) provides a router which such supports this. The main ISPs so British Telecom, Virgin, Plusnet, TalkTalk and Sky all supply customised "own brand" routers. These remove the ability to add static routes to the table. I ran into this issue a long time ago as I run a Token Ring network for some vintage equipment and ended up buying a Draytek router to fix the problem.

Those wanting to participate in IP over Radio need to be involved and understand what they are doing. I personally deplore this modern dumbing down, point and click operation. Radio should be about technical exploration. If you want to be involved in Amateur Radio Networking then you should have the appropriate equipment and know how it works.

Fellow Hams, I don't see how this helps amateurs with ISP provided routers. All the ones I have encountered supply a single gateway via DHCP and do not permit additional routing options. So anything on the routers ring fenced LAN will route any "routable" packet, and all packets starting 44.x.x.x are routable to the ISPs router. So if you start splitting the 44 range then you are you going to have to manually add routing entries to each device on your network? Surely routing should be done in a router not spread round individual devices? If you want to get involved in networking you should get a decent router.

Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18 napisal: Yet having a 'static route only'  as a least common denominator is not a bad idea either. Certainly comparing in complexity to IPIP  mesh or BGP. Next common denominator should be a VPN to POPs. BGP is something we need to avoid for end users. It has a illusion of a  simple setup, but to understand and manage BGP, this is certainly out of reach for most of radio amateurs.

On 28 Jul 2021, at 13:35, Janko Mivšek via 44Net <44net(a)mailman.ampr.org> wrote: Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18 napisal: Yet having a 'static route only' as a least common denominator is not a bad idea either. Certainly comparing in complexity to IPIP mesh or BGP. Next common denominator should be a VPN to POPs. BGP is something we need to avoid for end users. It has a illusion of a simple setup, but to understand and manage BGP, this is certainly out of reach for most of radio amateurs. 73, Janko S57NK

As a network engineer I would agree that static routes are not ideal and you should avoid them, and that you should use a BGP-capable router as it solves all these problems. But as a TAC member, I have to represent the entire amateur radio community, and I see that people still have to or prefer or want to use this approach.

Rob, I find your last two messages disrespectful for everyone involved in this, that sacrificed hundreds of hours of their own personal time voluntarily to serve the community.

On 28 Jul 2021, at 13:11, Tony Langdon via 44Net <44net(a)mailman.ampr.org> wrote: On 28/7/21 8:39 pm, Antonios Chariton (daknob) via 44Net wrote: Thanks, that's better. I have Reply List back. :) I can still reply privately, if I wish (Reply by default on this list replies to the sender, not the list). I'm not sure what you can do, because I still have to do all of the leg work. Sure, we can allow long crossover times, but that raises the issue of managing 400-500 IPs, and there's still a number of time critical changeovers that have to happen.

That would help, if there was 5 years of guaranteed stability.

netmap sounds interesting, but where does that run? My VPS is also fairly old, so installing new software can get tricky. However, I will have to be careful not to confuse the various services and systems that I'm running. Some things are rather IP sensitive. I have no idea how they'll handle netmap.

Yeah, see what the Board says. Yeah, I'd need some time with the new IPs allocated, so geolocation can catch up. Putting me in San Diego isn't very helpful! :D

Except that network doesn't need renumbering, it's part of the VPN already, and one day I want to run IP over RF, using that allocation.

Don't know if the Germans were running any of that type of infrastructure. I know some other IRLP reflectors use 44.x space (though I'm the only one in 44.190/16), and I believe the IRLP VPN service does as well.

You are correct that this is something that should be managed locally and not by ARDC. It was brought up as an example and the TAC has no intention of setting a policy at this level. This can be seen from our resolution that does not mention anything related. I apologize for the confusion.

We currently have a large number of users that have reached out that have an ISP-provided router that they do not want to change, regardless of cost, as it’s simple and it just works. These users have a radio on their roof that connects to an Intranet like HAMNET. They want a single prefix they can point as a static route to this radio, and the remaining of it to be caught by the default route they have to their commercial ISP. The equipment their ISPs typically give them does not support any kind of VPN or tunnel. Moreover, if they install e.g. a Raspberry Pi to do the VPN, then they still have the issue of “what prefix do I need for the static route”. The 44 address space that is "Direct BGP" made the conscious decision of being available on the Internet, which means that these users should reach them via their commercial ISPs. Some other operators want to only be reached over the Intranet. This proposal gives a way for all these users to finally connect to the Intranet that they want to join without forcing them to massively complicate their network with more equipment, VPNs, dynamic routing protocols, etc.

We therefore believe that it massively decreases the barrier to enter in both cost, knowledge, complexity, and time. For the current TAC, lowering the barrier to entry is something we need to address now, and not in 20 years. We do not like to exclude people and tell them to come back in 20 years because they’re not as knowledgeable or willing to spend the time, money, and effort right now. Instead, we try to serve them today, and help them join the 44 Net.

It is true that there are more advertised IPv4 addresses in 44.128/10 on the Internet. However, according to the study that we did, and is linked in the original post, there is a *massive* discrepancy between advertised space on BGP and actual usage. We see large parts being advertised (entire /16’s) yet only 2-3 users with < 20 hosts within them. Although we looked at the allocation plan, we identified that it’s more helpful to either look at it in more depth (e.g. end-user allocations) or also rely on the ICMP checks we did, where possible.

These checks showed us that about 75% of the IPv4 addresses that respond to ping are available on a large Intranet and the vast majority of that is in 44.128/10. That said, if we did not use 44.128/10 for the Intranet part, we would cause around 75% of the global users (in terms of IPv4 addresses responding to ping) to renumber.

To sum up, I agree that 44.128/10 has more advertisements on the Internet, but in our detailed look, the vast majority of hosts within it are Intranet-exclusive. Therefore, we decided that this should be the Intranet prefix.

This proposal aims to make it as simple as possible for the users to join the network. This can be achieved with a single static route in their ISP-provided equipment, for 44.128/10.

The users don’t want to have to create multiple entries (some equipment limits to 8 static routes) or have to update them regularly every time we allocate something, and until everyone changes their static route to have network splits or reachability problems. If this passes, they can add a single static route (to a radio or a VPN server) and never have to worry about changes again.

Using any RFC1918 prefix for the Intranet has been considered by the TAC. Unfortunately, it comes with a set of problems that don’t occur in the currently proposed scheme: because everyone can use these networks, by definition, there *will* be collisions, and there will be no central coordination and guarantee of non-overlapping spaces. Nobody can prevent two “Intranets” from using the same address space, a lot of users already have a 10/8 network on their homes, that will most likely have overlaps with the Intranet, etc. By using 44.128/10 that is centrally managed and coordinated by ARDC, we guarantee that each user can enjoy a globally unique allocation that is guaranteed to not overlap with existing network infrastructure or with other networks they want to interconnect with.

We want to be able to accommodate for every use case with our proposal, so we don’t want to leave any user or community behind. Perhaps it’s better to think of the two spaces as “Internet” and “Intranet”.

The first use allows communication of hosts to and from the entire Internet, 0/0. The second use case is a private network that only ham radio operators can access. This can be connected with radio links, satellites, VPNs over the Internet, etc. We do not want to force you to use a specific technology. We just want to make sure that we provide a network for both use cases. Your users in The Netherlands may want to remain connected to HAMNET in Germany and the rest of Europe. They may also want to have Internet access with publicly routable addresses. Both these use cases are fine and perfectly acceptable. If you determine that you need to be connected to both networks, and connection to the Intranet is not simply enough, you can request a matching allocation (I think /17?) in 44.0/10, and then set up a “netmap”. This is an iptables target (also available in RouterOS) that replaces the first bits of an IPv4 address. With this, you can leave all the IPs intact so you can communicate with Germany, and on the single point that you connect to the Internet you can advertise the new prefix, and perform “netmap” of the entire old /17 to the entire new /17. So the Internet will see you as 44.0/10 and the “radio network” / Intranet will see you as 44.128/10.

Furthermore, I would like to clarify that this proposal is that of the entire TAC, and I am responding to the e-mails on behalf of the TAC, as its designated Spokesperson. This is not simply the proposal and the opinion of a single person of this body.

I hope this is helpful.

On Wed, 28 Jul 2021, Rob PE1CHL via 44Net wrote: Please suggest some (positive) alternatives.

My opinion is that when you want to offer users hassle-free access the solution is to offer routing capability in a backbone network so that they only have to send their traffic there. While still allowing advanced users to do it themselves. Another opinion is that we should not spend effort on facilitating the use of ISP routers. We cannot know the capabilities of ISP routers now or within the next 5 years, and I can already tell you that there are ISPs that manage the router and do not allow the user to do ANYTHING except some minor changes like setting the WiFi password. Minimum equipment is a dedicated device (router,computer) for AMPRnet routing with software sufficiently advanced to do that. Static routes were used in 1990.

That's a false statement. The goal of ham radio in general is to provide improvement, learning and experimenting. Sorry for being blunt, but somehow the goal of amateur radio was lost here... It was never its goal to provide "easy adoption" of anything. We have CB and PMR radio for that. As we have commercial internet for the networking needs of network noobs. Otherwise we would not have our licensing exams and the licensing system, and the restrictions for using the 44 network space. And as the terms and conditions of the ampr network say, is is no replacement for commercial internet access. I think this organisation and network has lost its goal, direction and its appeal since the passing of Brian Cantor, and the rise of TACs and other "management" organisms that don't seem to share to much with the ham radio spirit of pioneering and inovation. So unless you care to keep this thing uncentralised and distributed the only direction of the 44net is downwards into oblivion. If this is the goal, then you are on the right track. BTW, speaking of the TAC and its decisions, if 100 people speak against something proposed and supported by a small number of people, you may actually consider that the specific proposal may be wrong... Right now I haven't seen to many traction for the proposal here, other than 2-3 people. I wish you all good luck, and will remain just as a bystander with popcorn in both hands, watching the game. 73s. Marius YO2LOJ July 28, 2021 7:44 PM, "David McGough via 44Net" &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Do you suggest that we kick out all the “network noobs” and only have a network of “network pros”? I am personally against the idea of discriminating against users based on their skills. I would not like to be part of a network where only “pros” are allowed and all “noobs” are shown the door. I see great value in being open and inclusive to everyone.

On 28 Jul 2021, at 18:44, David McGough via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Speaking from direct, personal experience, helping thousands of ham operators get VoIP gear (Raspberry Pi 2/3/4 hardware) on-line, I know for a fact that trying to accommodate the myriad of ISP supplied, cantankerous routers could drive a person mad! I wouldn't dream of trying to go beyond the most basic NAT rules on home-grade routers---certainly not adding static routes nor VPNS, etc. This being said, some hams can and do pull this off, but it's way beyond the attainable scope for most.

I've also found that small expenses (say under $100) really aren't a significant entry barrier at all, nor is having hams flash SD cards, configure basic networking, etc. The key is simple, complete documentation and well tested installation procedures. Making it EASY is the key. That doesn't mean no cost.

There is no need to explain that.  I am fully aware which person on the TAC has come up with this shit and that it is only intended to fix his own broken network.  All the others chime in that they have no issue and don't need any fix.

Rob PE1CHL via 44Net je 28. 07. 21 ob 14:40 napisal: I really like to have an explanation of a statement that HAMNET is broken, and from both sides, from you Rob and from Jan DG8NGN as a HAMNET architect.

On 28 Jul 2021, at 14:40, Rob PE1CHL via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: On 7/28/21 2:15 PM, Antonios Chariton (daknob) via 44Net wrote: There is no need to explain that. I am fully aware which person on the TAC has come up with this shit and that it is only intended to fix his own broken network. All the others chime in that they have no issue and don't need any fix. Also, that "intranets within 44.128.0.0/10" now do not have to renumber is no coincidence either

On 28 Jul 2021, at 12:56, Janko Mivšek via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Hello everyone, Rob PE1CHL via 44Net je 28. 07. 21 ob 11:33 napisal: We in S5-Slovenia are also going the similar way as Netherlands - to use an 44.150/16 mostly as 'Intranet' but few of those IPs will be reachable from public Internet. By BGP announcing the whole /16, then selectively filtering traffic on the firewall. We see this way the simplest for both ARDC and our end users, who make their allocated IPs publicly accessible by a simple click on the forthcoming web application.

On 28 Jul 2021, at 12:36, PH5X via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Seems like a waste of a /10 to never route and never announce it to the internet by policy, especially with the current scarcity of IPv4 addresses.

It should be up to the coordinator of assigned 44 net space to decide if they want to announce their network to the Internet or not. It should always be an option to start or stop announcing a block at any time for any reason, without having to renumber entire networks with possibly hundreds of users and thousands of machines. Firewalling and routing policies are also a tool that coordinators or operators can use to steer or block traffic.

With this proposal a machine would require at least two IP addresses from two different networks (with additional overhead for subnet, router, broadcast addresses) just to have connectivity to both. This doesn't help with the limited amount of addresses we have. It would also make it impossible for devices and routers to automatically choose the most optimal path towards a machine, whether it is via a radio link, the internet or a tunnel. This means we would need more address space, and we are not benefiting from the advantages of multi homing.

44.137.0.0/16 for example already shows that a network that connects both to the internet and to a local radio network works perfectly fine. Users only need 1 IP address for a single machine to have connectivity to the internet and to the radio network. There also seems to be a lot more announcements in 44.128.0.0/10 (876 prefixes) than in 44.0.0.0/10 (533 prefixes) or 44.64.0.0/10 (340 prefixes), so your statement that most current Intranet users reside on 44.128/10, and that most Internet-connected users reside on 44.0/10 is not true.

Regards, PH5X

On 28 Jul 2021, at 13:31, Ruben ON3RVH via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Antonios, I don't see this as an improvement on the current network. I see it as a complete useless redesign of the network that will make it harder on the average ham to get onto the network. How does he decide if he want to connect to the (useless) intranet? Why would he want to connect to an intranet, what solutions does it solve and what information can be found on that intranet that should not be publicly available? Keeping in mind that we are amateur radio operators, bound by license and that we should not have any secrets seems contradictory to having a private intranet that can only be reached by radio. Also keeping in mind that radio is not an option for everyone. For example, Belgium has no connectivity to HAMNET and is completely separate and only routable from the internet. We do not have "secret" parts. If he then also want a range to be publicly routable, then he has to request an extra (!) subnet and be smart enough to configure his router with policy based routing so that the public part goes to his allocation and his other allocation is not routed to the internet nor reachable from the other network? This will cause more problems and standard routers cannot do this kind of policy based routing. Thus creating more issues..

I agree with the others that using a publicly routable ip space, especially a /10 is a waste of ip and resources for an intranet. What is the basis of the TAC to consider that a non-issue? It is not because we have large parts of space unused that we should squander it

Also, did you take into account during your tests that not everything responds to icmp ping packets? There are large parts that filter icmp packets at the border.

And for last, please do not rely on static routing! As this is a redesign, at least use dynamic routing protocols.

73 Ruben ON3RVH

On 28 Jul 2021, at 18:19, Ruben ON3RVH via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: You keep mentioning “ We have a large number of users that agree with this statement and they want this private use case supported.” but no one was asked, there was no poll, no onquiry,.. so how did you get the information that a large portion of users only want an intranet?

Everyone I talk to, everyone that wants an allocation here in Belgium wants it to be publicly routable. Because that is what public ip space is designed for.

Intranets should stick to rfc1918 adresses. There is no need for an overlap, an isp will most likely give out ip’s in the 192.168 range. I know of no ISP that gives out ip’s in the 10 range (agreed, I don’t know every isp) but even if they used those ip’s on their wan side that would not conflict as the ham intranet would be routed over a different or tunnel interface and should - never ever - be routed through or by an isp router. But still, what services do the current intranets offer that should be kept offline from the public internet? And even then, it is easy to filter those ranges at the border.

But I am trying to understand: if we give you publicly routable IPv4, what is the problem with other people getting non-publicly routable IPv4? We can foresee that we will be able to accommodate all your current and future requests. Why is it a problem that some other people need it for a different reason? I am really trying to understand from all these e-mails what else we would do with the space..

On 28 Jul 2021, at 15:59, David McGough, KB4FXC via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Hi Everyone, As a casual observer and out of curiosity, I looked over the proposed TAC document and I'm left puzzled as to what REAL problem this proposal is attempting to resolve?? In this day and age of very inexpensive, commodity ARM-processor based computers (like the RPi4B or Rock64, etc.), the notion that cheap routers have insufficient resources to maintain large dynamic (or even static!) routing tables and quickly route traffic, leaves me completely baffled--since I already do this all the time.

Also, I really don't understand why in this day and age of scarce IPv4 space, anyone would want to make a new, private, non-Internet available block?? I realize the original intentions and the purpose behind the 44/8 allocation. With the absolute explosion of directly ham-radio oriented IoT devices, I would argue that Internet routable "experimenters" space is more important now than ever.

internet need to be allocated to a non routable space.

I suggested leasing the space out to provide income

Is there something special I am missing here?

Or is this a good place to sell while the market is way up there for IP space?

On 29 Jul 2021, at 22:04, Mario Lorenz via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Dear Antonios, Am 28. Jul 2021, um 00:31:52 schrieb Antonios Chariton (daknob) via 44Net: I have read the proposal, and would like to ask for clarification on a few points. These points possibly may have been covered in some discussions on the 44-ngn list, so I wanted to review possible discussions there, but the link to the archives of that list on www.ampr.org is currently broken. a) How do you define the "[amateur] radio network" as used in the first paragraphs of your proposal? Is there a difference to the term "Intranet for radio amateurs" as used in your proposed ARDC resolution?

The former reads like a description of involved hardware/systems, while the later describes its users (licensed radio amateurs).

The former could also be read as a policy/guarantee that no non-amateur-radio based means of communication are involved. Is that intended ?

I note that you also use the term "radio-only network" on page 3. Since 44.0/9 according to your proposal is not "radio-only", this would mean that 44.128/12 should not be accessible from 44.0/9, which is the opposite to your proposed resolution.

b) Which route do I need to put into my router to address the radio network ? In particular, how can you answer this question without considering the specifics of each individual case ? Why would there be only one route?

c) Can you back up the "originally intended" claim somehow ? I note that net-44 originated in the USA, which historically has rather liberal third-party traffic rules compared to other countries,

d) You propose a policy of not announcing the prefix on the internet. "the prefix" is presumably 44.128/10. Do I have to understand this as going back to pre-2012 (no direct BGP) or pre, uh, 1990 (someone remind me please when mirrorshades started providing encap tunnels and announcing 44/8).

e) Is there a rationale why existing regional networks cannot decide themselves what level of internet connectivity they desire, considering e.g. the local ham radio regulations and keeping their numbering and infrastructure which have been assigned to them long before ARDC existed as an entity. Is there a particular reason for not grandfathering them ?

f) Would proposed resolution #5, if adopted, direct ARDC to fund AMAZON's network connectivity ? [OK, I don't expect an answer, but ask to consider it as an example that far-reaching proposals must be worded *very* carefully]

Antonios, I really don't get it. ...

44.128/10 CANNOT talk to 44.0/10. 44.128/10 is, in their vision, a completely separate network, which can only be reached via RF. And to communicate with 44.128/10 you would need a new subnet within 44.128/10 ON TOP of your 44.0/10 subnet. So this makes routing in "home routers" (of which most ISP routers/modems cannot add any kind of static routes) more complex as you'll have 2 static routes to take care of and monitor.

On 30 Jul 2021, at 11:39, DD9QP Egbert via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Hi Ruben I agree there still is the split/brain problem. To overcome this into deep things most often might be much more complicated than they look in the first moment. 73 de Egbert DD9QP

Antonios, I really don't get it. I still have no answer to the question what that intranet is/will be hosting that is not suited for the general public. The answer "because we can" someone made is not a valid answer. Translated that would mean you oblige everyone to renumber, just for the fun of it, just because you can make everyone renumber. What I also don't understand is the stated fact that no one should be forced to buy hardware or should know routing protocols to be able to connect to the network or intranet. BUT, after reading through the hamnet documentation that you linked in the "proposal", which is from 2014, it clearly says that you have to have the wireless hardware to connect, buy a (quite expensive license) to connect to, and set up BGP and a route reflector to connect to HAMNET. This sounds like you DO need to know your way around networking and have to invest in hardware to connect to the intranet.

ISP provided routers are not able to connect via RF to another network. Also, the ISP provided routes I have in my setup, do not even allow VPN's. My cable provider router is completely locked and nothing can be added or changed, the only thing I can change, is my MAC address for my fixed IP because I pay extra for a fixed IP.

Since HAMNET is built upon BGP, one should only have to point 44/9 and 44.128/10 towards HAMNET and then automatically be able to connect to the "intranet" and then HAMNET should function as a POP towards the current IPIP mesh (which from the documentation it does) but HAMNET should also function as a gateway towards the current IPIP mesh and internet connected 44 ranges. Which it should know how to do since HAMNET is built upon BGP and BGP only contains routes that it receives from it's neighbours and sends the rest to the kernel default routing table, which for the internet connected 44 ranges would be towards the internet. And from the HAMNET document,(page 40) the HAMNET pop at DB0FHN IS the gateway to the IPIP mesh.

You also state that the intranet is RF only. This again puts a barrier between hams, those that know how to setup their RF environment and know networking, and the rest of the hams that do not. Also with making the intranet RF only, those of us that have no way to connect via RF (Belgium for example has no connection with HAMNET, and I am too far from the German border or Americas to be able to connect via WIFI)

I still don't know what you are trying to solve with this proposal. The object was to make it EASY for EVERY ham to connect to ALL parts of the 44 range, whether that is on HAMNET, IPIP or internet connected ranges, not to make it harder and make a niche intranet. Because a part of Germany wants it.

I would like to see details of the poll about the intranet, which markets were questioned and how they responded with numbers please. 73 Ruben ON3RVH -----Original Message----- From: 44Net &lt;44net-bounces+on3rvh=on3rvh.be(a)mailman.ampr.org&gt; On Behalf Of Antonios Chariton (daknob) via 44Net Sent: Friday, July 30, 2021 03:19 To: 44Net general discussion &lt;44net(a)mailman.ampr.org&gt; Cc: Antonios Chariton (daknob) &lt;daknob(a)daknob.net&gt; Subject: Re: [44net] A new era of IPv4 Allocations Hello Mario, please find my answers below: These are equivalent. The radio network and the Intranet are the same for the given context. Think of it like using amateur radio frequencies vs 4G / 5G frequencies. This is the first point. We do not want to limit the hardware, but we would like to have an IP version of the frequency plan: 44.128/10, however you connect to it, is the radio amateur band, and 44.0/10 is the commercial 5G band or the ISM band of WiFi. One is for people that are licensed, and the other is simply the Internet that anyone can use. Yes, correct. One of the things that this proposal can bring is that a part of the network is reserved for radio amateur to radio amateur communication. This is actually (part of) the proposal. That we guarantee that people in 44.128/10 can only be reached by other people there, and people in 44.0/10 (technically /9) can be reached from the entire Internet, except 44.128/10 (natively). This is similar to how only radio amateurs can transmit in a ham band, but everyone can transmit to an ISM band (including hams). You can address the “radio network” with a single route: 44.128/10. This proposal guarantees that everyone there will be on the radio-only network, the same way transmitting to 144-146 MHz in the EU is to reach hams only. Any traffic you receive is (should be) from a ham, and you should only send anything if you are a ham, and you intend to reach other hams. Transmitting to 2.4 GHz in the ISM band allows you to talk to more people (anyone), but also anyone can talk to you. We probably have a lot of people in this mailing list that were even a part of this and can speak up, but this happened before the Internet was (broadly) adopted and the 44/8 was a way for this “Internet” project some people were working on to talk to this network of these “radio amateurs” that they set up in the USA or Europe, etc. Yes, correct. This proposal wants 44.128/10 to not have any direct BGP allocations that appear on the Internet. Connectivity of these networks should happen between themselves (network to network VPN, radio links, …), the ARDC (or anyone else’s) PoPs, etc. and they will not communicate through the open Internet. Unfortunately this would be difficult to accommodate as the guarantees cannot be offered then. If radio amateurs don’t have a dedicated band to talk to each other, and they have to use the ISM bands, there’s no way to distinguish between normal people and licensed hams. You can’t tell and there’s no guarantee that the person you’re speaking with is a ham or anyone else. Similarly to the RF world, in IP there’s this kind of problem as well. If you have IP addresses on the Internet, you could receive traffic from anyone. Sure, you can use an ACL or a firewall, but that’s not guaranteed. Packets could be spoofed for example. If you have a special network where you know that all senders and recipients are hams, then you can build things with different assumptions. You can build internal tools or apps, websites, etc. It’s up to you. It’s a band where you will only find people of the same hobby as you, that are licensed. The other part is like an ISM band. Sure, you can use this to talk to other hams, and you can use it to talk to non-hams, and non-hams can use it to talk to you, and you have to establish by your own means who is who, and ensure that they can’t trick you. What our proposal aims to do is to create a separate “Ham Band” / Intranet / 44.128/10 and a separate "ISM band” / Internet / 44.0/9. By using simple RF or IP you can’t have them collocated into the same space. This is the reason why we cannot have scattered space and we want to have it aggregated and easy to address. Instead of our “band plan” being hundreds of lines and have it change daily, and move band from “ISM” to “Amateur Radio” and vice versa, we want to create a very simple band plan of 2 entries that don’t change. One is, and will remain to be “ISM” (44.0/9) and one is, and will remain to be “Radio Amateur” (44.128/10). Having a more stable and simple band plan is easier for everyone. They can make more informed decisions for the future, they can choose who they want to talk to, and they can even decide to use both bands: use a handheld radio (Radio Amateur) and a phone with WiFi (ISM). This is what we try to do on a technical level. Clearly define the two bands, and make sure that they are very few, and very stable. In the IP world this translates to easier routing (each “band plan” entry is a route, and if it’s just one, it could even be a static one), and less frequent changes. I don’t have to consult today’s band plan to know why 44.5.5.5 does not respond from 44.128.128.128, if the reason is that 44.5.5.5 decided to be Internet-only today or Intranet-only tomorrow. We could have made use of complex routing protocols and policies that would dynamically try to discover what each address or subnet is (because it’s not always clear and we can’t always tell what each address wants to do, even if we forced everyone to connect to an ARDC PoP) and then continually adjust this and maintain a complex state. This is something that a lot of people would also have to do, or they would have to find someone to do it for them (e.g. the ARDC PoPs). Going towards our value of being as inclusive as possible, we did not want to force people that don’t want to to have to do this or to have to connect via an entity that can do this. By having a 2-line band plan that doesn’t change over time people can even hard-code it if they don’t want to deal with all of this complexity or necessarily rely on someone to do it for them and then form a dependency to them. Furthering the analogy, a handheld VHF manufacturer relies on a constant band plan to allow TX to 144-146 MHz and doesn’t have to build a system for their product to download this hour’s or this day’s Amateur Radio allocation and change the functionality based on that. You can also be sure that your local amateur radio repeater won’t be today at 89.7 MHz and your favorite radio station won’t transmit to 145.500 MHz this afternoon. That’s an interesting point, and we could look into improving the language, but we thought that the “TAC-proposed Global PoP Infrastructure” was specific enough to prevent ambiguity. In any case, I imagine that after we deliver our proposal to the ARDC Staff, it will be vetted by both them, and the Board, to avoid problems like that. Thanks for mentioning it though! I hope this clarifies it enough for everyone, Antonis _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Let the users, who are technologists after all, work out how to route traffic based on their own needs.

Gerrit, I re-iterate myself, but what you should tell them, and then actually do it, is point 44/9 and 44.128/10 towards their radio and fix hamnet. Users should only have to point the two routes 44/9 and 44.128/10 towards their radio. THAT IS IT. The Hamnet BGP enabled backbone and the pop DB0FHN should take care of the rest. **It is as simple as that.** Supposedly, from the docs linked in the proposal, DB0FHN has the connectivity to the current IPIP mesh. So what is the problem then? Maybe the rest of the 44 network that is internet only connected? Well that shouldn't have to be an issue either. Route the rest of the 44 network that is not known in the IPIP mesh (the larger /9 & /10, as more specifics will be routed to the IPIP mess peer) towards it's transit provider and you're done. I just don't get why hamnet is making such a big deal of what should be a very simple networking task.. 73 Ruben ON3RVH -----Original Message----- From: 44Net &lt;44net-bounces+on3rvh=on3rvh.be(a)mailman.ampr.org&gt; On Behalf Of Gerrit Herzig DH8GHH via 44Net Sent: Friday, July 30, 2021 16:31 To: 44Net general discussion &lt;44net(a)mailman.ampr.org&gt; Cc: Gerrit Herzig DH8GHH &lt;dh8ghh(a)darc.de&gt; Subject: Re: [44net] A new era of IPv4 Allocations Hello Charlie, As stated earlier, I am a region coordinator for the HamNet in Germany. I have a lot of users who are using the HamNet via RF access, but they are no network technologists. They keep asking me, which route they have to set in their FritzBox to be able to reach HamNet destinations as well as internet-only destinations of the 44 net. What shall I tell them? The answer to this question is the proposed band plan. I do not understand why this is considered as a bad idea. What are you loosing by accepting this proposal? Nothing except the time needed for the necessary changes. I know the effort, we have been affected by the sale... As stated earlier, I - and most of the european HamNet users - route 44/8 via RF at the moment, which is obviously not a good idea. So please accept the proposal or provide a better solution that does not require to become an "network technologist". Renumbering to RFC1918 & RFC6598 is not a solution as Antonios already wrote in several emails. 73 de Gerrit, DH8GHH -----Ursprüngliche Nachricht----- From: Charlie Smurthwaite via 44Net Sent: Friday, July 30, 2021 2:29 PM To: Mario Lorenz via 44Net Cc: Charlie Smurthwaite Subject: Re: [44net] A new era of IPv4 Allocations Apologies for more email, but I would just like to throw in my own (very simple) personal opinion on this topic. I strongly believe that the correct solution is to divide up the IP address space geographically (ie by country), and then simply give out allocations, regardless of purpose, as is the case already both with 44net and the rest of the IP address space. This gives people the flexibility to use the IP addresses in whatever way they see fit, whether that be a well known radio protocol, an experimental radio protocol, a tunnel, an experimental wired protocol, or just Amateur radio related services on the public Internet. Let the users, who are technologists after all, work out how to route traffic based on their own needs. Any attempt to artificially carve up the address space by purpose will only further confuse matters. There isn't a single unified 44 network, and not everyone who runs by RF necessarily wants to be connected to or disconnected from any other network, including the Internet. Charlie _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Gerrit, I re-iterate myself, but what you should tell them, and then actually do it, is point 44/9 and 44.128/10 towards their radio and fix hamnet. Users should only have to point the two routes 44/9 and 44.128/10 towards their radio. THAT IS IT. The Hamnet BGP enabled backbone and the pop DB0FHN should take care of the rest. **It is as simple as that.** Supposedly, from the docs linked in the proposal, DB0FHN has the connectivity to the current IPIP mesh. So what is the problem then? Maybe the rest of the 44 network that is internet only connected? Well that shouldn't have to be an issue either. Route the rest of the 44 network that is not known in the IPIP mesh (the larger /9 & /10, as more specifics will be routed to the IPIP mess peer) towards it's transit provider and you're done. I just don't get why hamnet is making such a big deal of what should be a very simple networking task.. 73 Ruben ON3RVH

...having something (44/10) routed via BGP on the internet is "making it _available_ to anyone without a licence". That does not mean that the Ham operator is going to reply to anyone.

A Ham "on" 44.128/10 would have an IP on 44.128/10, they would be wanting to "route to" 44.128/10, but would already *be on it*.

That seems quite an absolute position. :(

Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent. Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information! You can find our 5-page PDF here: https://pdf.daknob.net/ardc/tac128.pdf <https://pdf.daknob.net/ardc/tac128.pdf>

On 10 Aug 2021, at 23:30, Toussaint OTTAVI via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote:  The purpose is not only to allow/block traffic. The TAC proposal describes two different user cases (called "Internet" and "Intranet") that suit different needs all over the world. Some of us are already using some similar schemes, but with different implementations all over the world. This makes routing a headache, and there are many situations where sysops don't know how to route traffic correctly. F/ex, in France, most of D-Star or DMR stuff which have 44et addressing are in fact using dual addressing, and have also a classic Internet IP, so that they can be reached from Internet. The separation into two subnets proposed by the TAC solves that, by defining clear routing policy for each subnet : - The "Internet" subnet is routed on public Internet via eBGP, and packets are carried via Internet - The "Intranet" subnet is not announced on Internet, but is only routed internally (as European HamNet does with iBGP) In your situation : - If you want to be reachable from public Internet, you can choose the "Internet" subnet, and set up your firewall rules according to your needs - If you want to be on a completely closed network not reachable from public Internet (such as Hamnet), then you can choose the "Intranet" subnet. Here, we decided to use the best of both modes. We're using dual addressing, and each site can have both Internet and Intranet addresses. Any device just needs to be connected to the right Ethernet interface, and it automatically gets the right IP, and the right routing / firewalling policy. The TAC proposal is a normalization of what some of us are already doing, with 44.190 "Internet / no country", or with BGP announcement of 44.x subnet. It offers clear segmentation about the two modes, and should help setting up routing policies by just having two big subnets. With the current proposal, and if you need your full IP range to be reachable directly from public Internet, then yes, I think you'll have to renumber to something in in 44.0. Anyway, I would answer to your question by another question : Even with a good firewalling, do you really need and/or want all your IP range, all your endpoints, all your users to be exposed to public Internet ? As said before, we choose to use both addressing, and we decide individually for every application or device device. F/ex : - D-Star, DMR, XLX -> Internet subnet - Remote control of HF radio-club station -> Intranet subnet Then, another option for you would be : - Keep your current network in 44.138, but consider it as "Intranet", "HamNet clone", and stop announcing it via BGP - Get another subnet in 44.0 for "Internet" and announce it via BGP - Choose individually what devices need to be reachable from public Internet (they should not be the majority), and just migrate/renumber those to 44.0 Or better suggestion : Do dual addressing everywhere like we do :-) If things work well, we (the TAC and all the sysops here) should be able to define clear routing policies, build a backbone, define a common POP policy, and define standard configuration for "Access" routers or endpoints to be implemented on a wide range of low-cost platforms :-) Of course, this would involve some work for everybody. But if we want to make 44net access easier and gain users, it seems obvious we'll have to migrate the current mess (there are not two user groups that do exactly the same thing) to something a little bit more normalized and harmonized ofer the world. Then, we all will have to change some things, HI :-) 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Dual addressing means complicated policy based routing. The remaining 44net that we have today is ham only. Thus if one does not the internet to reach his/her subnet, all they have to do is add a simple firewall rule allowing 44/8 and 44.128/10 and denying the rest. That is a lot easier than policy based routing or dual addressing. That would allow fellow hams to reach the subnet, but not the rest of “the big bad internet” Ruben - ON3RVH

This is easily fixable at the pop level. Still no need for complicated setups. Since every subnet has to he known in the portal, a script could parse the portal for all known subnets and only allow those in and block the unknown subnets. Again, no need for complicated routers/routing. At the edge level you allow 44/9 & 44.128/10 and the pop filters the rest so that bgp hijacked subnets cannot even get to the network, let alone your edge There’s a simple answer to all cases that does not need renumbering. We also cannot have a part of the network not reachable for other hams and cannot ask every ham to have 2 subnets and do complex routing themselves.

Amprnet is an open network for hams and everything should be easily reachable to all hams that connect to amprnet.

Ruben - ON3RVH

On 11 Aug 2021, at 00:51, pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Well as I said to Ruben this is wrong. You may think you will fix the problem with such simple fix. The networking world is not as "clean" as you think. Once someone advertise a subnet in the 44.0/09 or 44.128/10 they would have access to your network. The thing is that it is already happening and AMPR/ARDC are already monitoring such event but it take times to find those rogue people, then AMPR need to contact the owner of the network that provide the bgp route top the rogue guys. Those could be legit guys but are with the rogue group and they could delay for days if not weeks the action needed to secure back YOUR network. Do you want to leave the front door of your house to the public if you were made promises that no one but the legit owner of the neighbourhood would have access to the road in front of your house? Not the same security risk I think. Pierre VE2PF ________________________________________ De : 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Rob PE1CHL via 44Net &lt;44net(a)mailman.ampr.org&gt; Envoyé : 10 août 2021 17:57 À : 44net(a)mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] A new era of IPv4 Allocations : Agree I agree! That motivation to split the network is totally bogus. Everyone in 44.0.0.0/9 and 44.128.0.0/10 can be "trusted" to be radio amateurs, it does not matter if they are on an isolated network or on a network connected to the internet. How it is routed (over radio or over internet tunnels, using what routing protocol, and what policy, does not matter at all. Of course on an isolated network you can have bad guys as well, so you will always have to be careful what you open up to others. Rob _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Well as I said to Ruben this is wrong. You may think you will fix the problem with such simple fix. The networking world is not as "clean" as you think. Once someone advertise a subnet in the 44.0/09 or 44.128/10 they would have access to your network. The thing is that it is already happening and AMPR/ARDC are already monitoring such event but it take times to find those rogue people, then AMPR need to contact the owner of the network that provide the bgp route top the rogue guys. Those could be legit guys but are with the rogue group and they could delay for days if not weeks the action needed to secure back YOUR network. Do you want to leave the front door of your house to the public if you were made promises that no one but the legit owner of the neighbourhood would have access to the road in front of your house? Not the same security risk I think. Pierre VE2PF ________________________________________ De : 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Rob PE1CHL via 44Net &lt;44net(a)mailman.ampr.org&gt; Envoyé : 10 août 2021 17:57 À : 44net(a)mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] A new era of IPv4 Allocations : Agree I agree! That motivation to split the network is totally bogus. Everyone in 44.0.0.0/9 and 44.128.0.0/10 can be "trusted" to be radio amateurs, it does not matter if they are on an isolated network or on a network connected to the internet. How it is routed (over radio or over internet tunnels, using what routing protocol, and what policy, does not matter at all. Of course on an isolated network you can have bad guys as well, so you will always have to be careful what you open up to others. Rob On 8/10/21 11:40 PM, Ruben ON3RVH via 44Net wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 11 Aug 2021, at 15:00, pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: You really dont see the big picture and only look at local solution for your specific need and case. What if a large group of ham make it possible to run a very large network of microwave links and you can connect to it from your home with a simple little radio from tp-link at 45$ US. Now you would like to connect to other ham. and you would like to have other ham to connect to your service you provide from that connection. How to you propose to have your need fufill with firewalling? How do you propose to have no other traffic than ham stuff that connect to your services? Will you manage login/password system to let only ham access some SDR receiver you provide? How many ham will you manage? do you have the coding skill to implement such things over other working software ? If not you, the other ham that would love to leave free accress to all ham? With your solution of firewalling they are left in the dirt. I see your next point comming. The ham that feed the links to the internet should firewall on their side. Ok , and how should they manage other hams that are not connected inside their RF network? make eception in the firewall rules? And what if someone on the internet spoof some IP adress? Cause it is easy to do so. We have seen this just the spring and there could still be some doing it right now undetected yet. And what about the LARGE firewall rules the rf link provider will need to create as each new user that want or dont want to be behind the big firewall? Pierre VE2PF ________________________________________ De : 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Rob PE1CHL via 44Net &lt;44net(a)mailman.ampr.org&gt; Envoyé : 11 août 2021 04:28 À : 44net(a)mailman.ampr.org Cc : Rob PE1CHL Objet : Re: [44net] A new era of IPv4 Allocations : Agree You already proved yourself wrong in the answer to Ruben. It does not matter how you layout your network, there is always the risk of bad people no matter how you do it. So everyone has to put a firewall close to their precious computers that allows outsiders to access only what they want them to access. You can partly use the source address for some of that validation, but that should only be used for noncritical access rules like "are they allowed to use my NTP and DNS server" and not critical rules like "are they allowed to operate my transmitter, or enter information in my system". For that, a separate authentication method is always required. It has been discussed before, it would be nice to have a global authorization system where you can validate that a user you have not registered locally is a valid radio amateur license holder, e.g. user VE2PF can be validated using some method like username/password, user certificate, etc. So people who forced their entry into the network still do not have that. But there is no way that some split in the network address range is going to provide anywhere near that, it will just be snakeoil security and it requires only one unguarded network entry to allow bad people to access that entire network, even when it is an "intranet". Rob _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Pops should not filter or firewall anything except for bogus 44ips bgp subnets, and that is very easily done.

Toussaint, I always wanted to visit Corsica, When I will, I hope to be able to meet you, and also hope I could hop along your island network if I am allowed to use my ham stuff in there. Do you know if Canada has reciprocity with Corsica?

On 10 Aug 2021, at 23:30, Toussaint OTTAVI via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote:  The purpose is not only to allow/block traffic. The TAC proposal describes two different user cases (called "Internet" and "Intranet") that suit different needs all over the world. Some of us are already using some similar schemes, but with different implementations all over the world. This makes routing a headache, and there are many situations where sysops don't know how to route traffic correctly. F/ex, in France, most of D-Star or DMR stuff which have 44et addressing are in fact using dual addressing, and have also a classic Internet IP, so that they can be reached from Internet. The separation into two subnets proposed by the TAC solves that, by defining clear routing policy for each subnet : - The "Internet" subnet is routed on public Internet via eBGP, and packets are carried via Internet - The "Intranet" subnet is not announced on Internet, but is only routed internally (as European HamNet does with iBGP) In your situation : - If you want to be reachable from public Internet, you can choose the "Internet" subnet, and set up your firewall rules according to your needs - If you want to be on a completely closed network not reachable from public Internet (such as Hamnet), then you can choose the "Intranet" subnet. Here, we decided to use the best of both modes. We're using dual addressing, and each site can have both Internet and Intranet addresses. Any device just needs to be connected to the right Ethernet interface, and it automatically gets the right IP, and the right routing / firewalling policy. The TAC proposal is a normalization of what some of us are already doing, with 44.190 "Internet / no country", or with BGP announcement of 44.x subnet. It offers clear segmentation about the two modes, and should help setting up routing policies by just having two big subnets. With the current proposal, and if you need your full IP range to be reachable directly from public Internet, then yes, I think you'll have to renumber to something in in 44.0. Anyway, I would answer to your question by another question : Even with a good firewalling, do you really need and/or want all your IP range, all your endpoints, all your users to be exposed to public Internet ? As said before, we choose to use both addressing, and we decide individually for every application or device device. F/ex : - D-Star, DMR, XLX -> Internet subnet - Remote control of HF radio-club station -> Intranet subnet Then, another option for you would be : - Keep your current network in 44.138, but consider it as "Intranet", "HamNet clone", and stop announcing it via BGP - Get another subnet in 44.0 for "Internet" and announce it via BGP - Choose individually what devices need to be reachable from public Internet (they should not be the majority), and just migrate/renumber those to 44.0 Or better suggestion : Do dual addressing everywhere like we do :-) If things work well, we (the TAC and all the sysops here) should be able to define clear routing policies, build a backbone, define a common POP policy, and define standard configuration for "Access" routers or endpoints to be implemented on a wide range of low-cost platforms :-) Of course, this would involve some work for everybody. But if we want to make 44net access easier and gain users, it seems obvious we'll have to migrate the current mess (there are not two user groups that do exactly the same thing) to something a little bit more normalized and harmonized ofer the world. Then, we all will have to change some things, HI :-) 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

OK, I've been watching this fire for a couple of weeks alternating between initial shock, outrage, disbelief. Now I'm going to go into denial, I'll probably skip bargaining since I don't have anything worth bargaining with. I manage one of the /23's that is hosted by Vultr (I used to self host, but I sold the business that provided those links and migrated to Vultr). From my perspective the 44net's existence showed with foresight of hams in the early 80's and it needs to be carefully managed and preserved. I was shocked a couple of years ago when comments on the list about funny things with listing turned into announcement that Amazon was now the proud owner of a large portion of the heritage of all hams. This had been done with no discussion or debate and was merely presented as a fait accompli. I don't want to open up that can of worms exactly, but I find myself questioning if we aren't looking at preparation for another round of this. You see the IETF already stared out the problem of internet connected / reachable hosts and non internet reachable hosts and gave us three allocations in RFC 1918 that anyone anywhere in the world can use. I saw reference to the 10.44.0.0/16 as a idea, but we could go far beyond that if we wanted to run a private routing registry for hosts that are intranet based and want routing to 44net systems. Could there be addressing overlap and challenges, yes their could, most people use the 192.168.0.0/16 subnets at home, and could be instructed to do so. So to me that looks viable (and I run a international corporate network that uses a lot of RFC 1918 space, I've dealt with a lot of variables, but it can use BGP to pass its routes just like the rest of the IPv4 space. So I find myself wondering what is really going on here and I start to wonder if this is preparation for another selloff of our space? You see, if the systems on a intranet are guaranteed not to talk with the internet, it doesn't matter if they use internet addresses because their speaking with any internet system is by definition invalid. So move all of the Intranet to one slice, and once everyone has moved. Sell it! They won't be affected because they can't talk to the Internet. The other side might have occasional connectivity problems, but they will be rare... I'm probably way off the deep end with this suggestion. But I really can't understand why forcing a substantial portion of our address space to be intranet only is a good solution. All I know for sure  is I Hate complicated rules being pushed into the address space about who can talk to who. I use firewalls on my borders, I expect anyone peered with me to do the same. I believe we tend to be law abiding, rule following folk, but there are many examples of amateur radio operators who aren't, and individuals who pretend to be licensed who aren't. I do understand consternation about people injecting routes for the 44 net and stealing our addresses temporarily. This can be a problem for every system. CYMRU publishes a list of Bogon's via BGP and HTTP, what if we just host on the portal lists of subnets that we have not allocated, or allocated for Intranet only usage. Those that care can download it into their firewall filter rules and if those appear on our Internet feeds they will be dropped (it would also help us detect such usage). I'm sure we all want we each think is best for AMPR, and I love that we are all so passionate about it. 73 Bill AF7SJ On 8/10/2021 4:43 PM, pete M wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

But what you may not know is that by selling some space again ARDC would loose it's 501c status and would have to pay a huge taxe amount on the selling of the new block and the same on the first block as this would be seen by the IRS as its core business and not seen as a charity entity. This would totally defeat the goal of selling another block.

pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Don't believe the above paragraph. The actual situation between ARDC and the IRS rules is far more complicated and interesting than what Pete describes. The loss of our 501c3 status is not at risk. We are still working out the details with our nonprofit tax lawyers. We will publish our first 990-PF (private foundation) tax return for 2020 on our website and to the 44net when we file it, and then we can talk with more certainty. John Gilmore, W0GNU ARDC board

This is already there. Some regions and amateurs do run their own DNS. I don't think it is that great, because it makes it impossible to simply transfer the entire DNS zone to a local server and have faster DNS lookups independent of an internet connection. But it works, I guess... IMHO it would be better to offer a DNS update API, where everyone can update their own host records in an easily automated way. It of course exists in the form of the mail robot and also the web DNS editor but apparently some people think it is not good enough. (I use the mail robot myself as part of an automated update) Rob On 8/14/21 5:32 PM, Bill Buhler via 44Net wrote: DNS delegation system for hams off of ampr.org or another domain name? But would it make sense to offer any ham out there a DNS subdomain based on their call? For those that want to limit access that could also become part of their checks, i.e. does the forward and backward DNS resolve to a subdomain.ampr.org domain? _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On Aug 14, 2021, at 10:44 AM, Rob PE1CHL via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: This is already there. Some regions and amateurs do run their own DNS. I don't think it is that great, because it makes it impossible to simply transfer the entire DNS zone to a local server and have faster DNS lookups independent of an internet connection. But it works, I guess... IMHO it would be better to offer a DNS update API, where everyone can update their own host records in an easily automated way. It of course exists in the form of the mail robot and also the web DNS editor but apparently some people think it is not good enough. (I use the mail robot myself as part of an automated update) Rob _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

100% agreed on an update api and portal page for dns updates. That’d be great. Also last I heard DNS delegation was only available if you were using BGP? Q for the group, last I heard the email dns robot was deprecated or disabled and I wasn’t aware of a web dns editor. If that’s the case, how would I get access? Mark - K9MEV

I'd be happy to use the email robot to update my own dns...... But last I heard it was available to coordinators only and I've never seen a description of howto use it published at least widely enough that it was seen by the amprnet masses.  I can also see security issues with such.  I've been asking for DNS zone deligation both forward and reverse for years, and I would fully support such a move.  It seems that the case for transfering the entire ampr.org zone is over rated and could still be done by crawling the DNS tree, but why?  if you are off line and disconnected you only need DNS for your subnet anyway as you won't be able to reach anything else DNS or not. eric af6ep On 2021-08-14 08:43, Rob PE1CHL via 44Net wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Agreed, Zone transfers SHOULD be supported at least to Amprnet address space...... and deligations to run one's own forward and reverse dns SHOULD be allowed/maybe even encouraged.  If I have a /24 or larger which is bgp announced (which I do), I ought be able to fully manage the Forward and Reverse DNS for it and subdomain.mycallsigns.ampr.org without having to go my coordinator.  effectively by request I ought be able to be deligated those duties by my coordinator so they don't have to. Eric AF6EP

DNS pointing to 44 net addresses can be done by any using any domain. RDNS (PTR Records) can be either AMPR.ORG or delegated. On Sat, Aug 14, 2021 at 12:51 PM Rob PE1CHL via 44Net < 44net(a)mailman.ampr.org&gt; wrote: Note that "being able to manage ones own subnet" does not imply that DNS will have to be delegated. It could just as well be a possibility to edit DNS records on the central DNS with some authorization method that allows you only to edit records within your own range and with your registered callsign. It still keeps the DNS in once piece. Rob On 8/14/21 9:42 PM, Af6ep via 44Net wrote: Agreed, Zone transfers SHOULD be supported at least to Amprnet address space...... and deligations to run one's own forward and reverse dns SHOULD be allowed/maybe even encouraged. If I have a /24 or larger which is bgp announced (which I do), I ought be able to fully manage the Forward and Reverse DNS for it and subdomain.mycallsigns.ampr.org without having to go my coordinator. effectively by request I ought be able to be deligated those duties by my coordinator so they don't have to. Eric AF6EP _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

I guess I am missing exactly why it is so important to keep dns in one piece (centralized to one server) as you suggest.  What is so bad about dns acting as a tree that is crawled to resolve an address?  if it's connectivity that's the issue then the same issue exists generally getting from your network to mine and mine to yours.  If latency is the issue, that's what caching is for.  What issue do you wish to address by keeping all ampr dns on a small set of servers. Eric AF6EP On 2021-08-14 12:50, Rob PE1CHL via 44Net wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Just thought of this this morning, and was wondering if we could have a DNS delegation system for hams off of ampr.org or another domain name? Something like: af7sj.ampr.org    ns    myprimary.dns.server af7sj.ampr.org    ns    mysecondary.dns.server In my ideal deal world there would be a .radio TLD... or a .44net tld... But would it make sense to offer any ham out there a DNS subdomain based on their call? For those that want to limit access that could also become part of their checks, i.e. does the forward and backward DNS resolve to a subdomain.ampr.org domain? 73 Bill Buhler - AF7SJ _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Bill , As the TAC was discussing the proposal we all came to the conclusion that someone would come with the fear that ARDC/AMPR would prepare for the selling of some of the address space. First this is a valid fear and it is totally understandable. But what you may not know is that by selling some space again ARDC would loose it's 501c status and would have to pay a huge taxe amount on the selling of the new block and the same on the first block as this would be seen by the IRS as its core business and not seen as a charity entity. This would totally defeat the goal of selling another block. I don't believe the above paragraph either. A non profit (501c3) entity can sell off an asset and retain it's non-profit status. The rule is that the proceeds from that asset must be reinvested toward the mission of the organization. This is part of a misnomer of what a Non-Profit vs a for Profit entity is. The big question is what is profit? Generally a for Profit company has Shareholders (either public or private) that take a draw or dividend of the monies from the business after expenses are paid. In a non-profit all monies generaated are to be reinvested toward the orgaanizational purpose for the public good. Bear in mind that a lot of flack would be taken for it, but it would be perfectly legal for the C-level executives of a non-profit to derive a gargantuan salary for their services (which are deemed as operating exenses), then the board vote to sell an asset with the proceeds being turned back to the general fund, which then goes to pay those gargantuan C-level salaries. Eric af6ep Télécharger Outlook pour Android<https://aka.ms/AAb9ysg> ________________________________ From: 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; on behalf of Andy Brezinsky via 44Net &lt;44net(a)mailman.ampr.org&gt; Sent: Friday, August 13, 2021 12:30:34 AM To: 44net(a)mailman.ampr.org &lt;44net(a)mailman.ampr.org&gt; Cc: Andy Brezinsky &lt;andy(a)mbrez.com&gt; Subject: Re: [44net] A new era of IPv4 Allocations : Agree - No I don't +1 Bill. I was meaning to respond with something similar so thank you for saying it so eloquently. Don't try to get cute with encoding special information into the addressing scheme. Things can change and re-numbering to adhere to looks like a CCNA exercise of IP allocation is a waste of time. In the future, maybe private networks take off and that subnet starts getting too small. Maybe the FCC relaxes rules around encryption and we want to give internet access to things that were previously private. Is everyone expected to re-number /again/? Publish a BGP (or HTTP) feed of bogons (IPs that should never, ever be public) and let people consume that for automatic rules creation if they want it. On 8/12/21 11:08 PM, Bill Buhler via 44Net wrote: OK, I've been watching this fire for a couple of weeks alternating between initial shock, outrage, disbelief. Now I'm going to go into denial, I'll probably skip bargaining since I don't have anything worth bargaining with. I manage one of the /23's that is hosted by Vultr (I used to self host, but I sold the business that provided those links and migrated to Vultr). From my perspective the 44net's existence showed with foresight of hams in the early 80's and it needs to be carefully managed and preserved. I was shocked a couple of years ago when comments on the list about funny things with listing turned into announcement that Amazon was now the proud owner of a large portion of the heritage of all hams. This had been done with no discussion or debate and was merely presented as a fait accompli. I don't want to open up that can of worms exactly, but I find myself questioning if we aren't looking at preparation for another round of this. You see the IETF already stared out the problem of internet connected / reachable hosts and non internet reachable hosts and gave us three allocations in RFC 1918 that anyone anywhere in the world can use. I saw reference to the 10.44.0.0/16 as a idea, but we could go far beyond that if we wanted to run a private routing registry for hosts that are intranet based and want routing to 44net systems. Could there be addressing overlap and challenges, yes their could, most people use the 192.168.0.0/16 subnets at home, and could be instructed to do so. So to me that looks viable (and I run a international corporate network that uses a lot of RFC 1918 space, I've dealt with a lot of variables, but it can use BGP to pass its routes just like the rest of the IPv4 space. So I find myself wondering what is really going on here and I start to wonder if this is preparation for another selloff of our space? You see, if the systems on a intranet are guaranteed not to talk with the internet, it doesn't matter if they use internet addresses because their speaking with any internet system is by definition invalid. So move all of the Intranet to one slice, and once everyone has moved. Sell it! They won't be affected because they can't talk to the Internet. The other side might have occasional connectivity problems, but they will be rare... I'm probably way off the deep end with this suggestion. But I really can't understand why forcing a substantial portion of our address space to be intranet only is a good solution. All I know for sure is I Hate complicated rules being pushed into the address space about who can talk to who. I use firewalls on my borders, I expect anyone peered with me to do the same. I believe we tend to be law abiding, rule following folk, but there are many examples of amateur radio operators who aren't, and individuals who pretend to be licensed who aren't. I do understand consternation about people injecting routes for the 44 net and stealing our addresses temporarily. This can be a problem for every system. CYMRU publishes a list of Bogon's via BGP and HTTP, what if we just host on the portal lists of subnets that we have not allocated, or allocated for Intranet only usage. Those that care can download it into their firewall filter rules and if those appear on our Internet feeds they will be dropped (it would also help us detect such usage). I'm sure we all want we each think is best for AMPR, and I love that we are all so passionate about it. 73 Bill AF7SJ On 8/10/2021 4:43 PM, pete M wrote: I hate to be the bearer of bad news, but that is it not true. We have seen group of people getting some BGP announce of parts of the 44net with out being autorized to do so and they did this by having access to a bgp server and making the route seem legaly done. And those hacker could have had access to the whole 44 net ham space with your solution. Ok, the people that want that the whole internet can reach them are not bothered at all by that situation, after all they already are dealing with such rogue situation. But the one that DONT want anything but ham traffic either be by choice or by laws are really bothered by such situation.So, no that easy solution is just a small bandage over la large bleading wound and it can lead to some ham to loose their licence if the data sent by the rogue reach the airwaves. Pierre VE2PF ________________________________________ De : 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Ruben ON3RVH via 44Net &lt;44net(a)mailman.ampr.org&gt; Envoyé : 10 août 2021 17:40 À : 44Net general discussion Cc : Ruben ON3RVH Objet : Re: [44net] A new era of IPv4 Allocations : Agree Dual addressing means complicated policy based routing. The remaining 44net that we have today is ham only. Thus if one does not the internet to reach his/her subnet, all they have to do is add a simple firewall rule allowing 44/8 and 44.128/10 and denying the rest. That is a lot easier than policy based routing or dual addressing. That would allow fellow hams to reach the subnet, but not the rest of "the big bad internet" Ruben - ON3RVH On 10 Aug 2021, at 23:30, Toussaint OTTAVI via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Le 10/08/2021 à 20:26, R P via 44Net a écrit : Why should we separate networks ? Every simple firewall can block traffic with simple rule The purpose is not only to allow/block traffic. The TAC proposal describes two different user cases (called "Internet" and "Intranet") that suit different needs all over the world. Some of us are already using some similar schemes, but with different implementations all over the world. This makes routing a headache, and there are many situations where sysops don't know how to route traffic correctly. F/ex, in France, most of D-Star or DMR stuff which have 44et addressing are in fact using dual addressing, and have also a classic Internet IP, so that they can be reached from Internet. The separation into two subnets proposed by the TAC solves that, by defining clear routing policy for each subnet : - The "Internet" subnet is routed on public Internet via eBGP, and packets are carried via Internet - The "Intranet" subnet is not announced on Internet, but is only routed internally (as European HamNet does with iBGP) In your situation : - If you want to be reachable from public Internet, you can choose the "Internet" subnet, and set up your firewall rules according to your needs - If you want to be on a completely closed network not reachable from public Internet (such as Hamnet), then you can choose the "Intranet" subnet. Here, we decided to use the best of both modes. We're using dual addressing, and each site can have both Internet and Intranet addresses. Any device just needs to be connected to the right Ethernet interface, and it automatically gets the right IP, and the right routing / firewalling policy. The TAC proposal is a normalization of what some of us are already doing, with 44.190 "Internet / no country", or with BGP announcement of 44.x subnet. It offers clear segmentation about the two modes, and should help setting up routing policies by just having two big subnets. Le 10/08/2021 à 20:26, R P via 44Net a écrit : I (and all my country) sit on 44.138 which according to the proposal would be not connected to the Internet With the current proposal, and if you need your full IP range to be reachable directly from public Internet, then yes, I think you'll have to renumber to something in in 44.0. Anyway, I would answer to your question by another question : Even with a good firewalling, do you really need and/or want all your IP range, all your endpoints, all your users to be exposed to public Internet ? As said before, we choose to use both addressing, and we decide individually for every application or device device. F/ex : - D-Star, DMR, XLX -> Internet subnet - Remote control of HF radio-club station -> Intranet subnet Then, another option for you would be : - Keep your current network in 44.138, but consider it as "Intranet", "HamNet clone", and stop announcing it via BGP - Get another subnet in 44.0 for "Internet" and announce it via BGP - Choose individually what devices need to be reachable from public Internet (they should not be the majority), and just migrate/renumber those to 44.0 Or better suggestion : Do dual addressing everywhere like we do :-) If things work well, we (the TAC and all the sysops here) should be able to define clear routing policies, build a backbone, define a common POP policy, and define standard configuration for "Access" routers or endpoints to be implemented on a wide range of low-cost platforms :-) Of course, this would involve some work for everybody. But if we want to make 44net access easier and gain users, it seems obvious we'll have to migrate the current mess (there are not two user groups that do exactly the same thing) to something a little bit more normalized and harmonized ofer the world. Then, we all will have to change some things, HI :-) 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Yes, the roblem we have is that of bad actors and those not following thu amprnet AUP. We have that problem if we have one address space or multiple address spaces. splitting the space does not solve that. This is yet another example of attempting to solve a human socal problem by technical means. It' won't work, because it can't work.

But Kriss, does firewall apply to router or to client connected to router?

And when I talk about router I d mean the real thing, not the client end of things like at home where a device receive one IP and have a non routable to the internet local netork that need to NAT all the traffic to it's client.

How do you firewall anything if you need to route traffic back and fort as a real router on the internet?

We are trying to fix a layer 3 problem with a layer 4 solution.

+1 Bill. I was meaning to respond with something similar so thank you for saying it so eloquently. Don't try to get cute with encoding special information into the addressing scheme. Things can change and re-numbering to adhere to looks like a CCNA exercise of IP allocation is a waste of time. In the future, maybe private networks take off and that subnet starts getting too small. Maybe the FCC relaxes rules around encryption and we want to give internet access to things that were previously private. Is everyone expected to re-number /again/? Publish a BGP (or HTTP) feed of bogons (IPs that should never, ever be public) and let people consume that for automatic rules creation if they want it. On 8/12/21 11:08 PM, Bill Buhler via 44Net wrote: OK, I've been watching this fire for a couple of weeks alternating between initial shock, outrage, disbelief. Now I'm going to go into denial, I'll probably skip bargaining since I don't have anything worth bargaining with. I manage one of the /23's that is hosted by Vultr (I used to self host, but I sold the business that provided those links and migrated to Vultr). From my perspective the 44net's existence showed with foresight of hams in the early 80's and it needs to be carefully managed and preserved. I was shocked a couple of years ago when comments on the list about funny things with listing turned into announcement that Amazon was now the proud owner of a large portion of the heritage of all hams. This had been done with no discussion or debate and was merely presented as a fait accompli. I don't want to open up that can of worms exactly, but I find myself questioning if we aren't looking at preparation for another round of this. You see the IETF already stared out the problem of internet connected / reachable hosts and non internet reachable hosts and gave us three allocations in RFC 1918 that anyone anywhere in the world can use. I saw reference to the 10.44.0.0/16 as a idea, but we could go far beyond that if we wanted to run a private routing registry for hosts that are intranet based and want routing to 44net systems. Could there be addressing overlap and challenges, yes their could, most people use the 192.168.0.0/16 subnets at home, and could be instructed to do so. So to me that looks viable (and I run a international corporate network that uses a lot of RFC 1918 space, I've dealt with a lot of variables, but it can use BGP to pass its routes just like the rest of the IPv4 space. So I find myself wondering what is really going on here and I start to wonder if this is preparation for another selloff of our space? You see, if the systems on a intranet are guaranteed not to talk with the internet, it doesn't matter if they use internet addresses because their speaking with any internet system is by definition invalid. So move all of the Intranet to one slice, and once everyone has moved. Sell it! They won't be affected because they can't talk to the Internet. The other side might have occasional connectivity problems, but they will be rare... I'm probably way off the deep end with this suggestion. But I really can't understand why forcing a substantial portion of our address space to be intranet only is a good solution. All I know for sure is I Hate complicated rules being pushed into the address space about who can talk to who. I use firewalls on my borders, I expect anyone peered with me to do the same. I believe we tend to be law abiding, rule following folk, but there are many examples of amateur radio operators who aren't, and individuals who pretend to be licensed who aren't. I do understand consternation about people injecting routes for the 44 net and stealing our addresses temporarily. This can be a problem for every system. CYMRU publishes a list of Bogon's via BGP and HTTP, what if we just host on the portal lists of subnets that we have not allocated, or allocated for Intranet only usage. Those that care can download it into their firewall filter rules and if those appear on our Internet feeds they will be dropped (it would also help us detect such usage). I'm sure we all want we each think is best for AMPR, and I love that we are all so passionate about it. 73 Bill AF7SJ On 8/10/2021 4:43 PM, pete M wrote: I hate to be the bearer of bad news, but that is it not true. We have seen group of people getting some BGP announce of parts of the 44net with out being autorized to do so and they did this by having access to a bgp server and making the route seem legaly done. And those hacker could have had access to the whole 44 net ham space with your solution. Ok, the people that want that the whole internet can reach them are not bothered at all by that situation, after all they already are dealing with such rogue situation. But the one that DONT want anything but ham traffic either be by choice or by laws are really bothered by such situation.So, no that easy solution is just a small bandage over la large bleading wound and it can lead to some ham to loose their licence if the data sent by the rogue reach the airwaves. Pierre VE2PF ________________________________________ De : 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; de la part de Ruben ON3RVH via 44Net &lt;44net(a)mailman.ampr.org&gt; Envoyé : 10 août 2021 17:40 À : 44Net general discussion Cc : Ruben ON3RVH Objet : Re: [44net] A new era of IPv4 Allocations : Agree Dual addressing means complicated policy based routing. The remaining 44net that we have today is ham only. Thus if one does not the internet to reach his/her subnet, all they have to do is add a simple firewall rule allowing 44/8 and 44.128/10 and denying the rest. That is a lot easier than policy based routing or dual addressing. That would allow fellow hams to reach the subnet, but not the rest of "the big bad internet" Ruben - ON3RVH On 10 Aug 2021, at 23:30, Toussaint OTTAVI via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Le 10/08/2021 à 20:26, R P via 44Net a écrit : Why should we separate networks ? Every simple firewall can block traffic with simple rule The purpose is not only to allow/block traffic. The TAC proposal describes two different user cases (called "Internet" and "Intranet") that suit different needs all over the world. Some of us are already using some similar schemes, but with different implementations all over the world. This makes routing a headache, and there are many situations where sysops don't know how to route traffic correctly. F/ex, in France, most of D-Star or DMR stuff which have 44et addressing are in fact using dual addressing, and have also a classic Internet IP, so that they can be reached from Internet. The separation into two subnets proposed by the TAC solves that, by defining clear routing policy for each subnet : - The "Internet" subnet is routed on public Internet via eBGP, and packets are carried via Internet - The "Intranet" subnet is not announced on Internet, but is only routed internally (as European HamNet does with iBGP) In your situation : - If you want to be reachable from public Internet, you can choose the "Internet" subnet, and set up your firewall rules according to your needs - If you want to be on a completely closed network not reachable from public Internet (such as Hamnet), then you can choose the "Intranet" subnet. Here, we decided to use the best of both modes. We're using dual addressing, and each site can have both Internet and Intranet addresses. Any device just needs to be connected to the right Ethernet interface, and it automatically gets the right IP, and the right routing / firewalling policy. The TAC proposal is a normalization of what some of us are already doing, with 44.190 "Internet / no country", or with BGP announcement of 44.x subnet. It offers clear segmentation about the two modes, and should help setting up routing policies by just having two big subnets. Le 10/08/2021 à 20:26, R P via 44Net a écrit : I (and all my country) sit on 44.138 which according to the proposal would be not connected to the Internet With the current proposal, and if you need your full IP range to be reachable directly from public Internet, then yes, I think you'll have to renumber to something in in 44.0. Anyway, I would answer to your question by another question : Even with a good firewalling, do you really need and/or want all your IP range, all your endpoints, all your users to be exposed to public Internet ? As said before, we choose to use both addressing, and we decide individually for every application or device device. F/ex : - D-Star, DMR, XLX -> Internet subnet - Remote control of HF radio-club station -> Intranet subnet Then, another option for you would be : - Keep your current network in 44.138, but consider it as "Intranet", "HamNet clone", and stop announcing it via BGP - Get another subnet in 44.0 for "Internet" and announce it via BGP - Choose individually what devices need to be reachable from public Internet (they should not be the majority), and just migrate/renumber those to 44.0 Or better suggestion : Do dual addressing everywhere like we do :-) If things work well, we (the TAC and all the sysops here) should be able to define clear routing policies, build a backbone, define a common POP policy, and define standard configuration for "Access" routers or endpoints to be implemented on a wide range of low-cost platforms :-) Of course, this would involve some work for everybody. But if we want to make 44net access easier and gain users, it seems obvious we'll have to migrate the current mess (there are not two user groups that do exactly the same thing) to something a little bit more normalized and harmonized ofer the world. Then, we all will have to change some things, HI :-) 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Dual addressing may be complicated now because some 44.x subnets are annouced on BGP while some others are not, because some people are not aware about the fact they must route 44.190 differently, etc... The purpose of the TAC proposal is to simplify things by splitting / grouping networks into two big subnets, with just two "parent" routing policies.

Of course, it works. But every sysadmin has to know exactly how to route every subnet. F/ex, not everybody knows 44.190 routing policy. Grouping into "Internet" and "Intranet" categories, each category in a parent subnet,  would hugely simplify things.

But managing a database on the portal about what subnet is Intranet and what subnet is Internet would probably do the job, too. Some scripts could update routing policies from the portal at POP level, which will be managed by skilled sysadmins. Not really "KISS", but it would work.

Separate routes will still be needed at POP level.

Endpoints will just route all to the nearest POP, so that things remain simple. At least for remote endpoints connected to a POP via a tunnel; but for endpoints connected to several neighbors via meshed radio links, things may not be as simple... -- This makes me think our previous idea of a 3-level topology (backbone, POP, Access) may not be enough. Maybe, we need an intermediate : - Backbone : world-wide infrastructure managed by ARDC, and providing network background - Point of Presence (POP) : local / regional platform, connected to the backbone, and providing connectivity to end-users - (new) Router : Intermediate mesh router, connected to several neighbors via radio links, and contributing to the global routing in relation with nearest POPs - Access : Small low-cost router (Mikrotik/OpenWRT etc...) or software (VPN client, RPi) offering 44net IPs to endpoints by connecting to one or several POPs with PnP technologies

The problem is not for us (sysops / sysadmins) : we'll always find a solution. The problem is for end-users : today, connecting to 44net, HamNet or any local implementation, is far from easy !

On 11/8/21 8:16 pm, Rob PE1CHL via 44Net wrote: All nice, but the backbone would need to have _multiple_ links to the Internet.  For example, currently (by default), to get from my IPIP connected subnet to my BGP connected one, I have to do a very long trip of 2000+km via San Diego to communicate over 150km!  Obviously, an exit point onto the Internet geographically closer would be needed if I was going to trust the backbone to route my traffic correctly.

That would work if all routing takes place on the one device (nice, when you can get that).  That's currently not the situation here.  I also currently run several networks on the one wire.  However, my networking will be rearranged sometime in 2022.  Hopefully, I can physically and/or logically separate out the different networks into VLANs. And with the routing on one device, I would still have the option of setting up a VPN between my subnets, if I wanted to bypass NAT.  Currently, that's not necessary for the Internet facing services (they're designed to work with end users behind NAT, for the most part), but it is useful for some internal management tasks.

On Aug 12, 2021, at 05:38, Tony Langdon via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: something more user friendly. I would have 3 classes of IP in my networks: 1. Public, BGP routed (direct connection). Basically my existing 44.190 allocation is a prime example of this. These IPs are to provide Internet facing services. 2. Backbone routed IPs on LAN (or local wifi). These are mainly for intranet use, but not being on air, connection to Internet hosts is tolerated. For example, these addresses would be a good place to run an IRLP or Echolink node.

3. Radio based IPs. Here, I would be very selective what to allow by default - other Intranet addresses, possibly at least some of the public BGP routed 44net space. Individual hosts on radio may even have cause to communicate with specific Internet IP addresses (e.g. the end point for some other amateur link), on a case by case basis. Or I may allow specific ports/protocols only to the general Internet (e.g. Echolink, IRLP, etc).

On Aug 12, 2021, at 13:50, pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: If any IRLP or echolink node want to announce themself on both segment of the network I dont see any problem with that. their could be some echolink proxy's that could easily fix any connection problem. The same with allstarlink. ( not talking for them) but they already use 44 net addresses so having some dual address for their server should not be that difficult to implement.

There is one aspect that might be a potential issue, and that is where the 44net IP is on amateur links.  Open access to the Internet could be problematic, from a legal point of view.  I know our authorities are very conservative in this area, and in fact, it took a while to get Winlink approved for use here, that was a long running saga.  They're fine with using the Internet as a carrier for amateur traffic (e.g. RoIP networks like IRLP, Echolink, etc), or the IPIP tunnels, but not so keen where non amateur traffic could enter the amateur frequencies.  This implies there will need to be some fairly straightforward firewall options available.  I could easily use iptables, but others might need something more user friendly.  I would have 3 classes of IP in my networks: 1.  Public, BGP routed (direct connection).  Basically my existing 44.190 allocation is a prime example of this.  These IPs are to provide Internet facing services. 2.  Backbone routed IPs on LAN (or local wifi).  These are mainly for intranet use, but not being on air, connection to Internet hosts is tolerated.  For example, these addresses would be a good place to run an IRLP or Echolink node. 3.  Radio based IPs.  Here, I would be very selective what to allow by default - other Intranet addresses, possibly at least some of the public BGP routed 44net space.  Individual hosts on radio may even have cause to communicate with specific Internet IP addresses (e.g. the end point for some other amateur link), on a case by case basis.  Or I may allow specific ports/protocols only to the general Internet (e.g. Echolink, IRLP, etc).

On 13/8/21 1:43 am, Rob PE1CHL via 44Net wrote: That's likely to be insufficient.  I'm just flagging it as a consideration going forward - each connecting user needs to have full control of the level of Internet connectivity they want, to suit their needs.

Dual addressing may be complicated now because some 44.x subnets are annouced on BGP while some others are not, because some people are not aware about the fact they must route 44.190 differently, etc... The purpose of the TAC proposal is to simplify things by splitting / grouping networks into two big subnets, with just two "parent" routing policies.

the backbone is the POP ardc are proposing to build.

I think ARDC can offer end-user PoP access to their backbone themselves, and regional groups can always decide to setup their own access which connects to such a PoP and allows their own end-users to connect.

Some users also may not think their local access point is reliable enough and want to connect to an ARDC PoP or even more than one. It should always be possible to have multiple options, we should not wire the possibilities into the network design.

In our network it already works.

Whenever a user connects e.g. to OpenVPN, the route to their address is distributed using BGP.

Exactly people wont want to split route and program certain subnet and do all that maintenance that need to be done if a new allocation is given or other not fun task. They will want simple things to do and they will want to have fun while learning. \ Then your user could choose to joint either of the 2 possibility or even better both but in a very controled fashion and with a sens of securit for the ham only side cause none of the non ham world would have access. It is not a perfect system, but when you can remove 99% of risk from a system it is a huge improvement. I do not say it will be perfect and good security practice wont be needed. But we will start with a very large leap.

Lets concentrate on one aspect of this for a moment: the big argument here and what the TAC proposal seems to address (their approach nonwithstanding) seems to be seperating the address space used for ham to ham >only, vs Ham to Non-Ham.

First off, in order to be assigned addresses from the amprnet block per the AUP do I not need to be an amateur radio licensee?

If my thinking is correct that in order to comply with the AUP and be issued ip address space from the amprnet allocation I must first have my amateur radio license >then should not every ip address in the amprnet blocks be by definition acceptable to communicate with? if not why not? That covers HAM to HAM - NO >RENUMBERING OR SPLITTING THE NETWORK REQUIRED!

on the other hand, ham to general internet may have issues with local regulatory issues and it may not. How that is handled is and should be the choice of the local >operator of the gateway between 44net rf links and any non-rf links.

Where we have the issue is putting non acceptable traffic over an rf link. ultimately the source of the traffic has long ago been identified as the responsible party. by >virtue of the AUP we ought be able to trust any address from amprnet space holding the originator of said traffic responsible, or in the case of traffic to/from or >transiting amprnet space to another non amprnet ip space the first station (which should have amprnet addressing on all RF interfaces) to place the traffic onto an >amateur RF segment (part 15 or similar by country rf segments who cares, as that's allowed)Eric

AF6EP

It should always be possible to have multiple options, we should not wire the possibilities into the network design. Rob

Le 11/08/2021 à 15:03, pete M via 44Net a écrit : In my idea : - POPs are the equivalent of our current regional gateways. They are managed locally by us (sysadmins, coordinators, local teams...), not by ARDC ! Basically, we migrate independent and different systems to a common standardized model. - ARDC provides backbone for interconnecting POPs all over the world. This includes network links (to be defined), portal, all required back-office tools, administration, and support for POP maintainers.

Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent. Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information! You can find our 5-page PDF here: https://pdf.daknob.net/ardc/tac128.pdf <https://pdf.daknob.net/ardc/tac128.pdf>

Just to say I fully agree with the TAC proposal. Here in Corsica, we've been experimenting such a scenario for 2 years now : - a 44.168 "Intranet" subnet (routed locally on the island) - a 44.190 "Internet" subnet (routed on Internet via BGP)

The only constraint for us with the TAC proposal is that we'll have to renumber our 44.190.11.0/24 to something in 44.0.0.0/10. We have 21 child prefixes and 40 IP addresses to renumber. Of course, this will require some time, but it's not as if we had thousands of addresses :-) If we don't make mistakes, all can be done remotely :-)

Our current design is the result of several iterations in the last few years, and from several talks with Jann DG8NGN, (one of the founders and network managers of European Hamnet, and currently Chairman of the TAC) : - Our first design was using 10.44.0.0/16 "private" addressing and NAT. Sufficient for inter-connecting sites, but NAT headaches for inbound traffic. - Then, we migrated to 44.168 "Intranet" addressing, Hamnet-style, but with no IP-IP implementation (dislike the tech, and no current need to route outside of the island) - When 44.190 specs were published for Internet-connected things, we got a subnet and announced it using BGP and a $5 Vultr VPS. We deployed it for our XLX, D-Star and DMR stuff. - As we were testing, and we did not know in advance which addressing scheme would be the best for a specific situation, we decided to implement dual addressing on all locations.

Dual-addressing is a bit tricky to setup when you start from scratch. But once understood and implemented on a model with a "POP" and "Access routers", it's just a matter of copy-paste of configurations. As we are on a very small scale, we do it manually. But there should be no problems to write configuration-builder scripts for use on a larger scale.

This would not be necessary if those admins/designers used DNS names instead of static IPs in their systems, HI :-) I never understood why FQDN names are not used more in D-Star / DMR / Digital modes in general...

+1. I am a network designer. I don't want to choose or force something for my users. Every end-user should be able to choose which addressing scheme to use according to its own needs. As network admins, I think we have to provide both addressing schemes to our users, in a simpler and more standardized way.

Tony, IRLP will be no problem, all we need to know is when a new IP is available and working. There is no reason you couldn’t run with both the old and new IP simultaneously for a short time. Folks will connect to whatever the database says is the IP. Worst case it should take only a few hours for the new IP to circulate through the IRLP network.

Forgot to mention one other item on the wish list: portal integration for DNS management is a must, or an easy way to sub-delegate DNS to our own servers for reverse entries. Chris has been very responsive, but this should be a self-serve thing IMHO.

Date: Wed, 11 Aug 2021 19:00:20 -0500 From: Mark Van Daele via 44Net &lt;44net(a)mailman.ampr.org&gt; To: 44Net general discussion &lt;44net(a)mailman.ampr.org&gt; Cc: Mark Van Daele &lt;markvd(a)markvd.net&gt; Subject: Re: [44net] A new era of IPv4 Allocations

IMHO the TAC plan as presented is a non-starter. Anything that involves significant re-ip is overly burdensome even with funding. Usually $$

I also fail to see the justification of reserving 44.64/10 with no future purpose when it is already in use. I currently have space in this range that would be orphaned. While it wouldn't be a significant deal for me to re-ip, as you've seen from other posters it will be for some and I fail to see the well defined purpose to sequester such a large space.

Re selling space, there is no reason to sell more space. ARDC has plenty of funding assuming it is appropriately managed going forward. If anything they have the opposite problem, make sure funding is appropriately allocated and well spent.

Back to the proposal, do we really need to allocate a dedicated /10 for unconnected purposes? How about finding a /16 or /15 not in use or with limited use? Is there really that large of a defined need to have 4 million IPs reserved as unconnected?

For me, I appreciate the opportunity to provide feedback and this seems to be a solution in need of a problem. I might be missing something but I fail to see the justification for this radical of a change in your paper.

Re the future, from my perspective I am very interested in the new TAC-proposed Global PoP infrastructure and portal that has been proposed. I'd love to see more/better gateway options, different options for connecting (including easy to use methods for "newbies", options for those stuck behind carrier NAT aside from running their own BGP/POP, and a better portal to manage the space and connection options. This is where I?d be focusing a lot of my time.

IMHO the TAC should be focused on network stewardship, architecture, policy, and community need. I may have missed it, but does the TAC have a defined charter? It might make sense to get community feedback and prioritization on the problems we are trying to solve.

I'd also like to see ARDC have a better focus on providing network POP and hosting infrastructure that supports the amateur community. While giving out grants is great, I could see growth on the operations side as well to support better infrastructure. Especially with funding there is no reason you couldn't staff a small infrastructure department to support this.

Re the endpoint and connection discussion, I do use a Pi3 as my IPIP gateway using one interface and 802.1Q VLANs. I have it behind my primary pfsense firewall and forward ipencap from external to it. My notes on how I set up the pi are here: http://k9mev.ampr.org/piconfig.txt

I think the Pi solution or a cheap Mikrotik are both valid solutions.