A new RIPE Best Current Operational Practices document is in the making. Please contribute your expertise!
The Best Current Operational Practices Task Force (BCOP TF) was formed at RIPE 67 in October 2013 to initiate and coordinate the process of documenting good common operational practices in networking.
One of the most popular RIPE documents - Requirements for IPv6 in ICT Equipment (ripe-501 which was later superseded ripe-554) - was adopted by the BCOP TF.
Another common issue that kept coming up, 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 repeatedly heard questions about what size of IPv6 prefixes should be given to end-users and should they be assigned statically or dynamically. With the help of a team of experienced co-authors and a lot of feedback from the Internet community, we achieved consensus and the document was published as ripe-690 in October 2017.
Whilst still working on the ripe-690 draft, we heard about another common problem when deploying IPv6:
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.
Again we found a great group of experienced volunteers to start documenting some best current operational practices in this area (Sander Steffann, Jordi Palet Martinez, Nasser Heidari, Aaron Hughes and myself). We are also cooperating 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 leave a comment below or contact us at labs@ripe.net.
We will be sharing the draft as soon as possible and we are planning to discuss progress on this document at the RIPE 76 meeting in Marseilles in May 2018.
It’s time for another BCOP, please join us!
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Antonio Prado •
Hi Jan, just a clarification request on this sentence: "there are no IP reputation (black listing) mechanisms to protect from spam". Do you mean that they actually don't exist for IPv6 or they don't speak IPv6, or they are uneffective? Thank you -- antonio
Hide replies
Jan Zorz •
Hey, AFAIK they don't exist as they would currently be rather ineffective. If they would exist - what would be the size of the prefix to blacklist if a spammer is observed? /64? /56? /48? Anything else? Whatever size you pick you can affect other innocent users... Should we define this? Maybe... Cheers, Jan
Hide replies
Antonio Prado •
Yes, we should define that, of course, bearing in mind that it's not going to produce a win-win situation. What you call "innocent users" is necessary evil, unfortunately, whatever prefix boundary will be defined. Anyway: https://www.spamhaus.org/drop/dropv6.txt http://www.usenix.org.uk/content/rbl.html http://blacklist.woody.ch/rblcheck.php3 https://spameatingmonkey.com/services/SEM-IPV6BL thank you -- antonio
Per Jessen •
I would expect greylisting to be very effective on ipv6.