One of the biggest changes between IPv4 and IPv6 for network providers, particularly those that serve residential customers, is the absence of Network Address Translation (NAT).
While IPv4 made managing home networks entirely transparent for providers, this is not the case with IPv6, as the assignment is from the provider aggregatable (PA) IPv6 address space. Hence, changes within the provider’s network could affect address assignments for user devices.
As a best current practice, RIPE-690 recommends that providers should assign ‘persistent’ IPv6 prefixes to their customers. If providers strictly adhere to this recommendation, it would ensure that the assigned prefix would not change. However, some factors make it impractical to adhere to this recommendation. For example:
- A change in a customer’s ‘attachment circuit’ to a different routing device such as a Broadband Network Gateway or Cable Modem Termination Systems.
- A change in a customer identifier, such as the MAC address of customer premises equipment (CPE).
- IP address renumbering within a provider’s network.
- Lack of support in operations and business support systems.
So, while persistent prefixes are desirable, the reality is that users tend to have fairly ‘non-persistent’ prefixes, that might change because of some events on the provider’s network.
Impact to users
A change in the assigned prefix shouldn’t cause much grief to the user (beyond the renumbering of the home network). The issue arises when older prefixes, which are now stale, are not deprecated or invalidated.
The change in prefix assignment would often be signalled by either SLAAC or DHCPv6. When SLAAC is in use (as is often the case), the change would sometimes look like the addition of another prefix on the network. Devices then end up with multiple addresses assigned from multiple Prefix Information Options (PIOs) even though only one PIO is currently valid.
As the host considers all the addresses to be valid, they are candidates to be used for source addresses in communication. Unfortunately, these communications are likely to fail, if the source address is not from the currently valid PIO. This would result in a degraded or sometimes total service outage.
Root causes
Abrupt reloads of CPEs will sometimes result in a prefix change. In such instances, the CPE does not have the opportunity to deprecate the older PIOs. Typically, the home network might rely on the loss of media to invalidate the older prefixes.
However, in topologies where there are layer 2 switches (for example, Wi-Fi Extenders) between the CPE and the devices (Figure 1), devices may not detect the loss of media. Other root causes include:
- Where the Wide Area Network (WAN) component of the CPE can be reinitiated/rebooted without affecting the operation of its Local Area Network (LAN) component.
- Where providers or CPEs do not deprecate older prefixes during a change in PIO.
- Dynamic changes to Virtual LAN (VLAN) association in an enterprise environment.
Multi-home multi-prefix environment further complicates the issue
The issue is further complicated in multi-homing multi-prefix (MHMP) environments, which might be used by small and medium-sized businesses (SMB).
In the following scenario (Figure 1), an SMB might decide to obtain Internet access from multiple providers. It may then terminate the services on one or multiple routers on its LAN. Having multiple valid PIOs is the norm, as the CPEs would have to announce PIOs from each of the providers. The logic for selecting a source address would have to consider which exit provider is being used.
With multiple providers, the number of possible scenarios significantly increases with the events already described. Full analysis of these scenarios is beyond the scope of this post.
Current mitigations
Current implementations are pretty much dependent on the ‘ageing out’ of the stale information. Unfortunately, with the default timers, this would be seven days (PIO preferred lifetime). Furthermore, current specifications do not permit this value to be less than two hours. This is still considered as unacceptable. This issue is well described in RFC 8978.
RFC 9096 recommends some best mitigation practices, however, it is our opinion that to adequately increase the robustness of the Neighbor Discovery (ND) protocol, changes to the protocol specification are required. Furthermore, recommendations for MHMP environments are also required.
Proposed resolutions
This Internet draft (draft-vv-6man-nd-prefix-robustness) proposes several changes to increase the robustness of ND, including:
- Introducing a new ND Protocol Option (or flag) to indicate that the information contained in the router advertisement (RA) is comprehensive. The current specification permits routers to use multiple RAs to convey their information. Unfortunately, this also means that it is not easy for the host to infer what information is stale. Information in newer RAs would not automatically invalidate older information. With an option to indicate that this is a complete set of information from the router, the host can immediately invalidate older information from that router. This would immediately synchronize the host with the router. This is illustrated in Figure 3.
- Changes to the MHMP environment. These changes include:
- The host should prefer the default router that advertises the prefix used for the source address chosen.
- The host should deprecate PIOs if the prefix source is lost (with optional dampening).
- CPEs should not stop advertising themselves as a default router if one of their upstream providers is lost. Instead, they should deprecate the PIO.
We welcome your thoughts on draft-vv-6man-nd-prefix-robustness.
Loba Olopade is a Principal Network Innovations Engineer at Virgin Media O2. He is a co-author of the Internet Draft draft-vv-6man-nd-prefix-robustness along with Eduard Vasilenko and Paolo Volpato (both of Huawei Technologies) .
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.