Thank you bunches for posting this list. Spartan net I don’t see here, but they were the example used in a video recording from what I believe was a tapr dcc. They seems aware of and knowing of how to work with 44net announcements. They did request that the LOA include 3 separate AS which they specified. we shall see. I’m negotiating the same process at present.

Eric Af6ep

Sent using SMTP.

On Feb 4, 2021, at 8:02 AM, G1FEF via 44Net 44net@mailman.ampr.org wrote: Hello Angelo,

You are correct, an ASN (Autonomous System Number) is just a number, although often you will see it with “AS” before it, e.g. AS12345

There are generally speaking two ways folks announce their 44-net prefixes…

1. If you have your own ASN and suitable equipment in a suitable location etc, then you can setup a BGP session on your own equipment and announce your prefix to your ISP/NSP. In which case the originating ASN would be yours and the NSP details would be the organisation you announce to (there may be more than one NSP if you are multi-homing).

2. You don’t have your own ASN and your ISP/NSP will be announcing your prefix for you. In which case the originating ASN will belong to your ISP/NSP.

In your case, it sounds very much like 2) so on the form I sent you, you need to put your NSP’s ASN as the originating ASN, either in the format 12345 or AS12345 I don’t mind which! So you just need to ask your ISP/NSP what their ASN is.

Your ISP is no doubt connected to multiple providers but I don’t need to know about them, unless they specifically request that they are mentioned in the LOA - which occasionally happens.

I thought I would reply on the mailing list in case this helps others.

73, Chris - G1FEF

...

On 4 Feb 2021, at 15:44, Angelo via 44Net 44net@mailman.ampr.org wrote:

Hi Guys,

I am trying to locate two pieces of information to be able to complete my BGP request.

This seems to be more of a challenge then I though it would be. Is there a reference page or

wiki that I can provide to my ISP to be able to locate this information.

We have been dealing with these two questions for over 2 weeks. I am not sure if the ISP or the

NSP know exactly what we are looking.

From what I understand the ASN is just a number. No letters involved in this number. Is this true???

Any help in providing information to the NSP would help.

Break Down - I will be connecting to ISP via VPN connection.

                    The ISP connects to his feed in Houston via I ATT fiber connect to his NSP in Houston.

                     The ISP sell service to clients in his area. He has a /6 himself.

Please don't laugh. I am trying to lay this out the best I can. Any help would be appreciated.

73 de Angelo / N5UXT

---

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

Hopefully the "new core network" will be deployed "soon" so that indivuduals have no need to route a subnet via BGP just to get short roundtriptime to internet.  It will make it much easier to be connected to AMPRnet and internet without having to know and handle all that BGP related information.

Rob

On 2/5/21 3:38 PM, Angelo via 44Net wrote:

Hello Chris,

I want to thank you so so much for this email. I am sure this will help other as well. It has been a real challenge.

I finally got the information we need. ( I hope )

73 de Angelo

That is a misunderstanding about how the proposed new core network is working. It does NOT preclude the use of individual tunnels between friends, and it does NOT preclude the announcement of a private /24 on internet using BGP. It is a method to facilitate easier connection for those that do not have the luxury of a static IP and incoming IPIP passing through their ISP router.  That is becoming more and more common, and a solution is required not to lock out those that cannot have a suitable internet connection.   Even VPS offerings from major providers all over the world no longer are capable of participating in the IPIP tunnel mesh directly, as their "control panel firewall" only allows TCP and UDP ports to be opened incoming (replies on outgoing traffic are usually allowed).

Furthermore, the new core network allows people all over the world to have connection with internet when they want that, with round-trip times and packet loss rates that are usable for applications like voice protocols (VoIP, D-Star, DMR, Fusion etc), without being FORCED to do a BGP announcement for that.  It is more or less a standardization of service already offered in some places of the world (e.g. here in the Netherlands) so that everyone can use that kind of connection, not just those that happen to live in an area where this is already deployed. But when someone wants to do it "the old way", they still can do that.

Rob

On 2/6/21 4:09 AM, Boudewijn (Bob) Tenty via 44Net wrote:

You act or it is already decided. There are also clearly disadvantages of what some have proposed and I don't   talk about backups of ucsd to Internet, what is good. No, it is that it makes amprnet gateways more (or totally) dependent on other core (ARDC) routers to route to other amprnet gateways over Internet. It doesn't make it less dependent, it adds another layer on top of that. Presently, I'm more or less independent with my individual tunnels (and I care less that they are using ipip or another protocol) or when I should be running bgp. Instead that the risk is spread, it will be more concentrated with these proposals what I have read here and at the 44NGN list. This all to make it more easier? I'm already providing a lot of these services.

Bob VE3TOK

On 2021-02-05 09:59, Rob PE1CHL via 44Net wrote:

...

Hopefully the "new core network" will be deployed "soon" so that indivuduals have no need to route a subnet via BGP just to get short roundtriptime to internet.  It will make it much easier to be connected to AMPRnet and internet without having to know and handle all that BGP related information.

Rob

On 2/5/21 3:38 PM, Angelo via 44Net wrote:

When you change the way you look at things, the things you look at change

Max Planck

---

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

Good 'morning',

I am with Bob on this, and for me personally, I have found all of this quite overwhelming since Brian passed, before which ; this all seemed to be in a black box, and suddenly we are now inundated with more BGP use then I ever imagined was going on, and all these technical discussions that although I am capable of understanding, are quite far beyond my practical experiences, and I too am questioning complexities.

It's a lot to take in for just a 'short period of time'.

I like how Rob has summarized the need below if I may put it that way.

a method to facilitate easier connection for those that do not have the luxury of a static IP and incoming IPIP passing through their ISP router.

Agreed.

That is becoming more and more common, and a solution is required not to lock out those that cannot have a suitable internet connection.

Agreed.

So we could do this in a couple of ways for starters.

a) The community steps up and provides services to those they know in need. We're     experimenters, that's what we do. For years I 'suffered' not having a static IP, so I     can easily relate to not being able to participate.

There are several in the community that have done this for years already, for some     at great personal (not so much financial) expense may I add, I wont' list them ...

When I got my static IP, I decided to run an openVPN server (yeah, 12+ years ago)     so that several amateur radio guys throughout Canada could get a fixed 44 IP from     the rather largely unused allocation given to us for our province (Manitoba).

I was already IPIP 'linked' to UCSD and others, and this worked quite very well. The     only potential issue is what are you as a 'provider' willing to absorb as far as costs,     how much bandwidth could you handle, and such.

b) Since ARDC seems to have a massive amount of cash, perhaps it can apply for a grant     to itself and setup a bunch of openVPN services throughout the planet. I will even manage     some of them if you like, allocate a 44 subnet for this openVPN service, so that the once     dyndns users who are dying to get a static IP can finally get one. I have NO PROBLEM     running this service, if someone in ARDC wants to fund it. There are LINODE systems     world wide that could host this. I'm not partial to them, but relatively happy with them.

Even VPS offerings from major providers all over the world no longer

are capable

of participating in the IPIP tunnel mesh directly, as their "control

panel firewall" only

allows TCP and UDP ports to be opened incoming ...

I pay $10 a month to LINODE to host my amprnet playground. I have more or less full amprnet connectivity (IPIP), just requires one special iptables rule to make it work to get to my user space apps.

For 12 years I had a static IP direct to my house, motorola canopy, 6 miles away, but then the trees grew in and I was forced to go DSL, expensive, and no longer static. So for less then the price of running my servers at home, LINODE worked for me, I got my static back and the 'fun' returned.

But when someone wants to do it "the old way", they still can do that.

Of course.

Maiko Langelaar / VE4KLM

Rob,

That was in fact my proposal. Have ARDC setup a mesh of routers over

the world ...

Okay, so what's stopping 'us' from setting up a pilot ? If anyone at ARDC is listening, how about you assign a small pilot 44 subnet to our project, get us a linode account, make one of us administrators, and we setup an openVPN server. Have the routing to our small pilot 44 subnet put into place once we get the linode account setup.

commonly known VPSes run under Apache Aurora and similar.

I must be behind the times then. Never heard of it, so I just looked it up, for example :

Kubernetes is an open source orchestration system for Docker containers,      Apache Aurora is a Mesos framework for long-running services and cron jobs.

Good god, what happened to just a plain old *nix system running on a VM ?  (no, that's not a ludite comment, for anyone who wants to throw that at me)

Those cannot do IPIP [snip] People getting a $3/mon VPS often find

this out

once they get it deployed.  When you have a more directly managable

VPS it

will not have this problem.

Why do they have to use IPIP ? with the openVPN system 'we are proposing', you are immediately on 44 net, perhaps I am missing something here.

stuck in the past

Remaining stuck in the past VS the KISS principle are two different things.

But I do not want to force everyone with an unsuitable home internet

connection

to get a suitable VPS, run IPIP from there, and then setup a VPN to

that VPS,

all because we have done IPIP for 25+ years and now want to continue it indefinitely.

I don't understand the point to this last comment, why do we need IPIP here, and why would we need to run a VPN to our VPS ? Oh you mean because there is no existing solution which I think should be provided by ARDC. I think we're on the same page on that one (I hope so anyways).

Maiko Langelaar / VE4KLM

On 2/6/21 2:27 PM, M Langelaar via 44Net wrote:

Rob,

...

That was in fact my proposal. Have ARDC setup a mesh of routers over the world ...

Okay, so what's stopping 'us' from setting up a pilot ? If anyone at ARDC is listening, how about you assign a small pilot 44 subnet to our project, get us a linode account, make one of us administrators, and we setup an openVPN server. Have the routing to our small pilot 44 subnet put into place once we get the linode account setup.

That would be possible, but we largely have the proposed network already running for 6.5 years now and it is not necessary to prove that it works. Others have the same or similar setups.

...

commonly known VPSes run under Apache Aurora and similar.

I must be behind the times then. Never heard of it, so I just looked it up, for example :

Kubernetes is an open source orchestration system for Docker containers,      Apache Aurora is a Mesos framework for long-running services and cron jobs.

Good god, what happened to just a plain old *nix system running on a VM ?  (no, that's not a ludite comment, for anyone who wants to throw that at me)

When you offer VPS for $3/month of course you need something to automate the deployment.  Of course we are running VMware ESXi hosts in our network (in fact our gateway system for the Netherlands is a VM running on that), but for those commercial VPS systems it works a bit differently.  You can go to a web interface, select a place to deploy a VPS, an initial image (e.g. Debian, CentOS), a host name and click "deploy" and it is running.   The VPSes are deployed from standard images and there is a small agent that allows the management system (Aurora) to set things like a hostname and a root password inside the VPS on its first boot. The actual VPS you get still is a virtual Linux system where you get the root password and you can install and manage everything, it even has a public IPv4 and IPv6 address, but it is behind a firewall. There is a control panel where you can make some additional settings and one of them is a firewall setup. There is no "allow everything" setting. I can understand that, when you give out VPSes to lots of people you don't know, there will be lots of inexperienced people who only want the VPS to setup a website and that do not know about security, and you will be handling abuse reports (about hijacked systems) all the time. So a bit of protection helps, although probably not much these days.

...

Those cannot do IPIP [snip] People getting a $3/mon VPS often find this out once they get it deployed.  When you have a more directly managable VPS it will not have this problem.

Why do they have to use IPIP ? with the openVPN system 'we are proposing', you are immediately on 44 net, perhaps I am missing something here.

*I* am talking about *what we have now*.  And about how it can be improved. Please do not confuse those things.

...

stuck in the past

Remaining stuck in the past VS the KISS principle are two different things.

We keep stuck in the past because we won't deploy realistic things but keep discussing about how it could work in an ideal situation and with infinite human resources (financial resources as well in the past, but that is less of a problem now). The current discussion quickly moved on from creating a new more usable backbone network into enterprise-grade systems, worldwide announcement of the entire address space, use of hardware routes rather than VMs, etc etc.

...

But I do not want to force everyone with an unsuitable home internet connection to get a suitable VPS, run IPIP from there, and then setup a VPN to that VPS, all because we have done IPIP for 25+ years and now want to continue it indefinitely.

I don't understand the point to this last comment, why do we need IPIP here, and why would we need to run a VPN to our VPS ? Oh you mean because there is no existing solution which I think should be provided by ARDC. I think we're on the same page on that one (I hope so anyways).

Yes I mean this is the current situation when you are in some place in the world where there is no existing deployment of such a system.  You need to do it yourself and you need to be on IPIP.   Or BGP-announce your subnet.  Those are quite complicated things, and this thread started because someone did not understand how to do it exactly. Had the new backbone network been in place, this would not be an issue because he could just connect to that.

Rob

On 2/6/21 2:59 PM, Jason McCormick via 44Net wrote:

I don't see how deploying some actual hardware is unrealistic. A VPS-based solution will not scale well because in the VPS, you're buying into a system that's oversubscribed by design and you're at the mercy of the software layer inside of the VPS system the host is using. The other consideration is that right now, practical use of 44Net address space is limited by all of the technological hurdles you already summarized so well. If we deploy an easy-to-use system that support things like a single OpenVPN connection for an endpoint or easier tunneling, then usage is likely to ramp up quickly. Having real systems designed in an "enterprise" way actually cuts down on user support problems later on or the need to redesign-on-the-fly as you grow. No one wants to be trying to rebuild the plane while it's in the air.

One of our problems is that we have a hard time coming up with a use case and killer advantage of our own network compared to the normal internet. One of the few hard advantages we have is the availability of large numbers of IPv4 addresses for free.  That enables us to run a network with clean routing and subnetting and without NAT.  Once we would migrate to IPv6 we would also lose that advantage. So, there really is no large influx of new users to be expected.  After all, why would you connect your system to 44Net unless you already are a networking buff that would like to run services at home and play with networking.  Not so many radio amateurs are.  In our country with ~13000 registered amateurs (and pop. 17M) we now have issues 244 OpenVPN certificates over the 6.5 year period that service is now up and running, and about 25 of them are usually connected. We also have about 125 AS numbers for routers around the country, and about 170 subnet routes being distributed via BGP (plus those for the VPNs).

That is a scale where software solutions like Linux VPSes either bare or with a router oriented OS+Configuration like MikroTik RouterOS still works perfectly fine.  We are not to be compared with an ISP with millions of subscribers.

Actually using VPSes instead of hardware makes it easier to ramp up (and down) quickly, as those providers normally have very convenient mechanisms to deploy new instances, which beat truck-hauling hardware around the world every time. Also when you use VPSes from an external supplier, it is them who are looking after the hardware, replace the broken fans and disks, and replace the entire machines when they become obsolete.

I think the only work we would need to do ourselves is to make a network design and base configuration of the equipment, and likely make some tools to assist in chores like adding a user account or a new node in the network. (doing reconfiguration for that)

Some people come up with the "disadvantage" that relying on a VPS provider would mean that your network is less reliable because you rely on some unknown external party.  I think it is not so bad because we can always decide to use VPSes from different providers, and even when you provide your own hardware you will still rely on others like a datacenter with their power, cooling and networking infrastructure. Plus you then need to support your hardware or have people do that. I don't think a small group of radio amateurs should think they can do a better job than people like AWS, OVH, LINODE, Microsoft Azure, etc which have dedicated professionals working 24/7 to maintain, monitor and improve their infrastructure.

Rob

We dont have high bandwith application?

What about 50 Mb/s ? is that high speed enough?

SDR kike the Hermes-Liet 2.0 can feed the HF spectrum to a software remotely By IP stream at up to 50Mb/s

Would it be a nice thing to have multiple SDR transceiver on multiple bands all over the world available to ham that run a 44net adress?

Would it even be a nice intitative to build an high speed RF linking system for that use case?

I can think of many more project like that.

Most people dont think of such project for a simple reason, most of the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact.

Just take the New pascket radio project, Canadian hams could use it at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say.

Pierre VE2PF

________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Cliff Sojourner via 44Net 44net@mailman.ampr.org Envoyé : 6 février 2021 15:03 À : 44Net general discussion Cc : Cliff Sojourner Objet : Re: [44net] ASN # and Network Service Provider (NSP)

Rob wrote:

One of our problems is that we have a hard time coming up with a use case and

killer advantage of our own network compared to the normal internet.

Yes and yes.

No one can think of any high bandwidth applications except video - perhaps mountaintop wildfire cameras, etc. Good in California...

Hams just don't generate a lot of data. Many are content to fool around with 50Hz CW or various digimodes. On 3400MHz!

I was interested in New Packet Radio at first. But there are no applications which would use even the soda straw 50kHz bandwidth on 70cm in US

Also the NPR primary folks seem intent to recreate IPv4 badly. The radio is a modem, a layer 2 device. IP is a WAN protocol, not at all optimized for LAN work. They should have looked at prior art of LAN protocols, IPX, Appletalj, XNS, etc.

So for me as a professional network engineer, I'll pass.

(I feel if we had compelling high bandwidth applications, we could have better justified our 3400MHz allocation...)

Thanks for indulging my digression.

73, Cliff K6CLS CM87

On February 6, 2021 9:03:42 AM PST, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

On 2/6/21 2:59 PM, Jason McCormick via 44Net wrote:

...

I don't see how deploying some actual hardware is unrealistic. A

VPS-based solution will not scale well because in the VPS, you're buying into a system that's oversubscribed by design and you're at the mercy of the software layer inside of the VPS system the host is using. The other consideration is that right now, practical use of 44Net address space is limited by all of the technological hurdles you already summarized so well. If we deploy an easy-to-use system that support things like a single OpenVPN connection for an endpoint or easier tunneling, then usage is likely to ramp up quickly. Having real systems designed in an "enterprise" way actually cuts down on user support problems later on or the need to redesign-on-the-fly as you grow. No one wants to be trying to rebuild the plane while it's in the air.

One of our problems is that we have a hard time coming up with a use case and killer advantage of our own network compared to the normal internet. One of the few hard advantages we have is the availability of large numbers of IPv4 addresses for free. That enables us to run a network with clean routing and subnetting and without NAT. Once we would migrate to IPv6 we would also lose that advantage. So, there really is no large influx of new users to be expected. After all, why would you connect your system to 44Net unless you already are a networking buff that would like to run services at home and play with networking. Not so many radio amateurs are. In our country with ~13000 registered amateurs (and pop. 17M) we now have issues 244 OpenVPN certificates over the 6.5 year period that service is now up and running, and about 25 of them are usually connected. We also have about 125 AS numbers for routers around the country, and about 170 subnet routes being distributed via BGP (plus those for the VPNs).

That is a scale where software solutions like Linux VPSes either bare or with a router oriented OS+Configuration like MikroTik RouterOS still works perfectly fine. We are not to be compared with an ISP with millions of subscribers.

Actually using VPSes instead of hardware makes it easier to ramp up (and down) quickly, as those providers normally have very convenient mechanisms to deploy new instances, which beat truck-hauling hardware around the world every time. Also when you use VPSes from an external supplier, it is them who are looking after the hardware, replace the broken fans and disks, and replace the entire machines when they become obsolete.

I think the only work we would need to do ourselves is to make a network design and base configuration of the equipment, and likely make some tools to assist in chores like adding a user account or a new node in the network. (doing reconfiguration for that)

Some people come up with the "disadvantage" that relying on a VPS provider would mean that your network is less reliable because you rely on some unknown external party. I think it is not so bad because we can always decide to use VPSes from different providers, and even when you provide your own hardware you will still rely on others like a datacenter with their power, cooling and networking infrastructure. Plus you then need to support your hardware or have people do that. I don't think a small group of radio amateurs should think they can do a better job than people like AWS, OVH, LINODE, Microsoft Azure, etc which have dedicated professionals working 24/7 to maintain, monitor and improve their infrastructure.

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

"Once I'm going overseas, usable bandwidth can drop to 10 Mbps or less, from end to end"

What a lucky man you are! If we use other software then OpenHPSDR we can get away with using abiut 10Mb/s for one slice. SparkSDR is one of them.

"The biggest challenge with high speed RF is cost and complexity. "

Cost, Ok a pair of 5.8Ghz Ubiquity radio that can do 30 KM+ high speed links will cost around 300$ US that is not that expensive but not every can buy a pair. But we dont need every one to be connected by RF, it would be an incitative, But not every one can do sta tracking, Not every one can have a tilt tower with beam for HF and a 3000$ radio and amp.

But If we would have a nice backbone all around the planet for the 44 net and local (national) way to connect to it, we could be able to do something like that project. But without a backbone I dont think project like that would be possible. Try to pass 10 Mb/s on ipip with the USCD modem and you will see that it is not possible to substain for long.

I know that cheap vps with limted BW and Ram would not do the job. But there is a way to scale things for sure with out spending the entire ARDC assets.

There was a baseball movie in the 80's and a voice in the movie kept saying , built it and they will come. I am not saying that we will have hugh inflow of ham using the 44 net adress just like that out of no where. But if we keep the BW to the level of the USDC modem on ipip we wont see much more activity then we have now.

I did try to run a ipip tunnel on ampr. I quickly figured that almost nothing that I had insterest in would work under that infrastructure. Yes a small web server, a mail server, maybe an Ip phone connection on a low codec. But real time voice communication at a good quality level would suffer cut and instability very fast. SDR even with a small BW device like the RTL-SDR would be marginal.

With such infrastructure you dont dream big. And I am not saying that what Brian did was bad. Far from it, he had I am sure big dream for the 44 net. But he worked with what he had. The selling of an asset that had no utilisation and would have had not much more use gave us now the possibility to dream big. He was not able to push his vision to the max. We should not keep on waiting for something to happen. It will not happen. Lets move, lets figure out what we will be able to do with a stronger infrastructure and then project will come. and if we need to modify the backbone, we will do it. There is no perfect backbone we can think of. If we wait for perfect decision, Brain would have not make the move he did.

Lets be bold, but not crazy ;-)

Pierre VE2PF

________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Tony Langdon via 44Net 44net@mailman.ampr.org Envoyé : 6 février 2021 18:54 À : 44net@mailman.ampr.org Cc : Tony Langdon Objet : Re: [44net] ASN # and Network Service Provider (NSP)

On 7/2/21 8:32 am, pete M via 44Net wrote:

We dont have high bandwith application?

What about 50 Mb/s ? is that high speed enough?

SDR kike the Hermes-Liet 2.0 can feed the HF spectrum to a software remotely By IP stream at up to 50Mb/s

Would it be a nice thing to have multiple SDR transceiver on multiple bands all over the world available to ham that run a 44net adress?

Now that would be neat - having access to SDR IFs remotely, though those speeds are only going to be available at a regional level if routing over the Internet. While I have 80+ Mbps available downstream, that really only applies to relatively local (within VK for me) endpoints. Once I'm going overseas, usable bandwidth can drop to 10 Mbps or less, from end to end. But the 2-2.4 MHz bandwidth of RTL-SDR class devices might be more practical on an international scale, which means a transport that can scale to suit available bandwidth. Also, for latency reasons, we would want optimal routing on our core infrastructure, which ties back to the previous discussion.

Nice out of the box thinking there. :)

