Our second g2k14 report comes from Henning Brauer (henning@), who writes:

I once again managed to miss arranging travel in time over way too much $work - but luckily found suitable (actually, even close-to-perfect) flights last week. Even affordable.

So I arrived monday evening. First I had a fix to vlan bpf on the radar - with the vlan changes I did in Morocco, the packets showing up via the bpf tap in vlan had the vlan ethernet header instead of the plain ethernet header that most consumers expect. Missed side effect of us prepending the vlan ethernet header right away instead of first preprending a regular ethernet header to only throw it away later and prepending a new vlan ether one. Now of course we don't want to throw away our shiny vlan ether header and again construct a new (real or very embryonic) ether header just to make bpf happy. The solution to that is a custom bpf copy function that just gets rid of the extra 4 bytes the ether vlan header has over the regular ether one. Before actually doing that I ended up cleaning up bpf.c quite a bit and cut a lot of duplicated code. Eventually got bpf_mcopy_stripvlan done without duplicating oh so much code again, it works as expected, the bug is fixed and bpf.c is much nicer than it used to be.

Then I mysteriously got sucked into netinet6. Years ago I added an interface flag, IFXF_NOINET6, to turn off inet6 per interface. Automagically adding an inet6 address just because an interface comes up is ridiculous and actually a security risk, since your machine is suddenly reachable over it (to some extent), which might not even be clear to the person taking the interface up. And it goes further, that automagic inet6 address even causes problems in some setups, e. g. with bridges. So we eventually decided to turn off v6 by default, which is how it should have been from the beginning - actively adding an inet6 address, manually or by running rtsol for autoconfig, turned it on and everything magically worked right. Without the implicit attack vector. So that is actually invisible to almost all that use inet6 - only those just using link-local, without any "real" inet6 address, had to adapt slightly. Pleasantly even the die-hard inet6 lovers in our group agreed with that move.

Did inet6 off by default by setting IFXF_NOINET6 in if_attach(), every interface showing up goes through that. But in a "inet6 only turned on when actually used" world, the NOINET6 semantic is backwards, and all those calls to inet6 attach functions guarded by checking that flag were useless. I wanted to clean that up, get rid of the flag and just not call the inet6 setup stuff (mostly adding the link-local addr) unless really needed. But that left a problem, we really really really want to make sure we don't accept router advertisements unless root clearly indicated he wants to do so. And the v6 autoconf semantics were a little weird to begin with. So here comes a new flag, IFXF_AUTOCONF6, set by doing "ifconfig <if> inet6 autoconf" or - for the moment - running rtsol. Very soon that ifconfig invocation will make the kernel send the router solicitation itself, i. e. no more need for rtsol and rtsold. That was part of the idea from the beginning, florian@ did the implementation, and as usual the entire thing is a big group effort, this time foremost between him, stsp, bluhm, mpi, naddy, benno and, well, me. I then could clean up the NOINET6 flag thing, get rid of it, add explicit IFAFATTACH/DETACH ioctls (which are not limited to inet6, even tho that's the implemented bits for now) and made the section at least nicer than it used to be. The semantics don't change, this is supposed to be user-invisible.

Also spent some time with Wouter reviewing the privilege handling and general early (potentially dangerous) code paths in nsd and unbound. Much to my surprise I didn't find a single real omission or error, but gave him some input how things can be nicer and easier to audit without giving up portability.

Mitja again did an awesome job organizing this hackathon (thank you!), the city of Ljubljana is really really beautiful, the people here are cool and nice. Definitely a recommended destination. Unfortunately didn't really have spare cycles to enjoy it over hacking and a LOT of time in (productive!) discussions.