- 44net - mailman.ardc.net

Pacific Packet Radio Society history site: www.pprs.org

by John Gilmore

Curtis Spangler, N6ECT, has kindly created an archive of documents and photos from amateur radio packet networking history. The Pacific Packet Radio Society was a small group of hams in the San Francisco Bay Area, led by Hank Magnuski, KA6M, in the 1980s. Hank's KA8M-1 repeater talked half duplex at 1200 bits/sec with VADCG Terminal Node Controllers throughout the Bay Area. A good chunk of the history is here, including how Hank originally requested and received the 44net IP address allocation: http://www.pprs.org/ In particular, in this page, Hank wrote on 1981-06-10 to Paul Rinaldo, W4RI, thanking him for information about the INTERNET protocols, and reported: http://www.pprs.org/bulletin/pages/page003.html "In looking over this document the application of the standard is fairly straightforward except for one area, and that concerns addressing. A four byte source or destination address is specified, and that does not meet our needs. The first byte of this four byte field represents a network, and about 40 of the possible 256 combinations are already assigned. I attempted to contact the author of the document to see if a number could be assigned to an amateur radio experimental network, or to see if there already was a number for personal computing networks, but John [sic] Postel was out of town, and I didn't get an answer to my question. It seems clear that 256 networks is somewhat limiting, and that some future revision of the standard will have to expand this field." (As we now know, figuring out how to allocate network addresses, and route packets among them, is not as simple as it seemed back then!) Page 13 reports, in a 1981-12-06 page of notes about how to build packet repeaters and networks: http://www.pprs.org/bulletin/pages/page013.jpg "Direct connect stations using IP protocol can use "NET 00 00 00" as the network node address. NET is decimal 44." John Gilmore, W0GNU

3 years, 8 months

1
0
0 0

no route due to no host resolution

by R P

Hi there My gateway (44.138.1.1) tunnel get the commercial IP host name from no-ip.com and the UCSD router use this name to resolve the IP and make tunnel to it since it use dynamic IP every time that this hos is in some reason not resolvable the UCSD takes it out from the routing table and i get no route to it anymore Even when the host is resolvable again the only solution is to write Chris and ask him to fix it for me Has anyone seen this thing at his system ? Is there any thing i can do to make the route back ? Or (prefered) can any mechanism be add to ucsd that when a certain host get resolved again the route will come back without any intervention by human ? Any help welcome .. Regards Ronen - 4Z4ZQ http://www.ronen.org

3 years, 8 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 10, Issue 112

by Bill Buhler

Sorry, I just realized that I broke threading when I replied to you Pierre, Now we really are getting to where there should be layer4 and Layer5 firewalls. Looking at this your proposal actually gives a false sense of security by segregating. Why do I say that? Modern web browsers will attempt to use https first if not explicitly told to. This was determined by their coders to be a good thing because it encourages privacy on the Internet, and few places of the world limit encryption. Of course most if not all amateur radio operators are prohibited from "obscuring the meaning" and therefore using encryption. We could walk down that rabbit hole, but lets not. Instead lets walk down the handshaking rabbit hole. If I want to do SSL with a website I access it at port 443. If I don't I access it at port 80. Therefore if I do a L4 firewall rule at the gateway that feeds rf link that rejects any traffic to or from port 443 I've prevented the handshake and no encryption will follow. SMTP can be a little trickier if I have enabled the libraries on my device for SSL, it's possible that it could issue a start tls command and negotiate a encrypted feed over what would normally be a unencrypted port. There are two solutions to this. One is to install a application aware next generation firewall (Palo Alto makes the one I use), which looks inside the packets at the actual data flows and classifies what the actual protocol being used is rather than just the port (socket address) that is being passed. With a Palo Alto I can drop or reject all traffic that uses encrypted protocols. Once dropped I'm safe. But many don't have these firewalls, and that's understandable. Instead, as the licensed radio operator, who knows the rules, they should learn how to disable the encrypted protocols running on their devices that will be problematic for these reasons. There is no universal solution, because if I just say "oh this network is unencrypted" doesn't mean that if I have setup a web server with a ssl port that someone else on the network won't access it over chrome and accidentally end up with a encrypted feed. Being on the network is only the first step, administrating our devices to comply with the rules is a ongoing and important thing. Fortunately, most devices either have limited packet filtering built in, or can have features like SSL/TLS disabled in their settings. Which makes this a moot point. For my RF devices I make sure that their backhaul link blocks known points of encryption. Because that is the purpose of a firewall, and proper network stewardship. Just like I filter Bogons and known bad actors at the edge of my network connections. Sorry for the novel, but I believe in trying for a universal solution, many are missing why the solution won't cure the problems. Best regards, Bill Buhler - AF7SJ On 8/17/2021 12:30 PM, pete M wrote: > Bill, yes making rules like you just told will get rid of all the > traffic that is not 44. > > But it does not fix some issue that ham will have with the normal ham > to the world exchange of data. > > There are 2 use case that we seen. One being ham talking to ham and > the world and earing from ham and the world. > > The second use case is ham talking to ham, end ham earing from ham only. > > In the explanation you gave this would fit only the first use case and > the local guys would firewall what he want or not. > > But when we come to the ham to ham only use case we fall short. On > many network we cannot allow to have encryption on RF. Now let's say > someone put a web site on a 44 address and enable https. The ham on RF > want to connect to it. He open his browser and he is now actively > passing encrypted data over the air. > > What will the 44.128/10 segment will provide is to make sure that > everyone on that segment won't encrypt anything and won't put someone > else into a bad situation > > Pierre > VE2PF >

3 years, 8 months

2
1
0 0

A new era of IPv4 Allocations

by Antonios Chariton (daknob)

Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent. Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information! You can find our 5-page PDF here: https://pdf.daknob.net/ardc/tac128.pdf <https://pdf.daknob.net/ardc/tac128.pdf> The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations. Since the TAC does not have any authority on the IP (or any other) resources of ARDC, and we only have an advisory role, we end this document with a proposed resolution we intend to submit soon to the ARDC Board of Directors, where we urge them to vote and approve some key things required for us to be able to achieve what is described. We believe that the TAC represents the community and the 44 Net users, so we created this document and post it here in advance, with the purpose of being able to answer your questions, collect your feedback, and hear from you. This is why we briefly explain the situation in about 4 pages, and then we end with the resolution we want the ARDC Board of Directors to approve. I hope you like it, and I remain at your disposal for anything you may need. Antonis Links: [1] - https://blog.daknob.net/mapping-44net/ <https://blog.daknob.net/mapping-44net/>

3 years, 8 months

41
195
0 0

Re: [44net] 44Net Digest, Vol 10, Issue 112

by Bill Buhler

Pierre, Coming from twenty years helping various companies connect to the Internet, I find your view of firewalls to not match my own. A firewall can filter at any layer of the network stack (depending on the firewall), but layer 2 and layer 3 firewalls are extremely common... Therefore I look back on you're trying to firewall off a bunch of machines at L3 from the internet at large, while allowing them to speak to the other 44 net machines. I believe we would be better served if that is your goal to write the following rules in whatever ACL / Firewall language your platform allows at the network ingress: Source address 44.0.0.0/9 to any (or more specifically 44.0.0.0/9 & 44.128.0.0/10 if you want those extra rules). Source Address 0.0.0.0/0 drop to any There now your input doesn't allow non 44 net traffic to propagate through your network.... OK, I'm being a little bit simplistic here, but this is what we do in the real world. It is a pure L3 solution. Just like I would do L2 filtering (MAC address level) if I was connected to a ISP on a broadcast medium and only wanted to talk with my upstream provider. In the commercial space groups will publish their addresses mutually with each other to whitelist at the firewalls. I think if there are substantial groups who want to form private networks AMPR being a clearing house of that information is totally appropriate, but it should be up to those groups to control their ingress and egress points, not the network itself. Its job should be to build the backbone and enable connectivity between hams without conflicting address spaces. I have come to view this as a issue a premature optimization. We know where we are now, we know some of the struggles that certain groups are having. But top down solutions tend to have unintended consequences, and become rapidly brittle. Letting groups design their own ingress / egress rules allows them to rapidly iterate. Providing them out of band additional information such as lists of networks that only want to speak to hams, or lists of un-allocated blocks will give them the flexibility to design their rules, and the rest the ability to keep doing what they need to do. Finally, we are still seeing memory and processing power increase with each generation of devices, so we are in no danger of our ham radio network exceeding the basic capacity of most consumer devices, even ones that are on the used market. Best regards, Bill - AF7SJ On 8/16/2021 1:00 PM, 44net-request(a)mailman.ampr.org wrote: > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > Today's Topics: > > 1. Re: A new era of IPv4 Allocations : Agree (pete M) > 2. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M) > 3. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M) > 4. Network layer easy explaination. A must read. (pete M) > 5. Re: A new era of IPv4 Allocations : Agree (Rob PE1CHL) > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

3 years, 8 months

1
0
0 0

Network layer easy explaination. A must read.

by pete M

https://insights.profitap.com/osi-7-layers-explained-the-easy-way There are a lot of people comming with solution to the problem that the TAC want to fix. They are comming with solution that are not at the same layer level. This break networking communication. Using a layer 4 software to fix a layer 3 problem wont work. Same as using a layer 3 software wont fix a layer 4 problem. All the layer need to work as intended for a full network to work. TCP and UDP are at level 4 Firewall acts on layer 3 and up. IP is at layer 3 only. routing is a layer 3 task. You can use a firewall to slect what packet pass or not pass up to a point. But at the routing level if you are a link for multiple links. how can you firewall something and not brake routing? how do you make sure that the netwokr you filter with the firewall is really not ok to pass? Judgement call? But at the same time what if the user ask you to do it. One thing is clear, on an open network architecture the local node that pass 3rd party traffic is not to filter any traffic. this woudl break the routing and prevent actual data that to pass on the route that the layer 2 and 3 decided to be the best. But again how to fix a demand of a use that want to have some traffic filtered from the begining? By creating a non open network. And that is the ONLY REAL solution to prevent the breaking of any route at the layer 3 and make sure that the trafic is ligit. All the route are pointing to the non open network and all the node pass all the traffic that need to pass trough them. Client at the end put firewall to prevent some traffic to reach them but they are end of lines not transporting data to 3rd party. I hope this will help removing some of the fog that flow all over the networking talk. Pierre VE2PF

3 years, 8 months

1
0
0 0

Unable to ping any nodes

by CJ Kelley

Hi Everyone, I was running a JNOS BBS a few months ago and I was able to connect to other nodes on the 44net. I had to take JNOS offline for a few months while some changes to the network were made. No changes were made to the JNOS node, though. The gateway IP did change and it was updated on the AMPR gateway. I have brought the JNOS back up, but now I am not able to ping any 44net node. I am able to ping other servers like google.com. I performed a packet capture and I see that the ICMP request is being sent from JNOS, but the ICMP response is not being received. jnos> ping 44.135.92.10 jnos> Resolving 44.135.92.10... jnos> jnos> jnos> ping google.com jnos> Resolving google.com... 172.217.14.110: rtt 21 It is the same story with other nodes as well. Any recommendations? 73, de KG7UJH Christopher Kelley

3 years, 8 months

6
9
0 0

Use cases

by Lynn Grant

Greetings, I have been a ham for over 50 years (though not recently active), and have been involved with networks for about 20, so I am following the recent discussions with great interest. While I can understand in general terms what might be done with hybrid Internat-ham radio links, I would find it very useful to see examples of what other hams are currently doing with them. Would it be possible to have a few hams do short write-ups on what they are doing, and put them on the ARDC home page? Right now, it seems heavily skewed towards how to set up the networking end of things (which, of course, is very important, and something that hams new to networking could use some help with), with not much attention given to "Why would I want to do this?" Thanks, and 73, Lynn Grant N8AF / V31LK

3 years, 8 months

8
20
0 0

Portal requests not processed?

by Iain R. Learmonth

Hi, I made a request for an allocation via the portal on the 8th but I've not even had so much as an automated message yet. I've sent an email to G1FEF anticipating that some extra justification would be needed and also to provide the LoA details, but nothing. Is everyone on holiday? Thanks, Iain. -- https://hambsd.org/

3 years, 8 months

1
0
0 0

intranet security illusion

by ei4ku＠ei4ku.ampr.org

it just takes one bad actor inside an intranet to spoil your weekend. or maybe not even on purpose: a hijacked phone will do the job. great debate, very informative! 73 de stefan ei4ku

3 years, 8 months

2
1
0 0

On Allocations, PoPs, and Proposals

by Rosy Wolfe

Hello everyone, I, along with the board and staff, have been reading these messages. First of all, I want you all to know that YOU ARE HEARD. The point of having the TAC put out a proposal was to get feedback before adoption. It turns out that a significant part of the feedback is negative. I think that this proposal needs more work and adjustment before we can consider implementing it. The board and I want to see consensus on the main points of a proposal among the major schools of thought on this mailing list. That said, it’s important to remember that the people on this list are not the only people using the AMRPnet. We have a complex task on our hands to reach as many of those people as possible as we evolve proposals toward consensus. Several board members have suggested that it's hard to find consensus on solutions until we have a consensus on what problem(s) the solutions are trying to solve. We have a tangle of issues like the complexity of IPIP tunnels, to BGP routing, to address space sparseness, to low performance. With this in mind, what problems with the AMPRnet do you think we should be trying to solve first? One thing we haven't communicated well before, is that we are actively discussing budget and infrastructure for a “backbone” network of PoPs (Points of Presence) of the 44net on various continents, to make it easier for hams to connect to the AMPRnet with minimal effort and higher performance. If you have ideas about how you would like to see this happen, feel free to share here on the mailing list. I know that there’s at least one alternative proposal on the way. There’s obviously more discussion to be had, but for now, please rest assured that no changes are going to be made without more input from you and others using the AMPRnet. I also want to thank the TAC for their work up to this point. They have dedicated hundreds of hours to come up with this proposal. Even if its release has cause some heated discussion, it’s critical that these discussions happen. They will help all of us come up with the best solution for how to most effectively organize our network for the future. 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

3 years, 8 months

18
49
0 0

On Allocations, PoPs, Proposals, and something called RF

by Jeff Archambeault

