agsandrew - Fotolia
Understanding why IPv6 renumbering problems occur
IPv6 renumbering can be a challenge, especially if a host using SLAAC obtains stale prefixes. But there are steps you can take to reduce your vulnerability.
Stateless address autoconfiguration, or SLAAC, is the mandatory and most common mechanism used to automatically configure IPv6 networks. In some network IPv6 renumbering scenarios, however, hosts employing SLAAC may end up using stale network prefixes, leading to connectivity problems. First, some background.
The IPv6 protocol suite supports two different mechanisms for automatic network configuration: SLAAC and Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
Support of SLAAC is mandatory, while support of DHCPv6 is optional -- with Android being one of the most notable platforms that doesn't support DHCPv6. As a result, SLAAC is the most common and widespread mechanism for automatic host network configuration.
SLAAC works generally like this:
- IPv6 hosts, joining a network, broadcast a request for network configuration information. Strictly speaking, the request is sent to a special IPv6 multicast address.
- IPv6 routers attached to the network will typically respond with the requested network configuration information, including network prefixes to be used for address configuration.
- Upon receipt of this information, hosts will configure one or more addresses for the advertised prefix -- with the only requirement being that the resulting address must not be already in use.
- From time to time, local routers will also broadcast the same network configuration information on the local network to keep the information fresh. Otherwise, the information might be considered stale and thus discarded.
One key change from IPv4 is, when SLAAC is employed, address assignment is not centralized -- as in the DHCP-based IPv4 world -- but hosts are free to select any unused address and use it without any kind of registration or lease from any other system.
IPv6 renumbering and how it works
Network renumbering typically consists of replacing a network prefix employed on a network with a different one. In IPv6, planned renumbering for networks employing SLAAC is expected to occur as follows:
- Local routers advertise the existing prefixes with small lifetimes, enabling local hosts to phase out such prefixes.
- At the same time, a new prefix is advertised on the local network, with a long lifetime, enabling hosts to configure addresses for the new prefix.
- Eventually, hosts cease to use the old prefixes and employ only the newly introduced one.
This is usually described as orderly or planned renumbering. It is characterized by local routers phasing out existing prefixes and introducing new ones, giving the local hosts timely information to stop using addresses configured for the existing prefix and to configure addresses for the newly introduced prefix.
Problematic IPv6 renumbering scenarios
A network may be renumbered in many different ways without the local routers being able to signal hosts that the existing prefixes should be phased out. Here's a common one:
In this situation, the local router performs two related, but separate functions. On the LAN side, it operates as a SLAAC router, providing network configuration information to the local hosts. On the WAN side, it operates as a DHCPv6-PD (DHCPv6 prefix delegation) client to dynamically obtain an IPv6 prefix from the upstream internet service provider (ISP). The ISP will typically lease the router a /48 prefix, which the local router will advertise as a /64 subprefix on the local network via SLAAC.
Once a prefix has been leased by the upstream ISP, the local router will only communicate with the upstream DHCPv6 server when expiration of the leased prefix is imminent, enabling it to renew the lease before it expires. Other than that, there will be no further communication between the DHCPv6-PD client on the router and the DHCPv6-PD server at the ISP.
In situations where the local router crashes and reboots, for example, the router will typically request a new IPv6 prefix from the upstream network, and the leased prefix may be different from the previously leased prefix. In these cases, the local router will advertise the new prefix on the local network, causing local hosts to configure IPv6 addresses for the new prefix.
Yet, unless the local router also advertises the old prefix with a small lifetime, hosts on the local network will continue using addresses belonging to the stale prefix in addition to the newly configured ones. This will usually lead to network connectivity problems until addresses configured for the old prefix expire. However, because prefix lifetimes average about one month, this means this problem may persist for an unacceptably long period of time.
Most home and small enterprise routers do not record leased prefixes on stable storage. As a result, if they are leased a new prefix upon a crash-and-reboot event, the local network will experience the same issue.
What you can do to avoid connectivity problems
You can avoid these problems in a number of ways. Keep in mind, however, some rely on protocol and/or implementation updates and thus may not be readily available. Among them are the following:
- Do not employ dynamic prefixes. This would mean, for example, that an ISP would always lease the same prefix to each home router or enterprise router, avoiding the IPv6 renumbering event. This method may or may not be feasible or desirable. Stable network prefixes may fuel privacy implications that also must be considered.
- Routers employing DHCPv6-PD should record leased prefixes on stable storage. In the event of a crash and reboot, previously leased prefixes can be phased out.
- SLAAC should be improved, enabling it to detect stale prefixes and to assign smaller lifetimes to network address resources. This would let SLAAC react more quickly to stale network information. There is ongoing work at the Internet Engineering Task Force to incorporate some of these possible improvements in an effort to reduce IPv6 renumbering conflicts.
