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 C9CFA201B88; Fri, 23 Nov 2012 15:26:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp54.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 694002B03CD; Fri, 23 Nov 2012 18:26:58 -0500 (EST) X-Virus-Scanned: OK Received: from legacy12.wa-web.iad1a (legacy12.wa-web.iad1a.rsapps.net [192.168.4.98]) by smtp54.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 436732B02E8; Fri, 23 Nov 2012 18:26:58 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy12.wa-web.iad1a (Postfix) with ESMTP id 30E31F78001; Fri, 23 Nov 2012 18:26:58 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 23 Nov 2012 18:26:58 -0500 (EST) Subject: Re: [Cerowrt-devel] cerowrt-next plans From: dpreed@reed.com To: "David Lang" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20121123182658000000_35975" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1353705975.992510644@apps.rackspace.com> Message-ID: <1353713218.198812384@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 23:27:00 -0000 X-Original-Date: Fri, 23 Nov 2012 18:26:58 -0500 (EST) X-List-Received-Date: Fri, 23 Nov 2012 23:27:00 -0000 ------=_20121123182658000000_35975 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ATwo reasons come to mind - I'm sure there are more.=0A =0A1) IPv6 adress= space is not exhausted and "owned" by a whole lot of ISPs. It's quite re= asonable to get a full prefix for this purpose.=0A =0A2) IPv6 is the future= of the Internet, especially suitable to "open Internet" applications where= the "open Internet" is extensible and routable. I think Hams should be en= couraged to experiment with such technologies where appropriate - that's wh= y Amateur Radio was created: to advance the state of the art of both operat= ions and technology, and engage people of technical talent in that quest.= =0A =0AThere's no particular reason why the IPv6 headers cannot be compress= ed using one of many "header compression" techniques, in whatever encapsula= tion is used to map IP datagrams to the wireless transmission layer (layer = 2). It turns out that I invented the first such header compression for IP = and TCP/IP and UDP/IP packets in about 1978, when the "layer 2" bindings fo= r encapsulating IP over serial lines (at 300 bit/sec) were still in flux (m= y tech report on the subject was listed as "prior art" when Motorola/Codex = tried to claim they invented it in a patent lawsuit against some Internet = router's serial link implementation - I think it was probably one of Cisco'= s, since Van Jacobsen was the one who contacted me many years later). Such= compression can make the IP headers smaller than the IPv4 headers would be= .=0A =0AIn general, as Hams get into "Internetworking" (which is far from t= he current practice of circuit-switched repeaters) there are lots of intere= sting problems where Hams can advance the state of the art into areas where= commercial folks don't want to solve the problem.=0A =0ASetting up ad hoc,= interoperable emergency wireless communications nets that also interoperat= e with whatever wired/fiber infrastructure is available is one obvious exam= ple of a problem that Hams can experiment with solving.=0A =0AI am prototyp= ing experimental Part 97 radio systems that use SDR-based, adaptive wavefor= m, very wideband transmission modes (likely to be most useful in the 5 GHz = and 10 GHz Amateur bands, where one can build QRP SDR transceivers that fit= in a 3"x5" board, running a full Android or openwrt stack).=0A =0ADavid KB= 1YFR=0A =0A =0A =0A-----Original Message-----=0AFrom: "David Lang" =0ASent: Friday, November 23, 2012 5:41pm=0ATo: dpreed@reed.com=0ACc= : "Dave Taht" , "bloat-devel" , cerowrt-devel@lists.bufferbloat.net=0ASubject: Re: [Cerowrt-de= vel] cerowrt-next plans=0A=0A=0A=0APlaying Devil's advocate here.=0A=0AWhy = do you need IPV6 for HAM use (other than the fact that it's new). There =0A= aren't enough users to exhaust the IPv4 address space, and the packets are = =0Alarger so they take more airtime.=0A=0ADavid Lang AG6AH=0A=0A=0A=0A On F= ri, 23 Nov 2012, dpreed@reed.com wrote:=0A=0A> 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.=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 Amateur Radio that mean that Amateur Radio subnetw= orks (unlike "open wireless" networks) have to have every message transport= ed directly traceable to a licensed operator, cannot be obscured, and canno= t contain "music". (I know, the rebel in me feels this is not a good thin= g, but when operating with my Ham hat, I understand the reason to color wit= hin these lines, in order to be a "good netizen" in Ham circles, and to be = constructive in gaining support from the various constituencies that suppor= t Amateur Radio's special status worldwide. There is no benefit whatever to= using terms like "war-driving" in conjunction with Amateur Radio just to g= et your name in the papers).=0A> =0A> It's perfectly reasonable to carry IP= v6 traffic as datagrams over radio networks operated by cooperating Amateur= s. (and could be hugely beneficial in situations like Hurricane Sandy) Wha= t we don't have is a "stack" that is best tuned for this style of internetw= orking.=0A> =0A> 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 Am= ateur Radio IPv6 stack. Also, I have some ideas about low-level ways to en= sure that there is always a responsible, licensed "control operator" for an= y messages delivered over Amateur Radio-licensed IPv6 transport paths, whic= h I have begun working on.=0A> =0A> That long discursion suggests that a si= mple 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 i= s pretty easy for many Ham hobbyists. (beware - you really should be aware= of the "band management" done by the ARRL, so you stay in the subbands whe= re digital signalling is encouraged. The 1.2 GHz band and above are prefer= able, and maybe the digital portion of 440 MHz, esp. if you don't disrupt = the FM phone activity there).=0A> =0A> -----Original Message-----=0A> From:= "Dave Taht" =0A> Sent: Friday, November 23, 2012 12:2= 7pm=0A> To: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" =0A> Subject: [Cerowrt-devel] cerowrt-next plans=0A>= =0A>=0A>=0A> I did finally get around to booting the ubnt linux 3.6.7 build= I=0A> talked about yesterday.=0A>=0A> Yea! It worked.=0A>=0A> Boo! I have = a ton of patches to modify to get back to equivalence with=0A> what's in ce= rowort-3.3.8-27=0A>=0A> So I'm planning on forking the "stable" cerowrt 3.3= repository for new=0A> development on 3.6,=0A> and am calling it cerowrt-n= ext. I may blow it away entirely and rebase=0A> on openwrt. Nobody=0A> look= !=0A>=0A> In the interim perhaps I'll stick up the ubnt-3.6.7 code, but the= re=0A> seems to be no demand, sooo...=0A>=0A> Updates:=0A>=0A> * Steven Wal= ker made a bunch of updates to ceropackages the other day,=0A> I haven't te= sted.=0A> thx steven. If anyone wants an updated ccnx-6.2, in particular, i= t's there...=0A>=0A> * Openwrt Head=0A> * Radvd must die - in favor of eith= er dnsmasq or quagga=0A>=0A> Backports:=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>=0A> Whatever ot= her patches didn't make it up to openwrt=0A>=0A> New development:=0A>=0A> *= Randomness/entropy framework infrastructure buildout=0A> The new randomnes= s frame in 3.6 and later requires driver support in=0A> order to work well.= =0A> Good crypto in things like WPA, and SSL requires good entropy.=0A>=0A>= A lot of people have been thinking "ooh, random numbers fixed in=0A> embed= ded linux since 3.6"=0A>=0A> Um, no. Well, partially...=0A>=0A> http://lwn.= net/Articles/507115/=0A>=0A> * TCP Fast Open test support=0A> TCP fast open= is supported server side in 3.6. There is some=0A> preliminary support for= it in netperf now=0A>=0A> * AHCP in dnsmasq=0A>=0A> After watching the del= iberations on homenet, and knowing ahcp fits a=0A> niche not addressed ther= e,=0A> and knowing that it solves a need that cannot be met by SLAAC, dhcp,= =0A> dhcp-pd, or ospf+pd,=0A> and after losing many battles with ahcpd, and= knowing AHCP NEEDS TWO=0A> implementations=0A> to go ietf standard track..= .=0A>=0A> I started hacking on the core idea one weekend 18 months ago. I= =0A> figured if I just got a couple weekends=0A> more free I'd be able to g= et the protocol into dnsmasq at the cost=0A> of a couple k in binary, and s= ave a mb of ram.=0A>=0A> I decided that dnsmasq was the right place to stic= k it, given that=0A> it managed address assignment=0A> already for multiple= other protocols. It turns out than an AHCP=0A> server is even simpler than= the=0A> client. I then started having some thoughts towards having prefix= =0A> distribution and border discovery in it...=0A>=0A> and felt that writi= ng a fresh implementation would be a good start=0A> towards understanding t= hese=0A> complex issues.=0A>=0A> Sadly, those weekends have not happened ye= t. :(=0A>=0A> It would be nice to find someone to work with to continue ge= tting=0A> this into dnsmasq. ? Even as an exercise,=0A> it's a good explora= tion into how ipv6 multicast actually works....=0A>=0A> Anyway I just folde= d in somepatches that compiled and opened up the=0A> port 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/dtaht/dnsmasq-ahcp= =0A> Protocol Specification:=0A> http://www.pps.univ-paris-diderot.fr/~jch/= software/ahcp/draft-chroboczek-ahcp-00.html=0A> existing ahcp server/client= code and doc:=0A> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/= =0A>=0A> Alternatively getting another ahcp server written in another=0A> l= anguage would be good.=0A>=0A> * DLNA (?)=0A> * small DHCP-PD support=0A>= =0A> Wide is not working out, isc and dibbler are too huge. It's time for= =0A> someone to write a small one... (not me!)=0A>=0A> Other suggestions fo= r the upcoming development cycle?=0A>=0A> -- =0A> Dave T=C3=A4ht=0A>=0A> Fi= xing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.ht= ml=0A> _______________________________________________=0A> Cerowrt-devel ma= iling list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/cerowrt-devel___________________________________________= ____=0ACerowrt-devel mailing list=0ACerowrt-devel@lists.bufferbloat.net=0Ah= ttps://lists.bufferbloat.net/listinfo/cerowrt-devel ------=_20121123182658000000_35975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Two reasons come to mind - I'm sure there are more.

