Re: [homenet] I-D.ietf-homenet-prefix-assignment

Hello Brian

Please find my answer inline.

Le 8 oct. 2014 à 02:32, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :

> On 08/10/2014 12:14, James Woodyatt wrote:
> 
> (quoting draft-ietf-homenet-prefix-assignment-00)
> 
>>   prefix.  If no ULA prefix can be found in stable storage, it MUST be
>>   randomly generated, or generated from hardware specific values.
> 
> That sentence is not OK. It should be:
> 
> If no ULA prefix can be found in stable storage, it MUST be generated
> as specified in [RFC4193].

The point was to have a pseudo-random algorithm that always generates the same ULA.
Stable storage can be used, but on most crappy home routers, writing on the SSD too much will kill it in a few thousands writes.

[RFC4193] states:
3.2.1.  Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].

If remembering the ULA prefix and using it again and again (using stable storage) is OK, I don’t see why we would need cryptographic pseudo-randomness here.
And actually that’s even worse. Why would a cryptographic pseudo-random function would be used with a *known* seed. 
The ULA doesn’t need to be secret. It just needs to be random enough to avoid collisions.

My point here is that if we conform to RFC4193, we lose the stability of the generated ULA, and IMHO we win nothing.
Correct me if I’m wrong, but I think using hardware specific values as seed is perfectly fine with the collision-avoidance requirement.

Cheers,

Pierre

> 
>> The requirements keywords in this section make for a pretty serious interop
>> clash with Thread networks <http://threadgroup.org/>, which generate their
>> own ULA prefix based on a method defined by its current conventions.
> 
> I sincerely hope that method conforms to RFC4193.
> 
>    Brian
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet