On 28 Jul 2021, at 09:35, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:

An issue I see here is that 44.190/16 was allocated to networks with no specific geographic location, and was/is intended for Internet facing services. A number of us (including myself) have space in here that is BGP announced (I'd say the majority, if not all the allocations here are BGP announced). What's going to happen with that space? Renumbering a BGP announced space is going to be highly disruptive, and for some services that require geolocation (e.g. Echolink proxies), there will be longer term anomalies in operation, while the geolocation databases are updated.

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.

Thanks, Antonis

Hi Chris,

What would you propose for amprnet.se <44.140.0.0/16> ?

Our license allowing Internet transit with ARDC and Sunet (the Swedish University Network) is based on making  radio amateur resources available to society as an extra lifeline when other networks fail or are not available. The services at such occasions are typical radio amateur applications such as remote hf stations, robust repeater networks, winlink email, chat services, aprs tracking, wspr-information, etc.

73

Bjorn - SA0BXI

...

On 28 Jul 2021, at 10:08, Antonios Chariton (daknob) via 44Net 44net@mailman.ampr.org wrote:

...

On 28 Jul 2021, at 09:35, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:

An issue I see here is that 44.190/16 was allocated to networks with no specific geographic location, and was/is intended for Internet facing services. A number of us (including myself) have space in here that is BGP announced (I'd say the majority, if not all the allocations here are BGP announced). What's going to happen with that space? Renumbering a BGP announced space is going to be highly disruptive, and for some services that require geolocation (e.g. Echolink proxies), there will be longer term anomalies in operation, while the geolocation databases are updated.

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.

Just to add to Antonis’ reply - I am standing by to receive new requests from anyone that has an existing BGP authorised allocation within 44.128/10 and I will expedite the issuing of new prefixes and the LOA for anyone having to renumber, we are also quite happy for you to have the two allocations side by side for a period of time to help in the renumbering process.

73, Chris - G1FEF

---

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

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.

73

Matt.

On 7/28/21 7:40 PM, Tony Langdon via 44Net wrote:

On 28/7/21 7:08 pm, Antonios Chariton (daknob) wrote:

...

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

Arrrgh, your use of Reply All and not deleting the direct email disabled my Reply List function, it seems. :(

...

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.

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?

...

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.

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

...

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.

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!

...

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.

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

Hello Matt. Thank you for the e-mail! Please find my reply below:

On 28 Jul 2021, at 12:08, Matt Perkins via 44Net 44net@mailman.ampr.org wrote:

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.

73

Matt.

Indeed, this does not sound “painless”, but I don’t think any renumbering can be. ARDC and the TAC can try to make it as painless as possible, but it will definitely not be completely painless. As I said to Tony, we are all here, in this mailing list, to make it as easy as possible, and the TAC requested from the Board the support of ARDC and enough time to make it easy.

I know that there will be cases of people that will have to go through this process. ARDC itself and the TAC members will go through it, as well. But with this split we make sure that the least amount of people will go through it. And for those that will, they will get all the support the community and ARDC can give them.

I hope this helps!

Antonis

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

On 28/7/21 9:18 pm, Antonios Chariton (daknob) via 44Net wrote:

Currently the people that reached out told us that their routers support static routing. It could be limited, e.g. 8 or 32 entry limit, but they support it. For reference, they are FritzBox, ZTE, TP-Link, etc. By splitting the space they can add a single entry, 44.128/10 to their radio or to their Raspberry Pi VPN server and keep the rest of the traffic to their ISP’s default gateway.

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.

On 28/7/21 9:51 pm, Rob PE1CHL via 44Net wrote:

In all networks I manage it is the same.  I think it is very unwise to design a network based on capabilities of ISP routers, as these vary widely and can change outside our control.

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.

Having an extra device (Raspberry Pi or similar, MikroTik router or similar) or at worst some code running on a PC (VPN client) is the way to go.   Routing by ISP router isn't.

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.

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

On 7/28/21, Antonios Chariton (daknob) via 44Net 44net@mailman.ampr.org wrote:

...

On 28 Jul 2021, at 14:02, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:

On 28/7/21 9:51 pm, Rob PE1CHL via 44Net wrote:

...

In all networks I manage it is the same. I think it is very unwise to design a network based on capabilities of ISP routers, as these vary widely and can change outside our control.

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.

...

Having an extra device (Raspberry Pi or similar, MikroTik router or similar) or at worst some code running on a PC (VPN client) is the way to go. Routing by ISP router isn't.

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.

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.

The current proposal accommodates for all users, both new and inexperienced all the way to Internet experts. At no point did we say we’re building a network only for people with static routes. That’s not what we want to do. We’re not prioritizing and discriminating against anyone based on network equipment or networking knowledge.

I hope this clears up things, Antonis _________________________________________ 44Net mailing list 44Net@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

On 28 Jul 2021, at 19:14, Pedro Converso pconver@gmail.com 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

If the network is operational right now, then I don’t see a need to have this affect you.

If these operators want to use BGP in the future, they can get additional IP addresses for that.

This is what I assumed when I told you that the answer is “No”, and why I said “It seems”. If for example they want the same addresses in BGP, then yes, they would have to change them. If they get additional, then it’s not needed, and they can use the new ones on BGP.

Antonis

On 28 Jul 2021, at 19:42, Pedro Converso pconver@gmail.com wrote:

Hello Antonis,

Thanks for answering, altought you says 'it seems' that could mean some troubles could eventually arise.

Some Argentina's GW users are thinking on BGP, so another way things could be worsening if those users decided to go on BGP.

Looking forward to keep our TCP/IP operation as it has always been.

73, lu7abf, Pedro 44.153 Coordinator

On 28 Jul 2021, at 13:51, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote: On 7/28/21 1:45 PM, Tony Langdon via 44Net wrote:

...

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

In all networks I manage it is the same. I think it is very unwise to design a network based on capabilities of ISP routers, as these vary widely and can change outside our control.

Having an extra device (Raspberry Pi or similar, MikroTik router or similar) or at worst some code running on a PC (VPN client) is the way to go. Routing by ISP router isn't.

Rob

It’s great that this works for your network, but as a TAC we want to accommodate for all networks out there, including the ones that use the ISP router. If we force people to have a router that supports OpenVPN (or any other protocol) then we immediately increase the barrier of entry. Our goal is the opposite: decrease it. We want more people in the network, not less.

That said, all our policy aims to create a network where it’s easy and accessible for people to join, however they like, and do whatever they want. We want to support all use cases, not just one.

Antonis

-----Original Message----- From: 44Net 44net-bounces+dave.g4ugm=gmail.com@mailman.ampr.org On Behalf Of Antonios Chariton (daknob) via 44Net Sent: 28 July 2021 12:19 To: 44Net general discussion 44net@mailman.ampr.org Cc: Antonios Chariton (daknob) daknob@daknob.net Subject: Re: [44net] A new era of IPv4 Allocations

Hello, thank you for your comment. Please see my reply below:

...

On 28 Jul 2021, at 12:57, g4ugm via 44Net 44net@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

Currently the people that reached out told us that their routers support static routing. It could be limited, e.g. 8 or 32 entry limit, but they support it. For reference, they are FritzBox, ZTE, TP-Link, etc. By splitting the space they can add a single entry, 44.128/10 to their radio or to their Raspberry Pi VPN server and keep the rest of the traffic to their ISP’s default gateway.

It is entirely possible that some routers will not support static routing at all. I can imagine this could be the case for similar models. If they do not have this capability, then unfortunately there’s nothing we can do with this equipment to provide access to 44.128/10. However, since 44.0/10 is on the Internet, users can still access this network just fine.

Users that fall under this category will probably have to have a VPN set up on their devices or opt-in for a better router. The reason the split is still beneficial is that although we can’t support these users due to technical limitations, we can at least support all the others whose equipment supports the configuration of static routes.

I hope this addresses your concerns.

Antonis

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.

Dave G4UGM

---

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

On 28/7/21 11:16 pm, g4ugm via 44Net 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.

Hmm, you raise a good point.  While I'm not into being elitist, I do believe that for hams these days, IP networking (at least IPv4, and preferably IPv6 as well) is now a necessary skill for many aspects of the hobby.  Not one that should be on the exam, but one we should be teaching to those who don't yet have the knowledge.  It's telling that 20 years after the first Echolink predecessor (iLink) was developed, people are still struggling with concepts like NAT and port forwarding.

Sure, we don't have to understand every part of the hobby in detail - I'll probably never build a high power RF PA or high performance transceiver from scratch, but I DO understand the basic principles involved in how they work (there was this exam thing for that ;) ).

And maybe another part that ARDC needs to look into is an educational arm, helping hams understand the technical underpinnings and being able to know why their ISP supplied router won't cut it, and technical information for those who want to further their knowledge and skills.  I for one would happily further my skills, if the opportunity arose, even though I have a fairly good understanding of IP.

Ham radio may not be a networking hobby, but we make extensive use of IP based networking in conducting our hobby.  And understanding that technology will help us as a whole.

Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18 napisal:

I really think that "we should accomodate static routes" is a very weak reason for the proposed changes. We should move away from static routes, if anything.

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

On 28 Jul 2021, at 13:48, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote: On 7/28/21 1:35 PM, Janko Mivšek via 44Net wrote:

...

Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18 napisal:

...

I really think that "we should accomodate static routes" is a very weak reason for the proposed changes. We should move away from static routes, if anything.

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.

Yes. If I was not clear: my proposal is to make a new backbone of PoPs instead of the current IPIP mesh (as was discussed end of last year) where a user can choose to:

First of all, let me say that we would like to see IPIP Mesh go away too some day, but we definitely need a robust Global PoP infrastructure first. I think we have many years until we can completely shut down IPIP mesh (at least the official ARDC one, anyone could set up their own). But this can happen gradually. As more and more users are available via the PoPs, then it will be easier to look into the future of IPIP Mesh. We have not discussed anything related to it so far.

• make a simple VPN connection with a local subnet and everything else is at the other end of the VPN. users can decide themselves if they want the local side of that VPN to be an isolated network of radio stuff and set a default route to the VPN, i.e. everything else than local is routed to the PoP and the router there decides how to further route that (to another PoP, to another user, to internet). user has to do no routing at all. everything static. is even possible in a Fritzbox and some other routers which can setup a IPsec VPN (or OpenVPN or Wireguard in some other routers).

This comes with the following issue: how do I know as a sender that you are making this available to the Internet? I will be able to send you packets, but your systems would just send the responses back over the Internet, and I would never get them, as I am Intranet-only. This can also lead to very difficult troubleshooting scenarios.

• second alternative is an "intranet only" version of that where the user only routes 44.0.0.0/9 and 44.128.0.0/10 to the PoP and routes all the remainder to their own ISP. That is the variant that is like what is done in Germany. User can use NAT in their router if they want to access AMPRnet from their RFC1918 network.

• third option is to run BGP over the VPN and receive and advertise AMPRnet subnet routes over that. this allows advanced users to become a gateway for others, or to setup multiple VPNs to different PoPs and have redundancy. extra VPNs to fellow amateurs for direct routes withoud dependency on the backbone are possible as well. Standard routers like MikroTik can do this, ISP routers of course cannot.

This all can work with some technical solutions and trying to think about a little bit more. As I said many times today, finding a technical solution to connect all users by the same means is easy. We don’t want that. That’s not the problem we try to solve. The problem we try to solve is to allow you, that want to use the ARDC PoPs, to talk to me, that I want to set up my own PoP concept globally, and connect users to my PoPs instead of ARDC’s. And of course we also want us to be able to talk to a radio-only network in the Bermudas that is connected via BGP.

We do not want to force anyone to use the PoPs. Yes, they will make it easier to connect, but only for the people that want a production-grade connection. Not for the ones that want to learn BGP or like to set up antennae, etc. It’s not just one category of people that want the same thing in this network. It’s many, and we should serve them all.

This is what was discussed and we got entangled in implementation decisions (like "are those PoPs to be hardware routers supplied by ARDC or is it better to use VPSes in the cloud") and at some time the discussion was taken offline by the TAC, never to be heard about again. In this solution, there is no reason at all to artifically split the network in intranet and internet sections because the decision how to route can be delegated to the PoP, which obviously runs software capable of dynamic- and policy routing.

Yes, in the network you describe, if you add a few rules and a few additional technical solutions, you could solve “a” / “your” problem. But not everyone else’s. The ARDCs PoPs don’t solve for how I want to connect to this network. So if we just go ahead and force a single way, a single technical solution for a social problem, then I personally believe that we will fail. We’re going to leave many more users either completely excluded or unhappy.

And that’s something that the TAC and ARDC probably do not want to do. This is a resource for all of us, and we should support all the use cases. Not just the ones we want to use, or consider useful, or important.

That’s the main argument here.

I hope that helps, Antonis

Thanks again for the message Rob! As always, reply below :)

On 28 Jul 2021, at 13:18, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

On 7/28/21 12:57 PM, g4ugm via 44Net 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.

I agree it is a "solution without underlying real problem". It is likely coming from the German HAMNET who have always operated like an intranet with some NAT routing via local users on their ISP-provided home router. However, it should not be an issue when a suitable router is present in the network, and when e.g. radio link equipment from MikroTik is used that already does contain a suitable router that can do the job perfectly, and setup a VPN "via" the ISP router to the new AMPRnet backbone.

I really think that "we should accomodate static routes" is a very weak reason for the proposed changes. We should move away from static routes, if anything.

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. It limits me technically, sure, but I understand why that’s important. And I will support it fully. I prefer to live in a network of two use cases with many people people that can easily join than one network where only a few people can be there.

Just look at how much more valuable the Internet becomes when more and more people around the world join. It’s arguably more useful than the ARPANET ;)

