OpenBSD Journal

g2k14: Henning Brauer on IPv6, bpf, vlan surgery

Contributed by phessler on from the all aces and no sixes dept.

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

g2k14 has been weird: I, for the most part, wrote IPv6 code. No, that doesn't mean I'd suddenly think inet6 is any good. But let's start from the beginning.

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.

(Comments are closed)


Comments
  1. By Anonymous Coward (2601:6:51c0:e1:e003:cfe6:f05c:4a47) on

    Recent versions of OpenBSD do not allow packet forwarding if the WAN interface accepts router advertisements. Effectively preventing me from using OpenBSD as my home router / firewall.

    Will the work of moving rtsold into the kernel wind up allowing OpenBSD to both accept router advertisements on the WAN interface and also forward packets?

    Comments
    1. By Anonymous Coward (50.180.16.158) on

      I'd also be interesting in see the ability to receive router advertisements while also doing ipv6 forwarding.

    2. By florian (80.139.75.59) on

      > Will the work of moving rtsold into the kernel wind up allowing OpenBSD to both accept router advertisements on the WAN interface and also forward packets?

      technically no, we could do that even with rtsold(8). There are just checks in rtsold(8) and all over the inet6 stack to not do SLAAC if forwarding is enabled. When implementing the per interface flag henning@ kindly marked all those places with /* XXX to restrictive */ or something along those lines. So one step forward could be to remove those checks and see if and what blows up :)

    3. By henning (46.114.3.139) on

      > Recent versions of OpenBSD do not allow packet forwarding if the WAN interface accepts router advertisements. Effectively preventing me from using OpenBSD as my home router / firewall.
      >
      > Will the work of moving rtsold into the kernel wind up allowing OpenBSD to both accept router advertisements on the WAN interface and also forward packets?

      By itself, no. But it paves the road towards that.

      Last not least I marked the spots with that check.

      Comments
      1. By Anonymous Coward (2601:6:51c0:e1:415d:9e32:67d1:fba4) on

        > > Recent versions of OpenBSD do not allow packet forwarding if the WAN interface accepts router advertisements. Effectively preventing me from using OpenBSD as my home router / firewall.
        > >
        > > Will the work of moving rtsold into the kernel wind up allowing OpenBSD to both accept router advertisements on the WAN interface and also forward packets?
        >
        > By itself, no. But it paves the road towards that.
        >
        > Last not least I marked the spots with that check.
        >

        Henning, thanks for the follow-up.

        While I'd like to see the RA acceptance and IPv6 forwarding capability sooner than later, unfortunately, diving into the depths of OpenBSD's networking code is more than a bit over what I can handle....

  2. By brynet (Brynet) on http://brynet.biz.tm/

    Thanks for the write-up henning. I'm now enabling IPv6 everywhere after your shining recommendation!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]