Kea Roadmap Update
We have updated the Kea release plan in our Knowledgebase to show that we expect to issue new major versions approximately every year, and each one will be supported for two years.Read post
An important tool used in managing IPv4 traffic is address blacklisting; if a server is found to only or mostly produce junk, a reputation service (Spamhaus, Phishtank, or others) will add the address to its list, and networks worldwide will block it, using tools like SpamAssassin, null route advertisement in BGP, or DNS RPZ. Similar reputation services are used for names as well.
The question has arisen: “Will IPv6 end address blacklisting”?
I think not, but the mechanisms used will likely change.
There are a lot more addresses, and they can be used pretty creatively. Some companies, for example, are experimenting with running a /64 (the prefix normally applied to a LAN) to a physical chassis and using it to identify containers within the system. That allows them to use BGP between a physical chassis and the routing fabric in a data center. An IPv6 address, in that context, replaces an IPv4 address+port pair. Also, temporary addresses are more easily created. Windows and MacOS place their permanent address into DNS and use it for incoming sessions; outgoing sessions use temporary addresses that change periodically, as a means of topology obfuscation.
I suspect that reputation services and blacklisting will be alive and well in the IPv6 network, but might be applied to prefixes instead of addresses, or larger (shorter) prefixes rather than smaller (longer) ones. We still have miscreant nodes, and we will still need to filter them out.
The place I scratch my head about in such cases isn’t the number of addresses. It’s the fact that they can change (which is also true in IPv4, but easier in IPv6). In networks using address autoconfiguration, address creation is so easy that people have seriously suggested creating a new temporary address for each TCP connection opened. If normal software can do that, so can malware, which becomes an attack on both the local routing system and the viability of the reputation services.
In a data center using prefixes for chassis, one approach to that will be to move the “good” containers to another machine, and therefore prefix, and kill the remaining ones. That also remediates malware the system may be running. When the prefix is removed from the blacklist, it can be put back into circulation. On LANs, the principles of RFC 4192 can be used to renumber it by deploying a new prefix and then removing the old.
“A good reputation,” a wise man once said, “is more valuable than costly perfume.” Responsible blacklist providers offer a way to remove single addresses, or to at least contest their blacklisting (e.g. https://www.spamhaus.org/lookup/), but today these don’t enable you to rehabilitate an entire prefix. For IPv6 networks, if we block by prefix, we will need to rehabilitate by prefix.
What's New from ISC