A homenet implementation may indeed decide to self-destruct in a puff of smoke before daring to step foot into the classful lowlands of the Interface ID, but I actually appreciate that the algorithm itself is more general; for robustness sake, in case it is ever used in a different context, in the event that why64 ends up being wrong, if ISPs don't listen to us and /64 becomes common and we have to do *something* to accommodate, etc.
Don't get me wrong, I've fought long and hard in many forums and venues to keep ISPs from thinking /64 is ever a good idea. I have no problem with the strongest language we can provide to try and enforce that. At the same time, hedge your bets. - Mark On Oct 8, 2014, at 4:21 PM, Tim Chown <[email protected]> wrote: > > On 8 Oct 2014, at 14:14, Pierre Pfister <[email protected]> wrote: >> >> Why should we mandate homenet implementations to *brake* in situations where >> they could work fine ? Why should we voluntarily prevent a link from being >> configured if we actually can configure it ? >> >> If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 >> to customers’ than ‘Homenet MUST brake when the provided prefix is not big >> enough’. > > But this is what the homenet arch text says in Section 3.4.1: > http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1 > > i.e. don’t go longer than /64, and ISPs should provide enough prefixes. > > The why64 text is very relevant here. > > Tim > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
