Re: [44net] Network 44.190.0.0/16 - Further information

Where this network is located (where the BGP advartuse point to ) ? 4z4zq Ronen http://www.ronen.org [http://www.ronen.org/My-QSl.jpg1zB]<http://www.ronen.org/> Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com www.ronen.org ________________________________ From: 44Net &lt;44net-bounces+ronenp=hotmail.com(a)mailman.ampr.org&gt; on behalf of Jann Traschewski &lt;jann(a)gmx.de&gt; Sent: Wednesday, May 9, 2018 2:36 AM To: 44net(a)mailman.ampr.org Subject: [44net] Network 44.190.0.0/16 - Further information Description: The network 44.190.0.0/16 is available to host amateur radio internet services using direct BGP. Allocations will be made usually in /24 chunks. The focus of this network is to transfer data as direct as possible (no radio, no tunnels) to keep reliability high. AMPRNet systems with no dynamic routing protocol support are able to route 44.190.0.0/16 via their ISP. Background: AMPRNet allocations are not partitioned by connectivity type. Each individual network can either be of type "radio", "tunnel" or "direct". AMPRNet systems may be "dual homed" and have a line based and a radio connection, thus there needs to be a decision whether a packet should be forwarded by line or by radio. This _could_ be achieved by AMPRNet systems *with* dynamic routing protocols by learning the routes and treating each route by its type (or any other available "flag"). However this will _never_ be the case for AMPRNet systems *without* support for dynamic routing protocols. Endusers running a *radio* connection to AMPRNet infrastructure such as HAMNET User Acess Points, IPIP-Mesh Gateways or even direct-BGP Gateways might ask how to integrate the radio connection into their home-LAN to have permanent access using any device on their LAN. Unfortunately standard home routers do not provide dynamic routing protocols, but there is often the functionality to add additional static routes like "44.0.0.0/8 via radio" and "44.190.0.0/16 via ISP". Sometimes customers are *forced* to use the router provided by the ISP to access the Internet (such a requirement is prohibited by law in Germany). Those might have no functionality to set static routes at all and you might end up attaching another router to the router to gain more functionality... As of today the standard setup for "dual homed" AMPRNet systems *without* support for dynamic routing protocols is to add 44.0.0.0 netmask 255.0.0.0 via <radio device within the home-LAN>. Outbound connections to 44.x.x.x will be made by their radio with the source-44 address and outbound connections to the Internet will be made with the source address obtained from the ISP. This worked without any issues as long as there were no direct BGP allocations within the network44. Nowadays we have several amateur radio internet services provided on the Network44 by direct BGP and the accessibility for the above mentioned AMPRNet systems highly depends on a proper radio connection and the backbone infrastructure to transfer the packet to its destination. The idea of 44.190.0.0/16 is to give willing stakeholders the opportunity to improve the situation. Amateur radio internet services can be hosted in that range while AMPRNet systems can make use of the additional route 44.190.0.0/16 via their ISP. The following issue has much more impact: Once direct BGP allocations started within the Network44 we encountered situations of full incompatibility. It is the case for amateur radio internet services (e.g. Echolink) working with a directory to map callsigns to IP addresses. Echolink does learn the IP address of an Echolink station (respectively of the used Echolink Proxy or Relay) from the inbound connection to the directory service. This leads to the problem, that AMPRNet systems forwarding 44.0.0.0/8 to the radio device on the roof will not have a slow or weak connection to a Echolink station using direct BGP but even *no* connection at all. Since they are registered on the Echolink network with their IP address obtained from the ISP but appearing with their Network44 address used over radio at the Echolink station using direct BGP, the connection is dropped due to a mismatch between "IP address <-> callsign". This will not happen if Echolink Relay/Proxy Servers or Echolink Stations will make use of address space from 44.190.0.0/16 while AMPRNet systems route 44.190.0.0/16 via their ISP. There will be no IP mismatch anymore. I made a diagram explaining the situation: http://db0fhn.efi.fh-nuernberg.de/~dg8ngn/echolink-amprnet.pdf 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX / DB0FOX / DB0ZM / DB0DBA / DB0HZS _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net