Wow. I've been watching lots of message traffic that really only applies to what I would consider to be "edge cases"...BGP especially, when I'm here in the Adirondack State Park in upstate New York, Secretary of the local club (W2WCR), hollering "Hey, we should look into rebuilding the packet network north along the Hudson to Montreal and west to Buffalo along the St Laurence like it used to be." for a few years now and getting "Well, we have winlink, so it's ok." I have my allocation, and can't even use it because my local packet nodes are stuck using some archaic BS that can't route netrom needs either a DOS box with real serial ports and UARTS and a real TNC-2 with 6pack eprom (done, invested about $100 in a mfg-1270c and community-supported eprom...only to find out a year after buying it and waiting that it doesn't work) or an old 2.x Linux kernel to even have half a chance. I'm an extra now, but to be honest, I was really looking forward to playing with packet. The local packet folks have been great, tho similarly frustrated, either with having to attempt to upgrade the existing Eastnet/Flexnet history lesson on sites that aren't exactly accessable or even upgradable, or trying to convince clubs and county-maintained systems that it would be in their best interest to upgrade or replace equipment that used to exist but there is actually no real upgrade/migration path. So I have a node running as best as 24/7 as I can, with no real motivation to do so, no mail feed, wondering what the point actually is. And all I see is BGP BGP BGP BGP....BGP, and oh, BGP mentioned in this mailing list, wondering if there is some relation to CRT, as old as the tech is around here. I thought there was some RF involved, but all I see is BGP. If I wasn't an IT person, with a MikroTik Routerboard, I wouldn't have a clue. That, and the fact that I'm practically in a broadband desert, literally makes me sick and tired of any discussion of connecting anything anywhere that doesn't involve RF. Hm. Perhaps I need to say that again. I AM PERSONALLY SICK AND TIRED OF CONVERSATIONS DEALING WITH PACKET RADIO/AX.25 THAT DOESN'T INVOLVE RF. YOU CAN'T GET THERE FROM HERE!!!!!! FSCK GBP. Some of us can only wish we weren't stuck with hoping someone will connect with our PC3+s or hand-configured direwolf linux/uronode systems who are interested in something called "packet radio". When is someone going to start dealing with the fact that there are AMATEUR __RADIO__ OPERATORS, WITH _AMATEUR RADIO LICENSES_ that may actually be interested in sending digital, AX.25 via IP to other anateur radio operators via RF? I can't possibly be the only one. Geez. Sorry. Just frustrated for a little too long, seeing lots of traffic I'd consider "Much todo about nothing" and lots of money behind it. WTF, over. 73 de Jeff AJ2A Jeff Archambeault Proprietor, Bark Eater Studios Technology Frustration Resolution Solutions jeff(a)barkeaterstudios.com (518) 696-5675 (home) (518) 595-9815 (cell)

3 years, 9 months

6
9
0 0

Re: [44net] On Allocations, PoPs, and Proposals

by Jim Ancona

On Mon, 2 Aug 2021 13:29:33 -0700, Rosy Wolfe <rosy(a)ardc.net> wrote: > With this in mind, what problems with the AMPRnet do you think we should > be trying to solve first? I've been subscribed to the list for a while, but I'm not currently an AMPRnet user. (I have been a ham for over 40 years, and I did run TCP/IP over AX.25 back in the nineties.) My background is in software development, not networking, so while I know about building high-volume web services, and I'd guess I know quite a bit more about networking than the average ham, much of the networking discussion here is well over my head. After trying to follow the discussion, I welcome the board and Rosy's attempt to reset things a bit, but I wonder if instead of asking "What problems with the AMPRnet do you think we should be trying to solve first?," we should first ask and try to answer "What is AMPRnet for?" The TAC document discusses reserving address space for non-Internet-connected "amateur radio-based networks," along with other uses. But as I understand it, some people here don't think that AMPRnet addresses should be reserved for things that will never be part of the Internet. I'd like to see a clear definition of what hams are using AMPRnet addresses for now and what they would like to be able to do in the future. In software development we talk about "use cases." According to Wikipedia: "A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal."[1] An actor might be an individual ham, a network administrator, or someone else. I wonder if trying to describe how AMPRnet is being used today, what is easy and what is too difficult and what we would like to enable in the future would help to provide a basis for discussion. If there were consensus on which use cases are most valuable, which are too hard to accomplish today and similar questions, then we would have a better basis to evaluate proposals with respect to how well they solve the important problems, how difficult or disruptive they are to implement and so forth. Jim N1ADJ 1 - https://en.wikipedia.org/wiki/Use_case

3 years, 9 months

1
0
0 0

fyi: was unsubscribed

by Thomas Osterried

Hello, just fyi: I was unsubscribed from the list since 2921-95-26 (where I received a last posting), without notice. Over the past weeks I thought, it's so quiet - nice, everyone enjoys vacation ;) Anyone else had this issue? vy 73, - Thomas dl9sau

3 years, 9 months

6
11
0 0

New email address

by G1FEF

Hello, Apologies for the extra noise on the list (re. Contact requests). I get a few bounce messages each month when the portal reminders go out - these are just folk that the portal can't reach and are at risk of losing their account. Secondly, please note my new ARDC email address: chris(a)ardc.net Please use this for any ARDC/AMPRNet comms specifically for me, personally. If you have any none personal comms, then you can use the following emails: abuse(a)ardc.net - Please report here any suspicious activity: suspected unauthorised BGP announcements, spam, compromised hosts, etc. We also support the following RFC2142 emails: hostmaster(a)ardc.net webmaster(a)ardc.net postmaster(a)ardc.net Currently the above four emails are forwarded to me, but it’s probably better to use these emails rather than emailing me direct in the first instance, e.g. in case I’m on holiday, we may redirect them to someone else. Thanks, Chris

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If KA1VRF is seeing this, or anyone knows how to contact them, please could they contact me privately: chris(a)ardc.net Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If PA3EDN is seeing this, or anyone knows how to contact them, please could they contact me privately: chris(a)ardc.net Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If K9WLF is seeing this, or anyone knows how to contact them, please could they contact me privately: chris(a)ardc.net Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If K4TQL is seeing this, or anyone knows how to contact them, please could they contact me privately: chris(a)ardc.net Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If VE6SLP is seeing this, or if anyone knows how to contact them, please can they email me privately: chris(a)ardc.net <mailto:chris@ardc.net> Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Contact request

by G1FEF

Hello, If WA4OKJ is seeing this, or if anyone knows how to contact WA4OKJ, please can they get in touch privately: chris(a)ardc.net <mailto:chris@ardc.net> Thanks, Chris - G1FEF

3 years, 9 months

1
0
0 0

Re: [44net] A new era of IPv4 Allocations

by Antonios Chariton (daknob)

Dear Mario, > On 30 Jul 2021, at 17:11, Mario Lorenz <ml(a)vdazone.org> wrote: > > Dear Antonios, > > Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob): > >> That’s what people want to do though. They want to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In the IP world, the src and dst can be different. People want to use an amateur radio resource to talk to a commercial resource, and a commercial resource to talk to a ham radio resource. > > Please define "people". Are these radio amateurs ? If so, why do you > want to restrict communication with them ? What they have to say can go > over amateur radio airwaves. If not, why are they in 44.(0). in the > first place ? Here's the thing: If there are "people" that are not radio > amateurs but want IP space for non amateur communication, they can go > and get it somewhere else, and pay for the privilege. > If that needs any TAC resolution to propose at ARDC, > I think you would find much support on this list. The first reference of people is hams, the second is non-hams. So this sentence becomes: That’s what hams want to do though. Hams want to use an amateur radio resource (44.0/10) to talk to non-hams on the Internet (that are not licensed). We do not want to restrict people on 44.0/10 and we want them to be able to speak to anyone on the Internet. Of course, ARDC here may have some policies against e.g. spam, piracy, etc. but that’s not relevant. They are responsible of figuring out though if their communication is legal. The proposal simply puts all the people that want to talk to the Internet in 44.0/10 and leaves all the people that don’t want to talk to the Internet with a 44 address to 44.128/10. >> These two networks can interconnect. EchoLink now bridges the Internet with the amateur radio spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio spectrum, we use IP addresses on top of callsigns. > > In which case you need to differentiate between amateur radio and third > party traffic. Indeed, yes. This is up to the operators of these services. We do not want to interfere with what they do and how. >> We have collected minutes of meetings that we did as the TAC, and they capture a part of the total work that has been put through this. However, at this time, they are not public. Is there something specific that you’re looking for? I could help provide more information on that. > > As discussed before, the pdf statement contains contradictory, not > sufficiently specific language. Your explanations, as given in your role > as TAC speaker, appear to contradict the specific resolutions that > TAC wants to propose to ARDC. The specific example being whether 44.0/9 > should be able to communicate with 44.128/10. > I'd like to resolve this obvious misunderstanding by looking at primary sources. To be clear: 44.0/9 *cannot* directly to 44.128/10 and 44.128/10 *cannot* talk directly to 44.0/9 under our proposal. I believe that this is what we include in the proposal text as well. For all intents and purposes, we treat 44.0/9 as any other IPv4 address on the Internet when we talk to it from the Intranet. The same way a 10/8 host cannot talk to 1.1.1.1 a 44.128/10 address cannot talk to 44.0.0.1. The operators of the networks will have to use NAT (like they do today), or they can also request a 44.0/10 space and do a 1:1 mapping of hosts, or anything else. - You should never receive a packet in your 44.128/10 address from a non-44.128/10 address - You should never receive a packet in your non-44.128/10 network from a 44.128/10 address >> >> So far, we are not working on any such response, and all TAC members agree with the responses provided by me. >> > They are inconsistent... > >> We only want to preserve some IP space that can be used for ham-to-ham communication. How they communicate is up to them. If they want to use radio-only, they can get an allocation off this space and build a radio-only network. If they want to communicate with carrier pigeons only, they can get an allocation and build a carrier-pigeon-only network. If they are okay with using tunnels *through* the Internet, then they can do that. > > OK, having established that, you would agree that any references to a > "radio-only networks" in the PDF should be reworded. Yes, this is something we can do, and it’s a good idea. >> We just want to make sure that we have some space reserved for this type of communication. Going back to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of the space is for ham-to-ham, and the rest is for ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can reach you. > > Each packet bears a source and a destination IP. If we agree > that any packet originating from IP from either 44/9 or 44.128/10 > are licensed ham radio amateurs (as stipulated by current ARDC AUP). We agree that this is what should happen. However, for any Internet-connected network, there’s no guarantee it will always be true. > If they are destined to a 44.destination via a radio link, it can be > assumed they have sufficient authority to be passed on as ham-ham > communications. What happens if they do not have sufficient authority to pass? Where will this be reflected and how can users pick an alternative path? > If they are destined to non-44, or originate from non-44 > they *may* still be allowed as third-party communication, but this will > be jurisdiction-specific. I guess this is up to the operators and the local laws they have for each link, as you mention. However, how is it signaled and to whom that packets can or cannot pass from a link so if they’ll be dropped I can avoid sending them and pick a different path. Can I as an end-user pick a different path? It seems to me that some paths on this global BGP network will only pass some forms of traffic based on the source and the destination. Accounting for the destination is easy: if no traffic should go there, remove / filter out the route. But what happens when you want to filter by source a few hops down the network? How does my router know (and everything else in the network) which *source* decision is also made? What happens with combinations of (src, dst) and how will they be reflected on BGP? Do you plan to introduce BGP Extended Communities that will have a global meaning and all users should alter their path selection algorithm by using these and applying appropriate terms and rules in their BGP peerings? The problem here is how do I know which path I need to follow (and since I only control the first hop, the path that everyone must route with, through 44/8) that will get me to a given destination within 44/8? If I see 20 paths, but only 2 of them will forward my traffic based on my use case (src, dst) how can I tell which ones are that, and how can I affect the routing from my node to this one in order to ensure packet delivery? Do I just have to rely that BGP will hopefully pick the path that doesn’t drop my packets instead of the ones that does? Will every router in the entire network apply source-based policy routing? How will this be signaled? Will every have to manually maintain tables of “if src is x, use table y”? Most routers today can do this as statically configured firewall rules + additional routing tables. Is there a way to dynamically propagate this information to the entire network? Is it safe to allow people to control your routing policy? Who can modify your firewall rules to point to the “no radio” table? > Any station in the business of forwarding packets (ie. not your "end > user") can and must make the decision whether he actually forwards those > packets. Therefore anyone implementing a ham-to-ham-only policy can do > so within his network, *without placing any undue burden on other > people* to do the same or leave. You can’t just advertise routes on the single BGP control plane and then drop packets based on firewall rules. If you do this, any connection becomes unpredictable, and whether you get or not to your destination is a hit or miss, even if there are multiple valid paths to this network. If we use simple BGP then you only control the routes you advertise to your neighbors, and the AS Path. You can’t tell them “this route is available, but only if you are from 44.154/16, and if not, it doesn’t exist”. It’s all or nothing. If you advertise it, then for a correctly functioning network you must forward to this destination all traffic you receive for it, unconditionally. > If for convenience (and thats strictly convenience) several networks > want to partake on such a common strategy, it is *their* task to find > some unused IP range and renumber there. Precedent here is the original > HAMNET, which did this because it could not or did not want to use the > old 44.130 german network. As you can see above, creating a single BGP control plane across the entire network, that works with every use case people want can be a problem. Not only does it require advanced BGP knowledge and configuration, but it may not even be possible with most common hardware. For example MikroTik is known not to support Extended Communities in the first place. >> This is partly true: there is not a “single 44.128/10” but anyone can create their own network within this space. However, if some of these networks don’t want to talk to everything else, then this is working as intended, and they are by design not reachable. We hope that most of the networks there would want to be interconnected and they can do so through radio links, VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of the many methods people could use to make sure that these networks talk to each other. > > Now if one such network does not want to take part in this, then what do > you do ? Networking is a mutual understanding. Apparently therer seem > some difficulties between the dutch network and HAMNET. As long as > they dont get resolved, there will be no traffic exchange. meaning I as > an end user would have to have some sort of separate routing. This is > independent of which IP space is used. This is true, and a very common problem in community networks that I know of. People at one point have a diverging vision and don’t agree anymore and then they stop exchanging traffic. It is unfortunate to see in a network that’s supposed to connect people and it can really slow down deployment efforts, but it can always happen. We even see parts of that in the Internet too. I don’t think there’s anything ARDC can do to prevent this. The only thing is to make sure there’s enough room for everyone and interconnecting is easy. If some people want to be isolated or not talk to specific people, then I guess that’s that.. >> This is an important distinction and something we still allow: the ONLY thing we say is that 44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means that no part of this space may appear on the Internet. Of course, the exception here is that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent to it. It will be dropped at the edge and not forwarded anywhere. > > You are making this decision on top and over that of the people who > built and have run their respective networks for 25+ years. > You want to build such a network ? Fine. You find some unused space > and build it, or convince some existing ones to adopt that policy. > You need to learn sandbox etiquette. I appreciate you want to build a > bigger castle, but if you do that by trampling over the small ones built > by the other kids, you will be the bully. Nobody wants to play with > bullies. > > You also destroy the other ones completely unnecessarily, since your > isolationist approach can be solved by an ACL. Ultimately it will be > anyhow because ARDC will want to announce the space to prevent > hijacking. > And telling them that they can move to another sandbox isnt cutting it > either. This proposal aims to have ARDC continuously advertise 44.128/10 on the Internet, but as a whole block to which all traffic is dropped and not forwarded. We don’t want to change that. We have to keep advertising the space, for many reasons. Hopefully if we could get RPKI we could publish a ROA that would cause people validating to drop all announcements smaller than /10 in this space as well, so they are automatically discarded by filtering ISPs. As I have mentioned above, this problem is not simply solved by an ACL. It’s not a firewall rule to drop all traffic and that’s it. If all want to be on the same routing plane without causing massive packet loss and unreachable destinations, we have to find a way to inform everyone else of our policy. And BGP cannot currently do this, especially with the limitations of vendors like Ubiquiti and MikroTik. An ACL could solve this problem if we had a very centralized network where everyone connects to the PoPs and it’s mandatory, and interconnections between end users or networks is not allowed. If 44 Net looked like this then applying any type of police would be much easier. But if you allow for any use case, like hundreds of nodes connecting to each other, and only talk to the PoPs from 3 points on the Internet, then things can get more complicated. “Simple ACL” is easy on paper, but in reality it’s much more complicated than that. >> We can’t be certain, I agree with what you say. What we can do is make it much better than it is right now. We think that even if we can’t provide a perfect solution, we should still make steps to improve the situation. >> >> If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach you. If you are connected to the Internet, and you advertise your space with BGP, it is in fact *guaranteed* for non-ham traffic to reach you. > > I think your fundamental problem is that you confuse network nodes, > which are identified by IPs, and vertices, or links. The legal mandates > pertain to the links, not to the nodes. it is the responsibility of a > licensed ham to make sure only suitable stuff gets sent over a radio > link. There is no legal mandate not to communicate, using the radio ID, > over a non amateurradio link. Of course, I agree that there isn’t any mandate that I know of. However, all the policies of each and every individual link in every single part of the network must be immediately available to every single (at least “backbone”) router and must be used in the routing decision making. If people have links visible through BGP that silently drop traffic this will cause a lot of practical issues with unreachability like many we see in the network today. And the people, no matter how much they want to fix them, won’t be able to. >> You could argue that you could deploy ACLs or Firewalls, or any measure like that, and this would help you only accept 44/8 traffic. But this is still worse: packets on the Internet today can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a commercial ISP, and it would get through your firewall and possibly over your RF links just fine. > That was true more in the past than now due to reverse-path protection > and so on. It does not make a difference - you could tune a transmitter > to any frequency all the time. If you forward such packets, you have to > take certain responsibilities. Mind you, youre not an end user then. > You would employ things like route verification, checking if the packet > arrived via the correct tunnel etc. pp. > If you are not prepared to handle this, you should not be running a > gateway. Unfortunately mechanisms like uRPF that you mention only work to protect others from your network. If anything is more than a hop away, especially in a scenario where a gateway has a single transit provider / default route, then they can’t do anything. If you have a default route on your Vultr VPS (or even a full table, doesn’t matter), you see the entire Internet behind “eth0”. So everything coming that way will make it into your network just fine. The only thing that uRPF will do is to not allow packets from your own network to come via the Internet. Which you may have to allow eventually if e.g. your network is connected to the Internet via 3 points, and you want to go over the Internet in the case of a net split. So a lot of networks will end up disabling it (or choosing a more relaxed version, or technically not enabling it as it’s off by default) in the first place because it breaks legitimate use cases. I would personally agree that people running more core parts of the network should have more networking knowledge, and that would be expected, but I wouldn’t expect perfect, state-of-the-art operational expertise and equipment support. I would still expect to see operators like these to simply configure BGP and a few filters. And that’s fine. We’ve learned from the Internet that any system that relies on everyone adopting it and playing fair is far less likely to be useful. If the network was more centralized and every 44 island required the PoPs to connect to each other, and everything had to go through them, then you could argue that the ARDC staff maintaining it would have to follow state-of-the-art procedures and since it’s only a few points we could also have capable equipment, etc. So this becomes kinda better. But still, this means a centralized network. Do we really want that? > Moreover, if two 44/8 networks connect with intermediate hops over the Internet, e.g.: >> >> 1. 44.1.2.3 >> 2. 44.3.2.1 >> 3. 192.0.2.15 >> 4. 193.5.16.50 >> 5. 44.4.6.7 >> 6. 44.7.6.5 >> >> (Which I assume is what you want to do if you want to be on the Internet BGP and block all incoming traffic from non-44/8 hosts) > >> >> Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a transmission in a ham band of packets that are not from a ham. This is much more common than you can imagine, and not always done maliciously. If I am node #1 and I do a traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a packet that was not generated by a radio amateur (it’s a non-manned station / router of Cogent / Telia / Hurricane Electric, …) over a ham band. > > Yes. And an ACL would block those packets, and I'd see * * * in the > traceroute. That is not unusual. Though they may not be illegal in all > jurisdictions with more liberal third party rules. Yes, exactly, the ACL would drop these packets, but how do nodes #1 and #6 know that this path drops certain packets? How do they know which packets are dropped? Do they have to manually set up routes to an alternative path to route around these links if they want to send some types of packets? Will they maintain a separate table of static routes by hand? How often will they update it? What if the policy of a link changes and suddenly more packets are dropped than before? Will they have to notice packet loss and take action to route around this region of the network? >> Now for the use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that all these port scans that people do will reach all IPv4 addresses in your network. Since you know this is going to happen, you cannot use any radio link in a non-ham band, as it is guaranteed that these stations will transmit a message over an amateur radio band that is not from a licensed user. Even with a stateful firewall that only allows outgoing connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a non-radio-amateur and you will be transmitting them over a band illegally. > > They *might* qualify as valid third party traffic. Someone sending an > to a loved one, for example when only ham radio links are available. You > can not know. The operator of the radio must make that decision. > > The control knob for such things is called an access control list. Thats > a different concept than that of a route. Yes, and that’s exactly the problem! The control plane that BGP sees is different than the data plane where the ACL drops the packets at. People using BGP see a valid path, but then without telling anyone the operator(s) of the link drop the packets. There’s no way for BGP to convey what firewall rules each link has attached to it and then take it into account during path selection based on packet values. And there’s probably a good reason for that, as you can’t accelerate any of that on hardware I imagine. >> If this law applies to you, then you cannot use the ham bands to “communicate with the open Internet”. >> I think that we both agree on that. > I can not use an amateur radio link as part of that communication. I can > still identify as a ham radio operator. Yes, I agree. >> Now moving to the case of “communicating through the Internet”. Let’s examine that. >> >> If the network does not appear via BGP on the Internet, then everyone has to set up tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem I described earlier (and any other similar case) won’t happen. The only routers and equipment that participates in this network is (or must be) owned and operated legally by hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is almost guaranteed to not break the law or at least it is much much much much much much more certain that such a system would not break the law than talking transparently “through the Internet”. > > You can easily build such infrastructure. In fact it has been done that > way for all the 25+ years I am in this game. Yes, this can easily be built. But isn’t building it easier if we guarantee that 44.128/10 does not appear on the Internet and should only be routed either on top of the Internet (tunnels, VPNs, …) or other means (radio) ? >> There are a lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly more. But I think this is a testament that the current network is not easy to use: you may have 20 users, but a single person was managing it and has to renumber everyone. If anyone participating was an expect, they would simply have to renumber their own hosts, that would be less than 200 for a typical setup. > > I do not follow this logic. > Your statement that one person renumbering 200 hosts is more work than > 20 persons renumbering 10 each. That is certainly not true, in fact it > is the opposite, youd have to coordinate those 200 people, and you would > have to assume these 200 people are fully competent -- that is the > opposite of your assumption in the first place... What I’m trying to say is that if every user of the network was competent and could easily do such changes (like many people have claimed in this thread), then we wouldn’t have cases where a single person is managing the network of 20 others. Everyone would probably manage their own network. So it’s a point to make towards the fact that not even the existing users are or want to be involved in all this routing. >> And the current users force their world view upon future users and also a large part of this network. I don’t think that it’s about who wins and who gets forced to submission. The TAC tries to create space for both use cases so we all win, and we are all happy. Like any rule in any civilized society, some people will have to make some sacrifices to co-exist. They will have to understand why they need to do this, and then they will have to give the others space to grow and have fun as well. > > Yes, and their demonstrated contributions over decades give them the > right to do that. And no, this is not a win-win solution. Youre taking > some peoples toys away and force them to expend work. . > If people voluntarily *agree* to move and make this sacrifice, that is > one thing. But this appears not to be the case here. We don’t really know to be honest as only a few people have participated in this conversation out of the thousands that use the network. So our margin of error here is 99% ;) We’re also not taking away anyone’s toys, if anything, we give them more. I respect the people that have been doing this for decades, but I also understand that we need to leave a lot of room for people that do this one decade, or 5 years, or 1 year, or 0 to grow as well and do what they want to achieve. Just because some people started this 25 years does not mean that this thing we have shouldn’t evolve to allow for more and more users to participate. >> I am aware that the bands are different for different regions of the world, but I do not want to make the example complicated. I thought that it was enough for people to understand my point, even if it’s region-specific, and that you can easily replace those numbers with your local ones. I did not see a benefit in being extremely precise in something that is not related to the point I try to make when the audience can probably understand it. >> >> If you did not get my point because of the fact that two digits are off, then I can rephrase the sentence with these digits as they stand around the world. > Now if you changed those digits, we would now have a transceiver > transmitting on 146..148 in Region 1, which in some jurisdictions can be > illegal. >>> Secondly, why would I not be allowed to listen to that amateur radio >>> repeater using my commercial all-band radio receiver? >> >> First of all, it may be illegal in some areas of the world, e.g. I think the U.K. or Greece. But I think that’s not your point ;) > > I am not sure about that, but see, thats the thing. The decision of this > being illegal can not be made globally (and your intranet is consisting > of the current allocations for allmost all of the world) but it needs to > be made on a local / country basis, as it has been in the past. There are certainly arguments for and against country-based vs use-case-based allocations. I feel like if we do country-based allocations, as is evident from my e-mail above, we will have a lot of trouble finding a way to represent the ACLs of each link on BGP (or any other mechanism that can reconfigure all network routers). If this is not possible, then we’ll need to have people maintain complex routing tables to go around entire countries (if they even can) just to be able to deliver some traffic, because the BGP Best Path drops it. If we go with a system based on use case, then this is not needed, as people can easily hardcode the two network policies that exist and easily route any way they want based on them. This list of links is easy to aggregate: any link in 44.128/10 has policy X, and each link in 44.0/9 has policy(ies?) Y. Antonis

3 years, 9 months

4
3
0 0

Future of AMPRNet Should NOT BE AMPRNet

by Jason McCormick

This is not a direct reaction to the TAC proposal, but something that's been on my mind in watching the discussion about the TAC proposal unfold on the 44Net mailing list - specifically around what the "goals" should be of... AMPRNet... ARDC... something else? This community needs to be looking to the future and not the past. The 44Net AMPR "network" is part of the past. It's a key resource, and currently, an exceptionally valuable one based on the current market for large contiguous IPv4 address blocks. Personally, I think selling off part of that IP range was a great move to fund the future. But I think that the future needs to be talked about beyond a reallocating of existing 44Net space and/or how people interact with it (e.g. the apparently now-defunct 44NGN project). The future of Amateur Radio needs to be in modern technologies and for this community that means IPv6 networks. Specifically, the goal for the future of ARDC/AMPRNet should be that AMPRNet as it exists today is just not that important anymore 5-10 years down the road, and hopefully closer to five. IPv6 has been hyped for decades now and if you've worked in and around networking, IPv6 is "just around the corner" according to the media and industry rags. But what many don't realize is that IPv6 is already here and has been for a long time. For example, Google already sees 35% of its worldwide traffic access using IPv6. The US-based adoption rate is 48%. Japan is 42%. Germany is 52%. India is 61%. My local club sites and personal websites see on average about half of all real connections using IPv6. Mobile phone networks are almost exclusively Carrier Grade NAT for legacy IPv4 + global IPv6 with the IPv6 traffic preferred. I'm sure the other large providers such as Microsoft would see something similar if they published such statistics. Major ISPs here in the US have handed out /64 and /56 IPv6 address blocks to properly configured/enabled equipment by default for at least five years. My point here is that while many pundits keep talking about an IPv6 "cliff event", the adoption of IPv6 was only going to be an over-time uptake and it's been going on in the background for years. IPv6 is very much here, has been for awhile now, and is of paramount importance to emerging countries in regions like APNIC and AFRINIC that don't have massive holdings of legacy IPv4 space like ARIN and RIPE regions do. ADRC/AMPRNet should be working with and encouraging the amateur radio community to make progress on tools and technologies that render IPv4, and notably the 44.0.0.0/8(ish) allocation, obsolete. Some areas that cry out for an active community leader include: 1. Make useful, educational information available accessible to the amateur operator that helps them understand what IPv6 is, how to use it with their ISP where available, how it's 90% the same as IPv4, benefits of IPv6, etc. I don't think this all needs to be net new material. Perhaps a curation effort with some original content that fills in the gaps important to radio users. 1. Work with hams and the major projects to enable IPv6 natively for common application such as digital voice (D-STAR, YSF, DMR, etc.), Pi-STAR, Allstar Link, IRLP, APRS, etc. This would include providing some funding, maybe in a Google "Summer of Code"-style project, and some expertise. Our area WAN network currently using 44Net space has been dual-stack IPv6 for years. However while our core non-radio systems could all be 100% IPv6, basically nothing about any of the amateur radio stuff we operate even knows what IPv6 is let alone has a prayer of working on it. There's a lot of great stuff out there that was written by someone who wanted to scratch an itch. All that software is great and serves the need, but it requires help and resources to move forward. 1. ARDC/AMPRNet should consider the merits of either outright becoming an LIR[2] and issuing global IPv6 space OR, at minimum, create a formalized "non-collisions registry" of the IPv6 ULA fc00::/7 space[3]. As part of the latter option, it should also define a set of rules for Global/ULA interoperability for "ham purposes" when operators may want their own global IPv6 space to interact with some common/shared ULA space. 1. Work with countries/regions/communities on their radio-based networks. Encourage and support the adoption of IPv6 addressing across these networks including making equipment recommendations, sample configurations, case studies, etc. 1. Help hams understand different protocols that are essential to operation of IPv6 networks. This includes things like SLAAC, DHCPv6, Route Advertisements, Neighbor Discovery, and basic dynamic routing protocols (static routes are wholly impractical in IPv6 networks). 1. ARDC should consider standardized IPv6 capability an essential component of any grant of funds for a project when a project has a networking component. None of the above is exhaustive, nor any sort of immediately workable plan. But all of this discussion on the re-re-allocation of the 44Net space has had me thinking today about what goals of this community should be and it struck me that we're all talking about a technology from the 1970s that most of the world is actively trying to replace or, at least, deprioritize. Heading outside now to dig out a bunker.... Jason N8EI [1] https://www.google.com/intl/en/ipv6/statistics.html [2] https://en.wikipedia.org/wiki/Regional_Internet_registry#Local_Internet_reg… [3] https://en.wikipedia.org/wiki/Unique_local_address

