Procedures for Renumbering an IPv6 Network without a Flag Day

Abstract

Procedures for Renumbering an IPv6 Network without a Flag Day Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Renumbering Still Needs Work

“…As described in [RFC4192], this allows for a phased approach to renumbering (adding the new prefix and addresses before removing the old ones).…”

“…Carpenter, et al For IPv6, a useful description of practical aspects was drafted in [THINK], as a complement to [RFC4192]. As indicated there, a primary requirement is to minimise the disruption caused by renumbering.…”

“…This applies at two levels: disruption to site operations in general and disruption to individual application sessions in progress at the moment of renumbering. In the IPv6 case, the intrinsic ability to overlap use of the old and new prefixes greatly mitigates disruption to ongoing sessions, as explained in [RFC4192]. This approach is in practice excluded for IPv4, largely because IPv4 lacks a Stateless Address Autoconfiguration (SLAAC) mechanism.…”

“…Almost ten years later, the IETF published "Procedures for Renumbering an IPv6 Network without a Flag Day" [RFC4192]. A few other RFCs have touched on router or host renumbering: [RFC1916], [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].…”

Report from the IAB Workshop on Routing and Addressing

“…They are also sometimes hard-coded into applications used in environments where failure of the DNS would be catastrophic (e.g., some remote monitoring applications). Although renumbering may be a mild inconvenience for some sites and guidelines have been developed for renumbering a network without a flag day [RFC4192], for others, the necessary changes are sufficiently difficult so as to make renumbering effectively impossible.…”