IPv6 policy has gone through many refinements since it was first adopted by the RIRs 20 years ago. Is it time for a more significant change? Join the RIPE Address Policy Working Group in conversation on the next phase of IPv6 policy.
IPv6 policy has developed through an interactive process. The bootstrap phase was designed to learn what would work and what would not. That informed a worldwide discussion that led to a common policy being adopted in all three of the RIRs that existed in 2002. That policy has been regularly refined since then. A broader review began at RIPE 83 in November 2021. We are now setting priorities and identifying the desired outcomes for the improvements that were identified.
We all understand that IPv6 offers a huge address space. In some ways it's not a surprise that the policy for distributing it has been a success. But policy balances competing demands, so we were not guaranteed the outcome we have.
The process to develop the policy framework we have now was explicitly as bottom-up as possible. While the IETF suggested one framework for allocating IPv6 addresses, network operators developed a different framework designed to meet their needs.
While the policy that we have now has been updated over 20 times since 2002, the framework published as ripe-246 is the same framework we use today. We’re currently looking at the overall framework to make sure it’s fit for the future.
At RIPE 83, in November 2021, the Address Policy WG agreed to review the IPv6 policy. The key question was: does the policy need significant change or is it still good?
A small group reported at RIPE 84 in May 2022. They were happy with the structure but suggested some refinements. These included:
- Improving the guidance on documentation requirements for large allocations
- Simplify the language and implementation of the HD-ratio, a new method of assessing utilisation of an allocation. The HD-ratio takes account of layers of aggregation in networks when setting out how efficiently address space should be used. The concept is simple but the underlying calculation is complex and could be presented in a way that is easier for most people to understand.
- Make it easier for small (PI) networks to assign a few addresses to other organisations. For example, hosting a rack of equipment for a business partner. The policy doesn’t allow this with PI space. Some organisations will just not register the assignment and others will become members and get an allocation when they only need a /48.
At RIPE 85 in October 2022 some people also called for one more improvement. They'd like allocations to fall on a nibble boundary. This would help networks develop address plans that use natural bit-boundaries.
The Address Policy WG will run a few webinar discussions in early 2023. These will focus on defining problem statements. Clear problem statements will make it easier for the community to reach consensus on policy proposals.
Sanding off a few rough corners after 20 years of IPv6 policy is a real success. But how did we get where we are today?
We often talk about a bottom-up policy development process. But that really is exactly what we used for IPv6. When the RIRs got their initial allocations from the IANA, a bootstrap policy was developed to learn from the first 100 allocations to networks. The process was focused on learning about how IPv6 allocation resembled and differed from IPv4.
That bootstrap policy granted a /35 allocation to any multihomed network that either planned to deploy IPv6 services within a year, or had 40 customer sites. The goal of this policy was to learn what the shape of a production policy ought to look like.
By May 2001 the RIRs had allocated 80 blocks. They recognised that they would not have a successor policy ready before hitting 100, so agreed to extend beyond 100. 101 allocations had been made by September 2001.
So what were the key findings from those first allocations?
Two lessons were learned. Firstly, the concept of trying to tie IPv6 allocations to a position in a hierarchy of networks wasn’t going to fly. Networks both grow and change the networks they connect to. Constraining that through the numbering system was not practical. Secondly, the bootstrap phase involved /35 allocations. These were both too small and not on a friendly bit-boundary.
These lessons were discussed on a global discussion list for developing the common policy. The goal was to ensure that networks everywhere in the world could get IPv6 address space on the same terms. That production policy set the minimum allocation at /32, which is on a bit-boundary and is eight times larger than a /35.
The resulting policy, as agreed in 2002 and adjusted over time, has broadly achieved what was called for by the IAB and IESG in September 2000.
The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On the one hand, when managing the use of a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as precious a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies.
We want to make sure the next phase of IPv6 policy is as successful as what we’ve had so far. As promised at RIPE 85, we will hold discussions with the community in the lead up to RIPE 86, in May. We already have a good idea of some of the areas for improvement. We want these discussions to help us identify priorities and the outcomes we need from the policy discussion, so volunteers in the community can draft policy proposals.
The first discussion will take place on Monday, 20 February 2023 at 13:00 UTC (14:00 CET). You can get details on for joining us on Zoom in the original announcement to the mailing list.