From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp141.iad.emailsrvr.com (smtp141.iad.emailsrvr.com [207.97.245.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 19F3421F0AE; Fri, 23 Nov 2012 13:26:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp34.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 6CA0A38020B; Fri, 23 Nov 2012 16:26:16 -0500 (EST) X-Virus-Scanned: OK Received: from legacy9.wa-web.iad1a (legacy9.wa-web.iad1a.rsapps.net [192.168.4.111]) by smtp34.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2CB97380193; Fri, 23 Nov 2012 16:26:16 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy9.wa-web.iad1a (Postfix) with ESMTP id F2AAEFF8001; Fri, 23 Nov 2012 16:26:15 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 23 Nov 2012 16:26:15 -0500 (EST) Subject: RE: [Cerowrt-devel] cerowrt-next plans From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20121123162615000000_90422" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1353705975.992510644@apps.rackspace.com> X-Mailer: webmail7.0 X-Mailman-Approved-At: Fri, 21 Dec 2012 08:31:29 -0800 Cc: bloat-devel , cerowrt-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 23 Nov 2012 21:26:18 -0000 X-Original-Date: Fri, 23 Nov 2012 16:26:15 -0500 (EST) X-List-Received-Date: Fri, 23 Nov 2012 21:26:18 -0000 ------=_20121123162615000000_90422 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ARegarding AHCP... it occurs to me that AHCP might be a better choice th= an the alternatives for use in Amateur Radio internet environments with IPv= 6.=0A =0AI would like to see a very future-oriented approach to IPv6 in Ama= teur Radio. There are some quirks in the rules for Amateur Radio that mea= n that Amateur Radio subnetworks (unlike "open wireless" networks) have to = have every message transported directly traceable to a licensed operator, c= annot be obscured, and cannot contain "music". (I know, the rebel in me f= eels this is not a good thing, but when operating with my Ham hat, I unders= tand 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 variou= s constituencies that support Amateur Radio's special status worldwide. The= re is no benefit whatever to using terms like "war-driving" in conjunction = with Amateur Radio just to get your name in the papers).=0A =0AIt's perfect= ly reasonable to carry IPv6 traffic as datagrams over radio networks operat= ed by cooperating Amateurs. (and could be hugely beneficial in situations l= ike Hurricane Sandy) What we don't have is a "stack" that is best tuned fo= r this style of internetworking.=0A =0APart of the stack needs to include I= Pv6 address assignment and routing, and also bufferbloat-prevention. My th= ought is that AHCP and other components useful for Cerowrt deployment would= be suitable for an Amateur Radio IPv6 stack. Also, I have some ideas abou= t low-level ways to ensure that there is always a responsible, licensed "co= ntrol operator" for any messages delivered over Amateur Radio-licensed IPv6= transport paths, which I have begun working on.=0A =0AThat 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 Raspber= ry Pi might be just the ticket, since interfacing such a board to off-the-s= helf transceivers is pretty easy for many Ham hobbyists. (beware - you rea= lly 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 a= nd above are preferable, and maybe the digital portion of 440 MHz, esp. if= you don't disrupt the FM phone activity there).=0A =0A-----Original Messag= e-----=0AFrom: "Dave Taht" =0ASent: Friday, November 2= 3, 2012 12:27pm=0ATo: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" =0ASubject: [Cerowrt-devel] cerowrt-next p= lans=0A=0A=0A=0AI did finally get around to booting the ubnt linux 3.6.7 bu= ild I=0Atalked about yesterday.=0A=0AYea! It worked.=0A=0ABoo! I have a ton= of patches to modify to get back to equivalence with=0Awhat's in cerowort-= 3.3.8-27=0A=0ASo I'm planning on forking the "stable" cerowrt 3.3 repositor= y for new=0Adevelopment on 3.6,=0Aand am calling it cerowrt-next. I may blo= w it away entirely and rebase=0Aon openwrt. Nobody=0Alook!=0A=0AIn the inte= rim perhaps I'll stick up the ubnt-3.6.7 code, but there=0Aseems to be no d= emand, sooo...=0A=0AUpdates:=0A=0A* Steven Walker made a bunch of updates t= o ceropackages the other day,=0AI haven't tested.=0A thx steven. If anyone = wants an updated ccnx-6.2, in particular, it's there...=0A=0A* Openwrt Head= =0A* Radvd must die - in favor of either dnsmasq or quagga=0A=0ABackports:= =0A=0A* IPv6 performance patch=0A* Multiple versions of fq_codel=0A* QFQ+= =0A* Wireless diffserv patch=0A* Memory reduction patches in pfifo_fast and= codel=0A=0AWhatever other patches didn't make it up to openwrt=0A=0ANew de= velopment:=0A=0A* Randomness/entropy framework infrastructure buildout=0A T= he new randomness frame in 3.6 and later requires driver support in=0Aorder= to work well.=0A Good crypto in things like WPA, and SSL requires good ent= ropy.=0A=0AA lot of people have been thinking "ooh, random numbers fixed in= =0Aembedded linux since 3.6"=0A=0AUm, no. Well, partially...=0A=0Ahttp://lw= n.net/Articles/507115/=0A=0A* TCP Fast Open test support=0A TCP fast open i= s supported server side in 3.6. There is some=0Apreliminary support for it = in netperf now=0A=0A* AHCP in dnsmasq=0A=0A After watching the deliberation= s on homenet, and knowing ahcp fits a=0Aniche not addressed there,=0A and k= nowing that it solves a need that cannot be met by SLAAC, dhcp,=0Adhcp-pd, = or ospf+pd,=0A and after losing many battles with ahcpd, and knowing AHCP N= EEDS TWO=0Aimplementations=0A to go ietf standard track...=0A=0A I started = hacking on the core idea one weekend 18 months ago. I=0Afigured if I just g= ot a couple weekends=0A more free I'd be able to get the protocol into dnsm= asq at the cost=0Aof a couple k in binary, and save a mb of ram.=0A=0A I de= cided that dnsmasq was the right place to stick it, given that=0Ait managed= address assignment=0A already for multiple other protocols. It turns out t= han an AHCP=0Aserver is even simpler than the=0A client. I then started hav= ing some thoughts towards having prefix=0Adistribution and border discovery= in it...=0A=0A and felt that writing a fresh implementation would be a goo= d start=0Atowards understanding these=0A complex issues.=0A=0A Sadly, those= weekends have not happened yet. :(=0A=0A It would be nice to find someone= to work with to continue getting=0Athis into dnsmasq. ? Even as an exercis= e,=0A it's a good exploration into how ipv6 multicast actually works....=0A= =0A Anyway I just folded in somepatches that compiled and opened up the=0Ap= ort into the current dnsmasq tree=0A and put it up on github. It does very = little else...=0A=0A My github repo for dnsmasq-ahcp: https://github.com/dt= aht/dnsmasq-ahcp=0A Protocol Specification:=0Ahttp://www.pps.univ-paris-did= erot.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.html=0A existing ahcp s= erver/client code and doc:=0Ahttp://www.pps.univ-paris-diderot.fr/~jch/soft= ware/ahcp/=0A=0A Alternatively getting another ahcp server written in anoth= er=0Alanguage would be good.=0A=0A* DLNA (?)=0A* small DHCP-PD support=0A= =0AWide is not working out, isc and dibbler are too huge. It's time for=0As= omeone to write a small one... (not me!)=0A=0AOther suggestions for the upc= oming development cycle?=0A=0A-- =0ADave T=C3=A4ht=0A=0AFixing bufferbloat = with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html=0A____________= ___________________________________=0ACerowrt-devel mailing list=0ACerowrt-= devel@lists.bufferbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/cerowr= t-devel ------=_20121123162615000000_90422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Regarding AHCP...  it occurs to me that AHCP might be a better choice = than the alternatives for use in Amateur Radio internet environments with I= Pv6.

=0A

 

=0A

I would like to see a very future-oriented approach to IPv6 = in Amateur Radio.   There are some quirks in the rules for Amateu= r Radio that mean that Amateur Radio subnetworks (unlike "open wireless" ne= tworks) have to have every message transported directly traceable to a lice= nsed 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 o= rder to be a "good netizen" in Ham circles, and to be constructive in gaini= ng support from the various constituencies that support Amateur Radio's spe= cial status worldwide. There is no benefit whatever to using terms like "wa= r-driving" in conjunction with Amateur Radio just to get your name in the p= apers).

=0A

 

=0A

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

=0A<= p style=3D"margin:0;padding:0;"> 

=0A

Part of the stack needs to include IPv6 address assignment and routing, = and also bufferbloat-prevention.  My thought is that AHCP and other co= mponents useful for Cerowrt deployment would be suitable for an Amateur Rad= io IPv6 stack.  Also, I have some ideas about low-level ways to ensure= that there is always a responsible, licensed "control operator" for any me= ssages delivered over Amateur Radio-licensed IPv6 transport paths, which I = have begun working on.

=0A

 

=0A=

That long discursion suggests that a simpl= e AHCP server and client implementation would be very, very helpful in a wi= der scope of usage.  One that brought IPv6 to Raspberry Pi might be ju= st the ticket, since interfacing such a board to off-the-shelf transceivers= is pretty easy for many Ham hobbyists.  (beware - you really should b= e aware of the "band management" done by the ARRL, so you stay in the subba= nds where digital signalling is encouraged.  The 1.2 GHz band and abov= e are preferable, and maybe the digital portion of  440 MHz, esp. if y= ou don't disrupt the FM phone activity there).

=0A

 

=0A

-----Original Mess= age-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Frid= ay, November 23, 2012 12:27pm
To: cerowrt-devel@lists.bufferbloat.net,= "bloat-devel" <bloat-devel@lists.bufferbloat.net>
Subject: [Cer= owrt-devel] cerowrt-next plans

=0A
=0A

I did finally get around to boot= ing the ubnt linux 3.6.7 build I
talked about yesterday.

Ye= a! 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 pla= nning on forking the "stable" cerowrt 3.3 repository for new
developme= nt on 3.6,
and am calling it cerowrt-next. I may blow it away entirely= and rebase
on openwrt. Nobody
look!

In the interim pe= rhaps I'll stick up the ubnt-3.6.7 code, but there
seems to be no dema= nd, sooo...

Updates:

* Steven Walker made a bunch of = updates to ceropackages the other day,
I haven't tested.
thx ste= ven. 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
* Mu= ltiple versions of fq_codel
* QFQ+
* Wireless diffserv patch
* Memory reduction patches in pfifo_fast and codel

Whatever oth= er patches didn't make it up to openwrt

New development:
* Randomness/entropy framework infrastructure buildout
The new ra= ndomness frame in 3.6 and later requires driver support in
order to wo= rk well.
Good crypto in things like WPA, and SSL requires good entrop= y.

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 su= pport
TCP fast open is supported server side in 3.6. There is somepreliminary support for it in netperf now

* AHCP in dnsmasq
After watching the deliberations on homenet, and knowing ahcp fi= ts a
niche not addressed there,
and knowing that it solves a nee= d that cannot be met by SLAAC, dhcp,
dhcp-pd, or ospf+pd,
and af= ter losing many battles with ahcpd, and knowing AHCP NEEDS TWO
impleme= ntations
to go ietf standard track...

I started hacking o= n the core idea one weekend 18 months ago. I
figured if I just got a c= ouple 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
i= t 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 im= plementation would be a good start
towards understanding these
c= omplex issues.

Sadly, those weekends have not happened yet. :(=

It would be nice to find someone to work with to continue gett= ing
this into dnsmasq. ? Even as an exercise,
it's a good explor= ation into how ipv6 multicast actually works....

Anyway I just = folded in somepatches that compiled and opened up the
port into the cu= rrent dnsmasq tree
and put it up on github. It does very little else.= ..

My github repo for dnsmasq-ahcp: https://github.com/dtaht/dn= smasq-ahcp
Protocol Specification:
http://www.pps.univ-paris-did= erot.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.html
existing ahc= p server/client code and doc:
http://www.pps.univ-paris-diderot.fr/~jc= h/software/ahcp/

Alternatively getting another ahcp server writ= ten in another
language would be good.

* DLNA (?)
* sm= all 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=C3=A4ht

Fixing bufferbloat with cerowrt: http://ww= w.teklibre.com/cerowrt/subscribe.html
________________________________= _______________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bu= fferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

= =0A
 ------=_20121123162615000000_90422--