> On 25 Mar 2015, at 02:01, Brian E Carpenter <[email protected]> 
> wrote:
> 
> 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.

And it’s very true. A point made several times through 6renum’s lifetime.

For one, it’s in the introduction here:
https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00 
<https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00>

Tim

>     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

Reply via email to