3 years, 9 months

5
4
0 0

Re: [44net] A new era of IPv4 Allocations

by Antonios Chariton (daknob)

Apologies, I sent this only to Mario and not the list. Here it is! > On 30 Jul 2021, at 14:08, Mario Lorenz <ml(a)vdazone.org> wrote: > > Dear Antonios, > > Am 30. Jul 2021, um 03:18:53 schrieb Antonios Chariton (daknob) via 44Net: >> Hello Mario, please find my answers below: > > Thank you very much for those insights. Although the image this paints > is very bleak indeed. > >> We do not want to limit the hardware, but we would like to have an IP version of the frequency plan: 44.128/10, however you connect to it, is the radio amateur band, and 44.0/10 is the commercial 5G band or the ISM band of WiFi. One is for people that are licensed, and the other is simply the Internet that anyone can use. > > Thats unbelivable, I can but hope that something is lost in translation. > Let me rephrase that: > The proposal is nothing short of ripping out 44.0/10 from the diverse > cloud of radio amateurs that AMPRnet stands for, and making it part of > the regular internet, available to anyone without a license and removing > traffic exchange with the remainder (44.128) of the AMPRnet. This > proposal is, in your spectrum analogy, taking away valuable ham radio > spectrum and dedicating it to general internet usage. That’s what people want to do though. They want to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In the IP world, the src and dst can be different. People want to use an amateur radio resource to talk to a commercial resource, and a commercial resource to talk to a ham radio resource. These two networks can interconnect. EchoLink now bridges the Internet with the amateur radio spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio spectrum, we use IP addresses on top of callsigns. > I call on the ARDC board to disapprove this plan. > > Then again, this is the opposite of the language in the > official proposal (last page), making me wonder whether > this is truly what the TAC actually discussed and decided. > Are there any public TAC meeting minutes or the like by chance ? We have collected minutes of meetings that we did as the TAC, and they capture a part of the total work that has been put through this. However, at this time, they are not public. Is there something specific that you’re looking for? I could help provide more information on that. The TAC discussed and proposed the PDF document you see, and more importantly the resolution at the end of it. Everything else is me trying to answer questions, provide reasoning and context, and try to address things not covered in the document. The reason we decided on me for this role (but still representing the TAC’s opinion, not giving my own) is that if we had to find a time to meet and discuss every single e-mail that we receive here and jointly write a response to that would massively increase the latency of answers you receive from minutes or hours to days or weeks. In order to make sure that I can still represent the opinion of the TAC, we discuss all e-mail asynchronously and a corrective statement needs to be issued, we will do so promptly, with a text that has been approved from all of us. So far, we are not working on any such response, and all TAC members agree with the responses provided by me. >>> The former could also be read as a policy/guarantee that no >>> non-amateur-radio based means of communication are involved. >>> Is that intended ? >> >> Yes, correct. One of the things that this proposal can bring is that a part of the network is reserved for radio amateur to radio amateur communication. >> >>> I note that you also use the term "radio-only network" on page 3. >>> Since 44.0/9 according to your proposal is not "radio-only", this >>> would mean that 44.128/12 should not be accessible from 44.0/9, which >>> is the opposite to your proposed resolution. >> >> This is actually (part of) the proposal. That we guarantee that people in 44.128/10 can only be reached by other people there, and people in 44.0/10 (technically /9) can be reached from the entire Internet, except 44.128/10 (natively). This is similar to how only radio amateurs can transmit in a ham band, but everyone can transmit to an ISM band (including hams). > > Your two statements are again contradictory. > One point of view, taken by some amateurs back in the 90s was that > the communication between two Amateurs should ONLY occur via radio > waves. In other words, a "radio only" network should, as the name > implies, not be using any other mode of communication, for example > an IP tunnel THROUGH the Internet. That is a different, much more > extreme position than defining some sort of an "Intranet" for amateur > radio usage, which could include internet links, tunneled or not, > as long as both end users are licensed amateurs. This is another > example why TAC should be very careful with wordings, and maybe provide > stringent definitions of some key terms. We only want to preserve some IP space that can be used for ham-to-ham communication. How they communicate is up to them. If they want to use radio-only, they can get an allocation off this space and build a radio-only network. If they want to communicate with carrier pigeons only, they can get an allocation and build a carrier-pigeon-only network. If they are okay with using tunnels *through* the Internet, then they can do that. We just want to make sure that we have some space reserved for this type of communication. Going back to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of the space is for ham-to-ham, and the rest is for ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can reach you. >>> b) Which route do I need to put into my router to address the radio >>> network ? In particular, how can you answer this question without >>> considering the specifics of each individual case ? Why would there >>> be only one route? >> >> You can address the “radio network” with a single route: 44.128/10. This proposal guarantees that everyone there will be on the radio-only network, the same way transmitting to 144-146 MHz in the EU is to reach hams only. Any traffic you receive is (should be) from a ham, and you should only send anything if you are a ham, and you intend to reach other hams. Transmitting to 2.4 GHz in the ISM band allows you to talk to more people (anyone), but also anyone can talk to you. > > That is simply not true, since there is no homogenous radio network. This is partly true: there is not a “single 44.128/10” but anyone can create their own network within this space. However, if some of these networks don’t want to talk to everything else, then this is working as intended, and they are by design not reachable. We hope that most of the networks there would want to be interconnected and they can do so through radio links, VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of the many methods people could use to make sure that these networks talk to each other. The only exception that would make the single static route argument not true is that if a single user wants to participate in more than one of those networks, and none of them, by design and choice, want to be interconnected with anything else. In this extreme case this person would need to use one static route per such network. This is still far less and changes much less frequently than if it’s a free-for-all where everyone can do whatever they want in any part of the IPv4 space. >>> c) Can you back up the "originally intended" >>> claim somehow ? I note that net-44 originated in the USA, which >>> historically has rather liberal third-party traffic rules compared >>> to other countries, >> >> We probably have a lot of people in this mailing list that were even a part of this and can speak up, but this happened before the Internet was (broadly) adopted and the 44/8 was a way for this “Internet” project some people were working on to talk to this network of these “radio amateurs” that they set up in the USA or Europe, etc. > > You (the TAC), made the claim and used it as a foundation > of your proposal. It is your onus to prove it or at least to plausibly > support it. I thought that people that actually set it up themselves would speak up, instead of me, where I just got to read and hear about it, but if nobody did it, I will come back to you with a proper statement. I just felt that it would be better to hear this from the people that were there for it. >>> d) You propose a policy of not announcing the prefix on the internet. >>> "the prefix" is presumably 44.128/10. Do I have to understand this as >>> going back to pre-2012 (no direct BGP) or pre, uh, 1990 (someone >>> remind me please when mirrorshades started providing encap tunnels and >>> announcing 44/8). >> >> Yes, correct. This proposal wants 44.128/10 to not have any direct BGP allocations that appear on the Internet. Connectivity of these networks should happen between themselves (network to network VPN, radio links, …), the ARDC (or anyone else’s) PoPs, etc. and they will not communicate through the open Internet. > > Sigh. This was not a yes/no question, but rather a question how far you > want to turn back the wheels of time for 44.128. Pre-2012, individual > networks did not have direct BGP announcements, but had connectivity > (or lets say the option to connect) through mirrorshades(.ucsd.edu) > which announced 44/8. I can bear witness that this worked that way at > least from 1995, but likely much longer. > > Radio network access has at all times been set according to the > gateway's jurisdiction and ham radio regulations, namely > third party traffic. In most of Europe, any non-44 IP frame over an > amateur radio link was (and likely still is) illegal. Not so in > the US under third party traffic rules, albeit the situation has > become considerably murkier with the advent of encryption (HTTPS, SSH). > > Again, please observe the careful distinction of "communicating > with the open internet" vs. "communicating through the internet" This is an important distinction and something we still allow: the ONLY thing we say is that 44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means that no part of this space may appear on the Internet. Of course, the exception here is that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent to it. It will be dropped at the edge and not forwarded anywhere. With this definition you can then create any type of construct you want on top of that. We only want to provide this guarantee to you. Depending on local or national or international laws you may have to do different things, but we only want to provide this very simple guarantee. Nothing more, nothing else. If it’s illegal to use 44.128/10 in some countries based on this guarantee, then you can always use 44.0/10. If it’s illegal for a country to use 44.0/10 and can only use 44.128/10, then they have to move to this part by law. >>> e) Is there a rationale why existing regional networks cannot decide >>> themselves what level of internet connectivity they desire, >>> considering e.g. the local ham radio regulations >>> and keeping their numbering and infrastructure which have been >>> assigned to them long before ARDC existed as an entity. Is there >>> a particular reason for not grandfathering them ? >> >> Unfortunately this would be difficult to accommodate as the guarantees cannot be offered then. If radio amateurs don’t have a dedicated band to talk to each other, and they have to use the ISM bands, there’s no way to distinguish between normal people and licensed hams. You can’t tell and there’s no guarantee that the person you’re speaking with is a ham or anyone else. > > You *never* can be certain. How many QSOs have you made where you > asked first for a copy of your partners license to be faxed ? > The problem is the problem of those allowing the traffic to cross > to a radio operated under amateur radio regulations, i.e. the operators > of that radio. Pre-2019, most of them would in the past have accepted > access to a sufficiently routed 44/8 IP as sufficient authentication, > although of course it is not perfect. Others required authentication > though a login on the gateway. We can’t be certain, I agree with what you say. What we can do is make it much better than it is right now. We think that even if we can’t provide a perfect solution, we should still make steps to improve the situation. If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach you. If you are connected to the Internet, and you advertise your space with BGP, it is in fact *guaranteed* for non-ham traffic to reach you. You could argue that you could deploy ACLs or Firewalls, or any measure like that, and this would help you only accept 44/8 traffic. But this is still worse: packets on the Internet today can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a commercial ISP, and it would get through your firewall and possibly over your RF links just fine. Moreover, if two 44/8 networks connect with intermediate hops over the Internet, e.g.: 1. 44.1.2.3 2. 44.3.2.1 3. 192.0.2.15 4. 193.5.16.50 5. 44.4.6.7 6. 44.7.6.5 (Which I assume is what you want to do if you want to be on the Internet BGP and block all incoming traffic from non-44/8 hosts) Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a transmission in a ham band of packets that are not from a ham. This is much more common than you can imagine, and not always done maliciously. If I am node #1 and I do a traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a packet that was not generated by a radio amateur (it’s a non-manned station / router of Cogent / Telia / Hurricane Electric, …) over a ham band. If you have the knowledge that any host you traceroute within 44.128/10 is (to the best of your knowledge and ability to tell) a radio amateur, and that these packets will not travel raw over the Internet, and no packets from the Internet can be introduced into this connection (because it’s inside a VPN for example), then you can be sure that running the traceroute command will not cause a number of people to break the law along the way. Now for the use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that all these port scans that people do will reach all IPv4 addresses in your network. Since you know this is going to happen, you cannot use any radio link in a non-ham band, as it is guaranteed that these stations will transmit a message over an amateur radio band that is not from a licensed user. Even with a stateful firewall that only allows outgoing connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a non-radio-amateur and you will be transmitting them over a band illegally. If this law applies to you, then you cannot use the ham bands to “communicate with the open Internet”. I think that we both agree on that. Now moving to the case of “communicating through the Internet”. Let’s examine that. If the network does not appear via BGP on the Internet, then everyone has to set up tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem I described earlier (and any other similar case) won’t happen. The only routers and equipment that participates in this network is (or must be) owned and operated legally by hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is almost guaranteed to not break the law or at least it is much much much much much much more certain that such a system would not break the law than talking transparently “through the Internet”. >> Similarly to the RF world, in IP there’s this kind of problem as well. If you have IP addresses on the Internet, you could receive traffic from anyone. Sure, you can use an ACL or a firewall, but that’s not guaranteed. Packets could be spoofed for example. If you have a special network where you know that all senders and recipients are hams, then you can build things with different assumptions. You can build internal tools or apps, websites, etc. It’s up to you. It’s a band where you will only find people of the same hobby as you, that are licensed. > > This used to be the description of 44/8 (now, sans the AMAZN part). To > my knowledge, this never changed (see ARDC's AUP). If it did, I would > support a reversion of that change. > >> The other part is like an ISM band. Sure, you can use this to talk to other hams, and you can use it to talk to non-hams, and non-hams can use it to talk to you, and you have to establish by your own means who is who, and ensure that they can’t trick you. >> >> What our proposal aims to do is to create a separate “Ham Band” / Intranet / 44.128/10 and a separate "ISM band” / Internet / 44.0/9. By using simple RF or IP you can’t have them collocated into the same space. >> >> This is the reason why we cannot have scattered space and we want to have it aggregated and easy to address. Instead of our “band plan” being hundreds of lines and have it change daily, and move band from “ISM” to “Amateur Radio” and vice versa, we want to create a very simple band plan of 2 entries that don’t change. One is, and will remain to be “ISM” (44.0/9) and one is, and will remain to be “Radio Amateur” (44.128/10). >> >> Having a more stable and simple band plan is easier for everyone. They can make more informed decisions for the future, they can choose who they want to talk to, and they can even decide to use both bands: use a handheld radio (Radio Amateur) and a phone with WiFi (ISM). This is what we try to do on a technical level. Clearly define the two bands, and make sure that they are very few, and very stable. > > People *DID* that, based on the current policy that each subnet can > decide if it wants internet connectivity. This was the policy that > governed AMPRNet for at least since the mid-nineties. > People built their network around that policy (and the legal > requirements). Later they *DID* opt for BGP or not. > > It is the TAC with this proposal that is flipping over the apple-cart. > For such a proposal, in addition to the potential benefits that such > a plan may bring, TAC MUST also address the cost epecially the work you force > uppon the affected users. I agree that we must address this work, and it could be a lot of it. Unfortunately the best the TAC can do is to include these resolutions for the board to vote on (give enough help, time, …). Anything else will have to come from the Board as we do not have any authority to help in any other way. There are a lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly more. But I think this is a testament that the current network is not easy to use: you may have 20 users, but a single person was managing it and has to renumber everyone. If anyone participating was an expect, they would simply have to renumber their own hosts, that would be less than 200 for a typical setup. >> In the IP world this translates to easier routing (each “band plan” entry is a route, and if it’s just one, it could even be a static one), and less frequent changes. I don’t have to consult today’s band plan to know why 44.5.5.5 does not respond from 44.128.128.128, if the reason is that 44.5.5.5 decided to be Internet-only today or Intranet-only tomorrow. >> >> We could have made use of complex routing protocols and policies that would dynamically try to discover what each address or subnet is (because it’s not always clear and we can’t always tell what each address wants to do, even if we forced everyone to connect to an ARDC PoP) and then continually adjust this and maintain a complex state. This is something that a lot of people would also have to do, or they would have to find someone to do it for them (e.g. the ARDC PoPs). Going towards our value of being as inclusive as possible, we did not want to force people that don’t want to to have to do this or to have to connect via an entity that can do this. By having a 2-line band plan that doesn’t change over time people can even hard-code it if they don’t want to deal with all of this complexity or necessarily rely on someone to do it for them and then form a dependency to them. > > You are forcing your world-view uppon all existing users of 44.128/0 > and require those that disagree to leave and expend effort to renumber. > I do not think that "inclusive" is quite the correct word for that. And the current users force their world view upon future users and also a large part of this network. I don’t think that it’s about who wins and who gets forced to submission. The TAC tries to create space for both use cases so we all win, and we are all happy. Like any rule in any civilized society, some people will have to make some sacrifices to co-exist. They will have to understand why they need to do this, and then they will have to give the others space to grow and have fun as well. Under no circumstances do we want a minority of very vocal people that shout to bend the majority to their will, simply because they can’t shout loud enough. And it seems that this happens frequently on the modern world. We have to understand that by forcing people to do anything, we only drive them away. I would consider it a failure if people gave up on a project or hobby or resource just because the environment there does allow room for them to grow, and I did not do my best to speak up for them. We have to understand that not everyone can shout. We are all different, and we all want different things, and we all have different needs. Some people are too shy to shout. Some people have weak vocal cords. Some people don’t speak the language we shout in. If we let these people be ignored, and we only do what these few vocal people say, then we will create something that is only inclusive and welcome to people that can and want to shout. This almost certainly guarantees a toxic environment that people will slowly start to abandon and leave it be, simply because it’s not what they want to do. If someone creates their own “People that shout” club, then that’s fine. They can all gather every week and shout to each other. I personally don’t want to join this club, I find no value in it. But we should collectively never allow these people to take over a public resource for all of us, that can benefit all of us, as this is dangerous. Just because they have the privilege to shout does not mean that other voices should not be heard. And not only that, but we should make all these decisions proportionately. Because this is a common resource, for all of us. Not only for some of us. Speaking personally, I will continue to be an ally and use my privilege of being able to shout to defend all these users and protect them and make sure that their voices are heard. > There are people that are fine with having the world communicate with > their 44. IPs. Nothing in your ham radio license forbids you talking > to other people, as long as you dont do it over a (amateur-) radio. > You proudly wear baseball caps with your callsign on it. Why can't > you wear your 44 IP? We want people to use their 44 IPs on the Internet! We are happy to see them do it, and we are really looking forward to all the nice things they can achieve by doing so. We just want to make sure that they’re not the only ones, and we leave some room for people that like something different. The current proposal gives enough space for now and in the future for people to do any of the two, or both things, as they wish. It’s about choice. > That said, removing the currently existing option to connect to the > internet by central gateway or direct BGP is a major, destructive > change of current policy. Sometimes, such destruction is requisite for > progress. It is the duty of the TAC to review such a change. > Such a review must be balanced, and necessarily must include a detailed > discussion of opposing views, a discussion why there is no > simple technical solution to the problem, and a discussion of those > negatively affected by this change. This all should be documented > for the record. Meaningful review would probably have also included a > documented poll of the affected network's coordinators. First of all, we do not remove the option for Direct BGP, and we won’t force anyone to use ARDC’s PoPs. That’s our goal. We reserve just as much space for Direct BGP as we reserve for non-Internet communication. Each user can decide which part of the network they want to be in, and they also have the option of picking both. Destruction is indeed sometimes necessary, but of course I think that we all agree that we should try to limit it. We don’t want to destroy anything. We just want to make a change over the next year so that it’s easier for everyone to move on in the future. We want to look at the long-term benefit of the network over the short-term trouble of renumbering a part of it. We are interested in the opposing views, the voices of the people that want to renumber, and we want to hear from all of you. This is why we started this thread a few days ago so we can get to hear all of you, and discuss with you. The PDF does not include a proposal that is final and that we have sent to the Board for a vote. It only includes *what we want to propose* and why we arrived at it after 4 months of work. If we get a good recommendation and we see the value in that, we would be happy to change it. It has not reached the Board and the Board is not going to vote on it if we don’t tell them we want them to. > At this time, I therefore believe the current TAC's proposal is > deficient and thus should be rejected (albeit without prejudice) As I said earlier, there’s nothing yet to reject. There’s no official motion made to the Board, and we will only send one after we get to hear you. >> Furthering the analogy, a handheld VHF manufacturer relies on a constant band plan to allow TX to 144-146 MHz and doesn’t have to build a system for their product to download this hour’s or this day’s Amateur Radio allocation and change the functionality based on that. You can also be sure that your local amateur radio repeater won’t be today at 89.7 MHz and your favorite radio station won’t transmit to 145.500 MHz this afternoon. > > This analogy is not suitable. For starters, the 2m band extends up > to 148 MHz in IARU Regions 2 and 3, which should give you pause to > consider the difference of what you are used to, what is legal in your > country, and what may be so in the rest of the world. I am aware that the bands are different for different regions of the world, but I do not want to make the example complicated. I thought that it was enough for people to understand my point, even if it’s region-specific, and that you can easily replace those numbers with your local ones. I did not see a benefit in being extremely precise in something that is not related to the point I try to make when the audience can probably understand it. If you did not get my point because of the fact that two digits are off, then I can rephrase the sentence with these digits as they stand around the world. > Secondly, why would I not be allowed to listen to that amateur radio > repeater using my commercial all-band radio receiver? First of all, it may be illegal in some areas of the world, e.g. I think the U.K. or Greece. But I think that’s not your point ;) If your radio supports both bands and you’re licensed for both, then you can talk to both using the same radio. If you’re not licensed for one of them, but a friend is, and you want to talk over it, you can set up a cross-band repeater (netmap, …) to allow you to do this. Antonis