Would it even be a nice intitative to build an high speed RF linking system for that use case?

The biggest challenge with high speed RF is cost and complexity. Not everyone is able to build UHF/microwave equipment reliably. I have a number of issues in that area - some intrinsic, some are time related, and the cost of high speed/wide bandwidth microwave equipment tends to be rather expensive, given that amateur applications tend to be low volume, compared to something like mobile phones or wifi.

I can think of many more project like that.

Most people dont think of such project for a simple reason, most of the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact.

Just take the New pascket radio project, Canadian hams could use it at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say.

I'm pretty sick to death of being held back by archaic US regulations. Here, we can also use whatever bandwidth a mode requires, provided we stay within the band limits (on VHF and up). There may be some interesting band plan issues on 70cm, but we hams can resolve those. On 1.2 GHz and up, there's bandwidth to burn, and it would be good to make use of that. :) Maybe the rest of the world should just get on with it and encourage US hams to lobby to get their regulations updated to match the rest of the world, and in the meantime, the US battles on as best it can until they can sort out their regs and join us RF wise.

-- 73 de Tony VK3JED/VK3IRL http://vkradio.com

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

We already have hundreds of SDRs available via IP. One aggregation is at http://websdr.org/

Frankly, sending 50MHz bandwidth at say 16 bits over IP is perhaps the worst way to do it... Just to find that elusive 50Hz CW signal!??

The latest SDRs have a massive A/D for baseband capture, perhaps 250MHz, immediately processed by multiple FPGAs, then perhaps sent to Gnu Radio on a very fast multicore CPU. This is no simple trick. But my point is, people smarter than me have figured out it is better to decimate and process locally, not at the end of an IP connection.

So i am still at a loss for compelling high bandwidth applications.

(Thanks for indulging my detour here. Back to regularly scheduled BGP etc.)

Cliff K6CLS CM87

On February 6, 2021 3:54:12 PM PST, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:

On 7/2/21 8:32 am, pete M via 44Net wrote:

...

We dont have high bandwith application?

What about 50 Mb/s ? is that high speed enough?

SDR kike the Hermes-Liet 2.0 can feed the HF spectrum to a software

remotely By IP stream at up to 50Mb/s

...

Would it be a nice thing to have multiple SDR transceiver on multiple

bands all over the world available to ham that run a 44net adress? Now that would be neat - having access to SDR IFs remotely, though those speeds are only going to be available at a regional level if routing over the Internet.  While I have 80+ Mbps available downstream, that really only applies to relatively local (within VK for me) endpoints.  Once I'm going overseas, usable bandwidth can drop to 10 Mbps or less, from end to end.  But the 2-2.4 MHz bandwidth of RTL-SDR class devices might be more practical on an international scale, which means a transport that can scale to suit available bandwidth.  Also, for latency reasons, we would want optimal routing on our core infrastructure, which ties back to the previous discussion.

Nice out of the box thinking there. :)

...

Would it even be a nice intitative to build an high speed RF linking

system for that use case? The biggest challenge with high speed RF is cost and complexity.  Not everyone is able to build UHF/microwave equipment reliably.  I have a number of issues in that area - some intrinsic, some are time related, and the cost of high speed/wide bandwidth microwave equipment tends to be rather expensive, given that amateur applications tend to be low volume, compared to something like mobile phones or wifi.

...

I can think of many more project like that.

Most people dont think of such project for a simple reason, most of

the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact.

...

Just take the New pascket radio project, Canadian hams could use it

