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(a)gmail.com
On Mon, Jun 11, 2012 at 12:45 AM, Geoff Joy <geoff(a)windowmeister.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Mon, 11 Jun 2012 02:52:55 +0300, "Marius Petrescu"
<marius(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net