3 years, 9 months

3
2
0 0

Re: [44net] A new era of IPv4 Allocations

by Antonios Chariton (daknob)

Hello Ruben, please find my answers below: > On 30 Jul 2021, at 14:46, Ruben ON3RVH <on3rvh(a)on3rvh.be> wrote: > > If we currently use 1% as you say (which I do not believe, but that's another discussion. One that I'm not going to have), what will change after the renumbering? Nothing. We would still use 1%. Yes, we will still use 1%. But if we exclude half of our users, then we’ll use 0.5%, which is much less (about half!). We can’t force people to use the space, we just try to help them use it for what they want to. Hopefully, if we do that, we can grow to 2%! > The other 99% would sit idly unused but reserved for an intranet that 90% of the hams don't use. I do not believe that, but that’s another discussion: one I’m not going to have ;) On a serious note, right now, today, Friday, we have more users that are on the Intranet and want to remain there than the rest of the network. Germany has most of the users of 44/8 and they all seem to want to join this Intranet. If anything, the people that want to use BGP are the minority. Yet we still want to serve them, as they should too be able to what they want with the IP addresses. > We currently only use 1% because the current IPIP mesh and current way of internet connectivity from the 44 space is a big mess. IPIP just does not work and is not scalable anymore, you have to be a network savage to know how to set up and use the IPIP mesh. > That part is the job of the TAC to facilitate. Making sure that every ham can use 44 space, can set it up, can use it and can be reachable from the internet (or not) as he/she wants to be. Yes, the IPIP Mesh (and setting up BGP) are not easy, and I definitely believe that we will see more use if we make it simpler. And this is what the PoP will try to address. We’re working on it, just as we work on this policy. In this proposal we reserve enough space for both use cases. If any of them reaches 100% (44.0/10 or 44.128/10), then we will proceed to give out space from 44.64/10. Until one of them is close to that, we do not consider resource exhaustion a problem. > You say that you want to make it easier for ppl to connect to 44 net, but you're making it harder. If one wants to be part of global 44 net AND the "intranet", they have to have 2 subnets, have to have a router capable of handling policy based routing, have to be able to configure PBR, etc etc.. > This is not something an average ham can be asked to do, not without major problems and issues. No ISP owned router is possible of PBR, at least not in a way that the user can configure it. > So effectively the TAC is shunning hams away from the intranet resources unless they know what they're doing. This is not technically accurate. A user that wants to be on both networks can add a static route to 44.128/10 and then connect to 44.0/9 through their ISP, over the normal Internet. If they want to use a 44-address to reach BGP hosts then they can add another static route to 44.0/9 to a service that can connect them, such as the ARDC PoPs. Then this service can statelessly and effortlessly netmap their 128 space to 0. Alternatively, this user can make use of ARDC’s (or anyone else’s) VPN profiles to receive a dynamic IP within both networks (by making two VPN connections) and then depending on the destination their computer or phone will automatically choose the correct IP. They don’t even need any allocation, or any set up. Just two VPN profiles on their phone, and they can reach anything and everything without any problems. This works because OpenVPN or Wireguard or […] can only route specific networks over the connection by sending a route to the user. > Also, taking into account that the 44.128/10 network is the most widely used, used by repeaters that cannot use dns or dynamic ip updates of it's peers, the disruption would be massive. How can any TAC support such a disruptive method. This proposal does not make any changes to the technical means a site is connected with. We leave this up to the user. All these operators of repeaters can still connect to the Internet using NAT, netmap, IPv6, or any other way the operators want to! > It is true that most of the Belgian ip 44 space is unused. I was waiting to build that out since there was a discussion that the TAC would create a draft on how to provision and route and interconnect networks, but now that I am reading the proposal over and over again, I just cannot believe that the TAC wants to destroy what we all hold precious. You can clearly read from the list that no one is happy about the changes, everyone questions it and does not see any added benefit in the current proposal. Hams disagree, networking hams that do this for a living (including myself) disagree, .. I really don't see how any network engineer can support such a disruptive and inadequate and besides the point design. First of all I think that you are being excessive. We are not destroying anything and we do not want to cause any harm to anyone. We are also hams and networking hams. If you are just building your network, you can decide on which part you prefer to be, and receive an allocation there. You are not affected by any renumbering. As I said in an e-mail to Mario a bit before, we don’t think that the only people that use the network are the ones on the mailing list. We also don’t expect every network user to be on the list. And finally, by definition the people that are against something will speak up much more than the people in favor. So I don’t think what you say about most people disagreeing is true. The current TAC supports this design because we want to set the policy, and not impose any technical changes to anyone. THIS IS NOT A TECHNICAL PROBLEM WE ARE TRYING TO SOLVE! That said, it’s unlikely that this can be solved with a technical solution. It’s a people problem. We need to make room for more people and make it AS EASY AS POSSIBLE for them to do WHAT THEY WANT, and HOWEVER they want to do this, ANYWHERE where they want to do this. Forcing people to do anything of technical nature goes against that. A lot of times technical people think they can solve every problem there is out there with a technical solution. This couldn’t be farther than the truth. We can easily get dragged into designing the perfect network with 200 PoPs and 50 VPN technologies, and we go over the fact that some problems are simply community issues, people issues, etc. I doubt that anyone can come up with a technical PoP infrastructure that addresses every possible need and use case that people might want to do. So instead of trying to have a solution that does it all or that it forces people to follow a certain path, we just opted for a solution that guarantees two things, and from that point on anyone can build anything they want on top of them. Try to imagine this solution in a world where the ARDC PoP system will never arrive. We will never deliver, or we will and then we will turn it down 6 months later. Do not rely on some Holy PoPs, Masters of Everything that are supposed to coordinate everything in a centralized fashion. Try to have a more distributed and mesh system in mind where everyone can connect to everyone else and exchange packets without any central authority to tell you what to do and when to do it and how to do it. > Please create a public poll on the matter of the intranet and disruptive way of carving the 44 network out, with a clear description of the intranet will be, will hold and what services will be hosted on the intranet and it's value. > I am looking forward to those poll numbers. I can be mistaken, but imo the results will not be in favor of the proposal. We do not know or care about what the Intranet will have. We do not know or care about what the Internet will have. We have no control over any of that, and this is up to the users. The Intranet will have whatever you set up for it to have, and the Internet will have whatever you set up for it have. We just have a lot of people that tell us that they want this, and if they say so, we are trying to give them what they want. We also have a lot of people that tell us they want free IPv4, and since they so, we are trying to give them what they want as well. Just become I belong to the second category doesn’t mean I should prevent the people in the first from having what they want. How would you feel if we had a poll on “which use case do you want for 44/8” and people voted “Intranet”? Would you like it for us to make the entire space Intranet and prevent all BGP advertisements and revoke all LOAs? Would you like 44/8 to disappear from the Internet, and ARDC to tell people who want free IPv4 to go and buy it? If you don’t like this thing, why force other people to do it the same way you are? Because if we have a poll, there is a real chance that people will vote Intranet only. Does that mean that the ARDC should take all your space? We believe that every person should have their space to do whatever they like. Intranet people should have their space, Internet people should have their space, and if a new use case exists in the future, we also want to be able to give these people their space as well. It’s a huge space and we can all fit inside and play nicely without being limited by others. > Please don't take my mails the wrong way. I appreciate the time the TAC is giving to this matter and the time everyone puts into it. I am just one voice amidst several that disagrees with the current proposal and the matters that the TAC sees as a priority (carving up the IP space to create an intranet versus creating more POPS, interconnect points and a global backbone. The issues for which that the TAC was created in the first place). It’s okay! As long as we stay calm and civil here it should all be fine :) We are always interested in hearing more opinions. We now have the problem of “we’ve been discussing this for 5 months, and we have everything thought of and in our head, and we just have to present it to the people”. Of course, there’s always the chance we missed something, and that’s why we want to have this public discussion. It’s just that a lot of points that are brought up were also brought up internally. I myself even asked if using public IP space for an Intranet is a good idea. I also did not like it the first time I heard of it. But I always tried to keep an open mind, look at the problem, and then evaluate this possibility. And the more I thought about it, the more it made sense and seemed as the only way to guarantee users of both networks a global uniqueness. But that wasn’t enough. We then studied how people currently use the space, how much we have, how many new allocation requests we get daily, etc. This gave us another piece of data: we have enough addresses. We then kept looking for other solutions, and by the time we had to decide, we looked at many things, we thought of many ways, and we had to combine it all and arrive at a final choice. This wasn’t easy. We had to make tradeoffs and we had to make some users unhappy. I wish we could avoid it, but any choice we made would lead to some people being unhappy. We could only try to minimize this amount of people, and even then try to give them as much support as we can to ease the pain. We understand that a /10 is very expensive, we’ve looked at the market price, we compared the price per IP depending on size (to see how much more a /10 is worth over 64 * /16 for example). Eventually we decided that we prefer to use more IPv4 addresses instead of making more actual humans unhappy. A lot of people may disagree with this decision, and they would prefer to see more unhappy people than IPv4 being used like that. That’s also fine, and we accept that. Our goal here is not to convince people. We’re just trying to help you understand why we made *this* decision and not the *other*, and why we stand by it. But we always do this with an open mind, and without looking at our personal interest. We are open to the fact that we could have missed something entirely. It may appear as we have already set our mind, but I can assure that we’re willing to reevaluate at any time. It’s just that we’ve been through most of these arguments internally and we thought about it, and we already have an answer that is good enough for us. Finally, the TAC is working on many other things as well, including PoPs, IPv6, RPKI, etc. but this just happened to be the first one that came out of the pipeline. We have done work in parallel, and it will slowly start to get to this mailing list for your feedback. Please also keep in mind that the TAC has no budget or staff assigned to it, which means that we can’t approve expenses, anything we do has to be approved by the Board (and ARDC Staff). We also have no staff allocation to us to work on things. We have an advisory role where we tell ARDC how we think they should build a PoP system (and that they should) and then it’s up to ARDC to build and maintain this. It’s not us that will be writing the code or administering it. We can experiment on our own time and come up with some advice (e.g. PPTP did not work, use L2TP), but eventually it is ARDC and its staff and contractors that will deliver the final product. Antonis

3 years, 9 months

1
0
0 0

Re: [44net] A new era of IPv4 Allocations

by Lucas Speckbacher OE2LSP

Hello all together, Here in Austria we use our 44.143/16 net purely for Hamnet/Intranet purpose. Most users are not on this mailing list and simple use the network. Most of the network is radio based with a few interlinks tunneled trough the internet https://hamnetdb.net/map.cgi#zoom=8&lat=47.811&lon=13.37&layer=Mapnik&overl… The nodes are using BGP routing as most of Hamnet in Europe, most users are only connecting to the Network and don't have to care about BGP. The question I'm getting over and over again is, which Subnets should be routed to Hamnet to reach most of it and at the same time not blocking the Internet routed subnets. So this clear separation would clearly help us as well. Finally, those OMs who have Internet routed Subnets (outside 44.143) would have to move, but its clearly worth the effort. Some of us are in training as we had to move allot of infrastructure after the subnet was sold. 73 Lucas OE2LSP/KC1GDN

3 years, 9 months

9
10
0 0

Fwd: A new era of IPv4 Allocations

by Antonios Chariton (daknob)

This was accidentally only sent to Ruben. > Begin forwarded message: > > From: "Antonios Chariton (daknob)" <daknob(a)daknob.net> > Subject: Re: [44net] A new era of IPv4 Allocations > Date: 30 July 2021 at 14:18:24 CEST > To: Ruben ON3RVH <on3rvh(a)on3rvh.be> > > >> On 30 Jul 2021, at 13:36, Ruben ON3RVH <on3rvh(a)on3rvh.be> wrote: >> >> Hi Antonio, >> >> Good day. (past noon here) >> I still don't get it sorry, your analogy makes no sense either because 44.0/8 was amateur radio only and 44/9 and 44.128/10 IS still amateur radio only. >> So there is no public, there is no FM, there is no VHF/UHF... >> >> Using public address space for an intranet nobody but some germans care about makes no sense at all. > > And one can also say that using amateur radio frequencies makes no sense at all. Is that true? > > If you use 44 addresses on the Internet, then they are simply IPv4 addresses. There’s nothing special about them. It’s just that some privileged people that got a license can get free IPv4, while some other not-so-privileged people have to pay insane amounts of money to get them. Do we want ARDC to only support the use case of connecting people to the Internet and being a global ISP? > > We think that amateur radio has much more to offer than just “connect to the Internet with no NAT”. There are more use cases, and I am sad to see that people don’t want to accept this or help accommodate the people that have these use cases. Especially at a time where more than half of us belong to this category, and there’s no cost involved in doing so, nor danger of running out of IPv4 addresses. I still don’t understand why some people prefer to harm their colleagues (the majority even) by depriving them of resources, just because they don’t enjoy to do the same things as them. How would you feel if we proposed a total ban on all use of 44/8 on the Internet? No more BGP, no more LOAs, no more IPIP Mesh routing to the Internet, no PoPs. We turn all of it into an intranet. > > That would feel terrible to me if I just wanted free IPv4 and just because other (most!) people don’t want it, they decided to completely prevent this use case. > > I am telling you again: we use 1-5% of the IPv4 space. 99% of it is sitting idle, and not being used. Why do you insist on keeping such an expensive and valuable resource unused, if other people (most people?) want to use it? That sounds like a terrible decision. > > If we only used 1% of our RF spectrum, it would start to disappear and be gone very soon. Would you prefer that we lose anything above 50 MHz, just because you only like to use < 50 MHz? Why can’t we all accept that some people only like VHF, and some only like UHF, and some only like HF? Why do we only have to force people to use one band, if we have all of them available? I am really struggling to understand this logic. This is really beyond me. We prefer to have space sit there until the end of time, not used, instead of giving it to our colleagues and friends that want to use this. I am sorry if I don’t get it, but this seems crazy and insane to me. > > We are using 1% of the space, and instead of wanting to use more of it, we tell more than half our users to move away from it. Why? So we can use 0.5% of it then? How is this any good? Why would we like to use *less* space, if we are already “borderline using it”? > > I know a lot of you have networking experience and have worked in ISPs and know how valuable IPv4 is. But this is way beyond what most ISPs deal with. We have 48 *thousand* /24s! We have 192 /16’s! I’m willing to bet that we have more space than 99.99% of the ISPs out there (by definition too, since we hold 1/200th or so of the “globally unique" Internet). A commercial ISP with 5000 customers and a /24 needs to save every drop. On the other hand, we only use one drop of our ocean. > > We are privileged to have more IPs than 99.99% of everyone else right now. Why do you not like us to use it for amateur radio purposes and instead prefer to just keep it unused? What’s the point of it? > > This is like the argument that we should preserve IPv6 space and not give each LAN a /64. I think most people that claim this simply don’t understand the sheer volume of “2^64”. The human brain just isn’t good at wrapping around these types of numbers. But if you look at the mathematics behind it, then maybe you can understand this better. > > We have a car with a tank of gasoline, and we only want to use half a liter of it, and then every time we consume half a liter, we want to go back to the gas station and fill it up again. We have a range of 720km with this car, yet we only want to do 5 km at a time, and then go to the station. > >> I'm looking forward to the poll data. (although I don't get why that has to take a few days as you already have that poll data as you've taken the poll amongst the German and American hams as you say) > > The TAC has not performed a poll, but instead we talked in 1:1 sessions with users and coordinators of these networks. If you feel like we should create a poll though, I imagine we could organize it and send one. > > Antonis

3 years, 9 months

2
1
0 0

Re: [44net] A new era of IPv4 Allocations

by Antonios Chariton (daknob)

Apologies, I sent this to Ruben only, and not to the list. > On 30 Jul 2021, at 13:36, Ruben ON3RVH <on3rvh(a)on3rvh.be> wrote: > > Hi Antonio, > > Good day. (past noon here) > I still don't get it sorry, your analogy makes no sense either because 44.0/8 was amateur radio only and 44/9 and 44.128/10 IS still amateur radio only. > So there is no public, there is no FM, there is no VHF/UHF... > > Using public address space for an intranet nobody but some germans care about makes no sense at all. And one can also say that using amateur radio frequencies makes no sense at all. Is that true? If you use 44 addresses on the Internet, then they are simply IPv4 addresses. There’s nothing special about them. It’s just that some privileged people that got a license can get free IPv4, while some other not-so-privileged people have to pay insane amounts of money to get them. Do we want ARDC to only support the use case of connecting people to the Internet and being a global ISP? We think that amateur radio has much more to offer than just “connect to the Internet with no NAT”. There are more use cases, and I am sad to see that people don’t want to accept this or help accommodate the people that have these use cases. Especially at a time where more than half of us belong to this category, and there’s no cost involved in doing so, nor danger of running out of IPv4 addresses. I still don’t understand why some people prefer to harm their colleagues (the majority even) by depriving them of resources, just because they don’t enjoy to do the same things as them. How would you feel if we proposed a total ban on all use of 44/8 on the Internet? No more BGP, no more LOAs, no more IPIP Mesh routing to the Internet, no PoPs. We turn all of it into an intranet. That would feel terrible to me if I just wanted free IPv4 and just because other (most!) people don’t want it, they decided to completely prevent this use case. I am telling you again: we use 1-5% of the IPv4 space. 99% of it is sitting idle, and not being used. Why do you insist on keeping such an expensive and valuable resource unused, if other people (most people?) want to use it? That sounds like a terrible decision. If we only used 1% of our RF spectrum, it would start to disappear and be gone very soon. Would you prefer that we lose anything above 50 MHz, just because you only like to use < 50 MHz? Why can’t we all accept that some people only like VHF, and some only like UHF, and some only like HF? Why do we only have to force people to use one band, if we have all of them available? I am really struggling to understand this logic. This is really beyond me. We prefer to have space sit there until the end of time, not used, instead of giving it to our colleagues and friends that want to use this. I am sorry if I don’t get it, but this seems crazy and insane to me. We are using 1% of the space, and instead of wanting to use more of it, we tell more than half our users to move away from it. Why? So we can use 0.5% of it then? How is this any good? Why would we like to use *less* space, if we are already “borderline using it”? I know a lot of you have networking experience and have worked in ISPs and know how valuable IPv4 is. But this is way beyond what most ISPs deal with. We have 48 *thousand* /24s! We have 192 /16’s! I’m willing to bet that we have more space than 99.99% of the ISPs out there (by definition too, since we hold 1/200th or so of the “globally unique" Internet). A commercial ISP with 5000 customers and a /24 needs to save every drop. On the other hand, we only use one drop of our ocean. We are privileged to have more IPs than 99.99% of everyone else right now. Why do you not like us to use it for amateur radio purposes and instead prefer to just keep it unused? What’s the point of it? This is like the argument that we should preserve IPv6 space and not give each LAN a /64. I think most people that claim this simply don’t understand the sheer volume of “2^64”. The human brain just isn’t good at wrapping around these types of numbers. But if you look at the mathematics behind it, then maybe you can understand this better. We have a car with a tank of gasoline, and we only want to use half a liter of it, and then every time we consume half a liter, we want to go back to the gas station and fill it up again. We have a range of 720km with this car, yet we only want to do 5 km at a time, and then go to the station. > I'm looking forward to the poll data. (although I don't get why that has to take a few days as you already have that poll data as you've taken the poll amongst the German and American hams as you say) The TAC has not performed a poll, but instead we talked in 1:1 sessions with users and coordinators of these networks. If you feel like we should create a poll though, I imagine we could organize it and send one. Antonis

3 years, 9 months

1
0
0 0

Fwd: A new era of IPv4 Allocations

by Antonios Chariton (daknob)

