Thanks for the pointer to draft-baker-6renum-oss-renumbering, Tim. It’s true that renumbering is only a sequence of numbering actions.
> On Mar 25, 2015, at 9:20 AM, Mikael Abrahamsson <[email protected]> wrote: > At this time, I do not understand the DHCPv6-PD state machinery to enable > temporal overlap of prefixes so one can achieve a graceful renumbering event. > I wrote this text a while back but never sent it to DHC. Could someone please > help by explaining how to do this temporal overlap using DHCPv6-PD? I can take a shot at this. I’ve done it in a production-like lab with cable equipment. I believe it was with an experimental OpenWRT or D-Link that supported dual-PD. > Now, after a while, the customer decides he wants to change the addressing > space, but he wants to do this gracefully, basically along the lines of > RFC4192. So for a certain amount of time, he wants to have two PDs, > and these need to be distinct. This is where your example stops working. At “the customer decides”. IMHO there’s no way to make this work purely as a customer-triggered sequence of event. Actually, why would the customer trigger this? Is there a good use case for this? In my mind, this is purely triggered from the ISP side, when a network event is planned to happen. Here’s a cable-oriented scenario (sorry, this is my background). In the cable world, providing a perfectly stable prefix for home customers is quite challenging, because the underlying physical network changes on a regular basis to accommodate physical network growth and changes (usually once or twice a year per user). It’s possible to provide stable prefixes, but it involves significant engineering and operational effort (hence a cost). An alternative for cable operators is to provide smooth IPv6 renumbering. Here’s how it could work. This is basically a simpler flavor of RFC4192. 1. The customer gets PD1 from CMTS A. (a /56 out a /40 for example). Stable operation. 2. A week in advance of a network change, a move from CMTS A to CMTS B, the customer gets a reduced DHCPv6 lease time to 24h. 3. 24h before the change, the client gets two prefixes PD1 and PD2, out of A and B /40s respectively. PD1 has a preferred lifetime of 0 and a valid lifetime of 24h. At this point, clients start using PD2 gradually as leases expire and get renewed. The number of disjoint routes in the ISP network raises (deaggregation happens) 4. The change is made overnight. At this point, all clients should already be using PD2. 5. Most clients will redo DHCPv6 (depending if they saw a link-down event, ymmv). PD2 is used everywhere and get re-aggregated in the original /40. PD1 should no longer be used, but is still routed (through B) and deaggregated. 6. PD1 is removed on the DHCPv6 server and lease time restored to its original value. After another 24h, PD1 is no longer present in home networks, no longer routed and no deaggregation remains. The only missing part to make this happen is for home routers to support multiple PDs. The specific DHCPv6 servers and CMTSes implementations I used already supported multi-PD years ago. The big advantage of this for cable operators is to keep user routes aggregated. JF _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
