[44Net] gateway updates - HIGHSPEED HAMNET
mcdermj at xenotropic.com
Thu Mar 25 09:51:20 PDT 2010
On Mar 25, 2010, at 10:42 AM, Steve Stroh wrote:
> Excellent comments towards the end there.
> In saying this next, I may be duplicating what's being done or what
> can be done. In describing this, I'm thinking about what's doable for
> the slightly-above-average digital knowledge ham.
> I think what we're going to devolve to is:
> 1. Each Radio LAN (each "collision domain") to get a semi-static
> gateway IP address that's Internet routable
> 2. Addresses within the RLAN are dynamically assigned and not
> necessarily routable (IE 10.x.x.x or 44.24.x.x)
This is essentially how the IPv6 pieces I proposed would work. IPv6 is nice in that it has an idea of a "router advertisement" where the router announces not only its address, but the prefix that is active on the segment. The client combines the 64-bit prefix with a 64-bit munging of its 48-bit MAC address, and comes up with a guaranteed unique address on the segment. So, now it essentially knows the equivalent of it's address, netmask, and default gateway. This is all performed with a simple multicast by the router. There's no back-and-forth of DHCP. This is one of my motivations for proposing it.
> 3. Individual users within the RLAN are "somehow" (much arm waving at
> how this is actually done) assigned hostnames -
I'm not sure the hostnames are really important here, it's more address assignment. What would be really cool is to provide an automated registration system where trusted users could log on and have DNS names like:
That they can delegate to themselves. For example, I could set up:
That would server XMPP chat for whomever wants to use it. We'd have to sketch out more details of the DNS, but this isn't necessarily that hard.
> 4. Communications between every RLAN have to be set up mostly by hand
> OR by periodically loading some list of gateway IP addresses that you
This is where BGP comes in. You have to establish BGP neighbors by hand. Networks would be responsible for interconnecting with themselves on an ad-hoc basis. The networks that want to talk to each-other certainly can, but there's not requirement. There might also be places for people who wanted to run central exchange points for regional traffic, etc.
> 5. Between each gateway you trust, there's an SSH tunnel.
I'd implement this with a more permanent tunnel, hence the proposal for v6 over v4 tunnels. They'd go along with the BGP4 sessions that would ride over them to distribute routing information.
> 6. When someone from another RLAN wants to communicate with me, they
> use the hostname to send traffic - email, ftp, etc. to my system. The
> packets route directly between the LANs - no central authority.
There's always a central authority somewhere. In this case, there are two:
1) Somebody has to run the DNS space. Either you're going to outsource it to the Internet, or someone on the network has to register names.
2) You're relying on the bi-lateral agreements of the people who run the segments. This is mildly the user relying on central authority.
> What I like about this idea is that it's relatively simple and
> decentralized. If you want to play, you only need to work things out
> with the systems you want to play with. Kind of like every repeater
> that wants to do linking works it out with the repeater they want to
> link with, vs having to "Mother, May I?" with a central authority
> (EchoLink being the exception, I think).
No, I certainly agree with you here. The Internet is really built on bi-lateral agreements, and it works out fairly well so far. The reason why you use BGP in these environments, though, is that it expresses *policy*, which is important in your model. Here's why.
Let's say Seattle has a bilateral agreement with Portland. I now establish some sort of bilateral peering between Corvallis and Portland. Does Seattle want my traffic? They don't have an agreement with Corvallis. It's fine if they do, but if they *don't*, BGP allows that sort of policy expression rather easily. RIP has very few knobs you can turn to implement these sorts of policy decisions.
> Given Brian's dichotomy of "we'll be doing it MY way, folks" / "what
> you guys decide you want to do", it doesn't seem likely that we'll
> make much progress during Brian's reign as Net44 czar. My scheme above
> doesn't really rely on the use of Net44 addresses.
I would suggest that we would not want to rely on 44/8 addresses. But, if you're going to interconnect networks, you're going to need to make sure that addresses are coordinated somehow so that they don't step on one another. I don't know what ARIN's policies are right now, but this is another reason to investigate v6, because ARIN is handing out addresses rather freely right now, and presents us the opportunity to set up a HamNOC for a /32 v6 address (which would provide us with *LOTS* of subnets).
> I agree wholeheartedly about your suggestion of moving on to IPv6. It
> was designed to be more secure, more scalable, and best of all, was
> designed in the "Mobile Internet" era, so it's much more capable for
> mobile / intermittent access situations like Amateur Radio. Plus, it's
> a NEW learning experience for Amateur Radio.
It allows us some interesting new stuff to explore, and possibly allows us to push the state of the art on the network layer. Plus, it has some features that would make it kinda nice for the next generation wireless networks we want to explore.
> I fully intend to be doing IPv6 over my (slow, antiquated) Amateur
> Packet Radio systems. I bet it can be made to work, and work well.
I think the biggest stumbling block is that it tends to be a little bit chattier than v4, which might not work out so well on slower networks, but I'd be interested to see your experiences for sure.
I've been doing some work on my MacHPSDR program and working with SDR and DSP quite a bit over the last couple of months, and what I would kinda thing would be an interesting project is some sort of SDR to do some of this high speed stuff. The next generation OpenHPSDR control board is going to have a gigabit ethernet interface on it, so that might be fun to play with. And there is going to be the possibility of running the gear on higher frequencies by looking at the aliases. The A/D converter is 120Msps, so you should be able to pull off at least 60MHz bandwidth signals with it. Anyhow... interesting things to think about in my copious spare time trying to graduate from law school.
Speaking of which, if you folks have anything you want investigated at Dayton, it turns out I'm going to be there this year. I'll be doing some demos in the TAPR booth, and giving a short talk on MacHPSDR in the SDR Forum.
Jeremy McDermond (NH6Z)
mcdermj at xenotropic.com
More information about the Seatcp