One Bit to the Left - An IPv6 Success Story

Developments in IPv6 can appear slow moving at times with new milestones often seeming few and far between. That said, there are examples of healthy growth out there if you know where to look, and we’re pleased to see that the policies in place to accommodate that growth are being implemented as they should be.

A quick recap on RIPE Policy and IPv6 allocations

According to current RIPE policy – i.e. the IPv6 Address Allocation and Assignment Policy (ripe-738) – LIRs that meet the initial allocation criteria are eligible to receive an initial IPv6 allocation of /32 up to /29 without needing to supply any additional information.

Out of that initial allocation, ISPs assign address space to customer networks or ‘sites’ in /48 blocks. Each /48 contains 65,536 /64s, the standard size for an IPv6 network. And each /64 contains 18,446,744,073,709,551,616 IPv6 addresses, to be assigned to hosts on those networks. As you can see, we’re talking unthinkable, phenomenal numbers of IPv6 addresses here.

For the ISP, having that initial /29 prefix means that they can accommodate 524,288 sites from their initial allocation alone. While that’s a very big number, as we’ve just seen, it’s much more down to earth than the number of addresses such a prefix actually covers. And, in what can only be a good sign for IPv6 growth, it’s a number that some ISPs have actually started to run up against.

The HD Ratio

To give some idea of how we arrived at extending the gigantic allocation that is a /29 to something even bigger, it will help to say a few words about the HD-Ratio.

In order to make sure that IPv6 address assignments are carried out as efficiently as possible, [RFC 3194] specifies a certain point at which addressing systems begin to ‘stretch beyond their practical limits’. That point is defined in terms of the HD-Ratio, an adaptation of the H-Ratio originally defined in [RFC 1715], and is expressed as follows:

According to the policy, a HD-Ratio of 0.94 is the utilisation threshold for IPv6 address space allocations. Simplifying things a bit, when speaking in terms of /48s, an ISP with a /29 will hit the 0.94 mark once they’ve assigned a little under 238,000 of their /48s. (More details on how the HD-ratio is used to calculate a ‘utilisation minimum’ can be found in Appendix A of ripe-738.)

The important point here is that, if an ISP can provide documentation proving that they have hit this threshold, then the RIPE NCC will go ahead and extend their allocation.

NetCologne GmbH

On 15 December 2020, for the second time since we started allocating IPv6, we received a request for a subsequent /29 allocation.

Like other ISPs, NetCologne GmbH – a telecommunications and Internet service provider located in the Cologne region of Germany – had decided to assign a /48 prefix to all their DSL / Cable Access customers, amounting to around 430,000 in total. So, with user growth was around 1000 a month, they were close to exhausting their resources.

To support their request, NetCologne GmbH provided a number of documents including screenshots from their IPAM, an overview of their Broadband remote access servers showing the /48 prefix delegation as well as an overview of their current IPv6 usage.

The documentation provided made it clear that NetCologne GmbH had indeed hit the relevant threshold, and in accordance with the policy, we were able to extend one of the /29s by one bit to the left, thus creating a /28. NetCologne GmbH indicated the preferred /29 for extension, and this was done on 22 December 2020.

An Interview with NetCologne GmbH

To learn more, we reached out to Michael Adams at NetCologne to tell us about their IPv6 journey:

• You received your first allocation in 2005. Tell us about how you started with IPv6?

In the beginning we made small steps. In 2005, there were a lot of questions that we had to clarify. Not only "what is IPv6 and how does it work?". Other questions were "why should we do it and why now?". As an ISP we are providing Internet access and if IPv6 would come we also would have to provide IPv6.

So we made ourselves familiar with the new protocol and it became very clear that it would become more important over time.

One of the first steps was to build a test environment consisting of a few routers and connect them to the rest of the world. We established DE-CIX peerings and connected our peering routers to the test environment using 6to4 tunnels.

The goal was to get more experienced and to create a playground not only for network engineers but also for the server people. Not only the hardware but also the colleagues had to become IPv6 capable.

• Your first assignment in the RIPE Database is the test environment that you established. How long did you spend working on IPv6 before you felt confident enough to deploy to your customers?

At the beginning, IPv6 was a part time project and the available time for it was limited. Therefore it took about three years to bring IPv6 to the customers. In these years we had to enable IPv6 inside the IP Core, on the Border and Distribution Layer.

We also had to make design decisions about the IGPs used and the network size for our customers. We had to test IPv6 for *DSL and Cable access. This also involved the provisioning and authentication part of the Internet access.

On the server side we had to enable IPv6 on our DNS, web and mail infrastructure. We also had to prepare services such as radius and our internal tools for monitoring and abuse management. So it took some time until we were able to provide IPv6 for interested people.

The first project was to become a SixXs POP. We were running this POP until 2017. We still had some issues to solve before we could enable IPv6 for residential *DSL customers in 2013. Lawful Interception for example.

• What were both the benefits and challenges that came from using IPv6?

One of the main challenges was to build up knowledge and experience. It just takes time. This applies to both the technicians and all other departments such as the hotline and sales. Even if IPv6 is not a product, it must be considered in the processes and service descriptions.

On the technical side the main challenge was the lack of support for IPv6 on different hardware platforms. Either features were missing or they were implemented in software which led to performance problems. A lot of CPEs had no proper IPv6 implementation.

