The reason (1 and 2) is that for a typical system that has both a public IP and an AMPRnet IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet IP to be reachable from public IP addresses on internet. Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet traffic is to go out via the IPIP tunnels. When such a system is on a source-address filtered internet connection, the default route for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system that has unfiltered internet access. Typically the system at UCSD. It is preferred that the varying gateway systems are configured only via RIP (usually in a separate route table), and that it is not required to make specific policy routing configuration for gateways. So the policy routing is static for 44.0.0.0/8. This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed by the routing policy (which is used both for the actual traffic and the encapsulated packets). When people see a way around that (I don't completely oversee if Jann's suggestion will achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please see the example configuration for Linux systems in the wiki and suggest a way how that could be made working without manual "ip rule" entries dedicated to specific gateways. Or else, those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine as well. Aside from that, of course it should still be validated that tunnel endpoints are not within the subnet being tunneled (3). That is simply an error condition. There were some networks that were claimed to be reachable via a tunnel at their first address (Sweden, for example) and there were some entries with tunnel endpoint == tunneled address. The portal should refuse that so that applicants are made aware of their error before such entries are broadcast via RIP and result in encapsulation loops. Rob