This was accidentally only sent to Mario. > Begin forwarded message: > > From: "Antonios Chariton (daknob)" <daknob(a)daknob.net> > Subject: Re: [44net] A new era of IPv4 Allocations > Date: 30 July 2021 at 15:32:26 CEST > To: Mario Lorenz <ml(a)vdazone.org> > > > >> On 30 Jul 2021, at 14:08, Mario Lorenz <ml(a)vdazone.org> wrote: >> >> Dear Antonios, >> >> Am 30. Jul 2021, um 03:18:53 schrieb Antonios Chariton (daknob) via 44Net: >>> Hello Mario, please find my answers below: >> >> Thank you very much for those insights. Although the image this paints >> is very bleak indeed. >> >>> We do not want to limit the hardware, but we would like to have an IP version of the frequency plan: 44.128/10, however you connect to it, is the radio amateur band, and 44.0/10 is the commercial 5G band or the ISM band of WiFi. One is for people that are licensed, and the other is simply the Internet that anyone can use. >> >> Thats unbelivable, I can but hope that something is lost in translation. >> Let me rephrase that: >> The proposal is nothing short of ripping out 44.0/10 from the diverse >> cloud of radio amateurs that AMPRnet stands for, and making it part of >> the regular internet, available to anyone without a license and removing >> traffic exchange with the remainder (44.128) of the AMPRnet. This >> proposal is, in your spectrum analogy, taking away valuable ham radio >> spectrum and dedicating it to general internet usage. > > That’s what people want to do though. They want to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In the IP world, the src and dst can be different. People want to use an amateur radio resource to talk to a commercial resource, and a commercial resource to talk to a ham radio resource. > > These two networks can interconnect. EchoLink now bridges the Internet with the amateur radio spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio spectrum, we use IP addresses on top of callsigns. > >> I call on the ARDC board to disapprove this plan. >> >> Then again, this is the opposite of the language in the >> official proposal (last page), making me wonder whether >> this is truly what the TAC actually discussed and decided. >> Are there any public TAC meeting minutes or the like by chance ? > > We have collected minutes of meetings that we did as the TAC, and they capture a part of the total work that has been put through this. However, at this time, they are not public. Is there something specific that you’re looking for? I could help provide more information on that. > > The TAC discussed and proposed the PDF document you see, and more importantly the resolution at the end of it. Everything else is me trying to answer questions, provide reasoning and context, and try to address things not covered in the document. > > The reason we decided on me for this role (but still representing the TAC’s opinion, not giving my own) is that if we had to find a time to meet and discuss every single e-mail that we receive here and jointly write a response to that would massively increase the latency of answers you receive from minutes or hours to days or weeks. > > In order to make sure that I can still represent the opinion of the TAC, we discuss all e-mail asynchronously and a corrective statement needs to be issued, we will do so promptly, with a text that has been approved from all of us. > > So far, we are not working on any such response, and all TAC members agree with the responses provided by me. > >>>> The former could also be read as a policy/guarantee that no >>>> non-amateur-radio based means of communication are involved. >>>> Is that intended ? >>> >>> Yes, correct. One of the things that this proposal can bring is that a part of the network is reserved for radio amateur to radio amateur communication. >>> >>>> I note that you also use the term "radio-only network" on page 3. >>>> Since 44.0/9 according to your proposal is not "radio-only", this >>>> would mean that 44.128/12 should not be accessible from 44.0/9, which >>>> is the opposite to your proposed resolution. >>> >>> This is actually (part of) the proposal. That we guarantee that people in 44.128/10 can only be reached by other people there, and people in 44.0/10 (technically /9) can be reached from the entire Internet, except 44.128/10 (natively). This is similar to how only radio amateurs can transmit in a ham band, but everyone can transmit to an ISM band (including hams). >> >> Your two statements are again contradictory. >> One point of view, taken by some amateurs back in the 90s was that >> the communication between two Amateurs should ONLY occur via radio >> waves. In other words, a "radio only" network should, as the name >> implies, not be using any other mode of communication, for example >> an IP tunnel THROUGH the Internet. That is a different, much more >> extreme position than defining some sort of an "Intranet" for amateur >> radio usage, which could include internet links, tunneled or not, >> as long as both end users are licensed amateurs. This is another >> example why TAC should be very careful with wordings, and maybe provide >> stringent definitions of some key terms. > > We only want to preserve some IP space that can be used for ham-to-ham communication. How they communicate is up to them. If they want to use radio-only, they can get an allocation off this space and build a radio-only network. If they want to communicate with carrier pigeons only, they can get an allocation and build a carrier-pigeon-only network. If they are okay with using tunnels *through* the Internet, then they can do that. > > We just want to make sure that we have some space reserved for this type of communication. Going back to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of the space is for ham-to-ham, and the rest is for ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can reach you. > >>>> b) Which route do I need to put into my router to address the radio >>>> network ? In particular, how can you answer this question without >>>> considering the specifics of each individual case ? Why would there >>>> be only one route? >>> >>> You can address the “radio network” with a single route: 44.128/10. This proposal guarantees that everyone there will be on the radio-only network, the same way transmitting to 144-146 MHz in the EU is to reach hams only. Any traffic you receive is (should be) from a ham, and you should only send anything if you are a ham, and you intend to reach other hams. Transmitting to 2.4 GHz in the ISM band allows you to talk to more people (anyone), but also anyone can talk to you. >> >> That is simply not true, since there is no homogenous radio network. > > This is partly true: there is not a “single 44.128/10” but anyone can create their own network within this space. However, if some of these networks don’t want to talk to everything else, then this is working as intended, and they are by design not reachable. We hope that most of the networks there would want to be interconnected and they can do so through radio links, VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of the many methods people could use to make sure that these networks talk to each other. > > The only exception that would make the single static route argument not true is that if a single user wants to participate in more than one of those networks, and none of them, by design and choice, want to be interconnected with anything else. In this extreme case this person would need to use one static route per such network. This is still far less and changes much less frequently than if it’s a free-for-all where everyone can do whatever they want in any part of the IPv4 space. > >>>> c) Can you back up the "originally intended" >>>> claim somehow ? I note that net-44 originated in the USA, which >>>> historically has rather liberal third-party traffic rules compared >>>> to other countries, >>> >>> We probably have a lot of people in this mailing list that were even a part of this and can speak up, but this happened before the Internet was (broadly) adopted and the 44/8 was a way for this “Internet” project some people were working on to talk to this network of these “radio amateurs” that they set up in the USA or Europe, etc. >> >> You (the TAC), made the claim and used it as a foundation >> of your proposal. It is your onus to prove it or at least to plausibly >> support it. > > I thought that people that actually set it up themselves would speak up, instead of me, where I just got to read and hear about it, but if nobody did it, I will come back to you with a proper statement. I just felt that it would be better to hear this from the people that were there for it. > >>>> d) You propose a policy of not announcing the prefix on the internet. >>>> "the prefix" is presumably 44.128/10. Do I have to understand this as >>>> going back to pre-2012 (no direct BGP) or pre, uh, 1990 (someone >>>> remind me please when mirrorshades started providing encap tunnels and >>>> announcing 44/8). >>> >>> Yes, correct. This proposal wants 44.128/10 to not have any direct BGP allocations that appear on the Internet. Connectivity of these networks should happen between themselves (network to network VPN, radio links, …), the ARDC (or anyone else’s) PoPs, etc. and they will not communicate through the open Internet. >> >> Sigh. This was not a yes/no question, but rather a question how far you >> want to turn back the wheels of time for 44.128. Pre-2012, individual >> networks did not have direct BGP announcements, but had connectivity >> (or lets say the option to connect) through mirrorshades(.ucsd.edu) >> which announced 44/8. I can bear witness that this worked that way at >> least from 1995, but likely much longer. >> >> Radio network access has at all times been set according to the >> gateway's jurisdiction and ham radio regulations, namely >> third party traffic. In most of Europe, any non-44 IP frame over an >> amateur radio link was (and likely still is) illegal. Not so in >> the US under third party traffic rules, albeit the situation has >> become considerably murkier with the advent of encryption (HTTPS, SSH). >> >> Again, please observe the careful distinction of "communicating >> with the open internet" vs. "communicating through the internet" > > This is an important distinction and something we still allow: the ONLY thing we say is that 44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means that no part of this space may appear on the Internet. Of course, the exception here is that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent to it. It will be dropped at the edge and not forwarded anywhere. > > With this definition you can then create any type of construct you want on top of that. We only want to provide this guarantee to you. Depending on local or national or international laws you may have to do different things, but we only want to provide this very simple guarantee. Nothing more, nothing else. If it’s illegal to use 44.128/10 in some countries based on this guarantee, then you can always use 44.0/10. If it’s illegal for a country to use 44.0/10 and can only use 44.128/10, then they have to move to this part by law. > >>>> e) Is there a rationale why existing regional networks cannot decide >>>> themselves what level of internet connectivity they desire, >>>> considering e.g. the local ham radio regulations >>>> and keeping their numbering and infrastructure which have been >>>> assigned to them long before ARDC existed as an entity. Is there >>>> a particular reason for not grandfathering them ? >>> >>> Unfortunately this would be difficult to accommodate as the guarantees cannot be offered then. If radio amateurs don’t have a dedicated band to talk to each other, and they have to use the ISM bands, there’s no way to distinguish between normal people and licensed hams. You can’t tell and there’s no guarantee that the person you’re speaking with is a ham or anyone else. >> >> You *never* can be certain. How many QSOs have you made where you >> asked first for a copy of your partners license to be faxed ? >> The problem is the problem of those allowing the traffic to cross >> to a radio operated under amateur radio regulations, i.e. the operators >> of that radio. Pre-2019, most of them would in the past have accepted >> access to a sufficiently routed 44/8 IP as sufficient authentication, >> although of course it is not perfect. Others required authentication >> though a login on the gateway. > > We can’t be certain, I agree with what you say. What we can do is make it much better than it is right now. We think that even if we can’t provide a perfect solution, we should still make steps to improve the situation. > > If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach you. If you are connected to the Internet, and you advertise your space with BGP, it is in fact *guaranteed* for non-ham traffic to reach you. > > You could argue that you could deploy ACLs or Firewalls, or any measure like that, and this would help you only accept 44/8 traffic. But this is still worse: packets on the Internet today can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a commercial ISP, and it would get through your firewall and possibly over your RF links just fine. Moreover, if two 44/8 networks connect with intermediate hops over the Internet, e.g.: > > 1. 44.1.2.3 > 2. 44.3.2.1 > 3. 192.0.2.15 > 4. 193.5.16.50 > 5. 44.4.6.7 > 6. 44.7.6.5 > > (Which I assume is what you want to do if you want to be on the Internet BGP and block all incoming traffic from non-44/8 hosts) > > Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a transmission in a ham band of packets that are not from a ham. This is much more common than you can imagine, and not always done maliciously. If I am node #1 and I do a traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a packet that was not generated by a radio amateur (it’s a non-manned station / router of Cogent / Telia / Hurricane Electric, …) over a ham band. > > If you have the knowledge that any host you traceroute within 44.128/10 is (to the best of your knowledge and ability to tell) a radio amateur, and that these packets will not travel raw over the Internet, and no packets from the Internet can be introduced into this connection (because it’s inside a VPN for example), then you can be sure that running the traceroute command will not cause a number of people to break the law along the way. > > Now for the use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that all these port scans that people do will reach all IPv4 addresses in your network. Since you know this is going to happen, you cannot use any radio link in a non-ham band, as it is guaranteed that these stations will transmit a message over an amateur radio band that is not from a licensed user. Even with a stateful firewall that only allows outgoing connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a non-radio-amateur and you will be transmitting them over a band illegally. > > If this law applies to you, then you cannot use the ham bands to “communicate with the open Internet”. I think that we both agree on that. Now moving to the case of “communicating through the Internet”. Let’s examine that. > > If the network does not appear via BGP on the Internet, then everyone has to set up tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem I described earlier (and any other similar case) won’t happen. The only routers and equipment that participates in this network is (or must be) owned and operated legally by hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is almost guaranteed to not break the law or at least it is much much much much much much more certain that such a system would not break the law than talking transparently “through the Internet”. > >>> Similarly to the RF world, in IP there’s this kind of problem as well. If you have IP addresses on the Internet, you could receive traffic from anyone. Sure, you can use an ACL or a firewall, but that’s not guaranteed. Packets could be spoofed for example. If you have a special network where you know that all senders and recipients are hams, then you can build things with different assumptions. You can build internal tools or apps, websites, etc. It’s up to you. It’s a band where you will only find people of the same hobby as you, that are licensed. >> >> This used to be the description of 44/8 (now, sans the AMAZN part). To >> my knowledge, this never changed (see ARDC's AUP). If it did, I would >> support a reversion of that change. >> >>> The other part is like an ISM band. Sure, you can use this to talk to other hams, and you can use it to talk to non-hams, and non-hams can use it to talk to you, and you have to establish by your own means who is who, and ensure that they can’t trick you. >>> >>> What our proposal aims to do is to create a separate “Ham Band” / Intranet / 44.128/10 and a separate "ISM band” / Internet / 44.0/9. By using simple RF or IP you can’t have them collocated into the same space. >>> >>> This is the reason why we cannot have scattered space and we want to have it aggregated and easy to address. Instead of our “band plan” being hundreds of lines and have it change daily, and move band from “ISM” to “Amateur Radio” and vice versa, we want to create a very simple band plan of 2 entries that don’t change. One is, and will remain to be “ISM” (44.0/9) and one is, and will remain to be “Radio Amateur” (44.128/10). >>> >>> Having a more stable and simple band plan is easier for everyone. They can make more informed decisions for the future, they can choose who they want to talk to, and they can even decide to use both bands: use a handheld radio (Radio Amateur) and a phone with WiFi (ISM). This is what we try to do on a technical level. Clearly define the two bands, and make sure that they are very few, and very stable. >> >> People *DID* that, based on the current policy that each subnet can >> decide if it wants internet connectivity. This was the policy that >> governed AMPRNet for at least since the mid-nineties. >> People built their network around that policy (and the legal >> requirements). Later they *DID* opt for BGP or not. >> >> It is the TAC with this proposal that is flipping over the apple-cart. >> For such a proposal, in addition to the potential benefits that such >> a plan may bring, TAC MUST also address the cost epecially the work you force >> uppon the affected users. > > I agree that we must address this work, and it could be a lot of it. Unfortunately the best the TAC can do is to include these resolutions for the board to vote on (give enough help, time, …). Anything else will have to come from the Board as we do not have any authority to help in any other way. > > There are a lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly more. But I think this is a testament that the current network is not easy to use: you may have 20 users, but a single person was managing it and has to renumber everyone. If anyone participating was an expect, they would simply have to renumber their own hosts, that would be less than 200 for a typical setup. > >>> In the IP world this translates to easier routing (each “band plan” entry is a route, and if it’s just one, it could even be a static one), and less frequent changes. I don’t have to consult today’s band plan to know why 44.5.5.5 does not respond from 44.128.128.128, if the reason is that 44.5.5.5 decided to be Internet-only today or Intranet-only tomorrow. >>> >>> We could have made use of complex routing protocols and policies that would dynamically try to discover what each address or subnet is (because it’s not always clear and we can’t always tell what each address wants to do, even if we forced everyone to connect to an ARDC PoP) and then continually adjust this and maintain a complex state. This is something that a lot of people would also have to do, or they would have to find someone to do it for them (e.g. the ARDC PoPs). Going towards our value of being as inclusive as possible, we did not want to force people that don’t want to to have to do this or to have to connect via an entity that can do this. By having a 2-line band plan that doesn’t change over time people can even hard-code it if they don’t want to deal with all of this complexity or necessarily rely on someone to do it for them and then form a dependency to them. >> >> You are forcing your world-view uppon all existing users of 44.128/0 >> and require those that disagree to leave and expend effort to renumber. >> I do not think that "inclusive" is quite the correct word for that. > > And the current users force their world view upon future users and also a large part of this network. I don’t think that it’s about who wins and who gets forced to submission. The TAC tries to create space for both use cases so we all win, and we are all happy. Like any rule in any civilized society, some people will have to make some sacrifices to co-exist. They will have to understand why they need to do this, and then they will have to give the others space to grow and have fun as well. > > Under no circumstances do we want a minority of very vocal people that shout to bend the majority to their will, simply because they can’t shout loud enough. And it seems that this happens frequently on the modern world. We have to understand that by forcing people to do anything, we only drive them away. I would consider it a failure if people gave up on a project or hobby or resource just because the environment there does allow room for them to grow, and I did not do my best to speak up for them. > > We have to understand that not everyone can shout. We are all different, and we all want different things, and we all have different needs. Some people are too shy to shout. Some people have weak vocal cords. Some people don’t speak the language we shout in. > > If we let these people be ignored, and we only do what these few vocal people say, then we will create something that is only inclusive and welcome to people that can and want to shout. This almost certainly guarantees a toxic environment that people will slowly start to abandon and leave it be, simply because it’s not what they want to do. > > If someone creates their own “People that shout” club, then that’s fine. They can all gather every week and shout to each other. I personally don’t want to join this club, I find no value in it. But we should collectively never allow these people to take over a public resource for all of us, that can benefit all of us, as this is dangerous. Just because they have the privilege to shout does not mean that other voices should not be heard. And not only that, but we should make all these decisions proportionately. Because this is a common resource, for all of us. Not only for some of us. > > Speaking personally, I will continue to be an ally and use my privilege of being able to shout to defend all these users and protect them and make sure that their voices are heard. > >> There are people that are fine with having the world communicate with >> their 44. IPs. Nothing in your ham radio license forbids you talking >> to other people, as long as you dont do it over a (amateur-) radio. >> You proudly wear baseball caps with your callsign on it. Why can't >> you wear your 44 IP? > > We want people to use their 44 IPs on the Internet! We are happy to see them do it, and we are really looking forward to all the nice things they can achieve by doing so. We just want to make sure that they’re not the only ones, and we leave some room for people that like something different. The current proposal gives enough space for now and in the future for people to do any of the two, or both things, as they wish. It’s about choice. > >> That said, removing the currently existing option to connect to the >> internet by central gateway or direct BGP is a major, destructive >> change of current policy. Sometimes, such destruction is requisite for >> progress. It is the duty of the TAC to review such a change. >> Such a review must be balanced, and necessarily must include a detailed >> discussion of opposing views, a discussion why there is no >> simple technical solution to the problem, and a discussion of those >> negatively affected by this change. This all should be documented >> for the record. Meaningful review would probably have also included a >> documented poll of the affected network's coordinators. > > First of all, we do not remove the option for Direct BGP, and we won’t force anyone to use ARDC’s PoPs. That’s our goal. We reserve just as much space for Direct BGP as we reserve for non-Internet communication. Each user can decide which part of the network they want to be in, and they also have the option of picking both. > > Destruction is indeed sometimes necessary, but of course I think that we all agree that we should try to limit it. We don’t want to destroy anything. We just want to make a change over the next year so that it’s easier for everyone to move on in the future. We want to look at the long-term benefit of the network over the short-term trouble of renumbering a part of it. > > We are interested in the opposing views, the voices of the people that want to renumber, and we want to hear from all of you. This is why we started this thread a few days ago so we can get to hear all of you, and discuss with you. The PDF does not include a proposal that is final and that we have sent to the Board for a vote. It only includes *what we want to propose* and why we arrived at it after 4 months of work. > > If we get a good recommendation and we see the value in that, we would be happy to change it. It has not reached the Board and the Board is not going to vote on it if we don’t tell them we want them to. > >> At this time, I therefore believe the current TAC's proposal is >> deficient and thus should be rejected (albeit without prejudice) > > As I said earlier, there’s nothing yet to reject. There’s no official motion made to the Board, and we will only send one after we get to hear you. > >>> Furthering the analogy, a handheld VHF manufacturer relies on a constant band plan to allow TX to 144-146 MHz and doesn’t have to build a system for their product to download this hour’s or this day’s Amateur Radio allocation and change the functionality based on that. You can also be sure that your local amateur radio repeater won’t be today at 89.7 MHz and your favorite radio station won’t transmit to 145.500 MHz this afternoon. >> >> This analogy is not suitable. For starters, the 2m band extends up >> to 148 MHz in IARU Regions 2 and 3, which should give you pause to >> consider the difference of what you are used to, what is legal in your >> country, and what may be so in the rest of the world. > > I am aware that the bands are different for different regions of the world, but I do not want to make the example complicated. I thought that it was enough for people to understand my point, even if it’s region-specific, and that you can easily replace those numbers with your local ones. I did not see a benefit in being extremely precise in something that is not related to the point I try to make when the audience can probably understand it. > > If you did not get my point because of the fact that two digits are off, then I can rephrase the sentence with these digits as they stand around the world. > >> Secondly, why would I not be allowed to listen to that amateur radio >> repeater using my commercial all-band radio receiver? > > First of all, it may be illegal in some areas of the world, e.g. I think the U.K. or Greece. But I think that’s not your point ;) > > If your radio supports both bands and you’re licensed for both, then you can talk to both using the same radio. If you’re not licensed for one of them, but a friend is, and you want to talk over it, you can set up a cross-band repeater (netmap, …) to allow you to do this. > > Antonis

3 years, 9 months

1
0
0 0

Scenario: DE HAMNET user accessing NL user's web service

by Janko Mivšek

Hello everyone, To be more concrete and to better understand issues behind the TAC proposal, I draw a scheme for fictional scenario where German user with non-public 44 IP wants to access via HAMNET a Dutch user's web service, running on his computer with public 44 IP: http://ftp.eranova.si/44net/scenario-de-nl-s57nk-jul21.png Both have 44 IPs in 44.128/16 range covered in TAC proposal. HAMNET is a closed network, non accessible from Internet while Dutch 44net is completely open to public access. Two extreme cases therefore. German user has set a simple static route: all traffic to 44.128/10 should go via HAMNET while all the rest via NAT to internet. NAT is needed because his local 44 IP is from a HAMNET's subnet which is not announced all over the Internet via BGP. Contrary to Dutch user, which local 44 IP is from BGP announced subnet and therefore everyone from Internet can access his web server. Also, he can access anything on the public Internet without any NAT needed. Furthermore, he is proudly represented on the Internet as radio amateur because of his 44 IP. Now to the scenario: German user finds his Dutch college website interesting and he'd like to access it. But his 44.128/10 static route will direct him over the HAMNET, not to public Internet. No access possible until HAMNET is connected directly to Dutch 44net. Now suppose we connect both those nets too. Dutch web server will now respond to German college's web request and response will be hopefully routed back to him. Hopefully the requests from public internet will also be served as before. Am I correct with this scenario? Are there any routing issues, are they already solved? Or how to solve them? If this scenario doable, are there some more issues? Best 73 Janko S57NK