After all, this is called the “Network Effect”: https://en.wikipedia.org/wiki/Network_effect https://en.wikipedia.org/wiki/Network_effect

Thanks again, Antonis

On 28 Jul 2021, at 15:11, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote: On 7/28/21 2:59 PM, Antonios Chariton (daknob) via 44Net wrote:

...

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.

You will probably also find people who prefer to use JNOS under MS-DOS and some script to download static routes. But that is no reason to still do it that way.

You seem to forget that your solution of a minor problem has a large impact on established networks. Sure, not networks that the people in your TAC do manage. So no need to consider their woes. Better yet, it presents a chance to make everyone feel how bad it was that a network had to be renumbered because its range was sold. Good riddance.

But really, you should not waste your time on this and go back to square 1. What are our requirements and how can we solve the issues. And this time take a different route than "lets's split the address space".

The fact that you do not know the discussion about the backbone is a bit embarrassing. There was a lot of traffic on a separate mailing list 44NGN and that mailinglist was suddenly deleted because it would be taken to the TAC and a report would come. And now a TAC member does not even know about it. So much has been discussed in the current TAC (according to you) and that apparently never has even come up. What a shame!

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. We all applied and gave up a lot of our time to make things better. If you can’t see that and prefer to attack us, I cannot prevent you from that, but I will not participate any further in this.

I will refrain from responding to any future e-mails of yours until you change your attitude.

We participate in a conversation here as adults and I do not believe that you have added anything in this or the previous message towards the conversation, you simply tried to offend people.

Antonis

On 28/7/21 8:39 pm, Antonios Chariton (daknob) via 44Net wrote:

...

Arrrgh, your use of Reply All and not deleting the direct email disabled my Reply List function, it seems. :(

Sorry, I just hit “Reply” now so it won’t happen again.

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 understand that a renumbering is not painless. But at least we are here to help to make it as painless as possible. I wish we could do something better. Germany had to renumber more than 8,000 hosts recently and it’s not something that we want anyone to go through often.

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.

We aim to make this change a long-term decision: we do not plan on changing the use case again. However, keep in mind that the TAC members have an one year term. Ours expires in about 7 months. It may be different people next year with different opinions, but we hope that the Board will agree to the “at least 5 years” that we proposed.

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

There are some technical solutions (like netmap that I mentioned in a previous e-mail) that can help you be available on the new space from day 1, and then give you enough time to renumber the hosts while both IP addresses work at the same time. As I said earlier, we plan to give time to people, and we hope that it will be something that will happen only once. We are also all available here, in this mailing list, to share our experiences and help each other. I am sure that Germany has plenty of that to share with us as the unofficial 44 Net champions of renumbering :)

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.

We are all in this together, and I would like to think that we are all working towards a common goal. Renumbering is something that we have to do, but the benefits of doing so will probably outweigh the cost, especially in the long term. The ARDC Board typically sets the direction for many years to come, and not for short periods of time that then get changed frequently.

Yeah, see what the Board says.

...

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

Yes, this is something that causes issues for network operators globally.. Just have a look at NANOG and all the geolocation problems they have weeks after the acquisition of new space. But Echolink is an amateur radio software, so I am confident that we could talk to the maintainers and be able to work out a solution, because of the changes that we do in a large scale. In the worst case that this isn’t possible, I think the 3 month period is definitely a reasonable time to wait for, if not more.

Don’t worry, we propose these changes to enable people, not to break their use case and cause them problems.

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

...

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!

Then start from that :) Let’s all take easy small steps first for quick wins, and move to the more complicated ones after we determined a path and found a solution.

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.

I can’t say I am familiar with that personally, but I would start a thread on the mailing list to figure out what other people did. Probably Germany had at least a D-STAR Reflector and an Echolink Proxy and they can provide some insight on how they did this. Alternatively, we can all figure out a path to do this together. You’re not alone! Collectively it should be easier!

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.

On 28/7/21 10:54 pm, Antonios Chariton (daknob) via 44Net wrote:

Yes, it will be difficult, and there are some hotspots for some people that single-handedly manage a lot of addresses, but if there’s anything we can do, we’re happy to help.

Unfortunately, I can't see a lot of scope there, beyond being able to get the new address block early (which has been covered).  And of course, unlike a commercial network (who surely have the same issue occasionally), I don't have a dedicate team of network admins to do the legwork - that's me. ;)

Yes, indeed. We would like to see more, but we requested “at least 5 years”. We’d like to see all future allocations based on this scheme. Keep in mind that the current Direct BGP allocations, no matter the size, are also time limited, in the current state of things, with no guarantee of renewal. So technically this was also a problem before, but realistically it did not affect anyone. I think we just have some more renumbering than usual to do now because this proposal is the largest change to IPv4 Allocation Policy in 44/8 since the original once with the States and Countries.

Yeah, I knew there was a limited timeframe on the "lease", but I didn't see any issue with that.  A lot of those contracts are renewed, unless there's compelling reasons not to.

It is configured in the iptables so it’s within the firewall of the Linux kernel. You don’t need to install additional software. Any Linux server or MikroTik Router (since it runs on Linux) can do it and all the traffic going through this host (e.g. the VPS in this case) can be modified. So you can route your new prefix, and add a rule to your firewall to check if the “Destination IP” is the new prefix, to perform the action “netmap” (instead of “accept” or “drop” or “reject”) to the old prefix. And similarly for outgoing traffic (if the Source is the old, “netmap” to the new).

Well, that's not an issue then, beyond RTFM. ;)

Hello Rob, thanks for your e-mail! Please find my replies inline.

On 28 Jul 2021, at 11:33, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

On 7/28/21 12:31 AM, Antonios Chariton (daknob) via 44Net wrote:

...

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:

Well, I see a couple of issues with that, which I will detail here:

