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

[Lorenzo Colitti <[e-mail]>]

On Sat, Apr 11, 2015 at 1:29 AM, Fernando Gont <[e-mail]>
wrote:

> On 04/09/2015 08:20 PM, Lorenzo Colitti 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.
>

But you have to say what happens in this case. If the client sends a
DECLINE for any reason, what happens? Is it dead in the water with the
wrong IP address? Does the server just respond with the same IP address as
before, hoping that the client will like it? If you don't want the draft to
specify the behaviour, you should at least provide a list of the possible
options, because from what I see, the possible options are all bad.


> 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.


One of the major objections I have here is that the draft says that the
addresses are stable and stateless. However, that statement is not true in
the presence of DECLINEs, collisions, or misconfigurations (probably more
likely than collisions). If the draft didn't say the addresses are stable,
or if it didn't say that the addresses can be calculated statelessly, then
that would be OK, but it does. I think that if you want to standardize this
approach, then IMO you need to quantify what happens in these cases.

Also, I think statelessness is pointless. DHCPv6 is a fundamentally
stateful protocol. It's not just the lease database - clients and servers
also keep track of IAs, server IDs, client IDs, DUIDs. Even if you make the
address calculation stateless, to show value you'll need to show whether
this scheme works when you swap out servers. If it this scheme doesn't work
when you swap servers, then there's really no point in making the address
calculation stateless, since you need to share state anyway.

More in general. Whether you continue work on this document is to you, but
I'll point out that Bernie has stated multiple times that he wants to see
people support this draft, not just "not object to it". I don't see much in
the way of support today. As far as I'm concerned, you may be able to
address the issues that I list above and remove some of the objections, but
I doubt you'll be able to convince me personally that this scheme has value
and turn me into supporter.

Cheers,
Lorenzo