Showing posts with label IPv4. Show all posts
Showing posts with label IPv4. Show all posts

Friday, July 11, 2025

Yes, The Book of PF, 4th Edition Is Coming Soon

© 2025 Peter N. M. Hansteen

Long rumored and eagerly anticipated by some, the fourth edition of The Book of PF is now available for preorder

The Book of PF, 4th edition front cover, placeholder

This week it was finally time to announce, to the fediverse and to mailing lists, that there is a new edition of The Book of PF in the works, and preordering is now enabled.


Note: This piece is also available without trackers but classic formatting only here.

A few questions immediately pop into readers' minds on hearing this news. The ones I get most often are,

Why now? What took you so long?

which quite frequently combines with

What changed? Are previous editions now useless?

I'll address both after repeating what I said in the email announcements:

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

What happened was, for quite some time after the third edition was finished, there were essentially no user visible changes such as syntax changes in the configuration for OpenBSD PF.

The code was definitely being worked on, developers fixed bugs, introduced optimizations such as network stack wide improvements in multicore support. But user-visible changes other than likely performance improvements did not appear, so I saw no urgent need to make updates to the book.

During the years following the late 2014 publication of third edition, I went on giving talks and tutorials, and at some point I welcomed input and help from my present co-presenters of the Network Management with the OpenBSD Packet Filter Toolset tutorials, Max Stucchi and Tom Smyth.

Over a few revisions, the tutorial sessions became ever more OpenBSD centered, possibly because we were all focusing more on that system than the others. And of course, over time we made tweaks to the material we present at the tutorials in response to our own real world experiences and feedback from attendees and others.

This went on for some years, with the still moderately popular conference sessions each yielding incremental changes to the material. Then, COVID-19 put all physical conference activities on hold for the years 2020 and 2021. EuroBSDCon 2022 in Vienna (originally planned as the 2020 conference), was our first post-lockdown presentation and a well attended one at that.

We went on to do more sessions at BSDCan 2023 and EuroBSDCon 2023. During the post-lockdown period, one question started popping up ever more frequently in email, social media (direct messages, even) and in connection with the sessions themselves,

Are you working on a fourth edition?
more often than not accompanied by
I'd love to get this in a FreeBSD version, can you do that too?

My answers would be roughly, "No tech book writer will ever reveal what their current project is until they have a specific publication date set", and "Sure, I will look into what I can do about that for sometime later"

On my way back from EuroBSDCon 2023 in Coimbra, where these questions had of course come up again, even from the quite small group of attendees at our session, I decided I that after eight years it might be worth at least looking into what, if anything beyond incrementing version numbers, would make sense to do to produce a new edition.

So I set out to assess. The book had seen some light touch updates for its second printing that were not in my pre-production .odt files, so I set out with the freshest .pdf and started making annotations. After a little while the volume of annotations had grown enough that I found it more useful to transfer those annotations to a normal text file. That file was becoming something like an outline of what a fourth edition would look like.

So testing my own 8 year old work against modern OpenBSD and FreeBSD, and poking around for PF material in general, I noticed several things.

Since the third edition was written, NetBSD, prominently featured in that edition, had developed their own NPF packet filter subsystem and deprecated their PF port. While DragonFly BSD still had PF in their tree, it looked like their version was seriously out of date (as far as I could tell equal to roughly OpenBSD 3.6, released in 2004).

So concentrating on the two free systems I was anyway in daily contact with -- OpenBSD and FreeBSD -- made sense.

My notes of things that needed to be done swelled over the next few weeks. The revision notes work became my main activity on evenings and weekends for a while, and by late November I sent off that file as an attachment to a mail message to Bill at No Starch that started with,

Dear Bill,
I think a fourth edition of The Book of PF might have a reason to exist soonish.

I went on to explain that while we had not had major announcements in the packet filtering space during the past few years, quite a few incremental and larger changes had indeed happened. A lot more had happened in user visible PF matters on the FreeBSD side than on the OpenBSD side, but incremental changes had happened there too.

And as you could reasonably expect, the world around us had changed enough that in addition to introducing some new features, existing examples and the way we present the issues to the reader needed a refresh in order to be relevant to anyone working in or starting out with modern TCP/IP networks.

