‹ Back
Deploy360 20 August 2013

BCOP Efforts Continue – An example in RIPE-554…

Jan Žorž
By Jan ŽoržFormer Operational Engagement Programme Manager

We continue to travel to different operators and Internet communities around the world to talk about the idea of documenting best current operational practices (BCOP). So far, we’ve visited almost every continent and planted seeds, and some of them are starting to grow.

Documenting current operational practices is not just useful for other (less traveled) operators to understand the best way to run a network and deploy new protocols and services –  but also to help operators avoid some common pitfalls and mistakes when starting and architecting new networks and help them select the right tools to use to run them.

An Example – RIPE-554

As an example, I would like to talk about a document that began with a real need and later gained consensus within the RIPE IPv6 WG community to become RIPE-554.

It all started with a simple question to a representative of our government here in Slovenia: “Why are you not requesting IPv6 support when buying equipment?

The answer was not surprising: “Because we don’t know how. Can you write us some text with the requirements and we’ll put it in our public tenders?

Challenge accepted! 🙂

Getting Started

I realized I’d have to pull together information from several different web sources into one useable document. Slowly, the draft text started to form. It went through the Slovenian IPv6 Working Group and public discussion at one of our Slovenian IPv6 Summits, then someone suggested I translate it into English and ask the RIPE IPv6 Working Group to comment on it. We wanted to see if anyone else needed such a document and specification. Sander Steffann helped me with the translation and modifying the first version, so he became a co-author of the document.

The reaction was instant – many responses indicated that this sort of work is really needed and comments on the proposed text started to flow. We tried to capture the suggestions and produced nine intermediate drafts to address and reflect the discussion. Finally we reached consensus and – with a clear promise to continue working on the document – we published the result as RIPE-501.

We knew that RIPE-501 was not perfect, but we wanted to publish something because so many people were asking for it. We translated the document into many languages and it was widely used around the world by governments, ISPs, enterprises, and many others.

Suggestions for improvements continued to come in, so we asked Merike Käo to be a new co-author and all of a sudden we were able to put additional perspective in the document. More text, more descriptions of how to use the document, more device types and so on – the document became more “human readable” and not just a bunch of RFC lists and short instructions on what to do with it.

After another year and a half of community discussion and another ten revisions of the draft, the community reached consensus that the document was ready and published the document as RIPE-554 that replaced and obsoleted RIPE-501.

So what is RIPE-554 all about?

It’s a procurement document that helps in requesting IPv6 support in HW/SW when buying ICT equipment.

It’s 18 pages long, so it is a manageable size and it specifies the mandatory and optional IPv6 requirements for hosts, consumer-grade L2 switch, enterprise/ISP grade L2 switch,  router or L3 switch, network security equipment, CPE, mobile devices and load balancers equipment.

It also specifies the requirements for IPv6 in software and IPv6 skill requirements of the systems integrator.

The important part is the generic text that is suggested to put in every tender:

All ICT hardware as subject of this tender must support both the IPv4 and IPv6 protocols. Similar performance must be provided for both protocols in input, output and/or throughput data-flow performance, transmission and processing of packets.

IPv6 support can be verified and certified by the IPv6 Ready Logo certificate.

Any software that communicates via the IP protocol must support both protocol versions (IPv4 and IPv6). The difference must not be noticeable to users.

Equipment that has not been put through the IPv6 Ready testing procedures must comply with the RFCs listed below:

This is just one example of the process and resulting document that would very well fit into the BCOP category – so why not identify more topics like this and start working on them?

‹ Back

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...

Join the conversation with Internet Society members around the world