Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

[Lorenzo Colitti <[e-mail]>]

On Wed, Apr 8, 2015 at 11:45 PM, Fernando Gont <[e-mail]>
wrote:

> But, in any case, as far as I recall this I-D does not say "you must
> employ this algorithm for all of the prefixes from which you lease
> addresses", anyway.
>
> If you have any suggested text that would address your concern, please
> do let us know.
>

Well, as you know my suggestion is to leave this up to implementers and not
standardize this algorithm at all :-)


> >     * Address stability can be achieved 100% stateless-ly, but need not.
> >     e.g., you can generate addresses as specified in this document, but
> >     still keep an address lease database. In that case, the server would
> >     employ this algorithm for generating the addresses in the first
> place,
> [....[
> >
> >     Does (some version of) this sound reasonable?
> >
> > Perhaps. But you have to document this, and if you document this and it
> > turns out that you need server-side behaviour changes, then you need to
> > update RFC 3315.
> >
> > Again, I don't think it's worth it.
>
> For the time being, I think we should not consider the 100% stateless
> version of this. After all, the man goal of this document is an address
> selection scheme for DHCPv6, rather than an improvement in terms of "now
> DHCPv6 can be fully stateless".


If this algorithm does not allow stateless operation, and still requires
keeping (and synchronizing) a lease database, then I really don't see the
point of specifying this algorithm at all, as it provides no advantages
over stateful random assignment.