Even with higher-speed radios, amateur radio-based networks typically will have limited bandwidth and higher latency than the public Internet. For instance, HAMNET is an active network deployed as a mix of a static, dynamic, and mesh routed network. There can be many hops over radio nodes to get to the destination. Each node will add latency and most links will have less than 100Mb/s of bandwidth. Considering these conditions, these networks should not be used for high bandwidth applications such as consumer video streaming (eg. Netflix, Hulu).

I think this is an issue that has to be managed locally, not by ARDC. Each local region has to decide how much bandwidth they make available in links, and what usage they determine to be appropriate. This has to be communicated to the local users. An amateur viewing Netflix via AMPRnet is likely not something we would want to see, but I don't think that making the AMPRnet an island is the way to achieve that.

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.

Routing to amateur radio-based networks needs to be easy to implement and can be supported by low-cost routers

Users and operators of amateur radio-based networks typically will have routers that are connected to both the radio-based network and the Internet and will want to pass traffic to the respective networks. This creates a challenge for these users: how to tell the routers which network connection should be used, based on the packet destination. If dynamic routing protocols such as BGP were used, this would lock out almost all operators as consumer-grade routers do not support these protocols. Dynamic routing protocols also require much more memory and CPU power than these routers support.

Well, I think that is an issue that we were going to handle with the new backbone network! Simple end-users would connect to a PoP and send all the AMPRnet traffic they cannot route locally (i.e. to their LAN or to a radio link) towards the PoP and have all the dynamic routing done in the new backbone network. That includes routing towards other regions on AMPRnet, and optionally also routing towards internet. The backbone network would be internet-connected in several places and find the optimal place to route that traffic towards internet, there is no need for the end-user to bother with that. They only need to make sure they route only their AMPRnet traffic there, and not all their normal household internet traffic. But that is something that a consumer-grade router cannot do anyway, so they would often need a more suitable router "behind" the ISP provided router when they would want to route AMPRnet traffic to internet. Those users that see AMPRnet as an island can just route 44.0.0.0/9 and 44.128.0.0/10 to the PoP and the rest to their ISP, and the typical ISP router can do that. When you really want to do all AMPRnet routing on an ISP router, you only need to make sure that your PoP can handle a VPN type that the typical ISP router can setup.

Also I do not understand why this is now brought up as an issue, at the moment where we have many different types of routers available in the 50euro/$60 price range that can do the policy routing and BGP routing. I would not want to advocate making network policy decisions based on "it should be usable with static routing" at THIS moment. Maybe 20 years ago, but not now. We need to look at the current and future situation and it looks bright w.r.t. dynamic routing.

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.

The TAC analyzed the current allocations within 44.0/9 (USA) and 44.128/10 (RoW). Based on the existing use-cases within both ranges and the necessary effort to renumber, the TAC proposes to use 44.128/10 as the prefix for the radio-based network.

Please show us that analysis, because I arrive at a different conclusion. I regularly download the advertised ranges from http://thyme.rand.apnic.net/current/data-add-ARIN and save the AMPRnet portion of that, and at the moment it appears that 182 subnets are advertised from 44.0.0.0/9 and 152 subnets are advertised from 44.128.0.0/10. Considering that the first network is twice the size, the number is comparable or is less for the first than the second.

However, when looking at the number of advertised IP addresses rather than the number of networks, the outcome is: 190720 addresses are directly advertised from 44.0.0.0/9 and 587008 addresses are advertised from 44.128.0.0/10, that is three times as much. So, there is much more effort to renumber when moving those advertised networks in 44.128.0.0/10 towards 44.0.0.0/9 than when doing it the other way around.

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.

Furthermore, the use of the 44.190.0.0/15 network is currently specificially for networks that are part of AMPRnet but are advertised as internet services. This was done as an earlier method to solve the "problem" that this proposal appears to try to solve, and when now doing it in the way of this new proposal that would all have to be reversed again.

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.

Therefore we believe that this is a holistically better option than what 44.190/15 was.

Finally, I am not in favor of any changes that are geared towards making the AMPRnet space a "private, isolated" space. We have the 44.x allocations because they can be routed to internet, when people do not want that they can use a 10.x allocation and be perfectly isolated from the internet. There is no need to have publicly routable space for that (and then declare it to be not routed by policy).

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.

The TAC sees no problem in using “publicly routable space” for the Intranet as it’s the only type of space that can currently guarantee this property of no overlaps and global uniqueness. Furthermore, ARDC has currently a very very large number of IPv4 addresses, and depending on how you count, the usage by end-users is less than 1-5%. I think that even if you count by /16’s on the Internet, the usage is still less than 5%, despite them being empty.

As you mention, a lot of TAC members did not like the idea as well as it was a waste, but since we could not find a better solution, we arrived at a tradeoff: we could either support many more users and make it much easier for someone to join at the cost of IPv4 space, or we could make it harder to join, require special equipment, etc. but conserve IPv4 space. This was an easy decision: we want a lot of users, we want to make it easy for them, we want them to enjoy being part of the network, and we have way more than enough IPv4 space that we need. And this is why we decided that this approach is better.

With the numbers provided above, we can give every current user an allocation in 44.0/10 and one in 44.128/10 and we would still have less than 10% usage of the overall address space, which means that we could still support over 8 times as many people and their networks. And this is a “worst case”: we take the highest usage percentage and we assume that all users want IPs in both spaces. With conversations we had with some users, we believe this is far from the truth. We have at least 2x/15 in Germany that only want to be on the Intranet part.

The proposal seems to consider two disjoint use cases, one is "the radio network" and the other is "the internet connected network". That is also reflected in the 44.190 allocation, and likely is behind many of the current /24 allocations where the user simply wants to play with servers on internet, hopefully for a use case related to amateur radio, and is not making a radio network at all. However, what we have here in the Netherlands is a combination of the two. It is a radio network, with additional internet tunnels to join areas without radio links between them (at least as an interim measure), but also it is internet routed and announced as a /16. We do not want to become an intranet! I think that use case has to remain, and has to be detailed more in the proposal.

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.

This is something that is supported by design and we hope it addresses your use case and provides you with the necessary flexibility to join the network without compromises.

Thanks, Antonis

Hello Rob, thanks again for the long reply. Please find my thoughts below:

On 28 Jul 2021, at 13:11, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

On 7/28/21 12:24 PM, Antonios Chariton (daknob) via 44Net wrote:

...

...

I think this is an issue that has to be managed locally, not by ARDC. Each local region has to decide how much bandwidth they make available in links, and what usage they determine to be appropriate. This has to be communicated to the local users. An amateur viewing Netflix via AMPRnet is likely not something we would want to see, but I don't think that making the AMPRnet an island is the way to achieve that.

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.

I think you are proposing a solution in search for a problem, and you inserted different "problems" in your proposal that seem fabricated at best. We need to look at the matter based on FACTS and not by setting up an entire problem sketch with fabricated reasons and evidence.

In case it wasn’t clear, the TAC or ARDC never proposed anything that would force rules upon local networks and how they connect to each other, or what bandwidth and latency allocations and requirements they make on their links. This is not our goal, nor do we believe that it is our job to do so.

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.

...

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.

About 8 months ago we had a discussion about a new backbone that would replace the IPIP mesh and that would exactly cover this. We had a lot of input, but the discussion was taken offline and the TAC would come with a proposal on how this would be designed and implemented.

I am aware of the discussion but our current TAC was formed 5 months ago and there was no TAC prior to that. I will look into the archives again to better understand what was said. All the members of the current TAC have been following the mailing list in the past and we never make decisions or proposals in vacuum: we always take into account the past, as well as the opinions and comments of current users.

After that, we have heard nothing for 8 months and now we get a paper that proposes to change the network layout, rather than implement the new backbone that would make that change unnecessary. What happened to the backbone proposal? When will it be published, and when will the implementation start? Would it not be better to not make unnecessary changes to the network pending that?

This is a good question: as you can see, our proposed resolution to the Board of Directors includes a statement that requests the funding of this network. Currently it is not fully defined, but we plan to finish this after this resolution, as we need to ensure there is funding for it, and the address plan is defined, since the solution will depend on it. You should expect more news soon, especially if this resolution is approved as is.

The new backbone would solve those issues by offering plain VPNs, that can be installed on many routers and other equipment out-of-the-box, and where a user could route the entire 44.0.0.0/9 and 44.128.0.0/10 minus their local network. No need for complicated routes.

This is something that we took into consideration but we don’t want to create a network where the only option to participate is to connect to these ARDC-operated Points of Presence / VPNs. We want to give users more freedom to do what they like. Building a global VPN network is much easier if you force all users to connect directly to that and receive their prefix statically. But this does not address use cases of Internet-connected radio networks that want to have multiple Internet uplinks and a shared prefix. What I’m saying is that there’s more to it than meets the eye. We could easily ignore all these users and set up an OpenVPN instance or equivalent and be done with it.

Again, our goal is to help interconnect everyone. Not only the people that happen to have a use case that is supported. This requires more advanced planning, more complicated decisions, and it’s never clear which is the right option: it’s all a series of decisions with each carrying its own tradeoffs.

There is always some minimal equipment or minimal effort. When you want to transmit on 20M, you cannot do that using your ISP router (some of them do...) but you need to build or buy a transceiver. When you want to be on AMPRnet, you may need to install some VPN software, or you may need to get a Raspberry Pi or a MikroTik router or similar. I do not see that as prohibitive and we should not try to make a network that covers that, because users will find another reason why they do not want to join.

Indeed, you need to have some minimal equipment or minimal effort for everything. I agree with that. What we try to do with this proposal and as a TAC is to push this “minimal” as much down as possible. For example, we identified that a lot of users do not want a statically assigned prefix, and they only get one because it’s required to connect.

