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 <[email protected]> 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: [email protected] >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
