Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)

Works for me, but for RFC 2119, s/CAN/MAY/.

Thanks
   Brian

On 09/10/2014 22:04, Pierre Pfister wrote:
> Hello James and Brian,
> 
> What do you think of the following proposal ?
> It allows any router to generate a ULA (it adds more complexity because collisions must be avoided, even though the Backoff was necessary at boot anyway).
> And it conforms to RFC4193 whenever possible (date is available and stable storage can be used).
> 
> 
> 9.1.  ULA Prefix Generation
> 
>    A router MAY spontaneously generate a ULA delegated prefix whenever
>    the two following conditions are met.
> 
>    o  No other ULA delegated prefix is being advertised network-wide.
> 
>    o  The ULA Backoff Timer is not running.
> 
>    A router MUST stop advertising a spontaneously generated ULA prefix
>    whenever another router is advertising a ULA delegated prefix.
> 
>    At startup, the ULA Backoff Timer is set to a random value between 0
>    and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
>    starts advertising a ULA prefix, all routers except the Network
>    Leader (Section 4.4) increase their Backoff Timer to a random value
>    between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.
> 
>    ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
>    router has to withdraw its own spontaneously generated ULA prefix due
>    to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
>    ULA delegated prefix is advertised network-wide and no new ULA
>    delegated prefix is advertised, for a lapse of time of 4 *
>    FLOODING_DELAY.
> 
>    The most recently used ULA prefix SHOULD be stored in stable storage
>    and reused whenever generating a ULA delegated prefix.  If no ULA
>    prefix can be found in the stable storage, it MUST be randomly
>    generated.
> 
>    ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if
>    the stable storage can't be used or the current date cannot be
>    determined, the prefix CAN be pseudo-randomly generated based on
>    hardware specific values.
> 
>    Not as well that this section doesn't prevent multiple ULA prefixes
>    from existing simultaneously.  ULA prefixes may be provided by
>    DHCPv6-PD or static configuration, as specified in Section 4.3, in
>    which case they are not considered as 'spontaneously' generated and
>    MUST NOT be withdrawn if another ULA delegated prefix is observed.
> 
> 
> 
> Le 9 oct. 2014 à 02:45, Mark Andrews <marka@isc.org> a écrit :
> 
>> Why are we arguing about this?
>>
>> You need to be able to *set* the ULA prefix to something that is
>> externally generated.  This needs to remembered across reboots,
>> power cycles etc.
>>
>> There is no point in having a stable algorithm to generate a ULA
>> prefix.  As far as I can see the only purpose is to avoid having
>> any non-volatile memory in the box and I don't see that as a realistic
>> box.
>>
>> You will also need non-volatile memory for internal prefix delegation
>> etc.  You you do want the same prefix to be handed to the same
>> internal router regardless of the request order.
>>
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 