We used a solution for automated feature testing. This solution did a great job. No one is happy if faulty CPEs are delivered to the customers. All of this is very time-consuming, with no immediate financial benefit.

One big benefit was to be prepared for IPv4 depletion. Without early preparation the risk was to become incapable of acting. Another benefit was that IPv6 connectivity can be a decision criterion for business customers when choosing an ISP. IPv4 exhaustion also made it necessary to connect residential customers via Carrier Grade NAT. In this case IPv6 is used for DSLite.

All in all, IPv6 keeps the business running.

• You also support a number of End Users who have an IPv6 assignment. Did any of them have concerns regarding IPv6 and what did you do to reassure them?

Usually they have no concerns when they already have an IPv6 assignment. They have reasons for requesting IPv6 space. Sometimes they ask about our lessons learned, our experiences with specific issues.

When starting with IPv6 we recommend thinking about an addressing plan and security issues. If they were used to a certain level of protection through NAT, this is different with IPv6. Of course, NAT is not a security solution. But it may be seen as something similar by customers. So it is important to know what happens when IPv6 is enabled.

A good addressing plan may make also security designs easier. Also a decision about the network size for customers is helpful. For example, we decided to assign a /48 to each customer, regardless of whether it is a business or residential customer. This has simplified many things such as all the tools for address or abuse management.

Before we started the IPv6 rollout for *DSL we went through a pilot phase. Interested customers could ask for native IPv6 support on their DSL connection.

Running a SixXs Pop was very helpful because we could ask the SixXs people for spreading the news about the pilot to their members. A direct communication was not possible because we did not know which of our customers were using SixXs.

During this pilot we provided support and FAQs to the participants and got feedback in return. In case of problems we try to solve them instead of just turning IPv6 off.

• What is the customer experience with the services that you provide and did you provide specific documentation / assistance to help them with IPv6?

Residential customers usually don't care much about the IP protocol. As long as the Internet is working as expected everything is fine. IPv6 is enabled by default on all our services and it is just working.

Business customers, on the other hand, receive a questionnaire in which they can provide information about their IPv6 requirements, for example:

- Do they want a stateful firewall?
- Do they want to use SLAAC on their LAN port?

• In 2017, you received a new allocation and only three years later, you have extended this. How did you experience the entire process of extending your allocation (preparation, planning, ticket handling by the RIPE NCC)?

All in all: very easy. Our first allocation was a /32, but after some time we realised it was too small. For assigning a /48 to each customer we needed a /29. Extending the /32 was not possible because we did not meet the requirements for a subsequent allocation.

Our IPv4 addresses in use would have justified an initial /29 allocation but we had not enough customers online to match the HD ratio. Returning the /32 and allocating a /29 would have meant to renumber the whole network.

The accepted policy proposal "Extension of the Minimum Size for IPv6 Initial Allocation" solved the problem. All further requests for subsequent allocations were easier because we met the HD ratio.

Planning and preparation is no big deal. We have to monitor the resources used on our access routers anyway and it is very helpful for documenting the IPv6 usage.

• You shared a lot of information that showed how you document your IPv6 usage as part of the extension request. Could you tell us about the process you followed to document your IPv6 usage as part of the extension request?

Most of the addresses are used for residential customers and we have to monitor the address pools used on our access routers. The monitoring system will send an alarm when the free pool falls below a certain threshold and we check the usage before moving customers from one router to another.

Our wiki pages obtain the data directly from the monitoring system. This overview is very comfortable for us and we can use it for extension requests.

• Do you plan to stop using IPv4 at some point and become fully IPv6?

As long as IPv4 is needed for full Internet access we have to support it. I believe running IPv4 will become more expensive over time. It is already causing additional costs for CGN devices.

The number of prefixes in a full v4 BGP table is still growing and I do not see the curve flattening. This means either to replace routers not capable of this table size or reducing the number of prefixes by filtering. For customers it will be becoming more and more difficult to get the v4 network size they want. But they can have lots of v6 addresses.

I think IPv4 will stay with us for quite a while, maybe some decades.

• Finally, what advice / wisdom could you share that may encourage others to move further with IPv6?

One should ask himself a few questions:

- How important is IPv6 connectivity for my business?
- What will happen when I do not get the amount of IPv4 addresses I need?
- How long does it take to deploy IPv6 for my business?

Sometimes I see IPv6 as a train that speeds up. It depends on how fast you can run if you need to jump on it one day. IPv6 is easy but it just takes time until everything is ready. At least you could ask your hardware suppliers and your ISP about their IPv6 support when you are buying new hardware or when you are choosing your Internet provider.

Another question might be what are the advantages of IPv6. CGN devices are used more and more for IPv4. This may add some network hops and can cause problems with some VPN solutions for example. Not every mobile provider offers IPv6. This can lead into connectivity problems when you try to access a service behind a NAT solution from your cell phone. Enabling IPv6 on your services may result in better connectivity for the people using them.

I believe IPv4 will cause more problems in future. Problems you can avoid with IPv6:

- It’s not magic
- It does not hurt
- Be prepared!
- Turn it on!

Summing Up

We know that IPv6 is still a slow journey for some, though this recent event does show that IPv6 is becoming important to our members and we’re delighted that somewhere, there has been a great need for more of it.

If you feel that you are reaching the point where your IPv6 address space is falling short and it's time for an extension, feel free to contact us at Registry Services and we’ll be glad to assist you.

Here’s to that next HD-Ratio based extension!