Summary

  • RIPE-690, published in October 2017 with Jan Zorz among its eleven authors, strongly recommends persistent IPv6 prefixes for customer LANs. It is operating guidance, not a registry allocation rule.
  • A changing prefix can simplify an ISP's pool layout but force customer devices, local services and DNS names to absorb a renumbering event after a reconnect. The document asks operators to test the CPEs they actually deploy.

A power cut is an expensive way to discover who owns the addressing plan. The provider's connection comes back; the customer's router may receive a new IPv6 prefix. Devices behind it still have to shed old addresses, take new ones and restore services that were named against yesterday's prefix. The bill for a neat access-network pool arrives in the living room.

Jan Zorz and ten coauthors put that exchange in RIPE-690, published on 16 October 2017. Zorz later announced the document to the IPv6 working group and thanked the broader contributors. Their question was unusually concrete for an era often sold with the word abundance: how large should a customer prefix be, and should the same customer keep it? A generous supply of bits does not repair a camera whose address changes at the wrong moment.

The guide recommends /48 or /56 for end customers. A lone /64 gives one LAN and little room to subdivide a site. Size, however, is only half the contract. Under a non-persistent scheme, DHCPv6 prefix delegation can draw from a pool attached to an access termination point. That is attractive to an ISP: routes aggregate cleanly around where customers connect. In a persistent scheme, provisioning must know which customer belongs to which prefix and location. The operator has to do more inventory work before the customer has to do emergency work.

Section 5 follows a reboot through the premises. The CPE can give one /64 to a home LAN and another to guest Wi-Fi. If its delegated prefix changes when it reconnects, both networks need fresh addresses. A home camera, a small server or a DNS name tied to the old address may stop being reachable until the change is handled. The authors do not claim every device fails. They say behavior differs, and an ISP choosing non-persistent assignment should verify the CPEs used by most customers.

RIPE-690 also allows an important split: the connection between network and CPE may be provisioned differently from the prefix routed to customer LANs. Keeping the latter stable need not freeze every address on the wire. The document calls persistent customer prefixes strongly preferable, citing simpler identification in AAA or provisioning systems, fewer logging complications and the possibility of stable, named services. It even notes an ISP may value lower churn. That incentive is on the page; no measured churn reduction is supplied.

The sharp point is who gets to call a reconnect harmless. A pool can be orderly on the provider's diagram while the customer's devices perform a surprise migration. Zorz's coauthored guidance asks the operator to price both sides of that diagram before assigning the prefix.