25 Apr
2018
25 Apr
'18
1:11 p.m.
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
>
>