=0A

 

=0A

1) IPv6 adres= s space is not exhausted and "owned" by a whole lot of ISPs.   It= 's quite reasonable to get a full prefix for this purpose.

=0A

 

=0A

2) I= Pv6 is the future of the Internet, especially suitable to "open Internet" a= pplications where the "open Internet" is extensible and routable.  I t= hink Hams should be encouraged to experiment with such technologies where a= ppropriate - that's why Amateur Radio was created: to advance the state of = the art of both operations and technology, and engage people of technical t= alent in that quest.

=0A

 

=0AThere's no particular reason why the IPv6 he= aders cannot be compressed using one of many "header compression" technique= s, in whatever encapsulation is used to map IP datagrams to the wireless tr= ansmission layer (layer 2).  It turns out that I invented the first su= ch header compression for IP and TCP/IP and UDP/IP packets in about 1978, w= hen the "layer 2" bindings for encapsulating IP over serial lines (at 300 b= it/sec) were still in flux (my tech report on the subject was listed as "pr= ior art" when Motorola/Codex tried to claim they invented it in a patent la= wsuit against some  Internet router's serial link implementation - I t= hink it was probably one of Cisco's, since Van Jacobsen was the one who con= tacted me many years later).  Such compression can make the IP headers= smaller than the IPv4 headers would be.

