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

[Fernando Gont <[e-mail]>]

On 04/09/2015 03:29 PM, Bernie Volz (volz) wrote:
>> So the clear benefit is that you can have multiple DHCPv6 servers
>> operating on the same network, and you get address stability
>> without an additional protocol.
> 
> This concept is flawed if the servers aren't cooperating. If there
> are multiple servers that don't share lease data, how does server 1
> know whether the lease was leased to another client or renewed, if
> server 2 ends up communicating with the client? 

Usually, you need servers to communicate because there's no way to tell
which address each server may have assigned to which client. But that's
not the case with this method.

Let me provide another example:

Let's assume that servers were to implement e method by which they
select the IID by embedding the client's MAC address in the IID (that
is, the server essentially generates a SLACC address for the client).

If you have multiple servers, and you have access to the client's MAC,
then there's no need for black magic to tell which addres will be leased
to which client.


The method specified in this document is similar in that respect, with
the only difference in that the IIDs are unpredictable.



> Server 1 may also
> expire the lease (and remove FQDN or other data). Or when a
> leasequery is done, the servers will return conflicting data (one
> says not leased, other says leased).

In all cases, the servers will compute the same address. -- that's the
whole point of the expression we use, and of the servers sharing the
same secret key.


> I just don't buy that is has any real benefit.
> 
> But I am going to refrain from discussing this topic any further as
> my position (not as co-chair, but as an individual) is clear. Once we
> get different people to weight in (either on the mailing list or at
> IETF-93) to determine consensus we can figure out the appropriate
> next step.

That's fine. I'd just like folks to decide based on the properties of
the method. Some of the assertions you've made about it are incorrect,
though.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492