It is about a year ago that I tried to discuss such a proposal.
My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers).
The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc.
The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them. And of course, radio links can be incorporated in the scheme.
Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board.
I see this as a solution for the following problems: - more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc. - non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those. - some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do. - the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables.
I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course). As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further.
I don't know if the attitude an scepticism has gone away now. We would have to see in a new discussion. Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever. Maybe not.
I don's see the need of routing the entire 44Net from internet to all those routers. When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues. Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router. That relieves us from being responsible for that announcement, and we use the ISP NOC services. But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number)
W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost.
Rob
I'm a relative newcomer to using 44Net for ham things (last 2-ish years) but we've made extensive use of it in our Megalink project for Northeast Ohio.
I think that something that is more turnkey for the ham community is sorely needed. Most hams are not network engineers. Much good work has been done over the years to make AMPNet what it is. However in 2020, most basic infrastructure is largely turnkey (e.g. AWS, Azure, cloud hosting, VPS, etc.). Infrastructure and network engineering is, sadly, a diminishing field because the need just isn't there anymore outside of the big providers. To support ham connectivity into the future, AMPR needs to offer something comparable.
The one caveat I would offer is that endpoints connecting to such a new service core should be one of a limited number of supported hardware + software configurations at the end. Experimentation can be free beyond the connection's edge device but the edge devices themselves need to be fairly uniform for supportability. I also firmly believe that any new service should be dual-stack v4 and v6. We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
The other thing is that having lots of transit at major providers is $$$++ (relatively speaking) and we're probably want run the core on some serious networking hardware. Would ARDC fund these? I'd be willing to help run one or several, but the expense of doing so is far beyond my budget.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Rob Janssen via 44Net Sent: Saturday, July 11, 2020 4:52 PM To: 44net@mailman.ampr.org Cc: Rob Janssen pe1chl@amsat.org Subject: Re: [44net] My view to 44net's future
It is about a year ago that I tried to discuss such a proposal.
My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers).
The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc.
The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them. And of course, radio links can be incorporated in the scheme.
Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board.
I see this as a solution for the following problems: - more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc. - non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those. - some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do. - the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables.
I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course). As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further.
I don't know if the attitude an scepticism has gone away now. We would have to see in a new discussion. Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever. Maybe not.
I don's see the need of routing the entire 44Net from internet to all those routers. When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues. Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router. That relieves us from being responsible for that announcement, and we use the ISP NOC services. But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number)
W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost.
Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello again,
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs". Not only would this solve the issue being discussed, this sort cooperation would help to build up and strengthen local HAM communities by getting HAMs with different skill-sets to work together on making AMPRnet connections work.
To get the ball rolling on this (to be a "doer" as KB9MWR mentioned above), I'd be happy to throw my hat in the ring and put myself on such a list:
I'm KE5SAI. I'm located in Austin and operate dedicated servers/VPSes in Dallas and Kansas City. I announce 44.76.17.0/24 to my upstreams. I do both amateur radio and IP networking as my hobbies. As such, if any HAM in the region would like "local" AMPRnet connectivity, I would be more than happy to carve off a piece of 44.76.17.0/24 for them (I've certainly got plenty of space on it to spare for other HAMs) and provide them with a tunnel to complete the connection. It would be better than "turnkey solutions". It would be HAMs working together, cooperating from each other and experimenting together.
Regards,
Erik KE5SAI
On Sat, Jul 11, 2020 at 4:11 PM Jason McCormick via 44Net 44net@mailman.ampr.org wrote:
I'm a relative newcomer to using 44Net for ham things (last 2-ish years) but we've made extensive use of it in our Megalink project for Northeast Ohio.
I think that something that is more turnkey for the ham community is sorely needed. Most hams are not network engineers. Much good work has been done over the years to make AMPNet what it is. However in 2020, most basic infrastructure is largely turnkey (e.g. AWS, Azure, cloud hosting, VPS, etc.). Infrastructure and network engineering is, sadly, a diminishing field because the need just isn't there anymore outside of the big providers. To support ham connectivity into the future, AMPR needs to offer something comparable.
The one caveat I would offer is that endpoints connecting to such a new service core should be one of a limited number of supported hardware + software configurations at the end. Experimentation can be free beyond the connection's edge device but the edge devices themselves need to be fairly uniform for supportability. I also firmly believe that any new service should be dual-stack v4 and v6. We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
The other thing is that having lots of transit at major providers is $$$++ (relatively speaking) and we're probably want run the core on some serious networking hardware. Would ARDC fund these? I'd be willing to help run one or several, but the expense of doing so is far beyond my budget.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Rob Janssen via 44Net Sent: Saturday, July 11, 2020 4:52 PM To: 44net@mailman.ampr.org Cc: Rob Janssen pe1chl@amsat.org Subject: Re: [44net] My view to 44net's future
It is about a year ago that I tried to discuss such a proposal.
My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers).
The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc.
The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them. And of course, radio links can be incorporated in the scheme.
Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board.
I see this as a solution for the following problems:
- more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc.
- non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those.
- some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do.
- the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables.
I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course). As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further.
I don't know if the attitude an scepticism has gone away now. We would have to see in a new discussion. Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever. Maybe not.
I don's see the need of routing the entire 44Net from internet to all those routers. When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues. Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router. That relieves us from being responsible for that announcement, and we use the ISP NOC services. But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number)
W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost.
Rob _________________________________________ 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
Sure, but we have been doing that for many years here in the Netherlands. My proposal was just to get this a little more formalized and widespread, so we could make it worldwide and have it replaced the IPIP mesh so newcomers can more easily connect to it.
Rob
On 7/11/20 11:28 PM, Erik Seidel wrote:
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs".
On Sat, Jul 11, 2020 at 4:34 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
Sure, but we have been doing that for many years here in the Netherlands. My proposal was just to get this a little more formalized and widespread, so we could make it worldwide and have it replaced the IPIP mesh so newcomers can more easily connect to it.
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
Rob
Regards,
Erik KE5SAI
On 7/11/20 11:28 PM, Erik Seidel wrote:
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs".
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I agree with Erik, that's a nice way to provide more flexibility and lower latency compared to the single central gateway. I would also be willing to contribute if needed. I have locations throughout North America and one in Europe. It would take some coordination and thought of course, but I would be willing to provide transit in these locations under certain conditions.
Cheers, Nate KJ7DMC
On Sat, Jul 11, 2020 at 2:42 PM Erik Seidel via 44Net 44net@mailman.ampr.org wrote:
On Sat, Jul 11, 2020 at 4:34 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
Sure, but we have been doing that for many years here in the Netherlands. My proposal was just to get this a little more formalized and widespread, so we could make it worldwide and have it replaced the IPIP mesh so newcomers can more easily connect to it.
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
Rob
Regards,
Erik KE5SAI
On 7/11/20 11:28 PM, Erik Seidel wrote:
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs".
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 am thinking more of using BGP to distribute the info, could be used as routing info as well but not necessarily, usually one can configure BGP to store the info in a separate routing table used only for lookup in a firewall rule or similar. Everyone only needs to advertise their own IPv6 networks, and will receive all the others from the peers. No need to put all that info in a central database!
Of course you would require some BGP peers and the portal could be a source of contact info to set them up. But once you have enough peers so that the network does not split up into islands when some random participant stops, it does not require some central resource where all info is stored. And when we would have those global routers as explained in my proposal, they could run the BGP instance for this as well (and still not be essential for its operation).
Rob
On 7/11/20 11:41 PM, Erik Seidel wrote:
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
My understanding was that Erik was discussing the distribution of IPv6 prefix info here, but maybe he wasn't.
When it is just about "finding who is a local gateway who would announce the IPv4 space you are in on internet, and who you can connect to", sure that could be added to the portal. As I am a coordinator for the regional network, I sometimes get requests via the portal from people who want to be on the IPIP mesh, and then explain them the alternative of connecting to our own gateway router. The portal could offer such info as an editable text for each regional subnet.
Maybe by setting up such a thing, we can then transition it into a system like I described, where the interconnects between those gateways can be made in a more modern way than we have now.
Rob
On 7/11/20 11:50 PM, Rob Janssen wrote:
I am thinking more of using BGP to distribute the info, could be used as routing info as well but not necessarily, usually one can configure BGP to store the info in a separate routing table used only for lookup in a firewall rule or similar. Everyone only needs to advertise their own IPv6 networks, and will receive all the others from the peers. No need to put all that info in a central database!
Of course you would require some BGP peers and the portal could be a source of contact info to set them up. But once you have enough peers so that the network does not split up into islands when some random participant stops, it does not require some central resource where all info is stored. And when we would have those global routers as explained in my proposal, they could run the BGP instance for this as well (and still not be essential for its operation).
Rob
On 7/11/20 11:41 PM, Erik Seidel wrote:
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
How would you suggest structuring the neighbor relationships here? Would there be a bunch of route reflectors in each region, or would this become more of a mesh topology?
Nate KJ7DMC
On Sat, Jul 11, 2020 at 2:51 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
I am thinking more of using BGP to distribute the info, could be used as routing info as well but not necessarily, usually one can configure BGP to store the info in a separate routing table used only for lookup in a firewall rule or similar. Everyone only needs to advertise their own IPv6 networks, and will receive all the others from the peers. No need to put all that info in a central database!
Of course you would require some BGP peers and the portal could be a source of contact info to set them up. But once you have enough peers so that the network does not split up into islands when some random participant stops, it does not require some central resource where all info is stored. And when we would have those global routers as explained in my proposal, they could run the BGP instance for this as well (and still not be essential for its operation).
Rob
On 7/11/20 11:41 PM, Erik Seidel wrote:
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Running .ham for my own equipment, its easy enough to arrange for intra Ham announcements without getting TLD recognized under IANA. Provide a anycast range that we all point DNS resolution.
Adam KC7GDY
On Jul 11, 2020, at 3:03 PM, Nate Sales via 44Net 44net@mailman.ampr.org wrote:
How would you suggest structuring the neighbor relationships here? Would there be a bunch of route reflectors in each region, or would this become more of a mesh topology?
Nate KJ7DMC
On Sat, Jul 11, 2020 at 2:51 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
I am thinking more of using BGP to distribute the info, could be used as routing info as well but not necessarily, usually one can configure BGP to store the info in a separate routing table used only for lookup in a firewall rule or similar. Everyone only needs to advertise their own IPv6 networks, and will receive all the others from the peers. No need to put all that info in a central database!
Of course you would require some BGP peers and the portal could be a source of contact info to set them up. But once you have enough peers so that the network does not split up into islands when some random participant stops, it does not require some central resource where all info is stored. And when we would have those global routers as explained in my proposal, they could run the BGP instance for this as well (and still not be essential for its operation).
Rob
On 7/11/20 11:41 PM, Erik Seidel wrote:
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
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
Of course it depends if you want to do IPv6 routing over our own routers, or just leave it to the ISP to route it over internet. When you want to do routing, of course you need to configure viable peers to route your actual traffic (e.g. the proposed global routers). But when you merely want to use BGP as a distribution mechanism for whitelisted subnets and not to do the actual routing using that information, it is not required to have a mesh and it is sufficient to have some "reliable" peers that complete the connectivity around the world. There are always some "more active" members that could offer such service, and it could also be offered e.g. at UCSD. The essential difference with offering some list "from the portal" is that there is no need to manually maintain a central database and assure its availability. Everyone can advertise their own prefix and make sure it is current (e.g. when the IPv6 prefix is dynamic).
Rob
On 7/12/20 12:03 AM, Nate Sales wrote:
How would you suggest structuring the neighbor relationships here? Would there be a bunch of route reflectors in each region, or would this become more of a mesh topology?
Nate KJ7DMC
On Sat, Jul 11, 2020 at 2:51 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
I am thinking more of using BGP to distribute the info, could be used as routing info as well but not necessarily, usually one can configure BGP to store the info in a separate routing table used only for lookup in a firewall rule or similar. Everyone only needs to advertise their own IPv6 networks, and will receive all the others from the peers. No need to put all that info in a central database!
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
I think this is a good idea that should require little effort for Chis G1FEF to implement.
When you are looking at your regional networks it could show if they are BGP or IPEncap connected. That flag is already there, and the means to be able to message those folks via the portal appears to be there.
Basically a trusted route registry DB for both IPv4 and IPv6 prefixes. And some tools for generating routes, ACLs, etc based on the type of object.
Tony AH6BW
On Jul 11, 2020, at 11:42, Erik Seidel via 44Net 44net@mailman.ampr.org wrote:
On Sat, Jul 11, 2020 at 4:34 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
Sure, but we have been doing that for many years here in the Netherlands. My proposal was just to get this a little more formalized and widespread, so we could make it worldwide and have it replaced the IPIP mesh so newcomers can more easily connect to it.
Make a list of HAMs who are announcing AMPRnet prefixes along with their locations and their contact info. Put it on the ampr.org portal so everybody can access it. That would be more formalized without being needlessly centralized.
Rob
Regards,
Erik KE5SAI
On 7/11/20 11:28 PM, Erik Seidel wrote: It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs".
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
With a little digging, that information is already available.
Get Origin AS for 44.76.17.0/24 here:
http://thyme.rand.apnic.net/current/data-add-ARIN
Then lookup AS.
https://ipinfo.io/AS36198#whois
Ron W6RZ
On 7/11/20 14:28, Erik Seidel via 44Net wrote:
Hello again,
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs". Not only would this solve the issue being discussed, this sort cooperation would help to build up and strengthen local HAM communities by getting HAMs with different skill-sets to work together on making AMPRnet connections work.
To get the ball rolling on this (to be a "doer" as KB9MWR mentioned above), I'd be happy to throw my hat in the ring and put myself on such a list:
I'm KE5SAI. I'm located in Austin and operate dedicated servers/VPSes in Dallas and Kansas City. I announce 44.76.17.0/24 to my upstreams. I do both amateur radio and IP networking as my hobbies. As such, if any HAM in the region would like "local" AMPRnet connectivity, I would be more than happy to carve off a piece of 44.76.17.0/24 for them (I've certainly got plenty of space on it to spare for other HAMs) and provide them with a tunnel to complete the connection. It would be better than "turnkey solutions". It would be HAMs working together, cooperating from each other and experimenting together.
Regards,
Erik KE5SAI
On Sat, Jul 11, 2020 at 7:30 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
With a little digging, that information is already available.
Get Origin AS for 44.76.17.0/24 here:
http://thyme.rand.apnic.net/current/data-add-ARIN
Then lookup AS.
That doesn't tell us much about the HAM's location and where their network's edge is located. The idea is to help HAMs find other local HAMs announcing AMPRnet prefixes.
Ron W6RZ
Regards, Erik KE5SAI
On 7/11/20 14:28, Erik Seidel via 44Net wrote:
Hello again,
It seems to me that we are making this more complicated than is necessary. How about this for a simple approach: There are already a number of HAMs who are already operating small networks and are announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you will, their locations and their contact info. Other HAMs in the area who wish to connect to AMPRnet and are interested in a more "local" approach (rather than just going through the UCSD edge) can then reach out to one of these "BGP speaker HAMs". Not only would this solve the issue being discussed, this sort cooperation would help to build up and strengthen local HAM communities by getting HAMs with different skill-sets to work together on making AMPRnet connections work.
To get the ball rolling on this (to be a "doer" as KB9MWR mentioned above), I'd be happy to throw my hat in the ring and put myself on such a list:
I'm KE5SAI. I'm located in Austin and operate dedicated servers/VPSes in Dallas and Kansas City. I announce 44.76.17.0/24 to my upstreams. I do both amateur radio and IP networking as my hobbies. As such, if any HAM in the region would like "local" AMPRnet connectivity, I would be more than happy to carve off a piece of 44.76.17.0/24 for them (I've certainly got plenty of space on it to spare for other HAMs) and provide them with a tunnel to complete the connection. It would be better than "turnkey solutions". It would be HAMs working together, cooperating from each other and experimenting together.
Regards,
Erik KE5SAI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
IPv6 has been discussed before, and I think the predominant opinion is that we should NOT get a /32 for an IPv6 version of AMPRnet (and get the same routing issues as we now have for IPv4), but rather we should encourage everyone to get IPv6 space from their own ISP or from a local IPv6 tunnel provider, and then devise some way to communicate our IPv6 subnets to eachother (so they can be used to further trust some IPv6 source addresses as being from fellow AMPRnet users) and maybe even route them over our own network.
Rob
On 7/11/20 11:10 PM, Jason McCormick wrote:
We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
I also firmly believe that any new service should be dual-stack v4 and v6. We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
Yes Rob and newcomers;
We have had discussion on trying to get a v6 allocation for ham radio before. And even if that could happen, we'd be in the same routing and infrastructure (data center) boat that we have now.
Conclusion:
It seems very unlikely hams will need their own allocation as the smallest IPv6 prefix assigned to a residential connection is a /64 subnet yielding 18,446,744,073,709,551,616 hosts.
We just need a means of advertising the ham netblocks (possibly announced by RIP/ RSS) and automatically configuring filtering (an iptables whitelist).
A DNS to register the ham hosts in, etc. An ideal situation would be a totally self-service DNS that uses LoTW (Logbook of the World) P12 certificates to authenticate hams, where they could then enter the IPv6 address(es) from their residential connection that are for ham use.
This is what I mentioned before.
On Sat, Jul 11, 2020 at 4:31 PM Rob Janssen via 44Net 44net@mailman.ampr.org wrote:
IPv6 has been discussed before, and I think the predominant opinion is that we should NOT get a /32 for an IPv6 version of AMPRnet (and get the same routing issues as we now have for IPv4), but rather we should encourage everyone to get IPv6 space from their own ISP or from a local IPv6 tunnel provider, and then devise some way to communicate our IPv6 subnets to eachother (so they can be used to further trust some IPv6 source addresses as being from fellow AMPRnet users) and maybe even route them over our own network.
Rob
On 7/11/20 11:10 PM, Jason McCormick wrote:
We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
We have had discussion on trying to get a v6 allocation for ham radio before. And even if that could happen, we'd be in the same routing and infrastructure (data center) boat that we have now.
Yes. But... I think the question is what's the purpose of providing the addressing comes into play. ISPs are not always offering unfiltered inbound connections. Even though I had a public IPv4 address, I spent 11 years behind a connection that permitted few inbound ports because they wanted to drive people to their "business" plans which where irrationally expensive. IPv6 doesn't change that business driver.
The other issue with IPv6 is portability. I don't know what your experiences are like, but it's only been within the last year that my current ISP's IPv6 PD /56 to me has been anything approaching stable. Constantly renumbering is a complete pain. Dynamic DNS helps for name-based services but not for things like routing, firewalls, etc. I gave up on trying to use my client PD for anything service-related years ago and pipe everything through he.net.
I suppose he.net is a solution to the problem currently, but I am not sure if he.net will provider TunnelBroker forever. Most of them have closed down at this point.
I'm all for a coalition-of-the-willing approach as others have suggested. I just think offering dual-stack would be helpful, at least in cases were numbering predictability and stability are important.
The other question of not having a centralized service brings up is how to protect the network operators. Permitting ad hoc traffic through your network and bring operational and legal risk. Having a central, official organization to at least sit atop that issue would be helpful.
I already offer services to other hams and groups, but only people I directly know or friend-of-a-friend arrangements - specifically because of liability and supportability concerns.
Just my $0.02.
Jason
On 12/7/20 7:29 am, Rob Janssen via 44Net wrote:
IPv6 has been discussed before, and I think the predominant opinion is that we should NOT get a /32 for an IPv6 version of AMPRnet (and get the same routing issues as we now have for IPv4), but rather we should encourage everyone to get IPv6 space from their own ISP or from a local IPv6 tunnel provider, and then devise some way to communicate our IPv6 subnets to eachother (so they can be used to further trust some IPv6 source addresses as being from fellow AMPRnet users) and maybe even route them over our own network.
Given the allocations that many ISPs provide, this sounds like a reasonable solution for those of us who can get a static prefix. For example, I have a /56, of which I'm currently using a single /64. So I have plenty of IPv6 space to play with.
On Sat, Jul 11, 2020 at 2:30 PM Rob Janssen via 44Net < 44net@mailman.ampr.org> wrote:
IPv6 has been discussed before, and I think the predominant opinion is that we should NOT get a /32 for an IPv6 version of AMPRnet (and get the same routing issues as we now have for IPv4), but rather we should encourage everyone to get IPv6 space from their own ISP or from a local IPv6 tunnel provider,
I disagree here, but only because I want to recommend running 44-net as an ham-centric ISP, and it will need to be dual-stacked.
The nice thing is that it's easier to purchase and announce IPv6 space, but eventually routing tables will grow very large, and /48s might get filtered for speed/space purpose
Thankfully, we can cross that bridge later on, since the public /32 ipv6 range is not running out anytime soon, and someone would need to pay for it.
-Clive
On Sat, Jul 11, 2020 at 1:53 PM Rob Janssen via 44Net < 44net@mailman.ampr.org> wrote:
It is about a year ago that I tried to discuss such a proposal.
My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers).
This sounds about right. I'm thinking "build it and they will come", but maybe I should assume there isn't much demand for a solution like this.
I feel this will become more like our frequency use - we didn't use 220mhz, therefore it was lost to commercial interests. It seems like this is already happening with 44net, but the details here seem sparse. (on purpose?)
The reason for 220mhz reallocation seemed to be due to a lack of ability to use the band by gear. 44-net will go the same route if we need tto attest BGP with RPKI that AMPRnet is unable to provide.
I doubt there is much stopping the US gov't taking 44-net by eminent domain and selling it to the highest bidder due to disuse, especially since ARDC is a US-based (nonprofit) company. The only way to protect that is to increase domestic and international use of this IP space to make taking it difficult.
W.r.t. the .ham TLD: I don't see what advantage that would bring, we
already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost.
Agreed, this is a splurge. Just as RPKI is going to cause us problems with BGP announcements, I sense DNSSEC adoption will cause us to go the same way if TLDs require it in future. For this, it's about taking control early of things that can cause problems for us later on.
Rob
-Clive
-
air gapped -
Clive Blackledge -
Erik Seidel -
Jason McCormick -
Lavanauts -
Nate Sales -
Rob Janssen -
Ron Economos -
Steve L -
Tony Langdon