For once, this article is not about security but rather on IPv6 for residential subscribers and their contract to their ISP. As I see more and more residential ISP moving to IPv6, most of them seem to simply import their IPv4 business model into IPv4. A lot of European ISP have two classes of contracts with their subscribers:
- a business-type contract where the IPv4 address is statically assigned to one specific customer for the duration of the contract, there is no inbound TCP port restriction;
- a residential-type contract where the IPv4 address is dynamically allocated and an IPv4 address change is required every day or so, it is usually combined with some inbound port restriction.
The reason is probably to force all people wanting to run any Internet service to move to the business-type contract, which is of course more expensive. The renewal of the IP address has little consequence for the typical IPv4 home network because NAT is used and the internal hosts always keep their RFC 1918 address. The only bad consequences is the loss of existing connections because the NAT table has to be reset and because remote peers are still connected to the previous IPv4 address. With IPv6, the consequences are more severe because the expected IPv6 home network will not use NAT for IPv6 but rather will rely on DHCPv6 Prefix Delegation to receive a /48 or /56 or even simply a /64 (the latter is from an ISP which has still to learn about IPv6) and will use RFC 4862 Stateless Address Autoconfiguration (Router Advertisement) or DHCPv6 on the internal side. This means that the IPv6 addresses of all inside hosts are indirectly assigned by the ISP. So far so good, but what happens if the ISP renews the delegated prefix every 24 hours? The change will cascade through DHCP prefix delegation and either internal SLAAC or DHCP to all hosts. Now, all hosts have at least two global IPv6 addresses: one based on the previous IPv6 prefix and one based on the new prefix. Obviously, the only useful address is the one based on the new prefix because if a host uses the old address, then it will never receive the reply from any host on the Internet as this reply will not be routed to it anymore. There is a simple way to solve this problem: use RA message to signal that the new prefix is available and that the previous prefix should not be used anymore. When a router advertises a prefix in a RA message, it associates several options with a prefix:
- A-bit: whether this prefix can be used for stateless auto-configuration;
- L-bit: whether this prefix can be used for on-link determination;
- Valid lifetime: for how long this prefix is valid;
- Preferred lifetime: for how long this prefix should be preferred
The RFC 4862 is pretty clear in section 5.5.3.e, valid lifetime cannot be set to 0 (or actually to any value below 2 hours – to prevent Denial of Services attack since RA are not authenticated in the absence of SEND). But, the preferred lifetime can be set to 0 and the RFC 4862 even states that this should be used to deprecate a prefix. Therefore, if the ISP keeps the same operation model and changes the IPv6 delegated prefix periodically, then it is mandatory for the IPv6 CPE to immediately adjust the RA messages sent on the home networks with a preferred lifetime set to 0 for the previous prefix and a non zero preferred lifetime and valid lifetime for the new prefix. We can only hope that CPE vendors will implement this mechanism correctly. PS: another hope is that the CPE will update automatically other settings and policies (notably firewall rules) when the delegated prefix is updated.