For this reason, the proposed Global Connectivity Platform will provide access to end-user devices directly, in “Access Mode”: it’s like connecting to a simple VPN server and receiving an ephemeral IPv4 address that gives you access to the network, without having to set up anything. You won’t even need a special router or anything special to set up. It’s like EchoLink allows you to transmit without a VHF radio..

As you can tell, it’s not easy to accommodate for every user perfectly, but it is our belief that we can accommodate for many more users without costing the existing ones too much (or nothing at all). We try to avoid the selection bias: if we only ask existing users, they will tell us that everything is fine, or they will suggest more technically advanced solutions. We also have to ask the non-users that want to join, but for whatever reason, they can’t. Who knows, maybe they are much more than the existing ones, too.

If you look at the Survey results that were presented last Saturday, the top 3 things that we need to improve according to the people are inclusivity, removing gatekeeping, etc. I believe that our current proposal has the ability to achieve that, at least to the degree possible by setting network policy. I think it’s a nice step towards this direction. We have many more that we need to take, but this is a good first one.

The fact that you hear that from the users is not very relevant. Back in the early days of packet radio there already were users that "would not invest in a Digicom modem". Not every aspect of ham radio is for everyone. That people respond "I do not want to purchase any equipment" in a questionnaire about "what would you want to do to join HAMNET" should not be taken as an indication that everything should be done without extra equipment! And even less so that the existing population should make whatever effort necessary to accomodate that type of new user.

As I said earlier, the TAC believes that there are many users that will join if we make “minimal” even less than what it is now. On top of that, we want to be inclusive, and like a community, in order to help some members of it participate equally, the others will have to make a few sacrifices. Just like a society, some members are more privileged than others: some have more money, time, knowledge, experience, etc. We believe that this privilege should be used to help others participate equally, and not as a gatekeeping mechanism to isolate or prevent others from joining. If some users don’t want to join because they don’t know, teach them, don’t block them.

...

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.

The barrier will be lowered with the new backbone network.

Indeed, the new backbone network aims to decrease the barrier, but it will be heavily helped if we also get the proposed split of address space based on the use case.

...

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.

1. you cannot research the network by scanning it from the outside. I, as an IP coordinator, have never seen any request for information about the usage of our network. Sure when you scan it from the outside you see only like 20 hosts. But that is because of trapdoor firewalling, not because there are so few. We just guard against port scanners and blacklist them.

Indeed, one can argue that the methodology used is not perfect. But we believe that it is “good enough”. We cannot take the time to talk to every single operator unfortunately and work around any weird firewall or route policy they may have. We scanned the network from the Internet, from IPIP Mesh, from HAMNET, and from the Internet using a 44 address. I think that this is reasonable enough to understand it. Sure, there may be a network that does not answer on odd-numbered ports or does trapdoor firewalling, or any crazy mechanism you can think of like only forwarding packets in even-numbered seconds.

If you are concerned about the Dutch network 44.137/16, then I can assure you that we scanned it, evaluated its size, and took it into account. I also have to say that the links you provided about the route collectors that you have internally certainly helped to get a better picture.

We are perfectly aware that our methodology was not 100% accurate, but we argue that it doesn’t have to be 100% accurate, it has to be good enough to a reasonable degree. And for the rest of the use cases, we have the mailing list to point out things that we missed. I personally believe that it’s unlikely we missed “5 full /16s” after all these scans and by trying different vantage points, but you never know..

...

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.

You should not look only at the number of hosts, but also the number of subnets. Effort to renumber is likely also depending on routed subnets. We do not have a flat address space where we can move hosts one by one.

Indeed, this is the primary metric that we used. Typically the number of hosts makes sense in servers, and the number of subnets makes sense in access. We had to take both into account. Although we could not get visibility into any network, we looked at several large ones, and certainly at everything that exists in the HAMNET DB, where 80% of the users of the total space reside.

...

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.

IMHO there should be no intranet AT ALL within network 44.

We respect this opinion, and we tried to present our view on why we need one and how that would help. However, we understand that we cannot and should not force anyone to change their opinion. We can only present our way of thinking, some context, and answers to your questions, to the best of our ability.

This proposal is the product of the work of the TAC over the past 5 months and hundreds of hours of calls and discussions and documents.

...

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.

That starting point is totally broken. You need to go back to square one and find a different solution to your problem. (which I have never seen in our network because we offer a default route to those users)

I understand that you may never had problems in your network, but for better or worse, not every network is set up and managed similarly to yours, nor do they want to do this. There is a very diverse set of setups out there, and we would like to see even more. The job of the TAC is to help every user build whatever they want, and not to force them all to do one thing that seems to be working somewhere else in the world, in a different environment.

Would you feel comfortable if we mandated the use of a specific network policy across 44 Net that was not yours? I don’t think anyone would like it. So instead of forcing a single use case and network policy, we simply aim to provide everything with the policy, guarantees, and technical infrastructure to do whatever they want, and be able to operate together with everyone else, no matter how they do it.

As I said earlier, it would be very easy for us to only provide a single VPN server and force everyone to connect there, with our terms. We would be done in a day, and with no renumbering. But that’s not our goal. We hope that you get to see that through these responses.

...

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.

There you go. Not a solution. Move away from the presumption that you need a static route in an ISP router, it is just invalid.

We have a number of users that ask this question to us weekly, and some times daily. We cannot just ignore them. If you cannot see that, I am afraid that there’s not much we can do towards this point. As I have said many times today, we try to help as many people as possible, not only a few privileged (by any definition) or existing users.

We know that we can find A solution that would work for SOME users by forcing them all to do SOMETHING. This is not our goal. We choose not to do this and instead try to find a solution that would work for ALL users and they can do ANYTHING and they can still talk to each other.

...

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.

You can setup a management system for 10.x.x.x space to guarantee that no two amateur radio intranets will use the same space. With a little research you can cut out the typical blocks used by existing ISP routers and not allocate those to anyone. Maybe really sometimes you will have an issue and someone has to renumber a small space, but I do not think it is a good idea to force large networks to renumber just to cover this imaginary problem.

This is not an imaginary problem. We have networks that would need to renumber and some times can’t renumber (e.g. their ISP gives a 10/8 address to their PPPoE connection). Trying to maintain a global register of 10/8 networks and carve out all the blocks that are used by something and could cause problems is a much worse solution technically speaking. What if we allocate 10.137/16 to The Netherlands, and then we have users in Spain where their ISP gives them an IP from this part in their PPPoE session? Will we buy the ISP and force them to renumber, or will we have The Netherlands renumber to another block, until we find that e.g. Docker uses it and we have to renumber them again?

All these problems go away if the space that we use is globally unique, like 44.128/10. So by having a few users renumber once, we avoid having to constantly maintain a registry that by definition overlaps with so many use cases that exist now, or will exist in the future. We have enough address space and we can afford to do this, and the pros outweigh the cons.

...

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

Stop there! No intranet please. people can decide to not route their space, but you should not enforce people to make their network an intranet just because someone else cannot manage their local network.

We value your opinion, but as I said earlier this is a conscious decision. We outline this in the proposal in detail, but if some networks advertise everything on BGP and some others don’t, and some networks are only on BGP and not on the Global Connectivity Platform, then things start to break and we have network splits and reachability problems.

To avoid this entire class of problems, and make sure that it can’t happen, no matter what the users choose to do, we split the address space so that you can reach every single host on 44.0/10 (and 44.64/10) over any consumer ISP connection, and you can reach 44.128/10 hosts through this network that you need to somehow get access to (either via VPN, the ARDC PoPs, Radio Networks, Pigeons, etc.).

...

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.

I prefer not to enter into NAT solutions in a network that was clean of NAT solutions until now. Let's go back to constructing the backbone that makes the routing decisions, allows users who do not get involved with that to stay away from those (and still allows users who want advanced solutions to interface with the routing), and lets not hardwire policy into the address space. That has never been a good idea.

The backbone is coming and will certainly help, but we do not think it will be adequate to address all the problems, and most importantly, we will not force anyone to connect to that. Our vision is that anyone should connect to others however they like, and we even allow for the option to create your own Global PoP Backbone if you want to!

I hope this is helpful.

Antonis

On Wed, 28 Jul 2021, Rob PE1CHL via 44Net wrote:

On 7/28/21 2:15 PM, Antonios Chariton (daknob) via 44Net wrote:

...

this proposal is that of the entire TAC, ... on behalf of the TAC, as its designated Spokesperson.

this shit ... I hope it never makes it.

Please suggest some (positive) alternatives.

Let's see if the TAC is an ADVISORY committee

Any response from the board/CAIDA will likely bring clarity about TAC.

Hearing that response clearly, requires more signal, and less noise.

-Paul

On 28 Jul 2021, at 15:01, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote: On 7/28/21 2:29 PM, Paul Sladen via 44Net wrote:

...

On Wed, 28 Jul 2021, Rob PE1CHL via 44Net wrote:

...

On 7/28/21 2:15 PM, Antonios Chariton (daknob) via 44Net wrote:

...

this proposal is that of the entire TAC, ... on behalf of the TAC, as its designated Spokesperson.

this shit ... I hope it never makes it.

Please suggest some (positive) alternatives.

I have already explained it in message e154cb27-eb26-2097-8acf-183bf8f93695@pe1chl.nl

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.

Why should we only have these as minimum requirements? I bet we can create a better network and a technical solution if we force everyone to buy $250k worth of equipment. Why should we accommodate anything else than a Cisco with 400G Ethernet?

Again, our job is to *reduce* the barrier to entry, not to *increase* it. This is our view. I understand that your personal opinion is to increase this barrier, prevent users from joining, and guide them to a single “one and only” solution. This is a valid approach, but it is against what the current TAC believes serves the community.

Antonis

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" 44net@mailman.ampr.org wrote:

Hi,

