On 17/08/2015 11:01, Juliusz Chroboczek wrote: >>>> which avoids renumbering. > >> Why do we care? Homenets need to be renumbering-proof anyway, because >> the ISP might change the prefix anytime. > > You're right, that deserves clarifying. We're trying really hard to make > sure that in no circumstances is running a Homenet router worse than > running an ordinary NAT/DHCPv6-PD router. Consider the following trivial > topology: > > ISP ---- Homenet router ---- stub link > > We'd like to ensure that: > > - the NATed IPv4 prefix assigned to the stub link remains stable; > - if the /56 delegated by the ISP is stable, then the global /64 > assigned to the stub link remains stable; > - if the Homenet router is announcing a ULA, then the ULA /64 assigned > - to the stub link remains stable. > > In short, we'd like any prefix assignments performed by the Homenet router > to survive a reboot, even in the absence of either explicit configuration > or stable storage.
That may be desirable, but must not be depended on. The homenet architecture is explicit on pp 25-26 that renumbering is an expected event: https://tools.ietf.org/html/rfc7368#page-26 The addressing, routing and naming architecture has to be ready for renumbering at any time. Anything else is broken. Brian _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