It took some weeks before the yes, we're on board for a fourth edition message came back. It is entirely possible that making an important business pitch just before Thanksgiving weekend is not an optimal thing to do, timing-wise.

But when the go-ahead came, I asked Henning Brauer, who had been very much involved with technical editing for the previous versions, and Kristof Provost, who does the major PF things on the FreeBSD side, to be my tech reviewers. Both accepted immediately.

Over the next few months intense editing and revising followed -- yes, I do make mistakes, and Henning and Kristof proved to be very good at catching them.

Now we are very close to having the final result. The fourth edition of The Book of PF focuses on PF on modern versions of OpenBSD and FreeBSD, with only minor mention of other platforms. The ports to Apple systems and Oracle Solaris are mentioned, but I decided early on to focus on the free systems for all examples. The FreeBSD parts have received significantly more attention than in previous versions, to the extent that we jokingly referred to the fourth edition as the be nice to FreeBSD edition.

The editing process has taken longer than I had anticipated, but we are on track now to have copies in readers' hands some time in the second half of 2025. I hope I will be able to bring physical copies of the fourth edition to EuroBSDcon 2025 in Zagreb in September. There will be a revised and updated version of the Network Management with the OpenBSD Packet Filter Toolset session there, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

So summing up,

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

If you have actually read this far, there is a good chance you might be interested in the book, the tutorial, or both. I welcome your comments and input.


If you found this piece to be useful, informative, annoying or would for some other reason like to contact me or comment, please do.

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).


Wednesday, June 8, 2011

My First IPv6 Spam

On the day of The Great Experiment, an anecdote on how much the world stays the same even with IPv6, security-wise. No reason to stay all dotty, this is when the fun starts.

Happy IPv6 Day, everyone! As I write this column, the 24 hour worldwide Internet Protocol, version Six preparedness experiment is still in progress, with some hours to go before the summaries, no doubt penned by industry luminaries, will start appearing. In the meantime, I have a small IPv6 anecdote of my own to share.


Note: This piece is also available without trackers but classic formatting only here.

Like most network oriented techies, I've had IPv6 somewhere in my field of vision for some time, with a footnoted TODO list to match. I started nagging local ISPs for their IPv6 plans some years ago, and as you've probably guessed, up until very recently the answer at essentially all European ISPs has been 'non-existent'. Among European nations, most of them pretty early in the queue when the original IPv4 address allocations were made, Norway was quite fortunate, and with a total population of less than five million and enough NAT to go around we have a good enough IPv4 address to total population ratio that makes for no panic of us running out of IPv4 locally.

So this left us early adopters to seek out the next generation connectivity via tunnel providers such as Hurricane Electric or Sixxs, with the dancing turtle at the Kame Project website as the early reward for venturing into 128-bit address territory.

For the longest while, that would be pretty much it. Once you'd kept your tunnel stable for a while, you could generally have a /48 subnet for the asking. But finding any good content on IPv6 or large amounts of IPv6 traffic of any kind was not easy. At parties we'd even bitch about the famous lines in one IPv6 textbook that claimed that IPv6 routing tables were generally much smaller and more compact than their IPv4 counterparts -- of course they're smaller, there are essentially no sites, and they produce next to no traffic!

Then, famously, the time came when the last /8 range allocations of IPv4 address space were made, and the IPv4 internet was officially full (should we just start telling them to go away yet?), for some values of at least. Even if certain European organizations or nations are not in any danger of running out of IP addresses, sixteen years after the initial IPv6 RFCs entered the standards track (see RFC1883 and friends), we found ourselves in a situation where any new large-scale implementations would likely be built exclusively with IPv6 or very nearly so, and the historical backdrop for today's experiment was complete.

I expect the summaries to say mostly that modern operating systems, at least the free ones such as OpenBSD came very well prepared for the task. The two protocols are in fact not compatible, but running both will work, and for the vast majority of services, the sysadmin's worksheet looks like this:

1) Get hold of whatever number of IPv6 addresses your application requires

2) Configure your network interfaces with IPv6 addresses (some systems come preconfigured to do their own autoconfiguration)

3) Edit in the required IPv6 addresses into your services' configurations

4) Add any AAAA records required to your domains' externally-visible zones.