at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say. I'm pretty sick to death of being held back by archaic US regulations.  Here, we can also use whatever bandwidth a mode requires, provided we stay within the band limits (on VHF and up).  There may be some interesting band plan issues on 70cm, but we hams can resolve those.  On 1.2 GHz and up, there's bandwidth to burn, and it would be good to make use of that. :)  Maybe the rest of the world should just get on with it and encourage US hams to lobby to get their regulations updated to match the rest of the world, and in the meantime, the US battles on as best it can until they can sort out their regs and join us RF wise.

-- 73 de Tony VK3JED/VK3IRL http://vkradio.com

---

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

How much deeper could we dig signals out of the noise if we sampled 32bit samples at 32 mega samples per second then piped it all over ip for the entirety of TACC to chew on. (Wiki lists TACC as 5th in the top 500)

Eric

Sent using SMTP.

On Feb 9, 2021, at 6:02 AM, pete M via 44Net 44net@mailman.ampr.org wrote: There is always multiple ways to skin a cat. But the SDR I talk about is a transceiver. I know we can use other type of processing and less BW. But what is the fun?

Téléchargez Outlook pour Androidhttps://aka.ms/ghei36

---

From: 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org on behalf of Cliff Sojourner via 44Net 44net@mailman.ampr.org Sent: Monday, February 8, 2021 6:01:48 PM To: 44Net general discussion 44net@mailman.ampr.org Cc: Cliff Sojourner cls@employees.org Subject: Re: [44net] ASN # and Network Service Provider (NSP)

We already have hundreds of SDRs available via IP. One aggregation is at http://websdr.org/

Frankly, sending 50MHz bandwidth at say 16 bits over IP is perhaps the worst way to do it... Just to find that elusive 50Hz CW signal!??

The latest SDRs have a massive A/D for baseband capture, perhaps 250MHz, immediately processed by multiple FPGAs, then perhaps sent to Gnu Radio on a very fast multicore CPU. This is no simple trick. But my point is, people smarter than me have figured out it is better to decimate and process locally, not at the end of an IP connection.

So i am still at a loss for compelling high bandwidth applications.

(Thanks for indulging my detour here. Back to regularly scheduled BGP etc.)

Cliff K6CLS CM87

...

On February 6, 2021 3:54:12 PM PST, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:

...

On 7/2/21 8:32 am, pete M via 44Net wrote: We dont have high bandwith application? What about 50 Mb/s ? is that high speed enough? SDR kike the Hermes-Liet 2.0 can feed the HF spectrum to a software

remotely By IP stream at up to 50Mb/s

...

Would it be a nice thing to have multiple SDR transceiver on multiple

bands all over the world available to ham that run a 44net adress? Now that would be neat - having access to SDR IFs remotely, though those speeds are only going to be available at a regional level if routing over the Internet. While I have 80+ Mbps available downstream, that really only applies to relatively local (within VK for me) endpoints. Once I'm going overseas, usable bandwidth can drop to 10 Mbps or less, from end to end. But the 2-2.4 MHz bandwidth of RTL-SDR class devices might be more practical on an international scale, which means a transport that can scale to suit available bandwidth. Also, for latency reasons, we would want optimal routing on our core infrastructure, which ties back to the previous discussion.

Nice out of the box thinking there. :)

...

Would it even be a nice intitative to build an high speed RF linking

system for that use case? The biggest challenge with high speed RF is cost and complexity. Not everyone is able to build UHF/microwave equipment reliably. I have a number of issues in that area - some intrinsic, some are time related, and the cost of high speed/wide bandwidth microwave equipment tends to be rather expensive, given that amateur applications tend to be low volume, compared to something like mobile phones or wifi.

...

I can think of many more project like that. Most people dont think of such project for a simple reason, most of

the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact.

...

Just take the New pascket radio project, Canadian hams could use it

at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say. I'm pretty sick to death of being held back by archaic US regulations. Here, we can also use whatever bandwidth a mode requires, provided we stay within the band limits (on VHF and up). There may be some interesting band plan issues on 70cm, but we hams can resolve those. On 1.2 GHz and up, there's bandwidth to burn, and it would be good to make use of that. :) Maybe the rest of the world should just get on with it and encourage US hams to lobby to get their regulations updated to match the rest of the world, and in the meantime, the US battles on as best it can until they can sort out their regs and join us RF wise.

-- 73 de Tony VK3JED/VK3IRL http://vkradio.com

---

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 09/02/2021 à 00:01, Cliff Sojourner via 44Net a écrit :

We already have hundreds of SDRs available via IP. One aggregation is athttp://websdr.org/

Don't think only in terms of bandwidth, but also in terms of services. This is a perfect example of things that would benefit from a "New Generation" 44net connection. F/ex, Internet users could be allow to listen only, while 44net users could be allowed (under some circumstances) to transmit, too.

That's a common problem for people who build Internet-related applications (such as Echolink, DMR, etc...) : How to ensure users coming from Internet are legitimate ham radio operators ? Everybody adopts its own solution, with more or less problems, but always with a huge overhead.

If we can provide a network-level authentication on 44net (still to be defined), then, the application developers would just have to focus on their app, and not about user authentication. Checking whether an user is a legitimate ham radio or not would be as simple as checking if the source IP is in the 44net range...

73 de TK1BI

Le 16/02/2021 à 10:45, Rob PE1CHL via 44Net a écrit :

Well, I don't think network level security is usable for that.  Right now, half the users do not even make their reverse-DNS working, so you cannot tell whom the incoming connects are coming from.

I was not talking about mapping every ham callsign with an IP address, which seems pretty un-doable to me, as we are mostly using subnets and not individual addresses...

As we already talked about, a certificate is probably the best way to use at application level (Echolink), where the user must be identified by its callsign. For that, a Certification Authority managed by ARDC is probably a good idea :-)

Anyway, there are situations, at lower layers, where it may be useful to be able to grant/deny access based on source address, where we need to ensure the user is a ham, but without necessarily knowing its exact callsign.

One of the things in my ToDo list is a "Content Manager" on our public web server, that would display a catalog of all the resources available on the internal network : - Users coming from Internet would see only the "public" things (WEB, APRS, XLX, meteo...) - Users coming from 44Net would be able to access other services such as Nagios monitoring, Netbox IPAM, NAS file server, dashboards of repeaters, ...

But we can be even more granular. We could offer direct access to some specific resource such as a radio-club remote rig only for the active (paid) members, repeater dashboard in read/write for local users and in read-only for other 44net users, SSH management restricted to local IP ranges, etc...

Voice repeater systems such as XLX, D-Star, DMR, Asterisk could also use basic source filtering on 44Net, which would avoid full exposure to "the wild Internet", which is a huge security concern, because all systems currently connected to Internet do not necessarily have full upgrade and patch management, etc...

All that without having to implement a full certificate management, just with a few basic firewall rules at the gateway.

73 de TK1BI

What happen on the 44net network is decided by the 44 network. If people want to use the internet as specified in the protocol they have all the other network accessibles. But if we want to discriminate what the other network have access to or have other priviledge then the "local" 44 net traffic have is our decision.

Téléchargez Outlook pour Androidhttps://aka.ms/ghei36

________________________________ From: 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org on behalf of Cliff Sojourner via 44Net 44net@mailman.ampr.org Sent: Tuesday, February 16, 2021 8:02:23 AM To: 44Net general discussion 44net@mailman.ampr.org Cc: Cliff Sojourner cls@employees.org Subject: Re: [44net] ASN # and Network Service Provider (NSP)

User authentication and user authorization belong in application layer, there is no place for those in any network layer.

Please refer to Internet model, layers 1 through 4..

Cliff K6CLS CM87

On February 16, 2021 2:29:33 AM PST, Toussaint OTTAVI via 44Net 44net@mailman.ampr.org wrote:

Le 16/02/2021 à 10:45, Rob PE1CHL via 44Net a écrit :

...

Well, I don't think network level security is usable for that. Right

now, half the users do not even make their reverse-DNS working, so you cannot tell whom the incoming connects are coming from.

I was not talking about mapping every ham callsign with an IP address, which seems pretty un-doable to me, as we are mostly using subnets and not individual addresses...

As we already talked about, a certificate is probably the best way to use at application level (Echolink), where the user must be identified by its callsign. For that, a Certification Authority managed by ARDC is

probably a good idea :-)

Anyway, there are situations, at lower layers, where it may be useful to be able to grant/deny access based on source address, where we need to ensure the user is a ham, but without necessarily knowing its exact callsign.

One of the things in my ToDo list is a "Content Manager" on our public web server, that would display a catalog of all the resources available

on the internal network :

• Users coming from Internet would see only the "public" things (WEB,

APRS, XLX, meteo...)

• Users coming from 44Net would be able to access other services such

as Nagios monitoring, Netbox IPAM, NAS file server, dashboards of repeaters, ...

But we can be even more granular. We could offer direct access to some specific resource such as a radio-club remote rig only for the active (paid) members, repeater dashboard in read/write for local users and in