Everyone needs to remember that the goal is EASY ADOPTION and USE.

Thanks for the e-mail Marius, here are some answers below:

On 28 Jul 2021, at 19:05, marius--- via 44Net 44net@mailman.ampr.org wrote:

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.

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.

About the progress of amateur radio, I know many young people that see no value in it because the Internet exists. No matter if we like it or not, the Internet is a growing reason on why people will not care about this hobby any more. So is it really in our best interest to also kick out the people that found some interest and want to join? I think that if anything we should embrace them and help them become part of it in a way that makes more sense for them: digital. Experience the hobby through a phone.

If we don’t bring more of these people onboard, then the 44net will literally die in two decades, and this is not an exaggeration.

We have to look at what these people like. Not force our own opinions and what we like upon then. We have to figure out what draws them, what they like to do, and then just help them do just that.

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.

We are always open to new solutions and proposals from members, and we will be happy to see one proposed, but right now the problem seems to be that all proposals either willingly or not try to exclude people and increase the barrier of entry. And this is something we disagree with on principle. Our mission is to make it easier. We could find many ways to make it harder.

Antonis

On 7/28/21 18:34, Rob PE1CHL via 44Net wrote:

On 7/28/21 7:28 PM, Antonios Chariton (daknob) via 44Net wrote:

...

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.

But that is what we have now, with the IPIP mesh!  I have repeatedly discussed here that we need to replace that with something easier to use, and it is always only postponed.

Brian used to say: that costs money, and we don't have any. But that is no longer a valid statement.

So now there must be some other reason.  But you would not know, as you even did not know about the above discussion. I am sure most participants here know what I mean. Instead of replying to mail, I suggest that you read some of the archives. And ask Chris G1FEF for the archives of the 44NGN list because that contains important information that you should read and understand before proposing a network restructuring.

Evening All,

This is a lively one.

Cards on the table, I'm one of the unlucky sods(44.155/16 with one /24 separately announced) that would have to do a good bit of re-ip ing of hosts including AMPR based DNS/APRS and BrandMeister Servers as well as re-doing/re-negotiating BGP peering should this proposal be accepted, that said, I'm not averse to change.

I think the reasons for limiting 44.128/10 to Radio only networks are very weak.

Someone already suggested that RFC1918 space could be managed to provide unique address space, and I would tend to agree.

I don't see the utility of assigning 44.X addresses and then restricting them to radio only network. This can be done today by putting, a simple ACL rule at the edge. At least then if the user changed their mind, they simply remove the ACL and they can have direct internet access, also, if a 44.X node is dual-stacked, then the chances are they will be accessible over IPv6 anyway (without the use of an IPv6 ACL)

I can see how having one single route would simplify things, but that is really a limitation of the users understanding, not I daresay a limitation of any hardware available today (or in the last 10 years)

I'm not involved at the Carrier level, but I would hazard a guess that advertising a prefix would almost always be better than not advertising a prefix to prevent piracy.

In summary, reading the proposal, I don't see any real advantage to this for anyone really, and thus would not support it,  but it's been great for getting a discussion going.

Responding to Rob, to my shame, I was not able to lurk on the 44NGN list to follow that discussion. I wonder has anyone summarised the discussion in a fashion similar to this proposal for everyone to see?

Regards

John

EI7IG

On 7/28/21 7:13 PM, Antonios Chariton (daknob) via 44Net wrote:

I also understand the people that really can’t pay $100 or want to add more cables and make a mess in their living room. I have friends in the hobby where even a purchase of $25 can require months of savings and making sure that what you buy is the right thing. And this is typically underrepresented groups, or young people. The same groups we want to bring onboard, and we complain are absent and “not interested”. There are adults today that never had a computer in their life. They only had tablets and most commonly phones. We should definitely allow them to use our network.

Sure but for that you don't need to renumber. You only need to make available some common services like OpenVPN access to the network. We have been doing so for years here and it works. You ask for and get an IP address allocated, receive a .ovpn file, install OpenVPN software, click on it and go. Routing to the entire AMPRnet, via your existing ISP, no matter if that is via an ISP router or via 4G or whatever.

When even that is too difficult, you are not the type of person we should try to get on board the network. For sure it does not cost any money other than what is required to buy a computer and have internet.

That also is the reason why we must be careful to set that as our goal: it has nothing to do with amateur radio, other than that the applicant needs to have an amateur radio callsign. Locally we prefer it when people at least do something amateur radio related.

Rob

On Wed, 28 Jul 2021, Janko Mivšek via 44Net wrote:

I really like to have an explanation of a statement that HAMNET is broken,

Yup ... most of the (*active) 44.x usage *is* HAMNET...

-Paul

On Wed, 28 Jul 2021, Rob PE1CHL via 44Net wrote:

while 44.x->44.x traffic is routed over radio.

The "over radio" is "via built-in VPN", for 99% of cases.

-Paul

Hello everyone,

Rob PE1CHL via 44Net je 28. 07. 21 ob 11:33 napisal:

However, what we have here in the Netherlands is a combination of the two.  It is a radio network, with additional internet tunnels to join areas without radio links between them (at least as an interim measure), but also it is internet routed and announced as a /16.  We do not want to become an intranet! I think that use case has to remain, and has to be detailed more in the proposal.

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.

Antonios Chariton (daknob) via 44Net je 28. 07. 21 ob 12:24 napisal:

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.

Avoiding NAT in any form is one of the biggest advantages of using 44 addresses. I think we need to stick with that goal.

Best 73 Janko S57NK

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.

Ruben - ON3RVH

On 28 Jul 2021, at 17:39, Antonios Chariton (daknob) via 44Net 44net@mailman.ampr.org wrote:

Thanks for the response Ruben, please find my answer below:

...

On 28 Jul 2021, at 13:31, Ruben ON3RVH via 44Net 44net@mailman.ampr.org 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..

To begin with, the TAC sees value in the Intranet and we do not consider it useless. We have a large number of users that agree with this statement and they want this private use case supported. We also believe and try to make connecting to the Internet much easier than it is today. Hopefully we will achieve it with one of the available methods, the Global Backbone / Connectivity Platform. Through this, all private networks like the HAMNET or the Belgium part will be able to connect to each other. But they can do so today, using tunnels and VPNs.

The proof that this Intranet is valuable is already here today: most of the 44net users are only on the Intranet. After talking to many users in Germany, which is by far the largest user of IPv4 space today, we always hear that they’re not interested in using these addresses to connect to the Internet, they only want them for the HAMNET-type network they have.

We hope that these changes will make it easier for existing and for new users to connect, and it will allow more people to participate. We always have to keep in mind that not everyone wants to do the same we want, and not everyone finds use in the same things that we do. The address space is reserved to *all* radio amateurs and not to some people or use cases. Our mission is to make it available to all of them, without forcing them to use it in a mandated way. And if we all want to co-exist together, we have to play by some rules, and we have to make some sacrifices so access is fair and equal to all.

This was the most difficult thing the TAC had to solve: create a network where people can do what they like, and not what *we* like, and if they play by a few very basic rules, then we can all coexist and talk to each other gracefully.

...

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

As I mentioned in previous e-mails, we want a globally unique IPv4 space that is guaranteed to not overlap with any current or future system that may exist out there. The only type of IPv4 space currently in existence that can guarantee this is Global Unicast. Everything else simply cannot meet this one and very simple requirement.

We are not using these addresses because we personally enjoy wasting them, or because we have so many that we may as well waste some of them, but we see their usage as *required* to address the above. We only mention that by using these addresses, we do not bring ARDC into a shortage situation where you won’t be able to receive an allocation because they’re all exhausted. By our estimations we will have way more than enough IPv4 addresses for the future, even if we provide everyone with two allocations in the two use cases.

AGAIN: We don’t want to waste them, they’re the only IPv4 addresses that can guarantee no overlapping globally, today and in the future.

...

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.

As I said in a previous e-mail, we know that the methodology is not perfect. We are aware of this, and we tried to take into account. But we believe that it is good enough. We cannot afford to spend 3 years designing the perfect experiment or talk to each and every current and future user individually and ask them about how their network works and how many devices they have. Before we reach the last person, we’d have all the data changed and we’d have more users. Personally I believe that all measurements we used for this decision are accurate to an order of magnitude. I would be very surprised if there are tens of thousands of hosts that block ICMP packets and nobody has heard about them or knows that they exist.

...

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

Our idea is to not rely on anything. The TAC does not recommend that people use static routes, or BGP, or Windows Servers, or Juniper routers, or anything. We propose this policy to *allow* the people that *want* or *have* to use a static route to be able to join the network. That’s all we want. To enable people to join and enjoy the 44 net, however they like.

...

73

Ruben ON3RVH

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

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/amprhosts.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

On 7/28/21, Antonios Chariton (daknob) via 44Net 44net@mailman.ampr.org wrote:

...

On 28 Jul 2021, at 18:19, Ruben ON3RVH via 44Net 44net@mailman.ampr.org 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?

We have approached a lot of the HAMNET communities and asked them if they want to be routable on the Internet, and they said no. We have also reached out to communities in the U.S. that have explained similar interest, or are doing this today already.

...

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.

I think that IPv4 space was designed before NAT existed. So it was actually designed with this use case in mind: everything has a Global Unicast IPv4 address, and everything can communicate with everything else, end to end.

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

...

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.

Well, the idea is that you will be able to filter them from now on! Only accept 44.128/10 :)

You can never be sure with RFC1918 addresses because everyone can use them. A lot of ISPs assign addresses from 10/8 to their customers, and then do NAT behind a single IP address of hundreds or thousands of customers. So suddenly you have to renumber any ham radio network that falls in the same subnet. VMWare may decide to assign VMs on computers 10/8 addresses (I think they do). Will you then renumber these people as well so people can run VMware on computers that are part of this network? And then what if I want to run Docker? It also uses parts of this space, too. Maybe my corporate VPN also uses 10/8. Will we renumber every user every time some entity on the Internet decides to use 10/8?