And you're done, at least for now. With quad-A entries in your externally-visible DNS, you will start seeing IPv6 traffic hitting your services from elsewhere, not just your own test traffic.

Your logs and other monitoring will show you how your rig behaves. Most likely it all just works, and your users won't notice anything different, except perhaps a dancing turtle (or missing ads on IPv6 for some web sites, as noted by some early IP version six day reports).

I did those things a little while back on my home network, and when the first few days did not show up anything I almost missed what could be an important event: my first spam email delivered over IPv6. I only read message headers when the message stands out somehow, and in this case it was clearly spam, so I took a peek at the headers in case I it would be worth blacklisting manually:

Received: from mo-p00-ob6.rzone.de ([2a01:238:20a:202:53f0::1])
by skapet.bsdly.net with esmtp (Exim 4.73)
(envelope-from )
id 1QFOdo-0001zq-E9
for bsdly@bsdly.net; Thu, 28 Apr 2011 12:40:25 +0200
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1303987210; l=2236144;
s=domk; d=edrenat.es;
h=Content-Type:Mime-Version:Subject:Reply-To:From:Date:X-RZG-CLASS-ID:
X-RZG-AUTH;
bh=CS67GJbTmE0wDhH/HieJqdndPSo=;
b=pNIf0dK3KnFhj/7mcP8KGm70V9/XxlPa/ALQSKRh0nBgWsT0mdoUxi2unepDaMlZMPW
cReoEgH/yMOF6T59Zf2X4fjrr358rU9hhxjQuV6lHwIpYoQWYwkxOqAB1iYL+SacIWspU
MYMrgju1GQLZps7hIeunhV0pfto8o4JeqqM=
X-RZG-AUTH: :KWgWcE6pb9/UNsdwkwZbgj6IM9/U3aYAugAbJE4rNBO+ejjApHAeOC4nD+Q=
X-RZG-CLASS-ID: mo00
Received: from PACO1 (cliente-98392.iberbanda.es [87.111.193.23])
by post.strato.de (jimi mo42) (RZmta 25.17)
with ESMTPA id J00252n3SABVBu ; Thu, 28 Apr 2011 12:29:29 +0200 (MEST)

The full message is preserved here with headers or as mainly message body as text if you're so inclined.

From the most recent Received: header we see that the delivery happened over IPv6, while the second tells us that the originator most likely did not have IPv6 connectivity, or at least did not see fit to use it if they did.

It's also worth noting that this message, like a surprising amount of spam in recent times, also comes with what appears to be a valid DKIM signature. So much for cryptograpic validation as an effective antispam measure.

Now of course my next step was to find out if this particular sender had tried to darken my mail spool before:

peter@skapet:~$ sudo grep edrenat@edrenat.es /var/spool/exim/logs/main.log 2010-11-07 14:21:44 1PF5Bm-0006RI-KB <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=251712 id=201011071353082974379@edrenat.es 2010-12-14 20:42:49 1PSaln-000255-PQ <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=759434 id=201012141954165325931@edrenat.es 2011-01-30 21:13:30 1PjdeA-0001Nn-If <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.161] P=esmtp S=1905781 id=201101302042161777948@edrenat.es
2011-02-22 21:59:05 1PrzIX-0006jv-7x <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=1227270 id=201102222041571040455@edrenat.es
2011-04-28 12:40:26 1QFOdo-0001zq-E9 <= edrenat@edrenat.es H=mo-p00-ob6.rzone.de [2a01:238:20a:202:53f0::1] P=esmtp S=2210478 id=201104281225569454004@edrenat.es 


Apparently they had, on more or less a monthly basis, so let's take a peek at the log entries for all of those messages:

peter@skapet:~$ for foo in 1PF5Bm-0006RI-KB 1PSaln-000255-PQ 1PjdeA-0001Nn-If 1PrzIX-0006jv-7x 1QFOdo-0001zq-E9; do sudo grep $foo /var/spool/exim/logs/main.log ; done
2010-11-07 14:21:43 1PF5Bm-0006RI-KB DKIM: d=edrenat.es s=domk c=relaxed/relaxed a=rsa-sha1 t=1289136101 l=251099 [verification failed - signature did not verify (headers probably modified in transit)]
2010-11-07 14:21:44 1PF5Bm-0006RI-KB <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=251712 id=201011071353082974379@edrenat.es
2010-11-07 14:21:44 1PF5Bm-0006RI-KB => peter <bsdly@bsdly.net> R=localuser T=local_delivery 2010-11-07 14:21:44 1PF5Bm-0006RI-KB Completed 2010-12-14 20:42:46 1PSaln-000255-PQ DKIM: d=edrenat.es s=domk c=relaxed/relaxed a=rsa-sha1 t=1292355762 l=766689 [verification succeeded]
2010-12-14 20:42:49 1PSaln-000255-PQ <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=759434 id=201012141954165325931@edrenat.es
2010-12-14 20:42:49 1PSaln-000255-PQ => peter <bsdly@bsdly.net> R=localuser T=local_delivery 2010-12-14 20:42:49 1PSaln-000255-PQ Completed
2011-01-30 21:13:26 1PjdeA-0001Nn-If DKIM: d=edrenat.es s=domk c=relaxed/relaxed a=rsa-sha1 t=1296418396 l=1927465 [verification succeeded]
2011-01-30 21:13:30 1PjdeA-0001Nn-If <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.161] P=esmtp S=1905781 id=201101302042161777948@edrenat.es
2011-01-30 21:13:30 1PjdeA-0001Nn-If => peter <bsdly@bsdly.net> R=localuser T=local_delivery 2011-01-30 21:13:30 1PjdeA-0001Nn-If Completed
2011-02-22 21:59:03 1PrzIX-0006jv-7x DKIM: d=edrenat.es s=domk c=relaxed/relaxed a=rsa-sha1 t=1298408169 l=1240300 [verification succeeded]
2011-02-22 21:59:05 1PrzIX-0006jv-7x <= edrenat@edrenat.es H=mo-p00-ob.rzone.de [81.169.146.162] P=esmtp S=1227270 id=201102222041571040455@edrenat.es
2011-02-22 21:59:06 1PrzIX-0006jv-7x => peter <bsdly@bsdly.net> R=localuser T=local_delivery 2011-02-22 21:59:06 1PrzIX-0006jv-7x Completed
2011-04-28 12:40:21 1QFOdo-0001zq-E9 DKIM: d=edrenat.es s=domk c=relaxed/relaxed a=rsa-sha1 t=1303987210 l=2236144 [verification succeeded]
2011-04-28 12:40:26 1QFOdo-0001zq-E9 <= edrenat@edrenat.es H=mo-p00-ob6.rzone.de [2a01:238:20a:202:53f0::1] P=esmtp S=2210478 id=201104281225569454004@edrenat.es
2011-04-28 12:40:26 1QFOdo-0001zq-E9 => peter <bsdly@bsdly.net> R=localuser T=local_delivery
2011-04-28 12:40:26 1QFOdo-0001zq-E9 Completed


This tells us that they've consistently sent to an address that features only on my website and has never been used as a sender or return address and has never been signed up for any mailing list of any kind. We also see that all the messages bar one pass the initial DKIM validity test.

There are several lessons to be learned here. One is that with a sensible choice of operating system and other software, the transition from classic IP version four only to a dual-stack configuration with both IP version four and IP version six running on your systems will likely be less dramatic than you have been lead to believe.

Another is that at least in some respect the world stays very much the same with IPv6 as it was with IPv4, and content is likely to cross the protocol border. Or to put it slightly differently, the same caveats about ill-intentioned traffic still apply; any security measures you had inplace before you went dual stack most likely need to be tuned to handle traffic from the brave new world of IPv6.

And of course, even if a number of implementation bugs have been found and fixed and a number of fundamental design flaws have been identified and worked around, only full scale testing like today's experiment (preferably sustained over longer periods) offer any hope of identifying and fixing the problems we haven't found yet. The looming IPv6 transition is likely to make and break careers, and some of us will have our share of both fun and nightmares while seeing to the confidentiality, integrity and general security of your data and your systems.

Good night and good luck, while we're slowly going from dots to colons.



Thanks to Sevan Janiyan for tweeting "Though the gmail website is reachable via IPv6, mail is still going via IPv4 :(" earlier today and reminding me of the incident that was the inspiration for this column.