I'm not quite sure about the "announcement" aspect of it. Are we talking announcements similar to BGP or ZeroConf that was mentioned earlier? What kind of announcements are being made now on LAN networks beyond printer/fileshare/UPnP for all of which you wouldn't want to have advertised in such a fashion over the WAN (even 44net - seeing how people get bent out of shape whenever any 'foreign' packet hits their firewall).

But to throw out a list... -NNTP/Usenet Servers - Possibly gateway BBS/FBB into NNTP -Common Databases - Callsign Database, Maidenhead and the like -Streaming Audio/Video - repeaters, remote receivers, sarex, ATV feeds or whatever you want to toss up there. -Video Conferencing - but I'm still struggling getting this working properly in the real world for public consumption... so may be a stretch goal. -Latency tolerant games like Chess, Poker... even TradeWars. -Internet of Things - Feed/Entertain my cat for me when I'm traveling... -Cameras - Not necessarily streaming... but for a while there on the internet, we could watch the sun set in tahiti while freezing in minneapolis... Let's hope it doesn't turn into ham radio #selfies :)

On Tue, Apr 22, 2014 at 5:27 PM, Eric Fort eric.fort@gmail.com wrote:

(Please trim inclusions from previous messages) _______________________________________________ Well, enum comes to mind.

Eric

On Tue, Apr 22, 2014 at 4:09 PM, lleachii@aol.com wrote:

...

(Please trim inclusions from previous messages) _______________________________________________ Eric,

Actually, there are some SIP servers on AMPRNet already; and I'm capable of standing up a SIP server at my station. The only problem personally is that there's not much of a reason to stand up multiple SIP servers. Even

if

...

we did, it would be a good idea to standardize the call scheme to interconnect them, so we could dial those with SIP registrations on the various servers.

Regarding announcing services:

What exactly do those who want services announced wish to accomplish by having services announced over the network (and to the world if added to the DNS)?

My idea was more-so that those who don't mind informing the AMPRNet at-large that they have a service to share (and don't mind sharing that information) could post it to the list.

-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Lets not reinvent the wheel -- http://en.wikipedia.org/wiki/SRV_record

Example (for DPLUS D-STAR Linking)

Is this something that would be automatic or another manual process? New servers should just should up in the resource list. Servers off line should disappear. If it's on the list it should be live!

Bill, WA7NWP

Cory,

First, let me say, feel free to have your own opinion. I just wanted to note that technical specifications speak contrary to your point of view.

IP allocations follow a system specified in RFC2050; not because there's a majority consensus on the Internet that RIRs possess authority to issue IPs. The current DNS structure exists because of the specifications in RFCs 1034 and 1035, not because people simply agree. If they did not, or there was no global technical standard, there would be no guarantee of unique names and numbers, different networks may reach a different resource depending on their location (or not reach a resource whatsoever). Operating System developers would have no way of programming and configuring defaults for 'standards' such as IPv4, IPv6, DNS, DHCP, etc.

44.0.0.0/8 is, in fact, one network, as specified in RFC1166. Many folk have noted that they don't wish to have their allocation connect to others (or to the Internet for that matter); that's their option and their firewall. In the same token, we have others who come to the mailing list, asking how to get their allocations online. I personally see it as a success that I established connectivity to the rest of AMPRNet; and when I BGP in the future, I intend to maintain a 44GW that will be reachable via tunnel as well. Others are using thier allocations for purposes that would not have thier allocation connected to the rest of AMPRNet, only part time, or in some test/research capacity; that's OK too. Regardless, so long as they are not announcing thier allocation (with permission) from another AS, any Internet traffic destined to that subnet will travel to where 44.0.0.0/8 is announced - your argument that 44/8 is not one network fails on that one notion.

Jann,

You mentioned spoofing. This is the reason the encap file and route table should be kept private. Only other amateurs would know the location of the other endpoints.

Also, thanks for the compliments regarding the aprscode tool.

-KB3VWG

Eric,

So you're suggesting we totally do away with dynamic routing; and each station setup (and keep updated) routes to others GWs manually?

-KB3VWG

Actually you *BOTH* have it wrong. What I'm suggesting is exactly the use of *DYNAMIC* routing and routing protocols with no need for the encap file whatsoever with each subnet peering with the other subnets which they decide to voluntarily exchange traffic with. The connection between said subnets being done over an authenticated connection. Various subnets then provide transit to other non peered subnets by use of dynamic routing protocols. As it is right now with the tunnel mesh and encap.txt I'm as obligated to accept (and route) traffic from miscreant.ampr.org as I am from saint.ampr.org (at least if I follow the principles embodied in the full mesh concept).

Eric AF6EP

On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu marius@yo2loj.ro wrote:

(Please trim inclusions from previous messages) _______________________________________________ No, the suggestion is to drop the whole encap stuff and do manual P2P... And take down the whole global interconnection concept.

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Thursday, April 24, 2014 23:20 To: lleachii@aol.com; 44net@hamradio.ucsd.edu Subject: Re: [44net] What is 44net?

(Please trim inclusions from previous messages) _______________________________________________ Eric,

So you're suggesting we totally do away with dynamic routing; and each station setup (and keep updated) routes to others GWs manually?

-KB3VWG

I think the better model is BGP "nodes" which provide VPN to subnets. The BGP node admins would provide the VPN authentication to know what subnets were attaching and BGP would provide Internet connectivity (including subnets).

________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223

On Thu, Apr 24, 2014 at 3:50 PM, Don Fanning don@00100100.net wrote:

(Please trim inclusions from previous messages) _______________________________________________ Why mesh? I'm not seeing any advantage with mesh that you wouldn't have with the RIP broadcasts? I do agree that intra RIP packets may be warranted if networks with multiple gateways start popping up. Plus there's always the chicken and the egg part in that how would you authenticate and add new tunnels/bootstrap new nodes?

On Thu, Apr 24, 2014 at 2:43 PM, Eric Fort eric.fort@gmail.com wrote:

...

(Please trim inclusions from previous messages) _______________________________________________ Actually you *BOTH* have it wrong. What I'm suggesting is exactly the use of *DYNAMIC* routing and routing protocols with no need for the encap file whatsoever with each subnet peering with the other subnets which they decide to voluntarily exchange traffic with. The connection between said subnets being done over an authenticated connection. Various subnets then provide transit to other non peered subnets by use of dynamic routing protocols. As it is right now with the tunnel mesh and encap.txt I'm as obligated to accept (and route) traffic from miscreant.ampr.org as I am from saint.ampr.org (at least if I follow the principles embodied in the full mesh concept).

Eric AF6EP

On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu marius@yo2loj.ro wrote:

...

(Please trim inclusions from previous messages) _______________________________________________ No, the suggestion is to drop the whole encap stuff and do manual P2P... And take down the whole global interconnection concept.

-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Thursday, April 24, 2014 23:20 To: lleachii@aol.com; 44net@hamradio.ucsd.edu Subject: Re: [44net] What is 44net?

(Please trim inclusions from previous messages) _______________________________________________ Eric,

So you're suggesting we totally do away with dynamic routing; and each station setup (and keep updated) routes to others GWs manually?

-KB3VWG

Eric,

OK, well, since I want to get it *CORRECT* and I'm still not understanding you...I wanted to be certain you are aware that we currently use dynamic routing via two methods, ENCAP (so long as the station uses some method to regularly update the file) and RIP44. Where I'm seeking clarity is on the statement:

with each subnet peering with the other subnets which they decide to voluntarily exchange traffic with

If you receive a dynamic routing statement over RIP44 or ENCAP, you're receiving all valid routes from the core 44 router. You're suggestion implies that you'd remove routes you do not wish to communicate with; or you'd explicitley firewall them. That confuses me because you go on to state:

Various subnets then provide transit to other non peered subnets by use of dynamic routing protocols

Why would you delete/firewall routes from your dynamically populated table, just to have another gateway route traffic on your behalf (who received the route information from the same source)?

-KB3VWG

I'm still wondering if you all are joking, or if you all are serious.

I've seen alot of folk simply say "we'll just connect via BGP."

I have some serious questions: What ISP do you folk have at home that allows BGP?!?! Do you manage or own a business where you can "borrow" bandwidth and setup your own BGP?!?! Is your equipment already at a tower or location where you can peer with the carrier(s) present there!?!?