That’s the reason we need global uniqueness and guarantee of non-overlapping addresses. There’s nothing technical preventing anyone for using 44.128/10 as an Intranet, and it’s the only reason we know to guarantee this uniqueness.

I hope this answers your questions, Antonis _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 29/7/21 1:38 am, Antonios Chariton (daknob) via 44Net wrote:

To begin with, the TAC sees value in the Intranet and we do not consider it useless. We have a large number of users that agree with this statement and they want this private use case supported. We also believe and try to make connecting to the Internet much easier than it is today. Hopefully we will achieve it with one of the available methods, the Global Backbone / Connectivity Platform. Through this, all private networks like the HAMNET or the Belgium part will be able to connect to each other. But they can do so today, using tunnels and VPNs.

I also see value in the intranet.  Here in Australia, the issue of interconnecting ham radio to the Internet is still a significant regulatory one, so my dominant use cases are either providing Internet facing services for hams (44.190.8/24 is dedicated to this), or intranet use (which is what 44.136.76.0/24 is for).

One unanticipated issue I've had is connectivity between by two IP blocks is poor by default (having to go via San Diego from VK isn't ideal!), but I locally solved that problem with a private route over a VPN between here and the host that 44.190.8/24 runs on.

It does flag a potential issue for some other IRLP reflectors though - I can't have an IRLP node with a VPN address, unless I'm careful about routing.

The existing network DOES have problems in some corner cases, and this is definitely the time to look at solutions.

Give me smooth connection between the Intranet and Internet 44net sites running BGP, and I might be inclined to renumber. ;)

On Wed, 28 Jul 2021, David McGough, KB4FXC via 44Net wrote:

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

Yes, the high-level context is missing: It appears to be:

Open the space up to all hams, regardless of hardware.

That means mobile phones, with built-in VPN facilities, contecting via 44.44.44.44 (or whatever) and getting insta allocated a 44.128 address.

Thus getting people (hams) "on the air" in ~3 minutes.

routing tables and quickly route traffic, leaves me completely baffled--since I already do this all the time.

Most hams can't manage this; ... barrier-to-entry is vastly too high.

I would argue that Internet routable "experimenters" space is more important now than ever.

Hams use Amateur Radio spectrum for communciating betweens hams---not broadcasting to the public.

(In my eyes) 44.128/10 is equivalent of Amateur Radio EMF spectrum.

-Paul

Dear fellow AMPR/Coordinator & user,

As stated on https://pdf.daknob.net/ardc/tac128.pdf proposed change will apply to 44.128/10 which means:

From 44.128.0.0 to 44.191.255.555 Check: http://ccna.exampointers.com/sub.php

Our Argentina 44.153/16 will fall into this as many other countries.

Quoting https://pdf.daknob.net/ardc/tac128.pdf (pg.4)

'Interestingly, the use case defined above requires some guarantees from the people using it 44.128/10 for it to work better than today: it needs to be “isolated”. That means that IP addresses outside of the range cannot talk to it.'

Interesting enough 44.0/10 has none of this restrictions. Allowing Internet-connected purposes and explicily stating 'if you want to join the Intranet and also be on the Internet, you will need to receive two allocations: one in each part of the space.'

Seems that this proposal is on the way into hampering and/or loosing 44.128/10 allocation in the future, and what next? perhaps all 44's.

This said, we strongly oppose presenting this proposed change, warning users of 44.128/10 to analyze and react accordingly.

73, lu7abf, Pedro Converso 44.153 Coordinator as well as The actual registrered 899 users on 44.153.x.x Seen on http://amsat.org.ar/amprhosts.txt

On 7/28/21, Jacob Slater via 44Net 44net@mailman.ampr.org wrote:

All, As many others have said, the proposal comes across as a solution in search of a problem. Renumbering devices - especially those at sites that I don't routinely access - will be needlessly expensive, time consuming, and painful, especially for those of us with sites that are difficult to access.

On radio networks, blocking ICMP (along with most other traffic) from unknown hosts should not be unexpected behavior. I don't think the methodology is inherently sound (not that it makes a huge difference).

For what it is worth, I am opposed to the changes as written.

Jacob Slater / K5AN

On Tue, Jul 27, 2021, 15:34 Antonios Chariton (daknob) via 44Net < 44net@mailman.ampr.org> wrote:

...

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%3E

The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations.

Since the TAC does not have any authority on the IP (or any other) resources of ARDC, and we only have an advisory role, we end this document with a proposed resolution we intend to submit soon to the ARDC Board of Directors, where we urge them to vote and approve some key things required for us to be able to achieve what is described.

We believe that the TAC represents the community and the 44 Net users, so we created this document and post it here in advance, with the purpose of being able to answer your questions, collect your feedback, and hear from you. This is why we briefly explain the situation in about 4 pages, and then we end with the resolution we want the ARDC Board of Directors to approve.

I hope you like it, and I remain at your disposal for anything you may need.

Antonis

Links: [1] - https://blog.daknob.net/mapping-44net/ < https://blog.daknob.net/mapping-44net/%3E

---

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

---

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

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. My backup internet provider's DSL moden, a fritzbox, is not capable of OpenVPN neither, not any other kind of VPN. So those would not be suited for either part of the 44 network. Thus the argument of making it easy for hams to connect via their ISP provided routers is also mute..

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 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Antonios Chariton (daknob) via 44Net Sent: Friday, July 30, 2021 03:19 To: 44Net general discussion 44net@mailman.ampr.org Cc: Antonios Chariton (daknob) daknob@daknob.net Subject: Re: [44net] A new era of IPv4 Allocations

Hello Mario, please find my answers below:

On 29 Jul 2021, at 22:04, Mario Lorenz via 44Net 44net@mailman.ampr.org wrote:

Dear Antonios,

Am 28. Jul 2021, um 00:31:52 schrieb Antonios Chariton (daknob) via 44Net:

...

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

The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations.

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?

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.

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

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.

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

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.

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.

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

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?

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.

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,

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.

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

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.

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 ?

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.

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]

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Hi Egbert,

If we read the proposal and answers from Antonio, then the following statement you made is not correct: -- 2.) 44.128/10 can talk to 44.128/10 - talks to 44.0/10 via the PoPs (without NAT!) --> only ONE routing entry. Intelligence is in the PoPs -- 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.

73

Ruben ON3RVH

-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of DD9QP Egbert via 44Net Sent: Friday, July 30, 2021 10:44 To: 44net@mailman.ampr.org Cc: DD9QP Egbert dd9qp@db0res-svr.ampr.org Subject: Re: [44net] A new era of IPv4 Allocations

Hi all

TNX to Antonious for his explanations. As far as I understand the whole bunch:

1.) 44.0/10 can talk to the whole world - whole world can talk to them

This implies that 44/10 can talk to 44.128/10 via the PoPs (without NAT!) --> only ONE routing entry. Intelligence for this is in the PoPs.

2.) 44.128/10 can talk to 44.128/10 - talks to 44.0/10 via the PoPs (without NAT!) --> only ONE routing entry. Intelligence is in the PoPs

Consequenses: - Issue of not knowing which networks are direct bgp and which are not has completey gone for both groups.

- No multiple routing entries in "primitive" home-routers any more

- Existing NAT-Issues (e.g. echolink) are gone

- No separation inside the 44net-community any more: full connectivity

- thoughts about technical solutions (e.g. PoPs) have been done and could be adopted

- there is no "either...or" , the proposal is open

In my opinion this is a very consistent concept and it would be a great advantage for the whole community.

Therefore I think it is worth to do some "house-cleaning" (call for renumbering) by the ARDC _before_ setting up the technical solutions for this approach.

73s de Egbert DD9QP

Am 30.07.21 um 08:34 schrieb Ruben ON3RVH via 44Net:

Antonios,

I really don't get it. ...

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

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

Am 30.07.21 um 10:55 schrieb Ruben ON3RVH via 44Net:

Hi Egbert,

If we read the proposal and answers from Antonio, then the following statement you made is not correct:

2.) 44.128/10 can talk to 44.128/10 - talks to 44.0/10 via the PoPs (without NAT!) --> only ONE routing entry. Intelligence is in the PoPs -- 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.

73

Ruben ON3RVH

Hi Ruben

I'm replying to you personally because I didn't want to make a mess of the list, but I just read your email, and then the proposal, and I wanted to reply to try to explain extremely briefly the problem that I believe this proposal is trying to solve.

If a user is connected to both the Internet, and to HAMNET hardware, then they could set up the following routes as you suggest: 44/9 and 44.128/10 towards HAMNET 0/0 towards INTERNET

The problem now is that person can not reach any network in 44/9 or 44.128/10 that is connected to the internet only.

Charlie

On Friday, July 30, 2021, 7:35:11 AM GMT+1, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

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. My backup internet provider's DSL moden, a fritzbox, is not capable of OpenVPN neither, not any other kind of VPN. So those would not be suited for either part of the 44 network. Thus the argument of making it easy for hams to connect via their ISP provided routers is also mute..

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 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Antonios Chariton (daknob) via 44Net Sent: Friday, July 30, 2021 03:19 To: 44Net general discussion 44net@mailman.ampr.org Cc: Antonios Chariton (daknob) daknob@daknob.net Subject: Re: [44net] A new era of IPv4 Allocations

Hello Mario, please find my answers below:

On 29 Jul 2021, at 22:04, Mario Lorenz via 44Net 44net@mailman.ampr.org wrote:

Dear Antonios,

Am 28. Jul 2021, um 00:31:52 schrieb Antonios Chariton (daknob) via 44Net:

...

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

