On 08/10/2014 20:50, Pierre Pfister wrote:
> Hello Brian
>
> Please find my answer inline.
>
> Le 8 oct. 2014 à 02:32, Brian E Carpenter <brian.e.carpen...@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.
There is nothing in RFC 4193 that prevents saving the generated ULA in
stable storage for future use; so I think you need to be clearer that
when a ULA is generated, it SHOULD be stored for future use (until the
next factory reset). I don't see why that generates more than a very few
writes to SSD.
> [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.
Well, yes, but randomness is randomness, i.e. all values are equally likely.
It's really the same thing. I think the assumption was that any box capable
of generating a ULA would already have something better than rand() built in
for other reasons.
> My point here is that if we conform to RFC4193, we lose the stability of the
> generated ULA, and IMHO we win nothing.
But if you deviate from the standard you need to say so explicitly.
"This procedure deviates from [RFC4193] because...".
> Correct me if I’m wrong, but I think using hardware specific values as seed
> is perfectly fine with the collision-avoidance requirement.
I would expect so, and I'm not against what you propose, it just needs
to be clearly documented.
Brian
> 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
>
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