- I don't know of any consumer ISP that allows their customers to route via BGP - There's an assumption that every nation in the world has widely-available broadband Internet connections or that that every nation will permit a Ham to connect via BGP - I don't know of many Hams that happens to have a spare Cisco Nexus (or other commercial equipment capable of BGP) laying around - I don't know of any consumer connections that 1.) could handle traffic for a /8 without reaching some bandwidth cap or restriction and 2.) allows BGP, servers or commercial grade equipment to be connected to the node - If we BGP on the Internet, that requires every station to procure an ASN plus equipment that can speak BGP, that's a large cost of entry just to tinker around, if they can procure an ASNs from their RIR/LIR

Aside from all of those points, exactly how do we continue routing to those who won't setup BGP, cannot setup BGP and/or cannot afford to setup BGP???

-KB3VWG

John,

Does not mean end users need BGP A few, maybe as little as 10, border nodes might run BGP and *provide VPN/Tunnel services to everyone else* and not everyone needs to run the same VPN/Tunnel protocol.

Then who would be setting up this BGP??? Some of those who announce their allocations now refuse to maintain tunnels for others.

Your theories can be tested now, without BGP. My gateway startup script should currently allow someone to route traffic to other valid nodes, simply test by pointing your gatewawy towards mine, return traffic will be via thier route for you (multi-homing), add your BGP later.

The idea is to have a fully connected address space using the Internet/BGP to interconnect.

The address space is fully connected now, problem are you trying to solve?

There can be multi-homing and tiers to minimize single points of failure. How many of you can say your 'home' ampr-lan doesn't have a single point of failure?

The only way for my home ampr-lan to eliminate its single point of failure problem is to get a second ISP at home and BGP with both of them; but you state above that this "does not mean end users need BGP," so I'm confused.

Encap/IPIP and RIP tables could theoretically have 16 million entries for Net-44, why not use aggregation and a tiered network instead?

??? Theoretically, yes, if all the space in 44net were divided into /32's. Realistically, that is not the case. Your suggestion still requires AMPRGW and some select few to maintain a "more complete" routing table than the end user has; currently, we all have a copy of the full routing table.

As I see it, the end user would use a router (a cheap Mikrotik or RasPi) with one or more upstream VPN connections to a border node or sub-tier router and would route all non-local 44net traffic over that connection/those connections. All the user needs is a VPN/Tunnel configuration and credentials provided by the border node/tier router operator. So much simpler.

Think big net, not personal net.

You do know this is how AMPRNet currently works (minus the VPN portion), right?

-KB3VWG

John,

Failure to do so is grounds for losing one's allocation.

I wholeheartedly agree with you; but in practice, that has not been the case (see the archive).

----

I'd love to help begin testing this concept. My 44GW should currently forward traffic to other IPENCAP destinations. You'd simply have to use my GW's public IP as your tunnel's default route. If this works, then we simply have to work on connectivity and peering of the other GWs providing the service.

Please be mindful that return traffic will take a path via the route in the other endpoint's route table; meaning, that the destination 44GW must be using the current Encap file or RIP44.

-KB3VWG 44.60.44.0/24

It seems to me that tempers are running a little high and that we've reached a point where there is more heat than light in this discussion. What say we give it a rest and all cool off a bit? - Brian

Bart,

I confirm that I've also experienced the same symptoms on Comcast; but the protocol number is 4 (IPENCAP). I suspected it for weeks and determined it was occurring last week. I'm unable to tell with certainty if it's dropped packets due to Comcast, or simply packets lost in transit.

It's not very wise to drop random encapsulated packets; because in most cases, it would result in more traffic (e.g. a TCP encapsulated packet).

If you still wish to test this further, Ostinato is a packet crafter/generator.

https://code.google.com/p/ostinato/

An easier method would be to setup a 44tunnel and directly ping another user's node that happens to be on Comcast (my GW - 44.60.44.1).

-KB3VWG

On May 3, 2014 3:46 PM, lleachii@aol.com wrote:

I think Steve was talking about the reference to a "cell site." If this

was about a Ham Radio network, it would be the first time I've ever heard of a cell site operating according to Part 97 rules. I was actually gonna ask Bart about that myself.

"Cellular" describes a system where you have directional antennas and reuse frequencies. For example, all antennas pointing north use 5920 MHz. Nothing inherently anti-Part 97 there.

This page has a diagram. The "cell" Bart was talking about is referred to as a distribution node here: https://www.hamwan.org/t/tiki-index.php?page=Puget+Sound+Data+Ring

Tom KD7LXL

Does this DNS zone exist online somewhere? Is there's an authoritative nameserver that holds these entries?

If so, I'd like to setup my 44DNS server to just download the zone file. I've been somewhat confused receiving an email of DNS entries every so often. I'm wondering if there's supposed to be a resolver that holds these records.

-KB3VWG

paine-s1.hamwan ADD CNAME ether1.paine-s1.hamwan.net ether1.paine-s1.hamwan ADD A 44.24.240.131 wlan1.paine-s1.hamwan ADD A 44.24.240.145 corvallis-er1.hamwan ADD A 198.178.136.80 seattle-er1.corvallis-er1.hamwan ADD A 44.24.242.20 capitolpark.nq1e.corvallis-er1.hamwan ADD A 44.24.242.0 paine.k7nvh.corvallis-er1.hamwan ADD A 44.24.242.8 corvallis-srv1-kvm.corvallis-er1.hamwan ADD A 44.24.242.25 baldi.corvallis-er1.hamwan ADD A 44.24.242.2 paine.ae7sj.corvallis-er1.hamwan ADD A 44.24.242.4 wlan1.paine-s3.hamwan ADD A 44.24.240.177 ether1.paine-s3.hamwan ADD A 44.24.240.133 wlan1.paine.ae7sj.hamwan ADD A 44.24.242.7 corvallis-er1.hamwan ADD A 198.178.136.80

That's exactly what happens....

________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223

On Sun, May 4, 2014 at 7:00 PM, Nigel Vander Houwen nigel@k7nvh.com wrote:

(Please trim inclusions from previous messages) _______________________________________________ These are mistaken forwards to the mailing list, rather than the AMPR DNS robot. So, these are HamWAN DNS records that would be added to the ampr.org zone. We are sending these updates through our local coordinator, who has I assume occasionally mistyped the destination address to forward to. HamWAN is using the ampr.org zone as a workaround until we can get reverse DNS delegated so we can manage it ourselves on our authoritative nameservers.

Thanks, Nigel K7NVH

Yes, When creating A records, If I recall (I haven't been handling our DNS updates) PTR records are created, which is what we're after. We already manage our own A records within the hamwan.net and hamwan.org domains.

We are aware of needing to have DNS servers be available to various sources, and our authoritative (not recursive) servers already meet the need of serving external networks.

Nigel K7NVH

On May 4, 2014, at 7:15 PM, lleachii@aol.com wrote:

(Please trim inclusions from previous messages) _______________________________________________ Delegated reverse DNS for 24.44.in-addr.arpa?

...that's interesting.

FYI, you listed A records, one was not a 44 address. You'll still need those forward entries if you wish to reach a device by hostname.

Most records in the in-addr.arpa domain are PTR records. Also, just a suggestion, you'll have to make sure that the DNS server is available inside and outside AMPR, should it be delegated.

-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Actually, there are some SIP servers on AMPRNet already; and I'm capable of standing up a SIP server at my station. The only problem personally is that there's not much of a reason to stand up multiple SIP servers. Even if we did, it would be a good idea to standardize the call scheme to interconnect them, so we could dial those with SIP registrations on the various servers.

To deploy this kind of infrastructure we can use a SIP Server like ("OpenSer"). This server will be a login server and a router server (enroute call to the endpoints), and the mailbox and the rest of services (echo test, text to speech, etc.) can be in individual Asterisk Servers. With SIP we can implement Voice, presence and IM services.

In the other hand with SIP we can deploy RoIP (radio over IP) services. for example HYT repeaters has a SIP interface to link to a PABX services (like asterisk) using SIP protocol.

A few years ago, I was deploying a similar infrastructure into the guifi.net network (Spanish wireless network).

I have more ideas to deploy services (cross-link DMR repeater to SIP servers to make direct calls, for example), and I know that my spanish colleague Alberto Sagredo will be interested in participate in this project.

Kind regards Alex Casanova (EA5HJX)

Regarding announcing services:

What exactly do those who want services announced wish to accomplish by having services announced over the network (and to the world if added to the DNS)?

My idea was more-so that those who don't mind informing the AMPRNet at-large that they have a service to share (and don't mind sharing that information) could post it to the list.

-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net