=0A

 

=0A

In general, as Hams get = into "Internetworking" (which is far from the current practice of circuit-s= witched repeaters) there are lots of interesting problems where Hams can ad= vance the state of the art into areas where commercial folks don't want to = solve the problem.

=0A

 

=0A

Setting up ad hoc, interoperable emergency wir= eless communications nets that also interoperate with whatever wired/fiber = infrastructure is available is one obvious example of a problem that Hams c= an experiment with solving.

=0A

 =0A

I am prototyping experimental Part 97= radio systems that use SDR-based, adaptive waveform, very wideband transmi= ssion modes (likely to be most useful in the 5 GHz and 10 GHz Amateur bands= , where one can build QRP SDR transceivers that fit in a 3"x5" board, runni= ng a full Android or openwrt stack).

=0A

 

=0A

David KB1YFR

=0A

 

=0A

&nbs= p;

=0A

 

=0A

-----Original Message-----
From: "David Lang" <david@l= ang.hm>
Sent: Friday, November 23, 2012 5:41pm
To: dpreed@reed= .com
Cc: "Dave Taht" <dave.taht@gmail.com>, "bloat-devel" <bl= oat-devel@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.netSubject: Re: [Cerowrt-devel] cerowrt-next plans

=0A
=0A

Playing Devi= l's advocate here.