The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations.

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?

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.

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

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.

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

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.

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.

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

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?

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.

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,

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.

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

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.

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 ?

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.

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]

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

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

Dear Antonios,

Am 30. Jul 2021, um 03:18:53 schrieb Antonios Chariton (daknob) via 44Net:

Hello Mario, please find my answers below:

Thank you very much for those insights. Although the image this paints is very bleak indeed.

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.

Thats unbelivable, I can but hope that something is lost in translation. Let me rephrase that: The proposal is nothing short of ripping out 44.0/10 from the diverse cloud of radio amateurs that AMPRnet stands for, and making it part of the regular internet, available to anyone without a license and removing traffic exchange with the remainder (44.128) of the AMPRnet. This proposal is, in your spectrum analogy, taking away valuable ham radio spectrum and dedicating it to general internet usage.

I call on the ARDC board to disapprove this plan.

Then again, this is the opposite of the language in the official proposal (last page), making me wonder whether this is truly what the TAC actually discussed and decided. Are there any public TAC meeting minutes or the like by chance ?

...

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

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.

...

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.

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

Your two statements are again contradictory. One point of view, taken by some amateurs back in the 90s was that the communication between two Amateurs should ONLY occur via radio waves. In other words, a "radio only" network should, as the name implies, not be using any other mode of communication, for example an IP tunnel THROUGH the Internet. That is a different, much more extreme position than defining some sort of an "Intranet" for amateur radio usage, which could include internet links, tunneled or not, as long as both end users are licensed amateurs. This is another example why TAC should be very careful with wordings, and maybe provide stringent definitions of some key terms.

...

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?

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.

That is simply not true, since there is no homogenous radio network.

...

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,

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.

You (the TAC), made the claim and used it as a foundation of your proposal. It is your onus to prove it or at least to plausibly support it.

...

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

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.

Sigh. This was not a yes/no question, but rather a question how far you want to turn back the wheels of time for 44.128. Pre-2012, individual networks did not have direct BGP announcements, but had connectivity (or lets say the option to connect) through mirrorshades(.ucsd.edu) which announced 44/8. I can bear witness that this worked that way at least from 1995, but likely much longer.

Radio network access has at all times been set according to the gateway's jurisdiction and ham radio regulations, namely third party traffic. In most of Europe, any non-44 IP frame over an amateur radio link was (and likely still is) illegal. Not so in the US under third party traffic rules, albeit the situation has become considerably murkier with the advent of encryption (HTTPS, SSH).

Again, please observe the careful distinction of "communicating with the open internet" vs. "communicating through the internet"

...

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 ?

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.

You *never* can be certain. How many QSOs have you made where you asked first for a copy of your partners license to be faxed ? The problem is the problem of those allowing the traffic to cross to a radio operated under amateur radio regulations, i.e. the operators of that radio. Pre-2019, most of them would in the past have accepted access to a sufficiently routed 44/8 IP as sufficient authentication, although of course it is not perfect. Others required authentication though a login on the gateway.

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.

This used to be the description of 44/8 (now, sans the AMAZN part). To my knowledge, this never changed (see ARDC's AUP). If it did, I would support a reversion of that change.

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.

People *DID* that, based on the current policy that each subnet can decide if it wants internet connectivity. This was the policy that governed AMPRNet for at least since the mid-nineties. People built their network around that policy (and the legal requirements). Later they *DID* opt for BGP or not.

It is the TAC with this proposal that is flipping over the apple-cart. For such a proposal, in addition to the potential benefits that such a plan may bring, TAC MUST also address the cost epecially the work you force uppon the affected users.

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.

You are forcing your world-view uppon all existing users of 44.128/0 and require those that disagree to leave and expend effort to renumber. I do not think that "inclusive" is quite the correct word for that.

There are people that are fine with having the world communicate with their 44. IPs. Nothing in your ham radio license forbids you talking to other people, as long as you dont do it over a (amateur-) radio. You proudly wear baseball caps with your callsign on it. Why can't you wear your 44 IP?

That said, removing the currently existing option to connect to the internet by central gateway or direct BGP is a major, destructive change of current policy. Sometimes, such destruction is requisite for progress. It is the duty of the TAC to review such a change. Such a review must be balanced, and necessarily must include a detailed discussion of opposing views, a discussion why there is no simple technical solution to the problem, and a discussion of those negatively affected by this change. This all should be documented for the record. Meaningful review would probably have also included a documented poll of the affected network's coordinators.

At this time, I therefore believe the current TAC's proposal is deficient and thus should be rejected (albeit without prejudice)

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.

This analogy is not suitable. For starters, the 2m band extends up to 148 MHz in IARU Regions 2 and 3, which should give you pause to consider the difference of what you are used to, what is legal in your country, and what may be so in the rest of the world.

Secondly, why would I not be allowed to listen to that amateur radio repeater using my commercial all-band radio receiver?

Best regards,

Mario, DL5MLO

On 30 Jul 2021, at 14:29, Charlie Smurthwaite via 44Net 44net@mailman.ampr.org wrote:

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

This is something similar to what we have now, only that some country users were not satisfied with how their country’s IP space is managed, or their local coordinator, etc. and they decided to get addresses outside of their country’s space. So this has already created some fragmentation.

There are countries in which the coordinator is just giving users allocations and there are countries that force people to follow a specific method or network and they cannot use their country’s allocation with the way they prefer.

Moreover, I’m told that the State and Country model that is currently used came from back when there was a single packet network and geography played a much more important role into routing and the equipment capabilities were far more limited. So just because we stuck to that for a few decades, does not mean that it continues to serve us today. Things constantly change, and it’s always good to hang on to the past too much. Something a fresh new look is required.

Finally, for all the other reasons why such a split makes sense (over a country-based one like now) have been discussed in length in my previous e-mail and there is no point in repeating them.

Thanks, Antonis

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 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Gerrit Herzig DH8GHH via 44Net Sent: Friday, July 30, 2021 16:31 To: 44Net general discussion 44net@mailman.ampr.org Cc: Gerrit Herzig DH8GHH dh8ghh@darc.de Subject: Re: [44net] A new era of IPv4 Allocations

Hello Charlie,

As stated earlier, I am a region coordinator for the HamNet in Germany.

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

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

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

Hi Gerrit,

I’m saying to send ALL internet traffic through the network, but certainly all internet bgp connected 44 networks and the ipip mesh. If I am correct in understanding, you are already sending all IPIP traffic to the pop, so why not all other 44 routes that are not in the IPIP mes(s)h?

That is how a pop should function. It acts as the gateway between ham networks that are not directly connected. That is what was asked from the TAC to investigate, design, put up to discussion, get approval and implement..

Ruben - ON3RVH

On 30 Jul 2021, at 19:13, Gerrit, DH8GHH via 44Net 44net@mailman.ampr.org wrote:

Hi Ruben,

sending all internet related traffic via the HamNet is no solution:

HamNet is not broadband DSL. There are users that have only 1 MBits uplinks to the HamNet. NPR-Users have less than 200 kBits available. In addition, we don't even know how good/fast the packets are forwarded in the HamNet.

The decision whether a data packet is to the HamNet or to the internet must be made in the users router at home. If a service is located in the internet, we want the data go through the DSL line.

I re-iterate my question: What are the correct route settings so that data packets destined for 44 internet services take their way via the DSL connection and data packets for HamNet go to my antenna?

73 de Gerrit, DH8GHH

Am 30.07.2021 17:09, schrieb Ruben ON3RVH:

...

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 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Gerrit Herzig DH8GHH via 44Net Sent: Friday, July 30, 2021 16:31 To: 44Net general discussion 44net@mailman.ampr.org Cc: Gerrit Herzig DH8GHH dh8ghh@darc.de Subject: Re: [44net] A new era of IPv4 Allocations Hello Charlie, As stated earlier, I am a region coordinator for the HamNet in Germany.

...

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

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

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

On Fri, 30 Jul 2021, Mario Lorenz via 44Net wrote:

...

44.128/10, however you connect to it, is the radio amateur band, 44.0/10 is the commercial 5G band or the ISM band of WiFi.

Thats unbelivable, I can but hope that something is lost in translation.

Hopefully lost in translation... (it could also be that myself/others are also lost in translation!)

The proposal is nothing short of ripping out 44.0/10 from the diverse cloud of radio amateurs that AMPRnet stands for, and making it part of the regular internet, available to anyone without a license

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

and removing traffic exchange with the remainder (44.128)

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

This is like having to tune radios to 144.1234 Mhz to hear each other, and be using the same transmission/reception mode.

I call on the ARDC board to disapprove this plan.

That seems quite an absolute position. :(

Are there any public TAC meeting minutes or the like by chance ?

I'm personally hopefully that ARDC will still take the opportunity to transition to something more open---with board minutes (and TAC minutes) plus regulary filed financials.

ARDC is not quite there yet; but there is still time. Hopefully a desire for openness is something we can agree on?

-Paul

Secondly, why would I not be allowed to listen to that amateur radio repeater using my commercial all-band radio receiver?

...You can, just sign up for a CAIDA research account and drink from the firehose that is the UCSD Network Telescope 44/8 incoming feed.

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

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:

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 44net@mailman.ampr.org 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 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 10 août 2021 17:57 À : 44net@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: 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

---

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

---

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

Le 11/08/2021 à 09:29, Ruben ON3RVH via 44Net a écrit :

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.

The current talks are about regional/local "POPs" managed by skilled sysadmins, and "Access routers" for endpoints (that can be Mikrotik/OpenWRT/etc..., or client software running on any platform). The "complex" routing stuff will be done by sysadmins at POP level (and the purpose of the TAC is to simplify it). End-users will get plug-and-play configurations obtained from the POP, and automatically generated. Users will just have to plug their equipment to the right Ethernet port. At least, that's what we should achieve, HI :-)

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

We all agree about that :-) But I don't think it's currently true, HI :-)