read-only for other 44net users, SSH management restricted to local IP ranges, etc...

Voice repeater systems such as XLX, D-Star, DMR, Asterisk could also use basic source filtering on 44Net, which would avoid full exposure to "the wild Internet", which is a huge security concern, because all systems currently connected to Internet do not necessarily have full upgrade and patch management, etc...

All that without having to implement a full certificate management, just with a few basic firewall rules at the gateway.

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

Ha! Ok, let's use ISO ISI layers then: what layer does that put user authentication and authorization?

My point is not that any model is the only way to do things, rather someone smarter figured a way most likely to work correctly.

Cliff K6CLS CM87

On February 17, 2021 1:55:18 AM PST, Toussaint OTTAVI via 44Net 44net@mailman.ampr.org wrote:

Le 16/02/2021 à 14:02, Cliff Sojourner via 44Net a écrit :

...

Please refer to Internet model, layers 1 through 4..

44net is not Internet ;-)

73 de TK1BI

---

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

On 2/17/21 11:03 AM, Toussaint OTTAVI via 44Net wrote:

But it can be useful as a simple pre-authentication for a group of users : all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network.

I think that will not work.  It would require trusting the entire group of network admins that they will only admit licensed operators to their subnetworks. I know that this is difficult to do for me.  When I get a request like "I am Rob PE1CHL and I want some addresses to use on 44Net" there is no way for me to really verify that this mail is really coming from a licensed operator, and even less to verify that he keeps that license during the time he can still use that address.  I do look for clues in the requests that hint that the user is not really a radio amateur (I sometimes get those via the Portal), but it is not 100%.

And how can I know what level of validation there is in other countries? And how can I know what is the license level of the operator behind the address when they cannot even bother to get their reverse DNS pointing to their callsign?

Sure, the admittance of only 44Net traffic (44.0.0.0/9 and 44.128.0.0/10) is a first step when guarding a system from access by just everyone, and try to limit it to mostly radio amateurs with hopefully good intentions. But I never would use it as a method to allow e.g. to operate a transmitter (as was the example use case).

Rob

I wonder if something like using a PGP trust chain could work (something like signing parties), or if the LOTW certificates could be used in such a way?

Just a couple of pre-coffee thoughts.

Erik

-----Original Message----- From: 44Net 44net-bounces+traderbeckola=tahoma.com@mailman.ampr.org On Behalf Of pete M via 44Net Sent: Wednesday, February 17, 2021 8:03 AM To: Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Cc: pete M petem001@hotmail.com; Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] ASN # and Network Service Provider (NSP)

That is why there are amelioration to be done to the portal.

We are used to how the portal works. But it will change and this will make more clear for many.

________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Rob PE1CHL via 44Net 44net@mailman.ampr.org Envoyé : 17 février 2021 05:16 À : Toussaint OTTAVI via 44Net Cc : Rob PE1CHL Objet : Re: [44net] ASN # and Network Service Provider (NSP)

On 2/17/21 11:03 AM, Toussaint OTTAVI via 44Net wrote:

But it can be useful as a simple pre-authentication for a group of users :

all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network.

I think that will not work. It would require trusting the entire group of network admins that they will only admit licensed operators to their subnetworks. I know that this is difficult to do for me. When I get a request like "I am Rob PE1CHL and I want some addresses to use on 44Net" there is no way for me to really verify that this mail is really coming from a licensed operator, and even less to verify that he keeps that license during the time he can still use that address. I do look for clues in the requests that hint that the user is not really a radio amateur (I sometimes get those via the Portal), but it is not 100%.

And how can I know what level of validation there is in other countries? And how can I know what is the license level of the operator behind the address when they cannot even bother to get their reverse DNS pointing to their callsign?

Sure, the admittance of only 44Net traffic (44.0.0.0/9 and 44.128.0.0/10) is a first step when guarding a system from access by just everyone, and try to limit it to mostly radio amateurs with hopefully good intentions. But I never would use it as a method to allow e.g. to operate a transmitter (as was the example use case).

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

There as been multiple discussion about ham only 44 net, and open to the world ham net. If you build a network with IPv4 Private Address Space, and prevent people from entering into that private adress space unless they show a kind of auth you have a nice secure network and you are calm about the traffic being sent to and from your ham project. But that is not 44net. 44 net is a routable network and many ham want it to be exposed to the whole internet so that the service they offer to the community can be accessible and they deal with the auth at the service level. Like repeater linking voip server, file server. Name it.

Yes we can have a part of the 44 net that is close to non-ham. that is all ok. But I think this is a loss of a scare resources that is an ipv4 adress space. But I am not against that idea.

The main thing about the amprnet is that we need to offer it for all ham to use in an easy way. We need to have a way for people to join into the adress space easily and reliably with enoug bandwith and low latency so that any project can work on it. THEN people will start using it a lot more. Could there be a way that we can have some block of 16 or 32 adress accessible from a simple wireguard link that would be created by a request to the portal, and that block of adress be accessible only to 44 net or to the whole internet. I dont know if it is manageable or even doable. We surely need more programmer and more network guru to come to that level of integration.

Me on my side I like to dream. (start the Supertramp dreamer song here)

Pierre VE2PF

________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 17 février 2021 11:34 À : AMPRNet working group Cc : Toussaint OTTAVI Objet : Re: [44net] ASN # and Network Service Provider (NSP)

Le 17/02/2021 à 11:16, Rob PE1CHL via 44Net a écrit :

When I get a request like "I am Rob PE1CHL and I want some addresses to use on 44Net" there is no way for me to really verify that this mail is really coming from a licensed operator, and even less to verify that he keeps that license during the time he can still use that address.

Maybe it's just a scale problem ? I don't have this one, because I'm living on a tiny island, and I do know every ham involved in TKNet. Maybe there should be more delegation, f/ex national coordinator delegating sub-tasks to trusted local radio-clubs ? Not sure it would be feasible everywhere, anyway...

If we setup a CA managed by ARDC, then ARDC would be in charge of identity verification, and would deliver a (multi-purpose) certificate directly to the end-user. Then, if someone gives you a trusted certificate, you won't have to do further verification.

Sure, the admittance of only 44Net traffic (44.0.0.0/9 and 44.128.0.0/10) is a first step when guarding a system from access by just everyone, and try to limit it to mostly radio amateurs with hopefully good intentions.

That's exactly what I meant. :-)

But I never would use it as a method to allow e.g. to operate a transmitter (as was the example use case).

Of course, it does not replace application-level user authentication. It's just a first level of filtering for applications that do not support user authentication (yet).

73 de TK1B1

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

On 2/18/21 11:12 AM, John Gilmore via 44Net wrote:

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

...

Could there be a way that we can have some block of 16 or 32 address accessible from a simple wireguard link that would be created by a request to the portal?

I agree that our current methods of connecting new hams are pretty klunky and could use some improvement.

We could do as you suggest, but if the wireguard traffic ever was transmitted over ham frequencies, that would make that new ham liable for violating their country's laws against encrypted traffic.

When you have a wireguard link over internet to some router that is connected to 44Net, and transmit traffic over that, no encrypted traffic is ever going to go over amateur frequencies.  The router will decrypt the traffic before forwarding it to its destination.

There is no need to relate the use of encrypted tunnels (over internet) to any regulations about encryption on ham frequencies.  I don't think there exist any regulations that would forbid this use of encryption.

Rob

"- 44.168.80.0/23, which is an internal, private network for hams, and which is not reachable from public Internet This allows for clear distinction about what is on Internet and what is not, and it simplifies firewall policy management."

"73 de TK1BI"

Here is one way of doing things that I dont like much, and at the same time I do understand why you do it that way. But for me that /23 of adress space is being lost. the /23 could be using one of the private subnet that are already available to us. That way you are sure that no one nowhere will jump in the group.

The 44 net adress space is by definition routable from all over the world.(if route tables are built for it. ) using them in an enclosed private network is not what it was designed for.

One thing to consider for the adress space is that some will not want people from other adress spaces to connect to them. I know that a firewall can reject whole ip space 100% of the ip of the world in one line, and with just a few line it will allow just the 2 remeaining 44 adress space . Yes ip adress can be spoofed. So yen we cannot use that as the main security of the network. But it will deal with 99% of traffic. for the rest we need to do real identification stuff. And that is not at the adress space level that it need to be done.

Sadly, the internet is no longer a "free for all" and we need to authenticate devices as well as people.... ... and TCP/IP predates and does not conform the ISO seven-layer model (remember its a "model" not a set of rigid rules) no matter how much you try and bash it to fit so you can sell to EU governments who want ISO conformance... .. for example we normally do WiFi authentication some where down in the lower layers, and many switches also authentic at the MAC level to prevent rouge devices...

Dave G4UGM

