Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182
On 26/03/2015 05:31, Alexandru Petrescu wrote: > Le 24/03/2015 21:01, Brian E Carpenter a écrit : >> On 25/03/2015 08:47, JF Tremblay wrote: >>> >>>> 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)? >> >> I'm not aware of a written version; it's something I've heard him >> say more than once. Of course there is RFC 4192, but it isn't in >> that. > > Not sure what the question was but there is a stds track RFC in the 2000s > about IPv6 router renumbering, authored at Fermilab IIRC. You mean RFC 2894, I think. As is written in RFC 5887: "An ICMPv6 extension to allow router renumbering for IPv6 is specified in [RFC2894], but there appears to be little experience with it. It is not mentioned as a useful mechanism by [RFC4192]." Brian > > That has a notion of difference between numbering and renumbering. > > Numbering is the initial assignment of prefixes on links. Presumably a > manual operation. > > Re-numbering is propagation of tuples [existing prefix, new prefix] with RAs > messages between routers. > > This technique was used by other protocols such as Hierarchical Mobile IPv6 > which is an RFC as well, although experimental IIRC. > > This of course brings the question of what is renumbering. > > Alex > > >> >> Brian >>> >>>> [...] 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 >> > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
