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.
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