-----Original Message----- From: 44Net 44net-bounces+dave.g4ugm=gmail.com@mailman.ampr.org On Behalf Of Toussaint OTTAVI via 44Net Sent: 17 February 2021 10:04 To: 44net@mailman.ampr.org Cc: Toussaint OTTAVI t.ottavi@bc-109.com Subject: Re: [44net] ASN # and Network Service Provider (NSP)

Le 16/02/2021 à 14:02, Cliff Sojourner via 44Net a écrit :

...

User authentication and user authorization belong in application layer,

there is no place for those in any network layer.

I don't know on which layer you could put it, but filtering access by source IP is a commonly used technique in business networks for restricting access.

Of course, it's different from user authentication. But it can be useful as a simple pre-authentication for a group of users : all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network.

73 de TK1BI

---

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

Well, I have changed to another NSP and still no success. Seems to be a problem with the advertisement  of my  subnet

44.108.2/24. I have received my LOA and have forwarded it to the NSP, but still been unable to get my subnet  advertised.

I know the stock answer to most of you will be, if they are a NSP, they should know what do. Since this is the second NSP,

I am looking specific steps/commands that need to be done to get subnet advertised.

Please refrain from sending the message, " They should know ." Forward that type of message to the NSP does not help much at all.

I am trying to help get this worked out.

Any help would be appreciated.

73 de Angelo

There are no specific universal commands, each company has their own process and procedure. You have to take direction from them. With my local data center, I entered the request into their ticketing system, including the email’d LOA. they then began the negotiation with all of their upstream providers. Some of them would not accept the email’d LOA, so I needed to get the letterhead version from (at the time) Brian. It took about three weeks of back and forth to get it set up and running. They did a static route of my allocation to my router in the DC, and I took it from there.

Later I split my allocation in half and sent part of it to Vultr (this required new licenses from ARDC). Vultr has a web form you fill out and submit. They do an email verification with ARDC, and I was working within about three hours from my initial submission (which is really quite amazing). At Vultr you must run a routing daemon on your host and speak BGP to their network. I chose to use BIRD (Bird Internet Routing Daemon) on my Debian host. The details on how to set that part up is well documented on their web site. The Vultr procedure is unique to Vultr, so posting it here would serve no purpose.

Many Data Center’s do not offer the service. Perhaps that has something to do with your lack of answers.

HI Angelo,

I can explain my journey, and hopefully it will help with your situation. There are a lot of barriers to this process, and some make sense.

While there are some network providers that will announce the netblock, some of the issue stems from what the end goal is. If one of those goals is to 'learn a life skill', you've hit a jackpot, there is a lot to learn. If it's simply to just have a few static IPs for your own use, cloud providers are a much easier and cheaper option.

The benefits of 'leasing' and announcing a netblock is mostly around portability of your IPs. For me, I wanted to setup a service where I can use the same IP address anywhere for time services. The idea is that if you're on AREDN (or another service), NTP can be setup on an IP address like 44.4.53.2, and anybody with a time server can create a time server with the IP 40.4.53.2. It's 'anycast' with some RF added for fun. Think of using 8.8.8.8 for DNS, we could use something like 44.4.4.4 for NTP/time.

That aside, there is likely a better mechanism than NTP to do this over the air, and that's where the experimentation and fun happens.

I will go forward with the idea that you would like these IPs to be portable somehow for the project you're using this block for.

The Internet is built on BGP, and a major part of that is the autonomous system number (AS or ASN). This number is unique on the internet for BGP services to learn how to get from one IP to another. For example, if your IP is 10.0.0.1, and trying to reach 10.10.0.1, will probably go through multiple autonomous systems to get there. Usually the shortest path wins.

10.0.0.1 (AS65536) -> (AS65537) -> 10.10.0.1 (AS65551)

There might be multiple routes to get there, which is where BGP comes in.

10.0.0.1 (AS65536) -> AS65538 -> AS65539 -> AS65551 etc..

This is a longer AS path, it becomes the less ideal path to send traffic. This way, if a path fails, there are 5 more paths left to get to me.

For visual representation of all the routes to my AS and path, check out https://bit.ly/3sggrKj - packets can go multiple different paths to get to me like Level3 and NTT but the shortest path wins.

To acquire an AS number, you need a business entity. For me, I already had a business entity called "I am a Bad Actor, LLC" for another project I had in the past for pen testing. I registered it in Wyoming using wyomingagents.com, which pretty much took about a day to receive the articles of incorporation. Cost here was $25 for a 'Registered Agent' + $102 for compliance filing.

We're up to $127 so far.

With the articles of incorporation, you can request an AS number. These are manually approved by various authorities (ARIN, RIPE, etc) but assuming you're in the US, ARIN is where you go (www.arin.net)

You'll need to submit 'sample documentation' for why you need an AS number. It will look something like this:

┌────────────────────────────────────────────────────────┐ │ │ │┌───────────────┐ ┌─────────┐ ┌────────────────────┐ │ ││ │ │ │ │ ARIX │ │ ││ Packet │ │ Choopa │ │ Amateur Radio │ │ ││ │ │ │ │ Exchange │ │ ││ │ │ │ │ │ │ │└───────────────┘ └─────────┘ └────────────────────┘ │ │ ▲ ▲ ▲ │ │ │ │ │ │ │ └────────────────┼──────────────────┘ │ │ │ │ │ │ │ │ │ │ │ ┌──────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ MY ASN │ │ │ │ ┌─────┴───────┐ │ │ │ │ Hurricane │ │ │ └────────────────────┤Electric FRE2│ │ │ └─────────────┘ │ └────────────────────────────────────────────────────────┘

Something like that. Make it pretty. Basically, you need the ASN to connect to multiple providers, including our very own internet exchange ARIX based in Hurricane Electric in Fremont.

This step will cost $550 for this ASN -, plus $150 per year.

So far we're up to $677 + 150 yearly.

Once you have the AS number, you will now be taken slightly more seriously with the ISPs and NSPs of the world. You've paid your dues to be part of an exclusive club. Mind you, there are as many AS numbers as there are IPv4 addresses, so there is no shortage of AS numbers, just additional barriers to entry for a reason (will go into this later)

For a list of providers that are willing to announce your new ASN with your IP range, head over to https://bgp.services and you can find a good list there. Vultr/Choopa is on the list, as well as many others.

I would recommend a small shop called FreeRangeCloud (freerangecloud.com), as the contacts there are really nice. It's not a big operation so you're not just a number. Also, be patient with them. :)

You have a few options at this point, but at first it involves getting a linux system up and running with BGP access. I personally use a Raspberry Pi 4 with 8GB of memory so I can hold full BGP feed in memory. I sent it to FRC to be installed in the rack within Hurricane Electric in Fremont.

Raspberry pi was $75, plus a case, memory card, and an NTP shield for my use-case. All said and done, about $110 + ntp sheild. You can get a VM that has similar specs for $8 or $10/mo. It's probably cheaper to do the VM path, but I needed the additional hardware.

Now we're up to $752 + $270/year.

You might want to also pick up a IPv6 IP range from freerangecloud while you're at it - a /48 (the minimum you can announce over BGP) goes for $5 setup, plus $5 a year. The steps below will be similar, but not exact for IPv6.

After your linux box is provisioned for your new IP range, we'll just add a dummy interface to accept the new IP range

# ip link add dummy0 type dummy # ip addr add <44-IP>/24 dev dummy0 44-IP is a real IP, not just network IP

There are a few services that can talk BGP on Unix, and the major one is called BIRD. I still use 1.6, but you can use any you'd like. BIRD is a bit overkill, but works well.

install it with your favorite package manager. I use apt.

apt-get -y bird

vi /etc/bird/bird.conf to get started. here is a sample config:

# something unique here on the network. Helps avoid routing loops in certain iBGP configs router id 10.0.0.1; # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds }

protocol kernel { export all; scan time 20; }

protocol direct { interface "dummy0"; import all; }

# Setup an outbound filter to ONLY announce the /24 assigned to you filter my_route { if net = <my netblock>/24 then accept; else reject; }

protocol bgp bgp_uplink { export filter my_route; import all; local as <your new ASN>; direct; neighbor <NSP BGP router> as <NSP ASN>; }

Save configs, start bird (service bird start) and check on it with "birdc"

birdc show protocol all

After this is complete, you'll need to get routes into the IRR (Internet Routing Registry) for your ASN. IRR is a group of registries loosely used to validate you own the netblock you are announcing with your AS. Not only that, but it also lists your uplink transit providers so they can re-announce your block. This is as an attempt to avoid someone hijacking your IP range and saying "this is mine". The IRR through ARIN was free and easy through their email interface. Since they've moved to web-based, they now validate the routes with blocks that are ARIN-owned, of which 44.x.x.x addresses are not.

The other options available are RADb, which currently costs $425/year for non-profit. There was talk about AMPR opening up an account, but that will require using the API for people with an ASN can update the DB themselves with authentication. I'm assuming this is in the works already.

But for now, this is the only way I know to update the IRR now ARIN is no longer accepting email-based updates.

So we're up to $1177 to start, and $575 per year to announce the IP.