3 years, 9 months

1
0
0 0

Is 44.159.159.0/24 allocated?

by Soha Jin

Hi there, I found an organization called SSL Corporation (AS38281) start announcing 44.159.159.0/24 since 2021-07-29 14:08:00. I found it here: https://radar.qrator.net/search?query=44.159.159.0%2F24 It is strange with that a renumber plan which says 44.128/10 will be used for radio only was just came out several days ago. I tried to find it on portal, but there is not such a prefix. I also tried to look it up with whois, but it reports a database error: $ whois -h whois.ampr.org 44.159.159.0 # # ARDC WHOIS data and services are subject to the Terms of Use # available at: http://www.ampr.org # # If you see inaccuracies in the results, please report them at # https://portal.ampr.org/contact-us.php # Database error# # ARDC WHOIS data and services are subject to the Terms of Use # available at: http://www.ampr.org # # If you see inaccuracies in the results, please report them at # https://portal.ampr.org/contact-us.php # This prefix is announced with a route object: route: 44.159.159.0/24 origin: AS38281 descr: Assigned by AMPRNET for radio experiment usage. admin-c: Charles Wang tech-c: Charles Wang mnt-by: MAINT-AS38281 changed: charleswang(a)nekollc.com 20210729 #13:20:12Z source: RADB I am here to ask if this announcement authorized? 73, Soha Jin

3 years, 9 months

2
2
0 0

Re: [44net] A new era of IPv4 Allocations

by Pedro Converso

Will proposed change affect 44.153.x.x allocations? Thanks 73, lu7abf, Pedro 44.153 Argentina Coordination

3 years, 9 months

11
17
0 0

Re: [44net] Future of AMPRNet Should NOT BE AMPRNet

by Antonios Chariton (daknob)

Hello Ian! Speaking as the TAC again, RPKI ROAs and route(6) objects are also something we worked on. It’s going to be proposed later, definitely after the summer, and will hopefully help many users and make Internet routing more secure for everyone! Thanks, Antonis > On 28 Jul 2021, at 23:03, Ian Chilton <ian(a)chilton.me.uk> wrote: > > Hi, > > Totally agree with all of the points about IPv6! > > On a related note…. > > I’m sure this has been discussed many times over, but with so many announcing 44 space with BGP, I think going forward it’s important to be able > to create RPKI ROAs (and IRRDB objects) for the space. > > Thanks, > > Ian

3 years, 9 months

2
1
0 0

Problems with gw.ampr.org

by G1FEF

Hello 44Net, Just to advise that there is likely to be heavy packet loss through the gateway server at UCSD currently. The 1G link has been fully saturated since just before midnight PST (see attached MRTG graph). I can’t even login to the server reliably enough to see what the traffic is but I guess some DDOS is ongoing. I will keep you informed as and when I have further information. 73, Chris - G1FEF

3 years, 9 months

2
2
0 0

Introducing Dan Romanchik - KB6NU - our new Content Manager

by Rosy Wolfe

Hello 44net! Given that he just posted info for the next community meeting, this is an excellent opportunity to welcome a new employee - Dan Romanchik, KB6NU, who is our new Content Manager. He'll be helping us with all things related to writing - newsletters, web content, and even helping with grantee proposals. Here's a little bit about Dan: Dan, KB6NU, has been a radio geek ever since he turned on his grandparents' Philco console radio about age 10. He got his first license at age 16, then obtained a BSEE degree from the University of Detroit. After working as a test engineer for a dozen years or so, he decided to direct his engineering talents in another direction and became a technical editor for Test&Measurement World magazine, a post he held for six years. After leaving the magazine, Dan was self-employed as a website developer and freelance writer. He blogs about amateur radio at KB6NU.Com and self-publishes the "No Nonsense" line of amateur radio license study guides. He's also self published *21 Things to Do After You Get Your Amateur Radio License" and *The CWGeek's Guide to Having Fun with Morse Code." He feels his biggest accomplishement has been helping thousands of people get their first amateur radio license or upgrade to General and Extra, either by reading his study guides or by attending the classes he teaches. He's very excited to now be working with ARDC and hopes that his work here will help even more people have fun with amateur radio. Please join me in welcoming him! 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

3 years, 10 months

4
3
0 0

Community Meeting: July 24, 2021, 1700 UTC

by Dan Romanchik KB6NU

We’re midway through 2021, and it’s time for the next ARDC Community Meeting! It will take place on: Saturday, 24 July 2021 1700 UTC (10am PT / 1pm ET / 7pm CET) In this meeting, we’ll cover: Grants made to date in 2021, including our first grant made outside the U.S. to DARC. Introductions of two new staff members: Grants Manager – Chelsea Parraga, KF0FVJ Content Manager – Dan Romanchik, KB6NU Questions from our attendees. The meeting will be held on Zoom. Info on how to join is below. This meeting is open to all interested parties, so please tell your friends! See you on July 24! // Zoom Info ARDC is inviting you to a scheduled Zoom meeting. Topic: July 24 Community Meeting Time: Jul 24, 2021 10:00 AM Pacific Time (US and Canada) Join Zoom Meeting https://us02web.zoom.us/j/86944554944?pwd=ZjlFdk5aUGgydGFCSnluenNzbm9SUT09 Meeting ID: 869 4455 4944 Passcode: 44net One tap mobile +16699006833,,86944554944#,,,,738141# US (San Jose) +12532158782,,86944554944#,,,,738141# US (Tacoma) Dial by your location +1 669 900 6833 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 312 626 6799 US (Chicago) +1 929 205 6099 US (New York) +1 301 715 8592 US (Washington DC) Meeting ID: 869 4455 4944 Passcode: 738141 Find your local number: https://us02web.zoom.us/u/kc7yFYiowZ

3 years, 10 months

1
0
0 0

Congratulations to ARDC's Grants Manager

by John D. Hays

Chelsea Paragga, the grants manager at ARDC passed her technician test over the weekend, after a couple of week's study, and is now the holder of station callsign KF0FVJ Please join me in congratulating her on this achievement. -- John D. Hays Kingston, WA K7VE

3 years, 10 months

10
9
0 0

DNS area coordinator for San Diego / CA

by Assi Friedman

Folks: Who is the coordinator listed as AMPRNET on the portal? I am looking to update a few DNS entries for the San Diego / CA area. Thanks, Assi KK7KX

3 years, 11 months

2
3
0 0

Announcing international grantmaking, starting with the Deutscher Amateur Radio Club (DARC)

by Rosy Wolfe

Hello 44net! I'm writing to share some exciting news: ARDC has begun to make grants internationally, primarily to 501(c)(3) equivalents (e.g. charitable organizations and schools). The first set of grants will go to the Deutscher Amateur Radio Club (DARC)(darc.de). One of their grants aims to expand the HAMNET in Europe, and the other supports OpenWebRX - a web-based SDR project. You can read more about these grants here: https://www.ampr.org/the-deutscher-amateur-radio-club-e-v-darc-initiates-gr… If you know of 501(c)(3) equivalent international organizations who may be deserving of a grant, please send them our way. We are also seeking partners in different parts of the world who may be able to use ARDC funds to make smaller grants in their region, just as DARC will be doing. Again, please spread the word - we're excited to expand our reach And! We don't plan for our reach to end here either - we'll post more information about further expansions (such as granting to individuals) as soon as we are able. All the best and 73, Rosy PS - you might notice I have a new email address - rosy(a)ardc.net. We're in the process of switching to a new mail server. More information about that coming soon. -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

3 years, 11 months

1
0
0 0

RIP broadcast does not reach my GW

by Marc, LX1DUC

Good afternoon, Since this morning it seems that no RIP broadcasts are reaching the commercial IP address of my GW. I've running ampr-ripd-2.4 in debug and verbose more for all of the afternoon, but I see nothing. I also checked the firewall rules (there are none) and also tried tracing packets with tshark. None of the methods should any RIP UDP packets arriving at my GW. The GW entry seems to exist at least since 2020-11-11 14:16:42, so it's not a new entry. A tracepath from the GW to 44.0.0.1 stops at sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50). Did anybody notice anything similar? 73 de Marc, LX1DUC

3 years, 11 months

2
1
0 0

IPv6

by lleachii＠aol.com

All, I've hear some people mention IPv6. I've said before "closed mouths don't get fed"... Maybe we can again ask for an IPv6 allocation to be given to us??? (I know this may be late.) 73, - Lynwood KB3VWG

3 years, 11 months

10
12
0 0

Introducing Chelsea Párraga, our new Grants Manager

by Rosy Wolfe

Hello, 44net! I'm thrilled to introduce y'all to ARDC employee #2: Chelsea Párraga! Chelsea comes from a family full of hams, as well as a background in both fundraising and grantmaking - most recently at History Colorado. In addition to being well-versed in all things grantmaking, she also loves learning and has even done some experimenting with a Raspberry Pi. She's been with us for a couple of weeks now and has definitely hit the ground running! If you have any questions related to grantmaking, feel free to give her a buzz at giving(a)ampr.org. It feels wonderful to start growing the team. Please give her a warm welcome! Many thanks and 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

3 years, 11 months

5
5
0 0

Uses of 44Net Allocations?

by Ian Chilton

Hi, I’m interested what people are using 44Net space for…. what do you use yours for (and what size allocation?). On a related note - there doesn’t seem to be a clear description of what you can and can’t do with it, other than nothing commercial? Thanks, Ian -- Ian Chilton E-Mail: ian(a)chilton.me.uk Web: http://www.ichilton.co.uk/blog Twitter: http://twitter.com/ichilton Github: http://github.com/ichilton

3 years, 11 months

5
4
0 0

BGP changes for 44net allocations?

by Jim MacKenzie

Hi, I have a 44net/AMPRnet allocation that had the appropriate paperwork done with Brian Kantor before he passed. This subnet has been delegated to me for a few years and I am using a VPS provider to advertise it via BGP so that it is accessible on the public Internet. My provider is selling to another company that is unlikely to continue this arrangement. Also, it seems my five-year contract has expired so it needs renewing anyway. :) Who is handling this documentation now? I'd like to arrange updated documentation so that I can get whatever new provider to sign on. Also, if anyone has any suggestions for providers with data centres in Canada (or with low latency to prairie Canada, at least), I'm all ears. I have found a prospect in Toronto and am waiting to hear back, but it is far from definite. Much appreciated. 73 Jim VE5EV

3 years, 11 months

6
6
0 0

Presentation to RATPAC

by John D. Hays

A recent presentation to RATPAC by ARDC (Rosy and Phil). https://vimeo.com/549072371 -- John D. Hays Kingston, WA K7VE / WRJT-215

3 years, 11 months

1
0
0 0

bgp router setup

by eric.fort.listmail＠fortconsulting.org

a few weeks ago somone linked to a really good youtube video on setting up a vm as a bgp router with bird and open vpn. now I cant find the post, the video or the link. could someone please repost this or at least send me the link. I want to get 44.18.28/22 routed as I have a network which it was ontained for now needing built. bgp is working TO my vm at vultr but I need to get the vpn side working out to the sites. Eric af6ep

3 years, 11 months

5
9
0 0

The utilization of 44/8

by Antonios Chariton (daknob)

Hello fellow 44net users, Yesterday I posted an analysis of the utilization of 44/8 on my blog, and you can find that here: https://blog.daknob.net/mapping-44net/ <https://blog.daknob.net/mapping-44net/> I thought you may find it interesting to read, and it also includes a map of the entire IPv4 and IPv6 Internet as a bonus so you can compare our usage to other parts of it. A note is that currently Germany's 44.148/15 already has very similar utilization to that of one of the most dense networks, 185/8 (comparison with 185.148/15): https://blog.daknob.net/content/images/2021/05/44-de-185-eu.png <https://blog.daknob.net/content/images/2021/05/44-de-185-eu.png> . According to the ping data, HAMNET accounts for over 75% of the hosts alive during the measurement, so that's a great example of what is possible for the entire network! I'll be happy to hear any thoughts and comments you may have on the topic. Antonis SV2OIY

3 years, 11 months

4
7
0 0

MIT Radome Re: 44Net Digest, Vol 10, Issue 74

by Ken

Very interesting article and nice tribute to Brian K. Good to see strong support from ARDC. Great job! Sent from my iPad > On May 7, 2021, at 1:00 PM, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. MIT Radome -- ARDC Grant (John D. Hays) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 May 2021 10:31:24 -0700 > From: "John D. Hays" <john(a)hays.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Subject: [44net] MIT Radome -- ARDC Grant > Message-ID: > <CAN77r3ya9MK4Ljs0XGfeE4YXCUp8kHugG7BmL-unTjMW9+LHNA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > https://news.mit.edu/2021/saving-the-mit-radome-0507 > > -- > John D. Hays > Kingston, WA > K7VE > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net > > > ------------------------------ > > End of 44Net Digest, Vol 10, Issue 74 > *************************************

3 years, 12 months

1
0
0 0

MIT Radome -- ARDC Grant

by John D. Hays

https://news.mit.edu/2021/saving-the-mit-radome-0507 -- John D. Hays Kingston, WA K7VE

3 years, 12 months

3
2
0 0

Renumbering networks (BGP announced only?)

by Magne Mæhre

Hi all. Just got a notice from our network person that he'd received an email from Chris notifying him of a renumbering of our allocated segments. Since I couldn't remember a discussion here (please excuse me if this has been discussed before), I just wanted to raise a few question - out of curiosity. We currently have a few /24 allocations within the 44.141.0.0/16 regional block (Norway). I think two or three of the /24 blocks are published via BGP. In the email, we're requested to renumber, and move the BGP announced segments over to the 44.31.0.0/16 (in the US regional /9 block). I don't think we've heard anything about the other addresses in 44.141.0.0/16 which are not BGP announced? I guess I'm curious about the rationale behind this decision? I think efficiency was stated, but I really can't see any big difference in having a /24 announced either here or there? Since we don't have the same upstream providers as our neighboring nets, there won't be any aggregation benefits (?). Is the plan to also deprecate the national and regional allocations? For our part, quite a few of the devices with 44-addresses are on mountain tops (beacons, remote receivers, sensors, etc.), but we have a 4 month window, starting in a months time, to get up there and do the renumbering. No big deal.. Just curious what the thoughts are.. --Magne / LA1BFA

4 years

1
0
0 0

contact info for aprs2.net pool

by Colin Bodor

Hello everyone. Maybe a long shot but figure there is some cross over. I setup an instance of APRSC in a "very good" location network wise (internet exchange, very low regional latency, no other APRS tier 2 servers close latency wise, data center, virtualized, multihomed etc - this is my day job, I run AS 55016 and announce 44net addresses via BGP, of which one is being used for APRSC). Anyway, would like to reach out to the folks at aprs2.net and see if I can get my server added to the noam.aprs2.net pool - pending meeting their requirements of course. I cant find any contact information however about who would be the correct person to contact about that, or the process to apply. Hoping someone here can help me get in touch? -Colin / VA6CCB

4 years

2
1
0 0

Re: [44net] JNOS.VA2OM.AMPR.ORG NNTP & AXIP services.

by VE2PKT

Good day, This message is for all of you using the NNTP on VA2OM, due to a misunderstanding in gateway configurations I had to do some changes. Now you can access the NNTP using jnos.ve2pkt.ampr.org port 119, if you like to POP some of your mail, you need to contact me for a access. if you have any question, feel free to ask by sending a message to: va2om(a)jnos.ve2pkt.ampr.org This is the same for all of you who had and AXIP linlk to VA2OM. please contact me -- 73 de Jean, VA2OM / VE2PKT

4 years

1
0
0 0

Re: [44net] TAC + 44net @ T+2 years

by lleachii＠aol.com

All, I'm actually learning a lot. Some I heard before; but didn't understand the implication - (not saying the research is/was bad). I'd simply say (as I read more on this topic) - that it wouldn't make any sense for an NGN44 Group to finally suggest something and it's not compatible with the "owner's" desire for the block/network. I digress. 73, - Lynwood KB3VWG

4 years

1
0
0 0

Re: [44net] VE2PKT.AMPR.ORG/LINUX.VE2PKT.AMPR.ORG

by VE2PKT

Good day, To all of you having a link or trying to reach VE2PKT.AMPR.ORG, I am having difficulty creating a new gateway on the portal. I keep getting the gateway IP all ready exist. But nothing is show when I log in. Working on the problem. Will let know the list once the gateway IP address is updated. -- 73 de Jean, VA2OM / VE2PKT

4 years

2
2
0 0

IP Ranges for Documentation

by Jason McCormick

Is there an allocation for documentation similar to RFC 5737? I was going to upload some stuff to the GitLab server but I wanted to generalize it so people didn't just copy/paste deploy stuff with my IP allocations in it. I looked on the portal but couldn't find anything. If there isn't, I'd like to propose that two /24s get set aside for documentation out of 44.0.0.0/9 that don't seem ripe for future use such as 44.0.192.0/24 and 44.1.255.0/24. Jason

4 years

13
43
0 0

ARDC is hiring: Administrative Coordinator, Communications & Community Manager

by Rosy Wolfe

Hi 44net, We've got a couple new job postings. Administrative Coordinator: https://www.ampr.org/ardc-is-hiring-an-administrative-coordinator/ Communications & Community Manager: https://www.ampr.org/ardc-is-hiring-a-communications-community-manager/ Please share with folks you think would be good fits. Many thanks! 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years

1
0
0 0

Re: [44net] 44Net Digest, Vol 10, Issue 45

by lleachii＠aol.com

Clive, Can you verify your callsign, please. I"m having a serious issue looking it up. Since transit is kinda physical (and AMPR/ARDC/TaskForce/committees are working on something for the future), I'm not sure why your offer makes sense. Can you more clearly explain how others not located near your data center obtain benefit? 73, - Lynwood KB3VWG -----Original Message----- Message: 1 Date: Sun, 28 Mar 2021 19:41:09 -0700 From: Clive Blackledge <clive(a)ansible.org> To: 44Net general discussion <44net(a)mailman.ampr.org> Subject: Re: [44net] DigitalOcean / Droplet Message-ID: <CAOqEX=gcXGmiKYOkNCueosi0=F-w2wtXzFQ29mNAiSo2K+hh6A(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi Angelo, Can you describe some of the issues or requirements that makes finding IP transit difficult? I can suggest quite a few options that have worked out for me, but it usually requires asking for exactly the right thing and little bit of luck of finding the right person. It is possible some of us here can start a joint venture and share some of the cost. Ideally we'd do it under the AMPRnet name, I guess it really can be under any corporate/LLC name. 73, -Clive KF6DFMA

4 years

3
4
0 0

Trying to contact N0OTZ

by G1FEF

Hi All, If Rial, N0OTZ is seeing this, please can you email me privately. If anyone knows, or is in contact with N0OTZ, please could you pass this message on. Thanks, Chris - G1FEF

4 years

1
0
0 0

Telnet login idle timer

by Gabriel Medinas

Hello friends, I have a problem with incoming connections to telnet port (23) in the login step that never put their credentials give a open tcp connection causing me to have a large sockets open. I have tried the mbox tdisc command which is not valid since the connection is still in the login stage without entering the mbox, consuming connection resources in the system. There will be some command to kill automatically the connections in the login stage by idle time (disc-timer) to delete this? JNOS 2.0m.4 (linux). Thanks, 73 de Gabriel YV5KXE YV AmprNet coord.

4 years

2
2
0 0

Club talk on AMPRnet

by Mitchell Southgate

Hi, Not sure the best person to approach for this but I belong to OARC a online amateur radio community which is mostly based on discord. We are a UK wide community open to all amateurs. We try and have regular club talks and wonder if there is someone willing to do a talk on AMPRnet as about 15 of our members are interested in what AMPRnet is. I have tried to explain best to them about it but would love to find someone who could give a better talk to try and help give some guidance on it. Our talks are normally held on Zoom. A few members have asked questions but I feel if someone could give us a general talk it would help give some insight into what AMPRnet has to offer I am happy to chat more off the list. 73's 2E0EMO

4 years

9
9
0 0

Amateur Radio Software Award - 2021

by KUN LIN

April 3rd, 2021 https://arsaward.com/ Announcing JS8Call as the winner of Amateur Radio Software Award ARSA committee is pleased to announce the recipient of the 2nd annual Amateur Radio Software Award to Jordan Sherer, KN4CRD, and his project, JS8Call. The award committee has considered numerous factors in choosing this year's winner, including the project's impact on furthering the interests of amateur radio, innovation, and community involvement. JS8Call is a full-fledged weak-signal digital communication application for amateur radio operators. In the spirit of open-source, Jordan extended the popular FT8 protocol instead of reinventing the wheel. During the 5 years of development, JS8Call has become a new tool for ARES function and cultivated a community of radio enthusiasts for digital communications. Jordan's work on JS8Call provides important innovation to advance the art of radio in the digital field. JS8Call is licensed under GPLv3 and can be freely downloaded at http://js8call.com. The ARSA committee is proud to present the 2021 Amateur Radio Software Award Certificate and an award grant of $300 to Jordan Sherer, the project owner and core contributor of the JS8Call application. We are looking forward to next year's Amateur Radio Software Award. Input and nominations for future awards are welcome. Be sure to visit our website https://arsaward.com for further information about the award. About the Award The Amateur Radio Software Award is an annual international award for the recognition of software projects that enhance amateur radio. The award aims to promote amateur radio software development which adheres to the same spirit as amateur radio itself: innovative, free, and open. Special Event Station We are operating the special event stations K2A, K2R, and K2S from Friday, August 27th through Sunday, September 5th, 2021 to promote innovative, free, and open amateur radio software. During the event, we will honor the 2021 award recipient. As part of the special event, we encourage people to submit nominations for the 2022 Amateur Radio Software Award. Award Committee Claus Niesen, AE0S (since 2020) Kun Lin, N7DMR (since 2020) Rich Gordon, K0EB (since 2021)

4 years

1
0
0 0

New version 1.2.4c of Echolink proxy/relay software

by Rob PE1CHL

For those running an Echolink proxy/relay farm or interested in doing so: I have released a new version 1.2.4c of my Echolink proxy/relay software, which is now available on my website https://pe1chl.nl/ as https://pe1chl.nl/Softw/elproxy.tar.gz New in this version: - fixes in the relay protocol by K1RFD (Echolink) - changed the TCP queue management, now it is no longer required to tweak the TCPQueueHighWater setting in the config file (setting can be deleted) and the TCP send queue sizes in the system parameters (sysctl.conf) - rewritten the use of select() to the Linux epoll(7) feature, should be more efficient When you are running relays for Echolink, please update the software as it resolves some issues for mobile users that were reported to K1RFD. When running only proxies, the update is not that important unless you experience the TCP queue issue described in the README file of version 1.2.3c and could not completely eliminate it using TCPQueueHighWater. 73, Rob PE1CHL

4 years

4
16
0 0

Git repository for AMPR stuff

by Marius Petrescu

Hi everyone, Since a lot of people do all kind of development work directed towards the ampr and the 44 network, wouldn't it make sense to have some kind of repository/version tracking for this work? Of course, there is Github, as a public place to do this, but wouldn't it be nice to have our own Git repository, which should be under ARDC control, where we could track our stuff, from code development and scripts, up to all the host and service lists? This could even be a topic for the grants committee... Costs are minimal, with only some effort towards the initial setup (Git is essentially free, with maybe a small payed support in setup from Atlassian if needed). Afterwards it is self-sustaining. 73s, Marius, YO2LOJ

4 years

22
42
0 0

Encrypted links on 5.8ghz. (WPA)

by pete M

I dont know what is the status of this case but I am asking here if anyone had some factual information on this. As we are using the frequency that are into the ISM band, We are also using device that are type accepted for that band. Those device are used legally with encryption by normal lambda user. If we dont modify the device power and frequency would it be legal for ham to also encrypt the signal? I understand that if we would use a higher power, different channel I would understand that we are now out of the ISM band rules. Pierre VE2PF

4 years

5
10
0 0

Is there anyone suffered DDoS just now?

by Soha Jin

Hi there, During UTC 0814-0816, 0820-0826, 0827-0834, 0843-0845, 0846-0849, 0934-0940, I was suffering ~600Mbps (peak ~900Mbps) DDoS attack on my 44net IP. I shared the situation in a discussion group, and found another ham whose 44net IP is also been flooded during that time. So I am here to asking if the same attack happened on other 44net IPs. 73, Soha Jin

4 years

1
0
0 0

Seeking quotes for ARDC Website + Branding Update (by April 31, 2021)

by Rosy Wolfe

Hello, 44net! I've heard from some of you that you might interested in helping to improve ARDC's website. We are currently seeking quotes from people who might be able to do just that, along with some branding work. Brief info is provided below. Please share with organizations you think might be good fits. Many thanks, Rosy // ARDC is seeking quotes from organizations who can help us with the following: • Creation of a comprehensive style guide, • Redesign of our website, ampr.org, along with migration to a new URL, and • Refresh and possible redesign of our logo. Please send in your proposal by April 31, 2021, and direct inquiries and proposals to: Rosy Wolfe, Executive Director Amateur Radio Digital Communications 5663 Balboa Avenue, Suite 432 San Diego, CA 92111-2705 USA https://www.ampr.org contact(a)ampr.org

4 years

4
4
0 0

Vultr bgp setup

by Eric Fort

If you use bgp with vultr could you please share your bird.conf. I finally have 44.18.28.0/22 on my account and I thought I had bird.conf correct...... but bird dies immediately when I try to start it. Eric Af6ep Sent using SMTP.

4 years

5
16
0 0

Git Repo for OpenVPN Examples

by Jason McCormick

All, In the spirit of what GitLab is supposed to be for, I've started a git repo for example OpenVPN configurations that people are using on 44Net. The intention is not to necessarily be a step-for-step guide (although that's always welcome) but to provide examples of what people are doing that work well. Anyone is welcome to become a contributor to the repo. https://git.ampr.org/N8EI/openvpn-config-examples I'm also planning on a routing configuration example and maybe a Wireguard example in the same spirit. Jason

4 years

3
2
0 0

reverse dns

by pete M

Hi to the group. I am helping a group that want to start a fast speed wireless network in the 5.8ghz for the bakebone and 2.4 ghz/900 mhz for the local network and mesh. they will annonce by BGP the subnet they were allowed. Of course they will use a DNS for many of the service they will have on the network. They are wondering how will reverse DNS will sork and if it is possible to change/add the reverse dns names of the machine. Thanks Pierre VE2PF

4 years

2
2
0 0

Wiki Edit

by R.D. Montgomery

Chris, I'm not sure if I have asked yet or not. But, can you grant me edit to the Wiki? I would like to start capturing some of these amazing details that we're getting passed through the mailing list. - How to setup Vultr - Perhaps tracking some of the group Wants - Gitlab Thanks in advance. --Ronnie W0rdm

4 years, 1 month

1
0
0 0

Re: [44net] Git repository for AMPR stuff

by Paul Sladen

On Sat, 3 Apr 2021, G1FEF wrote: > The ARDC board prefers open source, Yes, we all prefer open source. (Or any source at all). > there is currently no “code” on it at all. Chris: simple question; *where* is the code? -Paul

4 years, 1 month

3
2
0 0

Help with vultr bgp setup

by Eric Fort

> > I am having one hell of a time getting everything in order with vultr and getting 44.18.28.0/22 added to my account and announced via bgp. Could a few of those who have successfully negotiated and traveled this road before me please contact me and offer their assistance. I’m frankly exasperated with the whole thing. > > Eric > Af6ep > > Sent using SMTP.

4 years, 1 month

6
7
0 0

Re: [44net] IPIP tunnel and Ubuntu NetPlan

by KUN LIN

Thanks. This guides are very helpful. I'll try to follow. Kun N7DMR ________________________________ From: Brandon Gilmore <brandon(a)k7lgx.net> Sent: Thursday, April 1, 2021 8:52 PM To: 44Net general discussion Subject: Re: [44net] IPIP tunnel and Ubuntu NetPlan Hi N7DMR, I realize that this isn't a direct answer, but I started writing up my own approach for an AMPRnet IPIP configuration here: http://k7lgx.net/posts/2020-10-13-amprnet.html I'm not using netplan but instead configure systemd-networkd directly. If your distro is modern enough to include netplan then it seems likely that systemd-networkd could also be an option. The write-up is unfinished and rough around the edges, but it should be enough to get online. -- Brandon Gilmore (K7LGX) On Tue, Mar 30, 2021 at 09:15:42PM +0000, KUN LIN via 44Net wrote: > > Hi > Could someone let me know if it’s possible to setup IPIP tunnel for AMPRNet to UCSD’s gateway on Ubuntu’s Netplan? > > > > tunnels: > amprnet: > mode: ipip > remote: 169.228.34.84 > local: {IP address of my server} > addresses: > - "44.26.{my assignment}/29" > gateway4: {not sure what to put in} > > > > Thanks > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

4 years, 1 month

1
0
0 0

IPIP tunnel and Ubuntu NetPlan

by KUN LIN

Hi Could someone let me know if it’s possible to setup IPIP tunnel for AMPRNet to UCSD’s gateway on Ubuntu’s Netplan? tunnels: amprnet: mode: ipip remote: 169.228.34.84 local: {IP address of my server} addresses: - "44.26.{my assignment}/29" gateway4: {not sure what to put in} Thanks

4 years, 1 month

3
2
0 0

Announcing Request for Proposals for Education Projects and Amateur Radio Clubs

by Rosy Wolfe

Hello 44net! We have two new RFPs out, hot off the presses! The below text is posted on the blog, and I want to make sure you have it too. Please share with projects and organizations you think would make a good fit. Many thanks and 73, Rosy // Calling all educators and ham clubs! Amateur Radio Digital Communications (ARDC) is pleased to announce two requests for proposals (RFPs), designed to support amateur radio clubs as well as teachers who are interested in educating the next generation about amateur radio and digital communication science. The RFP for Amateur Radio Clubs seeks to support projects happening at amateur radio clubs. For this year, such grants are restricted to clubs inside of the United States. Grants in this category will be reviewed in two grant windows – the first one is short (starts now and ends on May 1, 2021), and the second one will run throughout the summer: Summer * Submissions due: May 1, 2021 * Distribution target: July 1, 2021 Fall * Submissions due: August 1, 2021 * Distribution target: October 1, 2021 More information, including a Q+A about eligibility and requirements, can be found in the RFP for Amateur Radio Clubs: https://www.ampr.org/wp-content/uploads/2021-03-ardc-amateur-radio-club.pdf The RFP for Education Projects is open to educational organizations both in the US and internationally. This granting window has one cycle, with distributions targeted for August 1, 2021 – ideally before the 2021-2022 school year starts. * Submissions due: June 1, 2021 * Distribution target: August 1, 2021 As with the RFP for Amateur Radio Clubs, more information can be found in the Education Project RFP: https://www.ampr.org/wp-content/uploads/2021-education-rfp.pdf SOME Q&A ABOUT THESE RFPS Thinking back on some questions that have come up at our community discussions, there are some high-level questions I imagine some folks will have. Here are answers to some of those. Q: Why is the Education Projects RFP open to international applicants, while the RFP for Supporting Amateur Radio Clubs is only open to applicants in the US? A: In order to most effectively get funds to amateur radio clubs internationally, we are looking to partner with organizations who can help to distribute such grants to clubs in their local area. We also have an exciting announcement about this brewing, so stay tuned! In the meantime, please direct any questions to giving(a)ampr.org. Q: How much do you plan to give to each one of these categories? A: ARDC is purposefully not setting a floor or limit on the number of grants that we will give in either category, or on the amounts given for each grant. The quality and quantity of applications that we get will determine the answers. With this in mind – we challenge you to tell as many people you know to help us get the word out! If you have more questions, please don’t hesitate to reach out: giving(a)ampr.org We look very forward to seeing your proposals! -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 1 month

1
0
0 0

ax.25 patch for 4.19.0-16 kernels

by Marius Petrescu

For those interested, I just added the standalone ax.25 patch packet for the Debian 10.9 kernel, 4.19.0-16: http://www.yo2loj.ro/hamprojects/ax25-4.19.0-16.tgz 73's Marius, YO2LOJ

4 years, 1 month

3
3
0 0

DNS updates

by Dan Keizer

Hi there. First-off, I don't normally post much to the group. I've been involved with the IP side of ampr.org since 1991 or so. We've run various gateways throughout the years and keep on expanding what we offer the local ham populations and ham services elsewhere. It was Brian who had given our group or network BGP auth letters. It takes alot of work to keep these systems running, and I know there's lots of people working on various aspects of our infrastructure. I have an issue that I would like some feedback from the ampr.org group on how to move this forward. We host a few ham websites for our groups and are transferring some of those to our data center with new upgrades/etc. To complete this process, there are a few DNS changes we need to have changed that are required. I've reached out to Luc Pernot (who is listed as our CDN contact person). He's confirmed he is the contact person (with a single word "yes"), but he has been completely unresponsive to support my request for DNS changes. I've reached out to G1FEF to support these changes. He initially indicated that even though the authority letter was issued to our va4wan group, and even though I was using the group's email to send the request to, he required the other domain admin person to make the request as the address block was in his name in our groups' email address. I even had this other admin person email him, and we have had no further contact since. And, by the way, I am the holder of the group callsign (va4wan) assignment from our Canadian radio authority. This request of mine initially started at the beginning of the month in March. It's now March 26. Two questions I have. Is there some other way in which we can update the DNS ourselves (like we did before) directly on ampr.org? How do I contact an admin person to assist with these changes in its current state? I understand this has been a volunteer group for the most part and I realize there may be various issues from time to time. I'd like to understand how we can be more efficient at handling change requests such as this in the future. I appreciate your feedback. 73, Dan ve4drk (va4wan admin)

4 years, 1 month

2
1
0 0

Setting up a vps for vpn routing of bgp subnet

by Eric Fort

Very shortly I will be setting up my vultr vps to route 44.18.28/22. Is there a faq or howto as to how to do this? I need to feed subnets to a couple different sites. Also I see many are using open vpn. Why open vpn as opposed to say IPSec, l2tp, ike2. Those that have preceded me down this road of bgp announcing your subnet ( or having your isp announce it for you) then using a Linux vpn server to connect your endpoints how did you do it once you had the loa in hand and why did you choose the software and methods you did? Thanks, Eric Af6ep Sent using SMTP. Sent using SMTP.

4 years, 1 month

3
3
0 0

Some one interested?

by VE2PKT

Good day, I am looking for someone interested to do some testing using the net44 address. I have setup a NNTP server, even if there is not much on it. It work great local but need someone outside my Lan to do some testing. It will not work using Internet address, it has to be from your ampr.org address, If interested please Email me: ve2pkt(a)gmail.com -- 73 de Jean, VA2OM / VE2PKT

4 years, 1 month

11
24
0 0

OpenVPN For Dummies

by Angelo

Hi Guys, Boy!! I must be getting really old. Some of this stuff is just not making any sense to me. Hi HI. I finally have all my routing (/24) from the ISP to the 44 network worked out. Matter of fact, I am able to use the OpenVPN client with no issue on a windows box. It is displaying the 44 address with no issues. ( I think I have it right.) I am able to access the internet with no issues. To the hard part. I am using an Ubiquiti EdgeRouter10X. I have been able to get the Edge to connect to the VPN server, but beyond that, I am unable to use a static address on any of my other devices and be able to access the internet. Here is some of the errors I am getting. Some of the error messages I am getting are : Mar 3 13:23:23 ubnt openvpn[1839]: TCP/UDP: Preserving recently used remote address: [AF_INET]44.108.2.2:1194 Mar 3 13:23:23 ubnt openvpn[1839]: Socket Buffers: R=[180224->180224] S=[180224->180224] Mar 3 13:23:23 ubnt openvpn[1839]: UDP link local: (not bound) Mar 3 13:23:23 ubnt openvpn[1839]: UDP link remote: [AF_INET]44.108.2.2:**** ( hinden ) Mar 3 13:23:23 ubnt openvpn[1839]: write UDP: Network is unreachable (code=128) Mar 3 13:23:23 ubnt openvpn[1839]: Network unreachable, restarting Mar 3 13:23:23 ubnt openvpn[1839]: SIGUSR1[soft,network-unreachable] received, process restarting Mar 3 13:23:23 ubnt openvpn[1839]: Restart pause, 20 second(s) The version of > Mar 3 13:23:23 ubnt openvpn[1839]: TCP/UDP: Preserving recently used > remote address: [AF_INET]44.108.2.2:1194 > Mar 3 13:23:23 ubnt openvpn[1839]: Socket Buffers: R=[180224->180224] > S=[180224->180224] > Mar 3 13:23:23 ubnt openvpn[1839]: UDP link local: (not bound) > Mar 3 13:23:23 ubnt openvpn[1839]: UDP link remote: > [AF_INET]44.108.2.2:1194 > Mar 3 13:23:23 ubnt openvpn[1839]: write UDP: Network is unreachable > (code=128) > Mar 3 13:23:23 ubnt openvpn[1839]: Network unreachable, restarting > Mar 3 13:23:23 ubnt openvpn[1839]: SIGUSR1[soft,network-unreachable] > received, process restarting > Mar 3 13:23:23 ubnt openvpn[1839]: Restart pause, 20 second(s) > The OS on the Edge is v.09 Hot fix. I am hoping to use some of the other ports for other eth (1-8 ) ports on the switch for other devices on the 44 network. Allstar, DX cluster, BPQ, Winlink etc. Guys, be gentle with me. I feel as dumb as a rock right now. Any help would be appreciated. Angelo

4 years, 1 month

4
5
0 0

Re: [44net] 44Net Digest, Vol 10, Issue 38

by va2dbj＠ve2cyh.org

On 2021-03-21 19:00, 44net-request(a)mailman.ampr.org wrote: > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > Today's Topics: > > 1. Re: Some one interested? (Michel Bouchard) > 2. Re: Some one interested? (Tony Langdon) > 3. Re: OpenVPN For Dummies (Keith Kasin) > 4. Re: Some one interested? (VE2PKT) > 5. Re: Some one interested? (VE2PKT) > 6. Re: OpenVPN For Dummies (Dave Gingrich) > 7. Re: OpenVPN For Dummies (Scott Nicholas) > 8. Re: Some one interested? (on4hu) > 9. Re: Some one interested? (on4hu) > 10. Re: Some one interested? (Marius Petrescu) > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net Bonjour a tous; je suis intéresser mais jai besson assistances a ce que vous écrire car je suis nouveau au système, ip j'attent mon numéro de hanshackhotline. Merci de votre temps 73 Robert va2dbj

4 years, 1 month

1
0
0 0

Re: [44net] Some one interested?

by on4hu

je ne vois pas cemnt , j'ai tunderbird sujr mon lnuw magia8 mais iomment avoir accen 44net 73 Les logiciels libres : il y a moins bien et bien plus cher ! Mail envoyé avec le logiciel libre Thunderbird sous GNU/Linux 2021-Mageia-8.0 > Envoyé: dimanche 21 mars 2021 à 18:07 > De: "VE2PKT via 44Net" <44net(a)mailman.ampr.org> > À: "Michel Bouchard via 44Net" <44net(a)mailman.ampr.org> > Cc: "VE2PKT" <ve2pkt(a)gmail.com> > Objet: Re: [44net] Some one interested? > > Salut Michel, > > Thunderbird me parais la meilleur solution, utilise comma > Newsserver: jnos.va2om.ampr.org > > si tu veux faire un post, fait le dans test@local. > > ti m'en donneras des news. > > 73 de Jean > > VA2OM / VE2PKT > > > On 2021-03-20 5:00 p.m., Michel Bouchard via 44Net wrote: > > Bonjour Jean, > > Moi aussi je suis intéressé. > > J’utilise mon router pour les adresses 44. > > 73 de Michel VE2BAR > > > > Michel Bouchard > > Envoyé de mon iPhone > > > > > >> Le 20 mars 2021 à 11:26, on4hu via 44Net <44net(a)mailman.ampr.org> a écrit : > >> > >> salut jean je suis interessé > >> vyh73 > >> andré ON4HU > >> > >> Les logiciels libres : il y a moins bien et bien plus cher ! > >> Mail envoyé avec le logiciel libre Thunderbird sous GNU/Linux > >> 2021-Mageia-8.0 > >> > >> > >>> Envoyé: samedi 20 mars 2021 à 16:08 > >>> De: "VE2PKT via 44Net" <44net(a)mailman.ampr.org> > >>> À: 44net(a)mailman.ampr.org > >>> Cc: "VE2PKT" <ve2pkt(a)gmail.com> > >>> Objet: [44net] Some one interested? > >>> > >>> Good day, > >>> > >>> I am looking for someone interested to do some testing using the > >>> net44 address. > >>> > >>> I have setup a NNTP server, even if there is not much on it. > >>> > >>> It work great local but need someone outside my Lan to do some testing. > >>> > >>> It will not work using Internet address, it has to be from your ampr.org > >>> address, > >>> > >>> If interested please Email me: ve2pkt(a)gmail.com > >>> > >>> -- > >>> > >>> 73 de Jean, > >>> VA2OM / VE2PKT > >>> > >>> _________________________________________ > >>> 44Net mailing list > >>> 44Net(a)mailman.ampr.org > >>> https://mailman.ampr.org/mailman/listinfo/44net > >>> > >> _________________________________________ > >> 44Net mailing list > >> 44Net(a)mailman.ampr.org > >> https://mailman.ampr.org/mailman/listinfo/44net > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > -- > > 73 de Jean, > VA2OM / VE2PKT > > Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode), VE2PKT-4 (XRPI) > : VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net) > : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) > RF: > 147.435 Mhz (1200 Bps), > > Internet: > Telnet: ve2pkt.dyndns.org port 23 (URONode) - VE2PKT-13 > Telnet: ve2pkt.dyndns.org port 2323 (Xrpi Node) - VE2PKT-4 > Telnet: ve2pkt.dyndns.org port 6300 (FBB BBS) - VE2PKT > Telnet: ve2pkt.dyndns.org port 9000 (DXCluster) - VE2PKT-9 > > E-Mail: > packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam > ampr net: ve2pkt(a)ve2pkt.ampr.org > Inet: ve2pkt(a)gmail.com > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

4 years, 1 month

1
0
0 0

Inviting you to ARDC Grantmaking Survey + Community Jitsi Call

by Rosy Wolfe

