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 08:20 PM, Lorenzo Colitti wrote:
> On Fri, Apr 10, 2015 at 4:34 AM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > 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.
> 
> 
> It is still the case even with this method, because the servers need to
> agree on the value of the counter variable. 

The Counter value is there for completeness sake. Me, I don't expecThe
assumption is that thanks to the huge address space, you want hit
collisions.

In order for this scheme to not result in address stability, two things
must happen:

1) There address collisions -- considered extremely unlikely, and,

2) Clines employ different DHCPv6 servers (failover scenario), and,

2) The two nodes that bootstrap do so in a different order (otherwise,
they will still be leased the same addresses).

I'd say that a DHCPv6 servers is free to store the Counter value for
each lease, if they please. But it's not worth it to synchronize it. --
the assumption in this scheme is that the address space for the local
subnet is so large that you will not find collisions.

If you, we could rename the I-D as "probabilistically stable" -- but I
hope that's not needed.

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