[HamGateNY] Current NY State DNS Entries

[Corey Reichle]

On Mon, Jan 30, 2017 at 6:18 PM, Brian <n1uro at n1uro.ampr.org> wrote:

> Corey;
>
> On Mon, 2017-01-30 at 17:09 -0500, Corey Reichle wrote:
>
> > My subnet has no relationship to EastNet, and until recently, I had
> > only an inkling it existed.
>
> It's been around since the 80's... formed and maintained by K2BJG/SK
> until he became SK. Now I'm the engineer, developer, and ip coordinator
> for all of EastNet with the exception of 44.68/16 but I do maintain a
> great relationship with Charles and helped him with his system recently.
> I also contribute to the LinFBB project and JNOS projects.
>
>

Awesome!  Thank you for your contribution to the amateur radio service.


> > Yes, NIH.  As far as the 44/8 net is concerned, IMO, it's an IP space
> > reserved for amateur usage, and Brian Kantor is the manager of the
> > block.  AMPRGATE is there to be able to act as the AS for the address
> > block.
> >
> Actually, BK is the "owner" of 44/8. Amprgate is not the AS for 44/8 but
> one of the Junipers within UCSD is. Amprgate is the ipencap system for
> 44/8 and also sends out the Ripv2 broadcasts. Years ago it was referred
> to as mirrorshades (you may recall). It's OS is BSD.
>
>
While I'm unable to locate the RFC that allocates the 44 net space, I
believe BK is the coordinator of the space, not the owner.


> > Personally, I would like to see the 44/8 net space, as a whole,
> > operate as a modern network functions.  If not that level, I would
> > like to see the NYS AMPR network do so.  In any case, I will not be
> > employing any kludges just to get my network routed somewhere, as I am
> > more than happy to coordinate with individual network operators, and
> > set up peering arrangements with them.  Using industry standard
> > routing and bridging protocols.
> >
> An individual subnet may do what you wish (see my private mail) but the
> mass percentage of users are using ipencap. Ipencap is not a kluge. The
> true issue is with spoofing and route protocol hijacking which for their
> own protection ISPs filter. While it prohibits experimentation there's
> nothing you can't do on the other side of the link.
>
> >
>

I think we're conflating two things:  The "kludge" I refer to is the
routing protocol currently in "popular" usage.  ampr-ripd is, by all
definitions, a kludge, that was designed prior to the creation of modern,
dynamic, link-state protocols.

Ipencap, I merely take philosophical aversion to:  I refuse to send/receive
traffic from the public internet, via an insecure channel.  Ipencap is
insecure, and easily spoofed.  I have no guarantee I am routing traffic
from whom I am to believe the other party is, and is subject to alteration
on-the-fly.  This is where IPSec/OpenVPN tunnels comes into play, in my
mind.


> > And that's fine.  At this time, it's the only manner ARCD provides.
> > That doesn't mean it's set into stone, and unchanging.  The best way
> > to convince ARCD to employ another method is to show (By use) it's
> > better.
>
> OpenVPN at amprgate wouldn't be feasible and it'd take up too much of
> BK's time from his employment. There's also possible agreement issues
> between UCSD and ARDC that may not permit such a thing. This I'm unsure
> of. It may not have anything to do with ARDC. I can say, for the cost of
> a 44-net block vs leasing one from an ISP is a hell of a deal and one
> shouldn't look a gift horse in the mouth.
>
>
OpenVPN would take no more time than it does to configure end-points for an
ipencap tunnel.  However, of course, that is not my call to make, and is
subject to the operator of that equipment.

I, myself, personally, will not deploy an insecure tunnel over the public
internet, on my gear, as that is my call, as I operate and own my
equipment, and feel I have a moral duty to my end point users.


> > Well, seeing as anything going over the public internet would be
> > tunneled in the IPSec tunnel, they wouldn't be able to stop any of it,
> > as route adverts would be sent to neighboring peers, via their links.
> > Just like it works in every large-scale network on the planet.
>
> That would be dependent on the upstream's NOC. Many now scan frames for
> such traffic, others could care less.
>
>
No NOC can scan IPSec tunnels, other than to see they are IPSec tunnels.
Same with OpenVPN tunnels.  Hence, the entire point.


