Hi Rob, Le 19/04/2018 à 19:07, Rob Janssen a écrit : I'm quite a beginner here, but here's my personal opinion. And I don't agree with you, HI :-) I think original routing methods are not easy to use and have drawbacks : - eBGP is not available to end-users, or even to small teams or repeater operators. It requires network skills, and access to telecom operator data centers. - ripd over IP-IP is nice, but it has severe drawbacks in nowadays'world : not talking about security (plain text password !), AMPRNet hosts behind IP-IP tunnel can not communicate with non-AMPRNet hosts, and this causes problems for digital modes such as D-Star or DMR. If a D-Star repeater in Paris on AMPRNet IP behind IP-IP tunnel wants to communicate with another D-Star repeater in Paris hosted on public Internet (99% of them), their communication will go through AMPR gateway at UCSD, which is not optimal at all ;-) One of the main purpose of amateur radio is to experiment new things. Then, I think it's globally a good idea to experiment new routing variants, that are more suitable with today and tomorrow usages. Of course, this will raise compatibility issues and routing problems. But that's our job to find solutions :-) Here, in Corsica, we'll try to adapt our home-made system (OpenVPN tunnels to two central gateways, and OSPF routing through 10.0.0.0/8 private addressing) to AMPR addressing. One of the main advantages is that user connection is very easy (we developed a Plug and Play system called "TKBox" : an OpenWRT router, which opens VPN tunnels to our two data centers, in VPN pass-through mode). It's suitable for a remote location such as our island, because our two data centers will be the only points of connection with the outside world. All the specific routing and firewalling has to be tone only there. Jann's project about 44.190.0.0/16, even if I didn't understand yet how it works ;-) also seems a good idea for me. The global idea of local or regional BGP platforms seems good to me, because it does not break existing things, thus allowing more 'direct' communications with public Internet (without having to go through San Diego gateway). Moreover, having such a BGP gateway in every country should facilitate firewalling/control about what is allowed by local rules, and what is not. We addressed that in our TKNet design : things that do require communication with public Internet (Echolink, D-Star, DMR) will be located in a dedicated "DMZ" zone of the firewall, with specific access rules. The "normal" amateur radio equipments (such as a remote HF station) will remain in the "private" part of the network, with no Internet access. Of course, we all must have an "overall" approach, so that those new experiments must (as far as possible) remain compatible with existing (old) things. 73 de TK1BI

Hi! First time posting to the mailing list... Name is Bradley, call is KG5GPK. I just wanted to put my opinion in this. Some people (such as the quote) don't believe in separating addresses based on the type of traffic. I do believe i understand the issue is EchoLink traffic is too much to route over the air? Keeping their radio busy? So what if instead of putting echoLink traffic on a new block, we have special data in the headers of the packet.. One that would help the server identify traffic such as echolink. But this would require some kinda proxy that inspects the headers.. Then routes it correctly. On Thu, Apr 19, 2018, 1:07 PM Rob Janssen <pe1chl(a)amsat.org> wrote: > > >/when the directory server is on AMPRnet, the problem with NAT between > /> >/HAMNET and internet disappears / > > I'm afraid, it would raise new issues... > > > For those who are planning to provide echolink proxy services (or any > > other useful internet based amateur radio services) within the AMPRNet > > by direct BGP, please ask for an /24-allocation within 44.190.0.0/16. > > > We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to > > their ISP rather than to their radio device on the roof. > > > Best case would be to host such services on non-44 IP-space at all. > > As you know, I don't agree with that. We should not segregate our > addresses > into different classes and force everyone into some class depending on what > they want to do. It is a stopgap measure that will lead to endless changes > and work, and it isn't even clear what "internet based amateur radio > services" > are exactly. For example, our repeaters are on Echolink on their AMPRnet > address, they > would be such services, we would have to route part of that space deeply > into our > network to get "special" addresses all the way there. Not going to happen! > > At the moment I am in contact with the Jonathan from Echolink and he is > interested > in setting up more relays as his existing relays in the US are getting > overloaded. > (he has temporarily moved some US users to our relays in Amsterdam) > > I think now that this is under change we could suggest moving everything > to AMPRnet > and it should solve the NAT problem there is now. Maybe the directory > server could > have both an AMPRnet and a public address to resolve remaining issues. > > Rob > >