Deploy360 IETF IPv6

How IPv6 SLAAC Responds to Renumbering Events

If you follow the IPv6 Maintenance (6man) Working Group of the Internet Engineering Task Force (IETF), you may have noticed the 300+ message email thread on an Internet Draft that was recently published on the “Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events”. This was prompted by the experiences of developing Best Current Operational Practice on IPv6 prefix assignment for end-users, an activity led by ISOC’s Jan Žorž and published as ripe-690.

SLAAC is used to automatically assign an IPv6 address to a host, but there are a number of scenario where hosts may end up using stale configuration information and thereby leading to interoperability problems.

For example, a typical IPv6 deployment scenario is when a CPE (Customer Premises Equipment) router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of the leased prefix on the LAN-side via SLAAC.

In such scenarios, if the CPE router crashes and reboots, it may lose all information about the previously leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems.

ripe-690 had tried to address this problem by recommending that operators lease stable IPv6 prefixes to CPE routers, but for various reasons, ISP may not be able or willing to do this, and may instead lease dynamic prefixes. In fact, a recent survey of ISPs indicates that 37% of the surveyed ISPs lease dynamic IPv6 prefixes to their customers, as opposed to the stable prefixes recommended by ripe-690.

Most of the input on the 6man mailing list fell into one of the following camps:

  • “ISPs should be leasing stable prefixes — if they don’t, they are asking for trouble!”
  • “CPE routers should record leased prefixes on stable storage, such that they can deprecate such prefixes upon restart — if they don’t, they are asking for trouble!”
  • “No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments”

This Internet Draft therefore tries to improve the current state of affairs through the following improvements:

  • Allow hosts to gracefully recover from stale network configuration information — i.e. detect and discard stale network configuration information.
  • Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner; unless it is actively refreshed by Router Advertisement messages.
  • Specify the interaction between DHCPv6-PD and SLAAC — which was rather under-specified.
  • Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart.

Based on the mailing list discussions, there would seem to be consensus this is a problem that needs to be addressed by the 6man Working Group.

The topic is therefore likely to be on the working group agenda at the IETF 104 Meeting at the end of this month in Prague, Czech Republic. So if you’re a network operator, vendor or otherwise have operational experience of this issue, you’re strongly encouraged to contribute to the discussion.

Further Information

Deploy360 Internet Exchange Points (IXPs) Internet of Things (IoT) IPv6

Promoting RIPE-690 @ Netnod

Our colleague Jan Žorž will be promoting RIPE-690 “Best Current Operational Practice: IPv6 prefix assignment for end-users – persistent vs non-persistent, and what size to choose” as the opening keynote at the forthcoming Netnod Meeting on 14-15 March 2018 in the Sheraton Hotel, Stockholm, Sweden.

RIPE-690 outlines best current operational practices for the assignment of IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making wrong choices when designing an IPv6 network will eventually have negative implications for deployment and require further effort such as renumbering when the network is already in operation. This was published in late 2017 after a year of intensive work by IPv6 experts around the world, supported by the Internet Society’s Deploy360 programme.

Netnod is a neutral, not-for-profit Internet infrastructure organisation based in Sweden that operates six Internet exchange points (IXPs) in five different cities where network operators can connect and exchange traffic.

There’s also several other interesting talks on the agenda, including trends in Internet-of-Things Distributed-Denial-of-Service botnets, prudent TLS, how to practically deploy IPv6 in the mass-market, how clouds are making new demands for connectivity and hyperconnected datacentres, and establishing research networks in Arctic environments, plus a panel session on the future of peering in the Nordic countries.

There’s still time to register, which is free provided you turn up!

Deploy360 IPv6 Technology

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

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

Deploy360 IPv6

IPv6 prefix assignment BCOP published as RIPE-690

We’re pleased to announce that after a year of intensive work by IPv6 experts around the world, supported by the Deploy360 team, the RIPE community has reached consensus on the Best Current Operational Practices (BCOP) for IPv6 prefix assignment for end-users – persistent vs non persistent and what size to choose. These were officially published as RIPE-690 this week.

RIPE-690 outlines best current operational practices for the assignment of IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making wrong choices when designing an IPv6 network will eventually have negative implications for deployment and require further effort such as renumbering when the network is already in operation. In particular, assigning IPv6 prefixes longer than /56 to residential customers is strongly discouraged, with /48 recommended for business customers. This will allow plenty of space for future expansion and sub-netting without the need for renumbering, whilst persistent prefixes (i.e. static) should be highly preferred for simplicity, stability and cost reasons.

The target audience of RIPE-690 is technical staff working in ISPs and other network operators who currently provide or intend to provide IPv6 services to residential or business end-users. Up until now, there have been no clear recommendations on how to assign IPv6 prefixes to customers, and a variety of different and sometimes problematic solutions have been implemented.

By bringing together subject matter experts with practical deployment experience, it’s been possible to identify common practices and problems, and provide recommended solutions to some of the more commonly encountered issues.

The authors of the document were Jan Žorž, Sander Steffann, Primož Dražumerič, Mark Townsley, Andrew Alston, Gert Doering, Jordi Palet, Jen Linkova, Luis Balbinot, Kevin Meynell and Lee Howard. Other contributors were Nathalie Kunneke-Trenaman, Mikael Abrahamsson, Jason Fesler, Martin Levy, Ian Dickinson, Philip Homburg, Ivan Pepelnjak, Matthias Kluth, Ondřej Caletka, Nick Hilliard, Paul Hoffman, Tim Chown, Nurul Islam, Yannis Nikolopoulos and Marco Hogewoning.

The document was submitted to the RIPE BCOP Task Force and then to the RIPE IPv6 Working Group, as part of the Internet community feedback and consensus building process. Thanks should go the Chairs of those groups who ensured the recommendations do conform with actual best operational practice, along with the RIPE NCC staff who facilitated the publishing process.

So now there are some agreed stable recommendations for IPv6 prefix assignment for end-users, we’d ask all network operators to read and consider the document when deploying IPv6 to your customers.

And as always, please visit Deploy360’s Start Here page to find resources on how to get started with IPv6.