> > Some sort of routing is required to determine where to route IP
> > packets.  It's not magic that happens.  And, Flex32, last I checked,
> > has no package available for OpenWRT or Cisco routers.
>
> Cisco's support ipencap very well! For years I was routing 44/8 on my
> 2600 without a glitch using ipip. Most people don't understand it.
> Flex32? Would you like fries and a blue screen of death with the ecomm
> message sir? :) Again, you need to define the type of RF here, standard
> packet ax25 or 802.11ham? In standard packet, there's no IP route tables
> within flex yet it routes the frames dynamically. Remember, you only
> need to focus on the top layer which is ax25 NOT ip. Since Ip is
> encapsulated under ax25, where ax25 goes, so will the IP. Let me present
> a quick example of routing IP under flex... w1edh.ampr.org is 2 1200
> baud hops from me... not the ideal for IP but there's no netrom
> overhead. As you'll see, IP to w1edh (which has no IP at all except what
> I built via VHF) does work:
> n1uro-15 at n1uro.ampr.org:/uronode$ tra
> Executing command...
> what IP or HOSTName do you wish to trace? w1edh.ampr.org
> Please wait while we trace to w1edh.ampr.org...
> traceroute to w1edh.ampr.org (44.88.8.1), 30 hops max, 60 byte packets
>  1  gw.ct.ampr.org (44.88.0.1)  6.328 ms  6.499 ms  6.880 ms
>  2  k1yon.ampr.org (44.88.4.1)  56.844 ms  61.509 ms  65.469 ms
>  3  w1edh.ampr.org (44.88.8.1)  5028.054 ms * *
> Tracing complete.
> URONode tracer v1.3 - TraceRoute utility by N1URO.
> Goodbye.
> n1uro-15 at n1uro.ampr.org:/uronode$ t w1edh.ampr.org node
> Trying 44.88.8.1:node... <Enter> aborts.
> Socket established to 44.88.8.1:node
> (w1edh.ampr.org:uronode) login:
>
>
Again, conflating two concepts:  Wireline protocols, and routing
protocols.  IPv4 (And v6) are wireline agnostic.

What I am suggesting is to move away from monolithic networking stacks
(Relying on the "magic" of flex to handle wireline and routing), and to
focus on the IPv4 aspect.  IPv4 is very well documented, and understood,
and most OS's can handle all of that just dandy.

Perhaps a diagram is a good way to explain why I am not keen on using a
custom routing protocol.  Here is a quick diagram of my network:
https://drive.google.com/file/d/0B-myPYu9SCyBSFhVRXA2OTd0aTQ/view?usp=sharing

ie, 13 and 14 stations are 802.11 stations, that could have additional
clients connecting.  When these radios come and go, the network dynamically
updates it's routing tables via OLSR.  My entire network runs OLSR, so all
the routes get updated quickly, and there is rapid convergence.

The same protocol can scale up, without the need for one single point of
failure for routing updates, and routing loops are prevented due to the
routing protocol in use.

And yes, .4 is an AX25 link, which again, can have many clients behind it,
even a neighboring AMPRNet network.  And, it will dynamically update the
routing as those networks come and go.  The networks can even be connected
via 14 and 4, at the same time, and link quality will determine the best
route the network should use.

None of this is possible with ampr-ripd/RIP44/whatever we'd like to call it.


> There's fbb mail forwarding over that link too so that explains the
> temporary latency of 5s, however you don't see flexnet.k1yon or
> flexnet.w1edh in the path. It's transparent but it is passing the ax25
> frame (with IP under it) to it's destination. I thought the same as you
> "you need an ip route table to route ip" however I found in this case it
> isn't true at all. pc/FlexNet has no ip/rose/netrom route tables in
> it... just ax25. We're actually using the IP feature to do axip within
> the native netrom nodes for our NetRom gateways. This also helps gain
> EastNet access into my SQL server.
>
>
> We used to have a nice 9600 baud ax25/ip network from Central Mass
> through CT and down the Hudson river however many stations went dark.
> it'd be nice to see that rebuilt and act as a nice parallel to an
> 802.11ham network.
>
>
Maybe, just maybe, the network went dark, because newer, better
technologies were never adopted, to provide a single, unified,
decentralized network?

We can do that here, in the NYS network.  If we make NYAMPR great again,
others will see the example.



