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

[Fernando Gont <[e-mail]>]

Hi, Lorenzo,

On 04/11/2015 01:38 AM, Lorenzo Colitti wrote:
> On Sat, Apr 11, 2015 at 1:29 AM, Fernando Gont <[e-mail]
> <mailto:[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.

In my mental model, if the client sends a DECLINE, that's interpreted as
a collision, hence Counter is incremented, and you get a different IPv6
address.

I guess this should be configurable:
1) "Hard assignment": IPv6 addresses collisions are flagged as
"impossible", and server always offer the same address (i.e., Counter is
not used at all)

2) Soft assignment: server assigns an address but offers an alternative
one in the case of collisions.


Not sure why you say all options are bad. If you were doing
randomized/statefull DCHPv6 address assignments, you'd have to handle
DECLINEs, too.



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

Ok. I will craft text along these lines. Among other things, discuss
DECLINES, note that collissions are expected to be virtually impossible
thanks to the address space, etc.


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

Swap == replace the server with a "cloned" one (same IPv6 address, and
Server DUID)?

or...?



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

Part of that seems to have to do with how things work if you swap the
server. I can give that a try (if you stay open to change yur mind if
that makes sense).

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