Why do you need IPV6 for HAM use (other than = the fact that it's new). There
aren't enough users to exhaust the IPv= 4 address space, and the packets are
larger so they take more airtime= .

David Lang AG6AH



On Fri, 23 Nov 2012, = dpreed@reed.com wrote:

> Regarding AHCP... it occurs to me t= hat AHCP might be a better choice than the alternatives for use in Amateur = Radio internet environments with IPv6.
>
> I would like to= see a very future-oriented approach to IPv6 in Amateur Radio. There are = some quirks in the rules for Amateur Radio that mean that Amateur Radio sub= networks (unlike "open wireless" networks) have to have every message trans= ported directly traceable to a licensed operator, cannot be obscured, and c= annot 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 su= pport Amateur Radio's special status worldwide. There is no benefit whateve= r to using terms like "war-driving" in conjunction with Amateur Radio just = to get your name in the papers).
>
> It's perfectly reason= able to carry IPv6 traffic as datagrams over radio networks operated by coo= perating Amateurs. (and could be hugely beneficial in situations like Hurri= cane Sandy) What we don't have is a "stack" that is best tuned for this st= yle of internetworking.
>
> Part of the stack needs to inc= lude 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 idea= s about low-level ways to ensure that there is always a responsible, licens= ed "control operator" for any messages delivered over Amateur Radio-license= d IPv6 transport paths, which I have begun working on.
>
>= That long discursion suggests that a simple AHCP server and client impleme= ntation would be very, very helpful in a wider scope of usage. One that br= ought 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 hobbyist= s. (beware - you really should be aware of the "band management" done by t= he 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).
= >
> -----Original Message-----
> From: "Dave Taht" <= dave.taht@gmail.com>
> Sent: Friday, November 23, 2012 12:27pm> To: cerowrt-devel@lists.bufferbloat.net, "bloat-devel" <bloat-d= evel@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] cerowrt-n= ext 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 cero= wort-3.3.8-27
>
> So I'm planning on forking the "stable" c= erowrt 3.3 repository for new
> development on 3.6,
> and a= m calling it cerowrt-next. I may blow it away entirely and rebase
>= on openwrt. Nobody
> look!
>
> In the interim perh= aps I'll stick up the ubnt-3.6.7 code, but there
> seems to be no d= emand, sooo...
>
> Updates:
>
> * Steven Wa= lker made a bunch of updates to ceropackages the other day,
> I hav= en't tested.
> thx steven. If anyone wants an updated ccnx-6.2, in = particular, it's there...
>
> * Openwrt Head
> * Ra= dvd must die - in favor of either dnsmasq or quagga
>
> Bac= kports:
>
> * IPv6 performance patch
> * Multiple v= ersions of fq_codel
> * QFQ+
> * Wireless diffserv patch> * Memory reduction patches in pfifo_fast and codel
>
&= gt; Whatever other patches didn't make it up to openwrt
>
>= New development:
>
> * Randomness/entropy framework infras= tructure buildout
> The new randomness frame in 3.6 and later requi= res driver support in
> order to work well.
> Good crypto i= n things like WPA, and SSL requires good entropy.
>
> A lot= of people have been thinking "ooh, random numbers fixed in
> embed= ded linux since 3.6"
>
> Um, no. Well, partially...
&g= t;
> 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 delibe= rations on homenet, and knowing ahcp fits a
> niche not addressed t= here,
> and knowing that it solves a need that cannot be met by SLA= AC, dhcp,
> dhcp-pd, or ospf+pd,
> and after losing many ba= ttles 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 ra= m.
>
> I decided that dnsmasq was the right place to stick = it, given that
> it managed address assignment
> already fo= r multiple other protocols. It turns out than an AHCP
> server is e= ven simpler than the
> client. I then started having some thoughts = towards having prefix
> distribution and border discovery in it...<= br />>
> 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 ge= tting
> 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 githu= b. It does very little else...
>
> My github repo for dnsma= sq-ahcp: https://github.com/dtaht/dnsmasq-ahcp
> Protocol Specifica= tion:
> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/dra= ft-chroboczek-ahcp-00.html
> existing ahcp server/client code and d= oc:
> http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/
>
> Alternatively getting another ahcp server written in anothe= r
> 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 dev= elopment cycle?
>
> --
> Dave T=C3=A4ht
><= br />> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/= subscribe.html
> _______________________________________________> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloa= t.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel_______= ________________________________________
Cerowrt-devel mailing listCerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/l= istinfo/cerowrt-devel

=0A
 ------=_20121123182658000000_35975--