I am primarily focused on demonstrating solutions to bufferbloat in my portion of bit's and bytes.
But I note that the present CeroWrt build appears to have working dhcp-pd (I've successfully got /56 /60, /61/ /62 subnets from it), and assigning that to the 6+ internal interfaces, support for every other form of ipv6 tunneling, the latest dnsmasq which has some good ways of bonding dns names to ipv6 AAAAs, support for routing ipv4 and ipv6 subnetworks over the quagga babel protocol (the two routers I'm demoing are meshed together at 5ghz) We had to fix a few nasty instruction traps in the ipv6 stack last month, but after doing that, I'm pretty pleased with the over-all performance and reliability - it survived the "thc" ipv6 tests handily, for example. Could use some more exaustive real-world testing, so, get it (for the wndr3700v2 and 3800 series) http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ We also have specialized builds for the ubiquity nanostation m5 and picostation m2hp products deployed in the campground testbed. We still haven't done anything with distributing prefixes inside the home beside ahcp, and I still find the dynamicism required by renting ipv6 addresses to so impact in so many aspects of the "sane usage of stuff like printers", and naming, and the security model as to *demand* ipv6 nat in the home... but I did not get around to implementing npt66 in this release!! (so those that would flame me for this opinion can hold off (pretty please!?) until perhaps I can go into the implementation details of all the many things that break today... with those that care. ) In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather like to see if these release can be made to work with ospfv6 on other devices. What else will be shown? The original homenet code was far too large to be usable on such a small device, but perhaps at least the ospf layer could be tried. And all that said, I'm rather totally buried with tests for, processing a ton of data from the field, and testing nfq_codel/bufferbloat. I just finished giving talks on that at MIT and Stanford on that stuff What's wrong with wifi? http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be Intro to codel and fq_codel: http://netseminar.stanford.edu/ On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John < [email protected]> wrote: > Statically assigning prefixes may enable testing but is not how homes will > be provisioned in reality. > > ========================================= > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > e) [email protected] > o) 609-377-6594 > w) www.comcast6.net > ========================================= > > > > > > > > -----Original Message----- > From: David Lamparter <[email protected]> > Date: Wednesday, February 20, 2013 9:41 PM > To: John Jason Brzozowski <[email protected]> > Cc: David Lamparter <[email protected]>, Lorenzo Colitti > <[email protected]>, Michael Richardson <[email protected]>, > "[email protected] Group" <[email protected]>, Jari Arkko > <[email protected]>, Mark Townsley <[email protected]> > Subject: Re: [homenet] Running code in Orlando > > >On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: > >> David Lamparter wrote: > >> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: > >> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson > >> >> <[email protected]>wrote: > >> >> > >> >> > Would/could another foot of such a network be on the IETF network? > >> >> > > >> >> > >> >> If the IETF network didn't respond to DHCPv6 PD requests, it > >>wouldn't be > >> >> much use. > >> > > >> >Even without DHCPv6 PD on the remainder of the IETF network, it might > >>be > >> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating > >>part > >> >of the provider network. > >> > >> Why emulate it? Is the intention here to test the the code on an > >> enterprise or corporate network? > > > >The scope of the plugfest is the interior and border of the homenet. To > >get the border right, we need the service provider side of that border > >in some form. If the IETF network runs DHCPv6-PD, that is an usable > >approximation. > > > >My suggestion was for the case that the IETF network won't be running > >DHCPv6-PD. In that case, the easiest way to make the IETF network > >usable as one uplink for the homenet plugfest is to ask for a /52 to be > >made available for the plugfest in some static way and then provide > >DHCPv6-PD from that, running on some random PC box/laptop somewhere. > > > >Actually - controlling the DHCPv6-PD might be advantageous in order to > >allow tinkering with it to see how the testbed reacts. > > > > > >-David > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
