I think you hit the nail on the head, Geoff.

I have been using my 44-net addresses as "private" IP addresses on my local LAN for years. There is absolutely no reason why you can't do this and it simplifies an awful lot of things. IP addresses are just numbers. Private IP addresses can be anything you want them to be. And if this design can serve double duty for you, then that's even better.

I had modified my own gateway software to set up a default SAFe (source address filtering) tunnel and then make the LAN smart enough (by dividing the IP address space in half) to know what part of the LAN produced 44-net traffic and what part of the LAN didn't. The LAN part that didn't produce 44-net traffic simply used its 44-net address privately (like any other private IP address) and defined its outgoing default IP route to the LAN router. The LAN part that did produce 44-net traffic simply defined its outgoing default IP routes to the IPIP gateway (instead of the LAN router).

Once the outgoing 44-net traffic was at the gateway, if its destination was a non 44-net IP address, then it chose the default SAFe tunnel I had set up to a well-connected IPIP gateway somewhere else (which I managed) that was itself not source address filtered and was able to put 44-net sourced frames on its network without them being considered spoofed. This was back in the day when we could not use mirrorshades for that purpose. Now, I understand that the newer amprgw does have this capability and that is a very good thing for the community.

Geoff, you are absolutely correct that as things stand now, peering could not be implemented between the traditional IPIP network and other autonomous 44-net systems on the internet, precisely because of the SAFe issue. You would otherwise continue to have to use amprgw as a destination for bouncing your 44-net sourced frames to this kind of system, and, this kind of system would still have to set up an IPIP gateway anyway just to accommodate the rest of the 44-network and it would become another IPIP-encapped destination for their 44-net address block(s) just like all of the others in the encap.txt file.

No doubt the folks who want to accomplish doing this have already figured all this out because they are very smart folks, but I believe it is the idea that the possibility exists for part of our network to become isolated and not connected with the rest of it that has some people wanting to go slowly with this. This is already happening with the few subnets that are being BGP-advertised off UCSD-site, and I think the gateways community needs to be prepared to deal with the issue of increasing non-connectivity when the numbers of these autonomous systems starts increasing.

If neither the traditional IPIP gateways community nor the folks who want to BGP-advertise don't care about the connectivity divide between the two, then there is probably no reason they cannot have their "slice of the pie" but that is not my decision to make.

--
73, de Barry, K2MF >>
k2mf.bgs@gmail.com

On Mon, Jun 11, 2012 at 12:45 AM, Geoff Joy <geoff@windowmeister.com> wrote:

(Please trim inclusions from previous messages)
_______________________________________________
On Mon, 11 Jun 2012 02:52:55 +0300, "Marius Petrescu"
<marius@yo2loj.ro> wrote:

>No spoofing. Just plain and simple NAT to your public IP.

If you are using NAT you don't need a 44.x.x.x address. In that case
there is no difference between hiding a 44net address and a 10net
address behind the NAT.

The whole point of this discussion, as I understand it, is how to
implement peering between AMPRNET and other autonomous systems on the
net. This would allow routing of 44net addresses without need for NAT
or tunneling.

The difficulty lies in getting ISPs to allow "ordinary users" to
maintain 44net IP addresses or networks and advertise routes from
within that ISP.

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