There is a chance you can bypass a lot of the above ASN malarkey, but you will be met with mixed results. If you use a small provider like Free Range Cloud (freerangecloud.com) or Neptune Networks (neptunenetworks.org) they can announce using their own ASN, and provide you a 'private ASN' that you can announce your route, and it will be passed on. You'll still need BIRD, but it gives you control over which network provider gets your traffic (which is, after all, the whole purpose, right? :)

Why is this so difficult, you say? Well, the short answer is that the internet providers as a whole don't want more ASNs on the network. It means their route tables get bigger, requires more memory/cpu, and routers get more expensive over time. I went for a 8GB raspberry pi, and that should give me some wiggle room for a while. Most routers have much less memory than that. Each additional route adds a little bit extra step for routers to do. ARIN also has bills to pay themselves.

Now for options -

If we can get IP addresses registered as "legacy" status in RIPE, we can use their IRR to avoid the RADb step above (saves $425/year). Also, if RIPE announces the IPs as legacy, it would be possible to take a chunk of IPs and announce them via AWS via AWS Global Accelerator and utilize cloud resources using the IPs. Instead of IPIP, we can hand out world-wide VPN endpoints. We can also create our own VPCs for different projects. This would give amateur radio a huge boost of bandwidth in places like Europe, Australia, South America, and India, and Africa.

For those of us who wish to keep our racks/cages/routers at datacenters, that's completely cool. We could maybe setup AWS Direct Connect in popular datacenters for direct connectivity to other AMPRnet nodes.

I learned a lot about BGP in the last 8 months doing it myself. It's also an expensive lesson to learn. Worth it? Maybe.

But not everyone wants to learn BGP just to get a network IP block for a project. ' Anyway - got a little soapbox-ey for a minute. I hope this helps. For anybody doing this for the first time, freerangecloud.com and neptunenetworks.org are the nicest and most willing to help NSPs out there.

73, KF6DMA

On Wed, Feb 17, 2021 at 9:24 AM Angelo via 44Net 44net@mailman.ampr.org wrote:

Well, I have changed to another NSP and still no success. Seems to be a problem with the advertisement of my subnet

44.108.2/24. I have received my LOA and have forwarded it to the NSP, but still been unable to get my subnet advertised.

I know the stock answer to most of you will be, if they are a NSP, they should know what do. Since this is the second NSP,

I am looking specific steps/commands that need to be done to get subnet advertised.

Please refrain from sending the message, " They should know ." Forward that type of message to the NSP does not help much at all.

I am trying to help get this worked out.

Any help would be appreciated.

73 de Angelo

---

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

WOW!!! Talk about being lost in a maze.  I find this to be more then it is worth sometimes.

On 2/17/2021 7:35 PM, Clive Blackledge via 44Net wrote:

HI Angelo,

I can explain my journey, and hopefully it will help with your situation. There are a lot of barriers to this process, and some make sense.

While there are some network providers that will announce the netblock, some of the issue stems from what the end goal is. If one of those goals is to 'learn a life skill', you've hit a jackpot, there is a lot to learn. If it's simply to just have a few static IPs for your own use, cloud providers are a much easier and cheaper option.

The benefits of 'leasing' and announcing a netblock is mostly around portability of your IPs. For me, I wanted to setup a service where I can use the same IP address anywhere for time services. The idea is that if you're on AREDN (or another service), NTP can be setup on an IP address like 44.4.53.2, and anybody with a time server can create a time server with the IP 40.4.53.2. It's 'anycast' with some RF added for fun. Think of using 8.8.8.8 for DNS, we could use something like 44.4.4.4 for NTP/time.

That aside, there is likely a better mechanism than NTP to do this over the air, and that's where the experimentation and fun happens.

I will go forward with the idea that you would like these IPs to be portable somehow for the project you're using this block for.

The Internet is built on BGP, and a major part of that is the autonomous system number (AS or ASN). This number is unique on the internet for BGP services to learn how to get from one IP to another. For example, if your IP is 10.0.0.1, and trying to reach 10.10.0.1, will probably go through multiple autonomous systems to get there. Usually the shortest path wins.

10.0.0.1 (AS65536) -> (AS65537) -> 10.10.0.1 (AS65551)

There might be multiple routes to get there, which is where BGP comes in.

10.0.0.1 (AS65536) -> AS65538 -> AS65539 -> AS65551 etc..

This is a longer AS path, it becomes the less ideal path to send traffic. This way, if a path fails, there are 5 more paths left to get to me.

For visual representation of all the routes to my AS and path, check out https://bit.ly/3sggrKj - packets can go multiple different paths to get to me like Level3 and NTT but the shortest path wins.

To acquire an AS number, you need a business entity. For me, I already had a business entity called "I am a Bad Actor, LLC" for another project I had in the past for pen testing. I registered it in Wyoming using wyomingagents.com, which pretty much took about a day to receive the articles of incorporation. Cost here was $25 for a 'Registered Agent' + $102 for compliance filing.

We're up to $127 so far.

With the articles of incorporation, you can request an AS number. These are manually approved by various authorities (ARIN, RIPE, etc) but assuming you're in the US, ARIN is where you go (www.arin.net)

You'll need to submit 'sample documentation' for why you need an AS number. It will look something like this:

┌────────────────────────────────────────────────────────┐ │ │ │┌───────────────┐ ┌─────────┐ ┌────────────────────┐ │ ││ │ │ │ │ ARIX │ │ ││ Packet │ │ Choopa │ │ Amateur Radio │ │ ││ │ │ │ │ Exchange │ │ ││ │ │ │ │ │ │ │└───────────────┘ └─────────┘ └────────────────────┘ │ │ ▲ ▲ ▲ │ │ │ │ │ │ │ └────────────────┼──────────────────┘ │ │ │ │ │ │ │ │ │ │ │ ┌──────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ MY ASN │ │ │ │ ┌─────┴───────┐ │ │ │ │ Hurricane │ │ │ └────────────────────┤Electric FRE2│ │ │ └─────────────┘ │ └────────────────────────────────────────────────────────┘

Something like that. Make it pretty. Basically, you need the ASN to connect to multiple providers, including our very own internet exchange ARIX based in Hurricane Electric in Fremont.

This step will cost $550 for this ASN -, plus $150 per year.

So far we're up to $677 + 150 yearly.

Once you have the AS number, you will now be taken slightly more seriously with the ISPs and NSPs of the world. You've paid your dues to be part of an exclusive club. Mind you, there are as many AS numbers as there are IPv4 addresses, so there is no shortage of AS numbers, just additional barriers to entry for a reason (will go into this later)

For a list of providers that are willing to announce your new ASN with your IP range, head over to https://bgp.services and you can find a good list there. Vultr/Choopa is on the list, as well as many others.

I would recommend a small shop called FreeRangeCloud (freerangecloud.com), as the contacts there are really nice. It's not a big operation so you're not just a number. Also, be patient with them. :)

You have a few options at this point, but at first it involves getting a linux system up and running with BGP access. I personally use a Raspberry Pi 4 with 8GB of memory so I can hold full BGP feed in memory. I sent it to FRC to be installed in the rack within Hurricane Electric in Fremont.

Raspberry pi was $75, plus a case, memory card, and an NTP shield for my use-case. All said and done, about $110 + ntp sheild. You can get a VM that has similar specs for $8 or $10/mo. It's probably cheaper to do the VM path, but I needed the additional hardware.

Now we're up to $752 + $270/year.

You might want to also pick up a IPv6 IP range from freerangecloud while you're at it - a /48 (the minimum you can announce over BGP) goes for $5 setup, plus $5 a year. The steps below will be similar, but not exact for IPv6.

After your linux box is provisioned for your new IP range, we'll just add a dummy interface to accept the new IP range

# ip link add dummy0 type dummy # ip addr add <44-IP>/24 dev dummy0 44-IP is a real IP, not just network IP

There are a few services that can talk BGP on Unix, and the major one is called BIRD. I still use 1.6, but you can use any you'd like. BIRD is a bit overkill, but works well.

install it with your favorite package manager. I use apt.

apt-get -y bird

vi /etc/bird/bird.conf to get started. here is a sample config:

# something unique here on the network. Helps avoid routing loops in certain iBGP configs router id 10.0.0.1; # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds }

protocol kernel { export all; scan time 20; }

protocol direct { interface "dummy0"; import all; }

# Setup an outbound filter to ONLY announce the /24 assigned to you filter my_route { if net = <my netblock>/24 then accept; else reject; }

protocol bgp bgp_uplink { export filter my_route; import all; local as <your new ASN>; direct; neighbor <NSP BGP router> as <NSP ASN>; }

Save configs, start bird (service bird start) and check on it with "birdc"

birdc show protocol all

