Starting a new BCOP – “How to run and protect an email server on IPv6” Thumbnail
Deploy360 19 December 2017

Starting a new BCOP – “How to run and protect an email server on IPv6”

By Jan ŽoržFormer Operational Engagement Programme Manager

After the recent series of technical Best Current Operational Practices (BCOP) documents that we initiated and co-authored, it’s time for new one. This time on how to run an incoming email server on IPv6 and survive!

Back in 2010 we started the IPv6 series of BCOP documents, starting with the popular RIPE-501 that was superseded by the even more popular RIPE-554 that discusses how to specify IPv6 functionality and compliance when ordering ICT equipment. This document emerged from listening to the Internet community that is deploying IPv6, and figuring out the common problems in order to come up with recommendations on how to solve them.

The next most common issue that we heard about, was that helpdesks of network operators would melt down if they deployed IPv6 to their end customers as they don’t know anything about IPv6. So we built an online tool and wrote some helpdesk procedures on how to troubleshoot IPv6 issues when users call them – resulting in another useful document that was published as RIPE-631.

After addressing this, we then repeatedly heard questions about what size of IPv6 prefixes should be given to end-users and should it be assigned statically or dynamically. We therefore put together a team of experienced co-authors from the Internet community (as with all BCOP documents) and after a year of hard work including incorporating all the comments and suggestions, we achieved community consensus and published this as RIPE-690 on 16 October 2017.

It’s worth noting that the same process of getting wide consensus from the Internet community was used (and will be used) for all BCOP documents.

Whilst still working on the RIPE-690 draft, we continued to listen to the Internet community to figure out where they’re still having issues with IPv6 deployment. And what we were hearing was that ways need to be figured out how to run incoming email servers on IPv6 as there are no IP reputation (black listing) mechanisms to protect from spam coming in from the Internet.

So we thought this was relevant enough to again ask for experienced volunteers from the Internet community to start documenting some best current operational practices in this area. We therefore signed up Sander Steffann, Jordi Palet Martinez, Nasser Heidari, Aaron Hughes and myself (Jan Žorž) as initial authors, and are also working in cooperation with the M3AAWG community and the Latin America & Caribbean BCOP Task Force through their co-chairs Ariel Weher and Luis Balbinot.

The call for volunteers is always open, so if you are an experienced system or network operator who’s running your email server on IPv6 and is successfully detecting and blocking spam along with other email attacks, please send an email to [email protected] to volunteer to contribute to this new BCOP document. It’ll be a lot of work before we’ll reach consensus, but this just means that the advice that we provide will be effective and useful for operational setups.

We’re just starting to put together this BCOP document, and we’re planning to publicly share it as some as there’s something substantive to review.

It’s time for another BCOP, please join us!

Jan Žorž

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...