AHCP and amateur radio

Sat Nov 24 10:50:39 EST 2012

Changing the subject to match the thread about the AHCP protocol...

On Fri, Nov 23, 2012 at 10:26 PM,  <dpreed at reed.com> wrote:
> Regarding AHCP...  it occurs to me that AHCP might be a better choice than
> the alternatives for use in Amateur Radio internet environments with IPv6.

Being able to form ad-hoc networks, particular in an emergency, over
whatever internet connectivity can be had, strikes me as rather
useful. And needed.

> I would like to see a very future-oriented approach to IPv6 in Amateur
> Radio.

So would I! I would like it very much if there was (for example)
globally routed portable IPv6 address space optimized for efficient
address allocation and multihomed with multiple, supported exit
points, with efficient internal routing.

An approach with AHCP for address assignment is promising,
particularly over ipv6, as obtaining a useful prefix is a pair of
packets, and routing information not that much more.

> There are some quirks in the rules for Amateur Radio that mean that
> Amateur Radio subnetworks (unlike "open wireless" networks) have to have
> every message transported directly traceable to a licensed operator, cannot
> be obscured, and cannot contain "music".   (I know, the rebel in me feels
> this is not a good thing, but when operating with my Ham hat, I understand
> the reason to color within these lines, in order to be a "good netizen" in
> Ham circles, and to be constructive in gaining support from the various
> constituencies that support Amateur Radio's special status worldwide. There
> is no benefit whatever to using terms like "war-driving" in conjunction with
> Amateur Radio just to get your name in the papers).

I appreciate the seriousness by which the amateur radio operators take
their responsibilities, but I have to think, the field would have been
more fun in the early 1900s, with giant spark generators, and the
like.

> It's perfectly reasonable to carry IPv6 traffic as datagrams over radio
> networks operated by cooperating Amateurs. (and could be hugely beneficial
> in situations like Hurricane Sandy)  What we don't have is a "stack" that is
> best tuned for this style of internetworking.

I'm not familiar enough with the current state of packet transfer over
the any medium available to amateurs. I just added several hams I know
to this discussion.

One of my own interests is in communicating with satellites in GTO better...

> Part of the stack needs to include IPv6 address assignment and routing, and
> also bufferbloat-prevention.  My thought is that AHCP and other components
> useful for Cerowrt deployment would be suitable for an Amateur Radio IPv6
> stack.

> Also, I have some ideas about low-level ways to ensure that there is
> always a responsible, licensed "control operator" for any messages delivered
> over Amateur Radio-licensed IPv6 transport paths, which I have begun working
> on.

Certainly not randomly distributing /64s around would help, as would
the authentication
features in the latest babel drafts.

That said, a DV protocol such as babel fails to scale to 10s of
thousands of users,
presently. (so do most/all other protocols) - so some
division/protocol split of backbone
and local mesh seem needed.

I have no idea how far up AHCP would scale, but higher than that as
(with ipv6) there is no need for a database, just a functioning
prefix.

> That long discursion suggests that a simple AHCP server and client
> implementation would be very, very helpful in a wider scope of usage.  One
> that brought IPv6 to Raspberry Pi might be just the ticket, since
> interfacing such a board to off-the-shelf transceivers is pretty easy for
> many Ham hobbyists.

My fresh new pi "just works" with ipv6, ahcp, and babel, once you
insert the ipv6 kernel module. It even runs bgp. It picks up RAs and
goes on the ipv6 front. I'm not happy about the throughput on ethernet
(75Mbit) but I suspect what you want to do will run at considerably
less thant

But it does seem wonderfully hackable to do many things, including
what you describe.

> (beware - you really should be aware of the "band
> management" done by the ARRL, so you stay in the subbands where digital
> signalling is encouraged.  The 1.2 GHz band and above are preferable, and
> maybe the digital portion of  440 MHz, esp. if you don't disrupt the FM
> phone activity there).

Lasers. IR. fun stuff like that?

>
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht at gmail.com>
> Sent: Friday, November 23, 2012 12:27pm
> To: cerowrt-devel at lists.bufferbloat.net, "bloat-devel"
> <bloat-devel at lists.bufferbloat.net>
> Subject: [Cerowrt-devel] cerowrt-next plans
>
> I did finally get around to booting the ubnt linux 3.6.7 build I
> talked about yesterday.
>
> Yea! It worked.
>
> Boo! I have a ton of patches to modify to get back to equivalence with
> what's in cerowort-3.3.8-27
>
> So I'm planning on forking the "stable" cerowrt 3.3 repository for new
> development on 3.6,
> and am calling it cerowrt-next. I may blow it away entirely and rebase
> on openwrt. Nobody
> look!
>
> In the interim perhaps I'll stick up the ubnt-3.6.7 code, but there
> seems to be no demand, sooo...
>
> Updates:
>
> * Steven Walker made a bunch of updates to ceropackages the other day,
> I haven't tested.
> thx steven. If anyone wants an updated ccnx-6.2, in particular, it's
> there...
>
> * Openwrt Head
> * Radvd must die - in favor of either dnsmasq or quagga
>
> Backports:
>
> * IPv6 performance patch
> * Multiple versions of fq_codel
> * QFQ+
> * Wireless diffserv patch
> * Memory reduction patches in pfifo_fast and codel
>
> Whatever other patches didn't make it up to openwrt
>
> New development:
>
> * Randomness/entropy framework infrastructure buildout
> The new randomness frame in 3.6 and later requires driver support in
> order to work well.
> Good crypto in things like WPA, and SSL requires good entropy.
>
> A lot of people have been thinking "ooh, random numbers fixed in
> embedded linux since 3.6"
>
> Um, no. Well, partially...
>
> http://lwn.net/Articles/507115/
>
> * TCP Fast Open test support
> TCP fast open is supported server side in 3.6. There is some
> preliminary support for it in netperf now
>
> * AHCP in dnsmasq
>
> After watching the deliberations on homenet, and knowing ahcp fits a
> niche not addressed there,
> and knowing that it solves a need that cannot be met by SLAAC, dhcp,
> dhcp-pd, or ospf+pd,
> and after losing many battles with ahcpd, and knowing AHCP NEEDS TWO
> implementations
> to go ietf standard track...
>
> I started hacking on the core idea one weekend 18 months ago. I
> figured if I just got a couple weekends
> more free I'd be able to get the protocol into dnsmasq at the cost
> of a couple k in binary, and save a mb of ram.
>
> I decided that dnsmasq was the right place to stick it, given that
> it managed address assignment
> already for multiple other protocols. It turns out than an AHCP
> server is even simpler than the
> client. I then started having some thoughts towards having prefix
> distribution and border discovery in it...
>
> and felt that writing a fresh implementation would be a good start
> towards understanding these
> complex issues.
>
> Sadly, those weekends have not happened yet. :(
>
> It would be nice to find someone to work with to continue getting
> this into dnsmasq. ? Even as an exercise,
> it's a good exploration into how ipv6 multicast actually works....
>
> Anyway I just folded in somepatches that compiled and opened up the
> port into the current dnsmasq tree
> and put it up on github. It does very little else...
>
> My github repo for dnsmasq-ahcp: https://github.com/dtaht/dnsmasq-ahcp
> Protocol Specification:
> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.html
> existing ahcp server/client code and doc:
> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/
>
> Alternatively getting another ahcp server written in another
> language would be good.
>
> * DLNA (?)
> * small DHCP-PD support
>
> Wide is not working out, isc and dibbler are too huge. It's time for
> someone to write a small one... (not me!)
>
> Other suggestions for the upcoming development cycle?
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html