After this is complete, you'll need to get routes into the IRR (Internet Routing Registry) for your ASN. IRR is a group of registries loosely used to validate you own the netblock you are announcing with your AS. Not only that, but it also lists your uplink transit providers so they can re-announce your block. This is as an attempt to avoid someone hijacking your IP range and saying "this is mine". The IRR through ARIN was free and easy through their email interface. Since they've moved to web-based, they now validate the routes with blocks that are ARIN-owned, of which 44.x.x.x addresses are not.

The other options available are RADb, which currently costs $425/year for non-profit. There was talk about AMPR opening up an account, but that will require using the API for people with an ASN can update the DB themselves with authentication. I'm assuming this is in the works already.

But for now, this is the only way I know to update the IRR now ARIN is no longer accepting email-based updates.

So we're up to $1177 to start, and $575 per year to announce the IP.

There is a chance you can bypass a lot of the above ASN malarkey, but you will be met with mixed results. If you use a small provider like Free Range Cloud (freerangecloud.com) or Neptune Networks (neptunenetworks.org) they can announce using their own ASN, and provide you a 'private ASN' that you can announce your route, and it will be passed on. You'll still need BIRD, but it gives you control over which network provider gets your traffic (which is, after all, the whole purpose, right? :)

Why is this so difficult, you say? Well, the short answer is that the internet providers as a whole don't want more ASNs on the network. It means their route tables get bigger, requires more memory/cpu, and routers get more expensive over time. I went for a 8GB raspberry pi, and that should give me some wiggle room for a while. Most routers have much less memory than that. Each additional route adds a little bit extra step for routers to do. ARIN also has bills to pay themselves.

Now for options -

If we can get IP addresses registered as "legacy" status in RIPE, we can use their IRR to avoid the RADb step above (saves $425/year). Also, if RIPE announces the IPs as legacy, it would be possible to take a chunk of IPs and announce them via AWS via AWS Global Accelerator and utilize cloud resources using the IPs. Instead of IPIP, we can hand out world-wide VPN endpoints. We can also create our own VPCs for different projects. This would give amateur radio a huge boost of bandwidth in places like Europe, Australia, South America, and India, and Africa.

For those of us who wish to keep our racks/cages/routers at datacenters, that's completely cool. We could maybe setup AWS Direct Connect in popular datacenters for direct connectivity to other AMPRnet nodes.

I learned a lot about BGP in the last 8 months doing it myself. It's also an expensive lesson to learn. Worth it? Maybe.

But not everyone wants to learn BGP just to get a network IP block for a project. ' Anyway - got a little soapbox-ey for a minute. I hope this helps. For anybody doing this for the first time, freerangecloud.com and neptunenetworks.org are the nicest and most willing to help NSPs out there.

73, KF6DMA

On Wed, Feb 17, 2021 at 9:24 AM Angelo via 44Net 44net@mailman.ampr.org wrote:

...

Well, I have changed to another NSP and still no success. Seems to be a problem with the advertisement of my subnet

44.108.2/24. I have received my LOA and have forwarded it to the NSP, but still been unable to get my subnet advertised.

I know the stock answer to most of you will be, if they are a NSP, they should know what do. Since this is the second NSP,

I am looking specific steps/commands that need to be done to get subnet advertised.

Please refrain from sending the message, " They should know ." Forward that type of message to the NSP does not help much at all.

I am trying to help get this worked out.

Any help would be appreciated.

73 de Angelo

---

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

Goal post??  My questions is, what goal post am I suppose to run to???????

Confused yet??

On 2/17/2021 6:15 PM, Cliff Sojourner via 44Net wrote:

Ok, I give up. Stop moving the goal posts.

You said 44net isn't Internet, now you say to use basic techniques used by business for Internet.

Src IP is insufficient for this. Lots more needed. Lookup stateful firewall. Also, think about multiple users per IP. Friendly advice.

Cliff K6CLS CM87

On February 17, 2021 2:03:59 AM PST, Toussaint OTTAVI via 44Net 44net@mailman.ampr.org wrote:

...

Le 16/02/2021 à 14:02, Cliff Sojourner via 44Net a écrit :

...

User authentication and user authorization belong in application

layer, there is no place for those in any network layer.

I don't know on which layer you could put it, but filtering access by source IP is a commonly used technique in business networks for restricting access.

Of course, it's different from user authentication. But it can be useful as a simple pre-authentication for a group of users : all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network.

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

Rob,

but we largely have the proposed network already running ...

Which is news to me, but being that I left Holland at the age of 1, I might be forgiven for not knowing this, now I live in central Canada.

*I* am talking about *what we have now* ...

Understood, thanks for the information.

Maiko

Actually, the idea would be to DELEGATE the user access to some point of presence which support optimized access to the full mesh/network (by whatever means, this is not important right now) and allow traditional VPN access to client that request it and do not have the means to participate in the grand scheme.

And this does not even need to be centrally coordonated except the delegation itself (like that system X gets subnet Y, that's it).

POPs could be supporting the current mesh for now, be BGP announce, whatever is needed to get them fully connected. The idea would be to provide end user access by means of non-custom protocols (again, no specifics, each POP should take their own decisions) without the need to set up an individual gateway, nor the need to get through amprgw.

Of course, everything degenerated in ideas of having everyone to use a one-fits-all solution, with everyone pushing their own agenda and impose it upon others...

Sorry to say, but I feel this will be just another failure, like anything else where some impose their specific solutions on others without working out a generic paradigm first.

Marius, YO2LOJ

On 06.02.2021 16:32, M Langelaar via 44Net wrote:

Rob,

Jason's comment about VPS scalability made me want to ask this (I forgot) :

...

That would be possible, but we largely have the proposed network

already running

...

for 6.5 years now and it is not necessary to prove that it works.

So the Dutch network is running it's own VPS service on it's 'own hardware' ?

So the proposal is to have ARDC run it's own VPS service that would give amateur radio ops what they need as far as tunneling requirements and so on ?

In addition we could add openVPN service as well ?

Maiko Langelaar / VE4KLM

---

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

On 2/6/21 3:32 PM, M Langelaar via 44Net wrote:

So the Dutch network is running it's own VPS service on it's 'own hardware' ?

So the proposal is to have ARDC run it's own VPS service that would give amateur radio ops what they need as far as tunneling requirements and so on ?

In addition we could add openVPN service as well ?

We have a pair of HP Proliant DL-380 servers (one G7 and one Gen9) running VMware ESXi 6.7 and a MikroTik CCR1009 router in a datacenter in Amsterdam. The ESXi hosts are running VMs for different amateur radio related services, including a gateway for the 44.137.0.0/16 network.  But also servers for Brandmeister, for example.

What I proposed was not to have ARDC run their own VPS infratructure, but to get VPS services from providers around the world to run gateways similar to this. They could consist of one or more plain Linux VPSes, and e.g. a MikroTik CHR which is a router running in a VPS.  (the routing cound be done with a plain Linux system as well, whatever the maintainers prefer)

To the end-users, it could offer both OpenVPN service for endpoints and serveral types of tunnels that can be used to run BGP and connect routers in the radio network to this backbone.  That means that radio network islands can be interconnected and it also functions as a backup in case a radio network becomes separated in different islands because a major radio link fails.

Users even can make private tunnels between them and either do some static routing or run BGP there as well to have automatic routing of traffic according to their own preferences.  And they can decide to connect to a couple of different nodes in the backbone network so their service won't be cut if one of them goes down for maintenance or because of problems in that particular datacenter.

Rob

Nice Jonathan!!! It will come in handle for me and others.

Angelo

On 2/4/2021 10:41 AM, Jonathan Lassoff via 44Net wrote:

And if you're looking for various providers that offer Internet BGP to VMs: http://bgp.services

On Thu, Feb 4, 2021 at 4:20 PM Dave Gingrich via 44Net < 44net@mailman.ampr.org> wrote:

...

If your host offers the service (not all of them do), they would know how to answer your question right off the top of their head. It is very important to keep them on the air and widely known. Vultr.com, for example is 20473, regardless of the site you choose.

Keep in mind there is a non-trivial amount of configuration work they have to do, to make it work. If they cannot tell you what their ASN is, they probably do not offer the service.

-- Dave K9DC Indianapolis

...

On Feb 4, 2021, at 10:44, Angelo via 44Net 44net@mailman.ampr.org

wrote:

...

Hi Guys,

I am trying to locate two pieces of information to be able to complete

my BGP request.

...

This seems to be more of a challenge then I though it would be. Is there

a reference page or

...

wiki that I can provide to my ISP to be able to locate this information.

We have been dealing with these two questions for over 2 weeks. I am not

sure if the ISP or the

...

NSP know exactly what we are looking.

From what I understand the ASN is just a number. No letters involved in

this number. Is this true???

...

Any help in providing information to the NSP would help.

Break Down - I will be connecting to ISP via VPN connection.

                      The ISP connects to his feed in Houston via I

ATT fiber connect to his NSP in Houston.

...

                       The ISP sell service to clients in his area.

He has a /6 himself.

...

Please don't laugh. I am trying to lay this out the best I can. Any help

would be appreciated.

...

73 de Angelo / N5UXT

---

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