On 8/11/21 2:33 PM, pete M via 44Net wrote:

You are again over simplyfing the situation to squeeze your solution as possible.

For your solution to work we need a setup a list of net that are either ham only, ham and internet, internet only. Imagine that a ham with a /20 and he use them to supply ip to a few service for ham only, some are for service for both internet and ham only, and some service just for the internet for club server that have publicity running on it, so it should not be over the air waves at all. and he supply a way to connect to ampr by a an rf network and each endpoint can deceide to be A or B. the IP are all scattered between al the use case. Just imagine the needed list to have that network running as it should by the pop. Now, we continu with 500 new allocation that do the same, add a few thousand new user asking for a /28 with each ip that can be used as any of the 3 possibility and put that in the routing and or firewalling of the pop.

That is actually no problem at all!  BGP manages that automatically.  As soon as a user connects to the PoP, their prefix will be announced on the network and all the other routers (and users who choose to use BGP) will get the new route.  When they disconnect, the route vanishes and the same space may be routed as part of a larger subnet, or become unreachable. There is no need to manually maintain a list for that.  That is the big difference with the current IPIP mesh which uses a static table maintained via a webinterface at portal.ampr.org.  There it is the responsibility of the operators to enter the subnets they route, and the data will remain there long after they have lost interest in being a gateway.

Rob

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 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 11 août 2021 04:28 À : 44net@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

On 8/11/21 12:50 AM, pete M via 44Net 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 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 10 août 2021 17:57 À : 44net@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:

...

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

---

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

---

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

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

Le 11/08/2021 à 15:15, Ruben ON3RVH via 44Net a écrit :

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

As far as "Internet" address range is directly exposed to wild Internet, as far as end-users are not necessarily aware about that (they used to be behind a NAT router), and as far as some connected devices may not always have all the latest security patches, our gateway firewall does a little bit more : - All incoming traffic except ICMP is blocked by default. Allowed traffic is defined explicitly (f/ex : full access for people who know what they are doing, or opening only the ports needed for the target application ; ssh always closed from "outside" unless specified) - Basic filtering of "bad" IPs (currently based on Firehol blocklists)

Anyway, this is a personal choice. As we (TK1BI, TK4TO, TK5EP, TK1CX) are the only sysadmins for all the island, and as we personally know all of our users (and installed their access routers), we found it simpler and easier to manage firewall rules on the central gateway than individually on every endpoint access router. On a country-wide setup, this may not be doable, anyway, HI :-)

Le 11/08/2021 à 15:57, pete M a écrit :

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?

You're welcome :-) Corsica is a department of France, and CEPT agreement does apply. We do not have any "public" 44net access, our repeater/network map is two-years old, and things are changing quite fast, HI :-) One thing on my ToDo-List is a dynamic APRS map of active network obtained from our monitoring (Nagios) and IPAM (NetBox) tools. For now, our http://xlx.radioamateur.tk is the most up-to-date repeater list. We are reachable through Echolink (TK5KP), D-Star/DMR (XLX755K) and some other more or less reliable things. All is linked together. We also have an XLX interlink with XLX929 (operated by VE2KBS).

Hope to hear you soon. 73 de TK1BI

On 8/11/21 2:59 PM, pete M via 44Net 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.

What if some local group does not believe in RF and wants to use two tin cans and a string?  or a swarm of pigeons? Shouldn't we be able to support them?  No.

There is always some minimal equipment list.  However, with that setup it would still be possible to do it when the PoP provides routing of a subnet to a connected user (without BGP) and the two hams can agree to use part of that subnet together (e.g. each uses half the subnet). Then with a couple of static routes you can route everything the correct direction. Of course it is more work than with a capable router, but hey you can proudly announce on the local repeater you saved $10 (and donated that to the repeater group).

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?

Firewalling in such cases is best done by network range.  When the router can do it.  If not, tough luck.

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.

The authentication system would be a service similar to LoTW certificates or Echolink authentication which are already in place. There would be some authority that checks applications by amateurs and provides them with the password or certificate, exactly like what LoTW and Echolink are already doing. There would be an authentication service (RADIUS server) in the backbone network, e.g. with redundancy using anycasting, where each service that requires autentication can validate the connecting user. Most software already in user has RADIUS authentication options or has plugin capability to allow using that. We use it internal to our network, e.g. to provide the user password validation required when connecting to a WiFi access point, or when setting up a PPPoE tunnel over the radio network. (in use to allow roaming users to connect to any access point and still get their fixed IP)

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?

Spoofing is an annoyance but often not really a security risk.  Only with datagram protocols like UDP there is a risk. With TCP you cannot really setup a connection from a spoofed IP. Hijacked BGP ranges would be a possibility, but they can be blocked by using address lists managed by the IP coordinator who allows BGP announcements. (he can compare the issued BGP permits with the actual info received from BGP)

And remember, these issues are NOT solved at all with an intranet!!  Even on an intranet, any bad guy can connect to it (easy when they have a license, but likely also when they don't) and start attacking systems.  Worse, when trojan/worm software enters the network at some place, it will happily propagate through the network. And, the situation will probably be worst when there is a false sense of security among the participants ("we are on an intranet, we do not need to worry").

Modern firewall technology does not need a ne rule for every user.  It can have rules that refer to address lists that contain multiple addresses or subnets that are to be in some category (e.g. blocked, firewalled, not firewalled, not existing) and a single rule tells the firewall what to do when addresses in that list are encountered. This is just standard technology available in Linux (ipset) and RouterOS (/ip firewall address-list).  RouterOS even can populate such lists using DNS names, we use that e.g. to load lists of "valid addresses on the local subnet" or "trusted network admins" from a DNS server (with slaves for redundancy) so we do not need to modify the config of several routers when the contents of such a list changes.

Rob

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 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Ruben ON3RVH via 44Net 44net@mailman.ampr.org 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 44net@mailman.ampr.org 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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@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.

Télécharger Outlook pour Androidhttps://aka.ms/AAb9ysg

________________________________ From: 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org on behalf of Andy Brezinsky via 44Net 44net@mailman.ampr.org Sent: Friday, August 13, 2021 12:30:34 AM To: 44net@mailman.ampr.org 44net@mailman.ampr.org Cc: Andy Brezinsky andy@mbrez.com 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 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Ruben ON3RVH via 44Net 44net@mailman.ampr.org 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 44net@mailman.ampr.org 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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

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

---

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

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

Thanks for the honesty John, I look forward to seeing that.

Could the TAC explore the subnet classification list idea? I think it would achieve the desired goals without nearly as much community turmoil / drama.

73

Bill Buhler - AF7SJ

On 8/13/2021 11:48 AM, John Gilmore wrote:

pete M via 44Net 44net@mailman.ampr.org wrote:

...

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.

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

+1

The subnet classification idea is a good one. Basically start by announcing a list of BoGons via bgp to the internet for subnets which are not authorized.

Eric

AF6EP

On 2021-08-14 07:35, Bill Buhler via 44Net wrote:

Thanks for the honesty John, I look forward to seeing that.

Could the TAC explore the subnet classification list idea? I think it would achieve the desired goals without nearly as much community turmoil / drama.

73

Bill Buhler - AF7SJ

On 8/13/2021 11:48 AM, John Gilmore wrote: pete M via 44Net 44net@mailman.ampr.org wrote: 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. 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

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

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:

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Not to mention what the commercial side of domains do, EPP (Extensible Provisioning Protocol).

The following are the RFCs for EPP that are listed on the Wikipedia page for EPP:

* RFC 3375 - Generic Registry-Registrar Protocol Requirements * RFC 3735 - Guidelines for Extending EPP * RFC 3915 - Domain Registry Grace Period Mapping (e.g. Add Grace Period https://en.wikipedia.org/w/index.php?title=Add_Grace_Period&action=edit&redlink=1, Redemption Grace Period https://en.wikipedia.org/wiki/Redemption_Grace_Period) * RFC 4114 - Using EPP for ENUM https://en.wikipedia.org/wiki/ENUM addresses * RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) (obsoletes RFC 4310, DNSSEC https://en.wikipedia.org/wiki/DNSSEC) * RFC 5730 - Extensible Provisioning Protocol (EPP) (obsoletes RFC 4930, which obsoleted RFC 3730) * RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping (obsoletes RFC 4931) * RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping (obsoletes RFC 4932) * RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping (obsoletes RFC 4933) * RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP (obsoletes RFC 4934) * RFC 8543 - Extensible Provisioning Protocol (EPP) Organization Mapping * RFC 8544 - Organization Extension for the Extensible Provisioning Protocol (EPP)

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me

On 2021-08-14 10:07 a.m., Darcy Buskermolen via 44Net wrote:

There is a whole RFC 2136 https://datatracker.ietf.org/doc/html/rfc2136 dedicated as an "API" for DNS updates.

On Sat, Aug 14, 2021 at 8:44 AM Rob PE1CHL via 44Net 44net@mailman.ampr.org 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

On 8/14/21 5:32 PM, Bill Buhler via 44Net wrote:

...

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

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

---

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

Hey Mark, I've posted about 3 different messages to this thread at this point and none have been approved. I tried saying earlier that there is already a .radio restricted to callsign holders only (amateur or commercial). Further to that the existing domain industry uses EPP and would allow us to properly give people subdomains in a similar style to how I own kagl.me

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me

On 2021-08-14 10:21 a.m., Mark Van Daele via 44Net wrote:

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

...

On Aug 14, 2021, at 10:44 AM, Rob PE1CHL via 44Net 44net@mailman.ampr.org 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

...

On 8/14/21 5:32 PM, Bill Buhler via 44Net wrote: 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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

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

---

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

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:

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:

...

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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

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