Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

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 <tjc@ecs.soton.ac.uk> wrote:

> 
> On 8 Oct 2014, at 14:14, Pierre Pfister <pierre.pfister@darou.fr> 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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet