> On Mar 24, 2015, at 2:00 PM, Brian E Carpenter <[email protected]> > wrote: > > [...] Make-before-break > renumbering (a.k.a. planned renumbering) is preferable but we can't > rely on it. (I also try to never forget Fred Baker's observation that > there is no such thing as renumbering: there is only numbering.)
Any reference for reading (on Fred’s principle)? > [...] However, Dave Taht told us > recently that renumbering *is* currently broken, and I'd like to see his > list of issues. For now, here are the issues that I see: I’ll let Dave answer for himself, but my personal experience at home currently is that it breaks quite often. As soon as the home network gets renumbered, new RAs are flooded, but no RAs are sent to de-prefer the current prefix (as specified in RFC7084 L-13). I’ve seen this happen both with 6RD and in native, with two home router vendors. I usually flap my link physically to flush old addresses. Btw, I didn’t raise this morning, but I believe smooth renumbering from an ISP is possible, at least for cable ISPs (costly, but possible). This requires support for multiple concurrent prefix delegations on home routers, which I haven’t seen yet in the wild. This requirement isn’t explicitly mentioned in RFC7084, only indirectly through the support for DHCPv6-PD (WPD-1). So on the short term, proper implementation of RFC7084 L-13 is required for smoother unplanned renumbering. For smooth planned renumbering, support for multiple concurrent PDs is required. It’s too bad that the homenet architecture doc (RFC7368 section 3.4.1) does not even mentions this possibility. JF _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