Hello 44net! Hope you are healthy and well wherever you are. I'm writing to invite you to a couple of things. 1. ARDC Grantmaking Survey The first is an invitation to take this survey about ARDC grant making, which you can find here: https://www.mysurveygizmo.com/s3/5789610/ARDC-Grantmaking-Feedback-Survey The survey covers our existing granting goals and some of the kinds of projects that we've funded so far. What do you think? What other grants would you like to see? Do you know of organizations, either in the US or abroad, that you'd like to see us fund? Let us know - it shouldn't take more than 5 minutes, more if you decide to give some longer written-out answers. 2. 44net + ARDC Community Video Call We'll go over the results together in a community video call, happening Saturday Oct. 10, 2020, at 17:00 UTC (10am PT / 1pm ET / 6pm BST / 7pm CEST). On this call, we'll introduce ARDC Board members, grants advisory committee members, and staff; go over the survey results together; talk about our grants made to date; and talk about any questions you have. If there's anything in particular you'd like ARDC to cover in the call, please let us know by responding to this mail or sending me a message directly: rosy(a)ampr.org. Here is the link to the call: https://meet.jit.si/ardc-44net-community-meeting-oct-10-2020 A note on the times: I realize that the times listed are more convenient for folks in the Americas, Africa, and Europe. If enough people from Asia and Australia wish to join but can't for timing reasons, we may do another group call for those time zones. Part of this exercise is also learning about 44net's distribution - where is everyone located? I'm looking forward to finding out. I'm also looking forward to better getting to know 44net and the greater ham community, and to use what I learn to help shape ARDC's 2021 grantmaking strategy. We are in a fortunate position to do a lot of good in the world - so let's do it! All the best, Rosy -- Rosy Wolfe Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 1 month

13
20
0 0

ARDC Job Posting: Grants Manager

by Rosy Wolfe

Hello, 44net! ARDC is looking to hire a Grants Manager. Please take a look at the posting here: https://www.ampr.org/ardc-is-hiring-a-grants-manager/ ...and feel free to forward to people you think would be excellent fits. I'll continue to post ARDC job listings here as they become available. Many thanks and 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 2 months

1
0
0 0

Using NPR Modem on AMPRNET ?

by R P

Hi there Is there anyone here that uses the NPR modems in the AMPRNET ? I would like to ask him some questions concerning the Network behave and config of the Systems Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org

4 years, 2 months

5
5
0 0

ASN # and Network Service Provider (NSP)

by Angelo

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

4 years, 2 months

21
63
0 0

Question about setting up 44net connection on BPQ

by CJ Kelley

Hi Everyone, I am trying to set up a BPQ node for access over the 44net and I have been running into trouble getting the connection working. I am running into an issue where I am not able to ping any 44 nodes. I can ping the local 44net interface, but can't ping past that. The host is in a DMZ, so it should be receiving the rip44 table. Even though the IPs are internal, I scrubbed them. What am I missing here? I am not able to ping any 44net nodes. I pulled 44.44.6.33 for sample: ping 44.44.6.33 PBSNOD:W7PBS-7} OK My arp table: arp PBSNOD:W7PBS-7} x.x.x.191 70:2a:d5:4a:29:9d 255 E 2770 The portion of bpq32.cfg for configuring the 44net connection. Port 1 is AXIP and Port 3 is the telnet port. IPGATEWAY Adapter \Device\NPF_{64EA23A4-79E1-4342-83E5-E92D65C2CA3D} 44ENCAP x.x.x.147 # Enable AMPRNET Tunnels and RIP44. I used 148 as the Tunnel Enpoint IPAddr 44.124.1.17 #This is the first IP in your AMPRnet allocation. IPNetmask 255.255.255.248 #AMPRnet netmask (Why is this 248 ? This is for your AMPRnet subnet. Your AMPRnet subnet is /29) IPPorts 1,3 ARP 44.124.1.17 x.x.x.147 3 D route 44.124.1.16/29 44.124.1.17 ; AMPRnet routes. route addprivate 44.124.1.16/29 encap 70.167.209.246 ; Arizona routes route addprivate 44.124.9.0/24 encap 65.49.149.125 route addprivate 44.124.7.0/25 encap 174.74.248.93 route addprivate 44.124.10/30 encap 50.116.8.127 route addprivate 44.124.1.8/29 encap 107.2.6.33 Thank you for your time, Christopher Kelley KG7UJH

4 years, 2 months

4
10
0 0

Recap (incl video!) from Feb. 06 Meeting

by Rosy Wolfe

Hello 44net, Please find a recap of our Feb. 06 meeting here: https://www.ampr.org/feb-06-community-meeting-recap-2020-annual-report-new-… Thank you for your patience - it's been a busy couple of weeks. One thing that's happened is that we've been getting our new TAC and GAC up to speed. Read about the new committee members in the link above! Have a great weekend, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 2 months

1
0
0 0

Greetings and http vs https

by traderbeckola＠tahoma.com

Hello! I am new to 44net and AMPR. As I am learning about the AMPR system and setting up a gateway, I have been working through the ampr.org website and found that a lot of internal links are broken, as they reference http://... , but the links have been converted to https://. Anyone else having the same issue? 73's Erik, N7FYO

4 years, 2 months

2
3
0 0

Updated Granting Goals

by Rosy Wolfe

Hello 44net, I'm pleased to share that ARDC has updated our granting goals for 2021. You can see them posted here: https://www.ampr.org/grantmaking-categories-requirements-goals/ The changes were made following feedback that the previous version was a bit confusing (including feedback from last year's 44net survey). This version breaks things down a bit more simply, into 3 high-level categories: * Support and Growth of Amateur Radio, * Education, and * Technical Innovation. Technical Innovation applies to the following areas: * Amateur Radio Technology & Experimentation, * Internet Technologies, * Digital Communications, and * Communication Science & Technology If you are interested in applying for a grant, please take a look at this new language. On a related note, we're looking forward to putting resources and effort into improving the Portal in 2021. I'll have more to share at our upcoming community meeting on Saturday 06 Feb. Learn more and sign up here: https://www.ampr.org/feb-6-meeting-sign-up/ Like last time, we'll share a report following the meeting for folks who can't attend, along with supplemental materials, including our first-ever annual report. More soon! Best wishes and 73, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 2 months

2
2
0 0

Contact request

by G1FEF

Hi, Does anyone know Ryan, K0RET and can get a message to him please? Ryan, if you are reading this, please could you drop me an email? Thank you, Chris - G1FEF

4 years, 2 months

1
0
0 0

Feb. 6 Community Meeting + New Survey

by Rosy Wolfe

Hello, 44net! It's 2021, and things are already getting off to a running start at ARDC. We've got a big year of grantmaking and 44net portal work in store for the year, with additional members being added to our Grants Advisory Committee (GAC) and a new Technical Advisory Committee (TAC) being created to support both efforts. We'll have more to share about it soon, and we'd love to tell you about it at our next **community meeting**: * Saturday, 06 Feb 2021 * 18:00 GMT (10am PT / 1pm ET / 7pm CET) Join us by signing up here: https://www.ampr.org/feb-6-meeting-sign-up/ In this meeting, we'll cover: * Highlights from 2020, * Grantmaking goals in 2021, * Introductions of new Technical Advisory Committee (TAC) and Grants Advisory Committee (GAC) Members, * Survey results from our latest survey, discussed below, and * Questions from our attendees. This meeting will be similar to the one we held on 10 Oct. 2020: https://www.ampr.org/recap-ardc-44net-oct-10-community-call/ This one is intended for a much broader audience. So - please tell your friends! We also plan to record this meeting for those who can't make it. ## New Survey Leading up to the meeting, we're also asking amateur radio enthusiasts to give us their thoughts in this survey: https://survey.alchemer.com/s3/6096699/ARDC-Amateur-Radio-Survey Please share it with other hams you know. As with the last survey, the aim is to get to know the people we aim to support through our grantmaking. And like our upcoming meeting, it too is meant for a broader audience. That's all for now! Looking forward to sharing more with everyone soon. All the best, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

4 years, 2 months

1
1
0 0

BGP et al

by Colin Bodor

Hello, with all the talk of BGP on the list I thought I would drop a note. I am also part of another volunteer effort for those of you already doing your own BGP. Project TON, its sort of like a RBL but via BGP www.projectton.com<http://www.projectton.com> you can setup a peering, and block bad actors (mostly SSH scans currently but our mix is always growing) or even do blocking by prefixes based on country. All free of course - and currently experimental so YMMV, we are just trying to contribute to the community and make the internet "safer". If anyone also had any questions about BGP stuff in Western Canada (Calgary), I could help with that as well - its my day job. My thanks to everyone dedicating their time to this effort. -C/VA6CCB

4 years, 2 months

1
0
0 0

Portal user name

by Tracy Markham

I forgot my portal login info ... entered my email address into the password reset and got the link, but it is asking to confirm my email address by entering my username - holy bazoombas I must have forgotten that one as well ... How to find your username? Years ago I deleted the welcome email ... Thanks Tracy N4LGH

4 years, 3 months

2
1
0 0

Re: [44net] Concerning over undocumented BGP announcements

by Nat Morris

On Sun, Jan 31, 2021 at 2:55 PM G1FEF <chris(a)g1fef.co.uk> wrote: > > > > On 31 Jan 2021, at 14:09, Nat Morris <nat(a)nuqe.net> wrote: > > > > Which blocks did you report? > > I don’t really want to go into specific details on an open mailing list. Suffice to say that keeping an eye on these and responding to problems keeps me busy enough! Why not? what is to hide? hijack discussions happen on other mailing lists in the public. So no more comment from yourself as the BGP co-ordinator on the prefixes in the report? https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whd… If you really do have the details on all these prefixes, there should be no reason you can't provide a statement on each, if it is an expected announcement, misconfiguration or hijackk Without you being slightly more forthcoming in public, in my eyes it puts the whole integrity of co-ordinating AMPRnet BGP announcements in doubt. > > Any explanation for these prefixes announced in the UK by AS61337, > > along side your portal prefixes, they are not documented at all in the > > portal: > > Not all allocations appear in the public listing on the portal, for various reasons. Try the Whois server if you want by check specific prefixes. Where is this publicly documented? > > RADB is ok, but not sufficient for the future. A better investment > > would be for the ARDC to negotiation with one of the 5 RIRs for > > prefixes to be registered there, so we could all benefit from use of > > their RPKI trust anchors. > > I can’t see that happening anytime soon I’m afraid, if ever, unless they drastically change their terms. We won’t do anything that risks losing our legacy status. Have the ARDC approached each RIR and discussed this? > > Having prefixes in RADB will not provide > > trust anchor functionality. > > Agreed, and RPKI is something we understand is desirable, there are several ways it could be achieved and will be the focus for the TAC at some point in the future. > > >> Which repo is this development taking place in? > > The development is taking place currently and will be open sourced when it’s ready. In the meantime, if you want to have input on any features you would like to see, feel free to contact Rosy and/or myself. I'd like to see planning for this taking place in the open, not closed. > > I noticed the github.com AMPRnet Portal repo has been removed. > > There was no point in it being there, we tried that route a couple of years ago and didn’t get anywhere. Nat, -- Nat https://nat.ms +44 7531 750292

4 years, 3 months

4
4
0 0

Concerning over undocumented BGP announcements

by Nat Morris

Hello all, Over the last few months I have noticed some odd BGP announcements of prefixes which have no allocations in the AMPRnet portal. After spotting 5 or 6 of these it made me wonder how many existed. This evening I took a snapshot of the RIPE RIS data for announcements within 44.0.0.0/9 and 44.128.0.0/10, which took place in 2021. Then scraped the allocations from the AMPRnet portal, compared prefixes directly and then used a radix tree to find a best match. The resulting data https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whd… At first glance there are some expected entries, for example users with a /22 or /23 announcing a more specific /24. What really worries me is the amount of announcements of /24s where the closest portal documented prefix is a /16. Are these being used legitimately? do AMPR co-ordinators what details about them? or have they been hijacked? Look for example at /24 announcements within country assignments, but no specific description! I would like to start a discussion around these specific prefixes. The scripts I wrote are here https://github.com/natm/amprnet-observer Kind regards, Nat. -- Nat https://nat.ms +44 7531 750292

4 years, 3 months

8
10
0 0

Ubiquiti XRouter X Gateway

by Lee D Bengston

Hello, I have followed the instructions at https://wiki.ampr.org/wiki/Installing_ampr-ripd_on_a_Ubiquiti_EdgeRouter_or…, but am encountering an error when running the ampr.sh script. line 28: /usr/sbin/ampr-ripd: cannot execute binary file The binary file is executable and I am attempting to run it from root. Line 28 has not been modified in the script: ampr-ripd -s -t 44 -i tun44 -m 90 The instructions say only to modify if needed, and based on the info in the Wiki I did not see a need to modify it, but I may be missing something. Any ideas? 73, Lee K5DAT

4 years, 3 months

3
15
0 0

BGP

by Angelo

I was wondering how long does it take for the routing tables to update on the internet? I have setup a 44.108.2.12 as a test machine. My BGP has been approved. I am able to surf the web with no issues, but here still seems to be no route to the ip address. It seems to stop at : sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu [132.239.255.50] Tracing route to bbs.n5eqo.ampr.org [44.108.2.12] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms dsldevice.attlocal.net [192.168.1.1] 2 2 ms 1 ms 1 ms 108-196-208-1.lightspeed.nworla.sbcglobal.net [108.196.208.1] 3 * * * Request timed out. 4 18 ms 15 ms 15 ms 12.123.239.110 5 15 ms 15 ms 15 ms 12.122.28.29 6 19 ms 15 ms 15 ms attga402igs.ip.att.net [12.122.117.121] 7 13 ms 14 ms 16 ms 4.68.62.225 8 * * * Request timed out. 9 53 ms 53 ms 53 ms CENIC.ear1.LosAngeles1.Level3.net [4.35.156.66] 10 55 ms 57 ms 54 ms dc-lax-agg8--lax-agg6-100ge-2.cenic.net [137.164.11.7] 11 55 ms 55 ms 54 ms dc-tus-agg8--lax-agg8-300g.cenic.net [137.164.11.83] 12 56 ms 55 ms 55 ms dc-sdg-agg4--tus-agg8-300g.cenic.net [137.164.11.85] 13 63 ms 55 ms 55 ms dc-ucsd-100ge--sdg-agg4.cenic.net [137.164.23.177] 14 55 ms 54 ms 54 ms nodem-core-6807-vlan2767-gw.ucsd.edu [132.239.254.61] 15 55 ms 55 ms 55 ms sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu [132.239.255.50] 16 * * * Request timed out. 17 * * * Request timed out. Any help would be appreciated. 73 de Angelo

4 years, 3 months

5
5
0 0

New /24 IP allocation "referred to BGP coordinator" No visible action.

by Geoff Joy

On or about January 5, 2021 I received an end-user allocation request for a "direct" /24 allocation "for working with ARDEN and IRLP for VPN and link setups" which I approved and submitted via portal.ampr.org. It didn't create the allocation I assigned to the network but was "referred to BGP coordinator". So far, there has been no action and no response to the original request nor a follow up to my request via the "contact us" link on the black hole that is the ampr.org portal. What is the status of the system and how are coordinators expected to act in this regard? I try to give my users timely, responsive service but it's very frustrating when I can't even track a submission or review submission histories. The end user has informed me that he is still awaiting action on the request. ke6qh

4 years, 3 months

5
9
0 0

Re: [44net] 44Net Digest, Vol 9, Issue 131

by Jay Koby

Confirming that ARIN's web-based IRR system won't allow 44net addresses, since there's no underlying allocation from one of ARIN's ranges. Your upstream provider will probably not be able to put in the IRR objects for you. For IRR, AltDB doesn't have a simple web interface but it does work regardless of the RIR (or lack of) that originally allocated the IPs. I don't think there's a way to use RPKI on the 44net range as of yet, though - that would likely need either a contract for one of the RIRs to sign resources or ARDC to set up, maintain, and gain trust for a certificate authority and handle RPKI requests like the RIRs do. Either of these is a pretty significant undertaking. 73 de K0BYJ, -- Jay On Mon, Dec 14, 2020 at 3:00 PM <44net-request(a)mailman.ampr.org> wrote: > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Re: 44NET Route Objects IRR (Caleb Pal) > 2. Re: 44NET Route Objects IRR (G1FEF) > > > > ---------- Forwarded message ---------- > From: Caleb Pal <cleb(a)defcon-3.net> > To: James Colderwood via 44Net <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 14 Dec 2020 08:57:53 -0800 > Subject: Re: [44net] 44NET Route Objects IRR > Hello, > > Your upstream providers may be able to put a proxy obj into the ARIN db > for you. Unfortunately ARIN changed their IRR db in June of this year. > They added a web based IRR service. According to ARIN, the web based > service only allows you to add object for resources you own (your > upstream ISP could not create those proxy objects since they do not own > the 44net resources). If they still use the ARIN email IRR system, they > can add proxy objects, they will just appear as ARIN-NOAUTH in the IRR > db. I don't think NOAUTH is a problem for most providers now, but could > be down the road if they start filtering/ignoring NOAUTH entries. > > Of course altdb, radb and others are options (full list at: > http://www.irr.net/docs/list.html). Not sure how other RIR's outside the > US are handling NOAUTH entries. > > I assume since AMPR does not have a RSA with ARIN, Chris cannot create > IRR records for those folks who BGP advertise AMPR resources? > > v/r, > > Caleb > > On 12/13/2020 10:08, James Colderwood via 44Net wrote: > > Hi Pierre, > > > > Thank you for the heads up. I was aware of altdb but it hadn't crossed > > my mind. Hopefully one of these solutions will work :-). > > > > On 2020-12-13 17:32, Pierre Emeriaud wrote: > >> Le dim. 13 déc. 2020 à 12:04, G1FEF via 44Net > >> <44net(a)mailman.ampr.org> a écrit : > >>> > >>> > On 13 Dec 2020, at 09:54, James Colderwood via 44Net > >>> <44net(a)mailman.ampr.org> wrote: > >>> > > >>> > Hi All, > >>> > > >>> > May I wish you all happy holidays! > >>> > > >>> > Quick question, I'm working on establising my 3rd upstream but hit > >>> a snag. The suppliers validation automation prohibits announcing > >>> AMPR addresses as the system can't qualify validity. > >>> > >>> Are you talking about automatically checking entries in an IRR, or > >>> RPKI? > >> > >> For service providers requesting an IRR route object to automate > >> filter creation I've been using altdb. While it has not a lot of value > >> in terms of authorization (anyone can create objects about any > >> resource - a proper LOA has more value here) it is usually enough for > >> provisioning tools to create appropriate filters / prefix-lists: > >> > >> $ whois -h whois.altdb.net 44.151.210.0 > >> route: 44.151.210.0/24 > >> descr: F4INU > >> origin: AS206155 > >> mnt-by: MAINT-AS206155 > >> > >> $ bgpq3 -4 -l F4INU as206155 > >> no ip prefix-list F4INU > >> ip prefix-list F4INU permit 44.151.210.0/24 > >> > >> > >> 73 de F4INU > >> -- > >> pierre > > > > > > > ---------- Forwarded message ---------- > From: G1FEF <chris(a)g1fef.co.uk> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 14 Dec 2020 17:26:28 +0000 > Subject: Re: [44net] 44NET Route Objects IRR > > I assume since AMPR does not have a RSA with ARIN, Chris cannot create > > IRR records for those folks who BGP advertise AMPR resources? > > The vast majority of folk advertising their subnet over BGP are using > altdb with no issues (currently). > > IIRC, altdb is run by one person, so if you don’t already have a MNTNER > object there, it can sometimes take some time to get one. > > Chris > > > > > v/r, > > > > Caleb > > > > On 12/13/2020 10:08, James Colderwood via 44Net wrote: > >> Hi Pierre, > >> > >> Thank you for the heads up. I was aware of altdb but it hadn't crossed > >> my mind. Hopefully one of these solutions will work :-). > >> > >> On 2020-12-13 17:32, Pierre Emeriaud wrote: > >>> Le dim. 13 déc. 2020 à 12:04, G1FEF via 44Net > >>> <44net(a)mailman.ampr.org> a écrit : > >>>> > >>>>> On 13 Dec 2020, at 09:54, James Colderwood via 44Net > >>>> <44net(a)mailman.ampr.org> wrote: > >>>>> > >>>>> Hi All, > >>>>> > >>>>> May I wish you all happy holidays! > >>>>> > >>>>> Quick question, I'm working on establising my 3rd upstream but hit > >>>> a snag. The suppliers validation automation prohibits announcing > >>>> AMPR addresses as the system can't qualify validity. > >>>> > >>>> Are you talking about automatically checking entries in an IRR, or > >>>> RPKI? > >>> > >>> For service providers requesting an IRR route object to automate > >>> filter creation I've been using altdb. While it has not a lot of value > >>> in terms of authorization (anyone can create objects about any > >>> resource - a proper LOA has more value here) it is usually enough for > >>> provisioning tools to create appropriate filters / prefix-lists: > >>> > >>> $ whois -h whois.altdb.net 44.151.210.0 > >>> route: 44.151.210.0/24 > >>> descr: F4INU > >>> origin: AS206155 > >>> mnt-by: MAINT-AS206155 > >>> > >>> $ bgpq3 -4 -l F4INU as206155 > >>> no ip prefix-list F4INU > >>> ip prefix-list F4INU permit 44.151.210.0/24 > >>> > >>> > >>> 73 de F4INU > >>> -- > >>> pierre > >> > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

4 years, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net