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

["Bernie Volz (volz)" <[e-mail]>]

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

This is NOT true at all (collisions virtually impossible). In fact, the exact opposite will almost certainly be true.

Also think of cases where much smaller spaces than a /64 are being used (such as when a server is configured for a start to end range (1 to 100000)) or when a longer prefix length is being used (/96) for assigning addresses.

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[e-mail]] 
Sent: Monday, April 13, 2015 9:05 PM
To: Lorenzo Colitti
Cc: Bernie Volz (volz); [e-mail]
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

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