> > Sure.  OpenVPN is the single point of failure then, just like ipip
> > encaps are the single point of failure today.  Not seeing what the
> > difference is?
>
> The difference is, if amprgate went offline for whatever reasoning, I'd
> still have 44/8 access to the globe as it's point to point. In the case
> of Ireland, the entire country is cut off from the globe. An OpenVPN
> server for NYS that's failed for whatever reason could cut NYS off from
> the rest of the country, if not itself as well.
>
>
It would still be point-to-point networking, just using OpenVPN/IPSec
tunnels with peers, who dynamically update routes as they come and go.
This is not rocket surgery, and is done around the globe today.

If you peer with my network, over an IPSec tunnel, and we exchange routing
information, and I peer with KX2XX (Hopefully, not a real callsign), and
exchange routing, YOU can reach KX2XX's network via mine, and vice-versa.
If you, and KX2XX were to peer with Germany over an HF link, and do the
same, we could ALL reach Germany.

This is basic, dynamic routing.


> > I'm not talking about ipencap.  I'm referring more to the routing
> > protocol:  ampr-ripd.
>
> One doesn't have to use that. There's the munge system and loader files
> as well. Of course as public IPs change such a system would be out of
> date.
>
>
So, without ampr-ripd, what is the routing protocol?


> > Well, for this discussion, we're talking about the wire-line links
> > needed to bridge island networks, not available via RF.  Regardless,
> > many routing protocols work just fine for wire-line or wireless, such
> > as OSLR.
>
> Why not build the RF? Maybe find some RF sites to act as a bridge
> instead? If you can place a wire, you can build RF.
> >
> >
>

I'm actually all for that, which is why I'm not overly concerned with
hooking into ARCD via an insecure tunnel, and more interested in peering
with NYS networks.


> > Praytell:  How does one access an IPv4 address, via RF, without a
> > routing table entry for it?  Sure, I can call KC2UGV-8 via KTOWN, and
> > NetROM will make it happen.  But, without a routing table and route, I
> > cannot ping 44.x.x.x.
> >
> Within a Flex based ax25 wan, the route tables are at each end point.
> The rest is handled via ax25. Simple. Perhaps you might want to attend
> the next EastNet meeting which will be late springtime.
> >
> > So, routing protocols ARE required for IPv4 routing.  RF or wireline.
>
> Not in the case of a Flex based system, and it's quite dynamic in
> nature. I know for your position this sounds like the impossible, which
> was EastNet's stumbling block for about 5 years until I figure out just
> how to do this. In the interim, we were fed a lot of misinformation on
> getting xNOS to do IP on EastNet by the Gunter Jost himself.
>

Just because Flex handles routing, doesn't mean there's no routing
protocol.  And, yes, I understand NetROM is a dynamic routing protocol for
AX25 frames.

What I will tell you, from my experimentation, my network design above
would not be possible using Flex, and is only possible due to my use of an
IPv4 routing protocol like OLSR.


> >
> > We are talking about a unified IPv4 network, which is what this
> > mailing list is for:  The NYS operators of an IPv4 address space.  The
> > physical layer isn't really at issue here, aside from how we link
> > island together until we have RF links.
>
> The physical layer is the starting point in reality when you study your
> OSI layers, so it does matter. The physical layer of an 802.11ham point
> and that of an ax25 point are two totally different beasts as to what
> they can and/or can not do especially if you're comparing a PacComm Tiny
> 2 Mk II with an X1J-4 eprom to a Microtik. You wouldn't use OSPF on
> X1J-4, and I don't believe Microtik does NetRom.
>
>
>
AMPRNet is an IPv4 network.  IPv4 is wire-line/less agnostic, and doesn't
care what carries it.  I route (Today) IPv4 over AX.25, and over 802.11.
Dynamically.

So, I suppose, in summation, I am willing to peer with anyone over RF or
over an encrypted tunnel via the public internet.  I can exchange static
routes, or we can agree on a common, modern, dynamic routing protocol.


> --
> I don't have to worry about body fitness in 2017. All I do is
> show my body to itself in the mirror and it throws plenty of
> fits.
> --------
> 73 de Brian - N1URO
> email: (see above)
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> http://uronode.sourceforge.net
> http://axmail.sourceforge.net
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Maryland, Massachusetts,
> New Hampshire, New Jersey, Pennsylvania,
> Rhode Island, and Vermont.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://n2nov.net/pipermail/hamgateny_n2nov.net/attachments/20170131/15b99909/attachment.htm>