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

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