Some Notes on IPv6 Bogon Filtering

At first a happy new year to you all!
For some of us it will bring IPv6-related happiness (and maybe a few – although temporary 😉 – sorrows). The IPv6 world is full of sources of pain & heated discussions, but in today’s post I will discuss a topic where life got presumably easier with IPv6 than it was with IPv4, that is the filtering of inbound traffic at network borders, based on source addresses considered to be invalid with regard to the place (of filtering) and the direction of traffic. This is often called “bogon filtering” or “filtering of martians” (more details and terminology to follow in a second).

People do this for various reasons like

• General/basic network hygiene (“obviously such packets are – at least when coming in over the Internet – somewhat invalid, so we don’t want to see them in our network”).
• Potential protection from (D)DoS attacks using spoofed source addresses from such prefixes (e.g. based on random source addresses). There’s varying numbers & opinions as for the extent of those addresses within such attacks, so one might follow this line of reasoning or not (=> this debate is not in scope of this post).
• Some regulatory frameworks might require such filtering, e.g. PCI DSS section 1.3.3 (as of v3.2.1) mandates for anti-spoofing filters.
• It’s considered best practice in certain contexts (no judgement from my side implied here).

Frankly I’m not a super big fan of spending much energy on this as I don´t really see a reasonable cost (operational effort, in particular when not done properly) to benefit (risk mitigation) ratio here – I will happily swap a full bogon filter list for some solid filtering of IPv6 extension headers if I had to choose between the two 😜 – , but it’s a recurring topic in IPv6 security circles. In fact after my RIPE79 talk on (types of) IP addresses and their security implications a reader reached out to with a question along the lines: “so should we just filter all prefixes as of slide 23 of your deck?” (which essentially contained a screenshot of the “IANA IPv6 Special-Purpose Address Registry”). Let me hence take this as an opportunity to discuss some intricacies of address-based network ingress filtering.

Usually the related rules of such ACLs can be broken down to the following categories:

• Drop “special use”/”special-purpose” prefixes which are not supposed to be seen in across-the-Internet production traffic, like the (majority of) addresses prefixes as of these lists for IPv4 and IPv6.
• Drop packets originating from address ranges not (yet) allocated by IANA or the RIRs.
• Anti-spoofing (drop packets at the network borders / ingress that pretend to originate from internal networks).
• Others, e.g. filtering packets based on (presumed) country of origin (see for example this post by Koen van Impe).

Before we analyze an actual example I’d like to come up with a bit abstract classification (regular readers know I sometimes expose a tendency to over-intellectual abstractions 😉) of address ranges typically found in such lists, together with a discussion of their operational implications.
I suggest going with the following categories:

• Special-purpose addresses that can usually be dropped without much consideration (=> default approach: include in list). The ‘documentation’ prefix 2001:db8::/32 (see RFC 3849) can serve as an example here – I can’t see any reason why one would accept packets with such a source address over the Internet.
• Special-purpose addresses that shouldn’t be filtered in most cases (=> default approach: do not include). For example I generally recommend not touching link-local addresses on transit networks between routers as this might impact (namely the session establishment of) routing protocols.
• Special-purpose addresses that need some consideration, based on an individual environment’s needs and objectives (no default, but “think about it”).
• Unallocated space. Here the main thing to keep in mind is that this might change over time (e.g. the RIPE NCC just started de-bogonising 2a10::/12). So one might only include prefixes of this type if operational procedures and maturity allow to update in case changes occur in this space (after following those in the sense of ‘noting them’…). There’s people only advocating this once prefixes of this group are received from a dynamic feed (like the well-known Team Cymru fullbogons list, disclaimer: this is just an example and I don’t have any commercial relationship with them) which in turn has its own set of intricacies and issues (trust the source of updates? what if this was subverted? contractual controls with the source? trust the transmission mechanism? etc.). See also here for the currently allocated IPv6 address space as of IANA.
• Anti-spoofing: put your own prefixes here (and make sure you don’t overlook any ;-).

Let’s have a look at the “Current IPv6 martians” list maintained (last on 2015-07-28…) by Job Snijders and to be found here (it’s for route filtering as opposed to ACLs, but for our discussion this doesn’t really matter):

It is mostly a combination of filtering special-purpose addresses (e.g. lines 1–4, 8–15 + 17, 25–27) and filtering unallocated blocks (namely lines 5–7 and 18–24, again also see this IANA link) , and it hence has some elements of several of the categories I introduced above.

Some parts deserve special attention & discussion though. First it should be noted that the first seven lines can be summarized to/replaced by ::/3. Admittedly though this doesn’t look as impressing on the stage of the security theater and/or ‘to the auditors’ 😂…

Furthermore the list contains both the TEREDO (2001::/32) and the 6to4 (2002::/16) prefixes. There is some debate if filtering those is appropriate as one might actually see legitimate traffic (albeit small amounts) from those. For example my friend Jason Fesler, who runs the very useful test-ipv6 site, told me he usually sees about 0.5% traffic coming in from the 6to4 prefix. On the other hand some people argue that 6to4 is so broken anyway that it would be better to filter it completely than expose users to the horrible user experience (then potentially attributed to IPv6) they will go thru via 6to4, e.g. see Gert Doering‘s contribution to the related thread (in May 2019) on “IPv6 ingress filtering” on the ipv6-ops (“IPv6 operators forum”) mailing list (a similar thread on ‘list of IPs to block outbound’ of October 2019 on the NANOG mailing list to be found here). So this would be a case of the above “think about it” category…

I now realize that, when it comes to IPv6 bogon filtering, things aren’t as easy as I presumed when I started writing this post ;-). In a nutshell potential filters in such lists can be broken down to some ‘always filter’ entries, some ‘stay away from this if you don’t exactly know what you’re doing’ pieces and some ‘it depends’ candidates. Whatever you do it will make sense to accurately comment individual entries and why you handle them in the way you do. Your fellow security admins (and the auditors…) will like that. In a follow-up post I might come up with a nicely commented list, for copy+paste purposes… stay tuned. And thank you for your attention while reading!
May 2020 bring lots of IPv6 joy for us.