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

[神明達哉 <[e-mail]>]

At Wed, 1 Apr 2015 17:30:50 +0000,
"Bernie Volz (volz)" <[e-mail]> wrote:

> To the WG and co-authors of this document, as a follow up from the
> Dallas (IETF-92) DHC WG meeting, there is the question as to next
> step(s) for draft-ietf-dhc-stable-privacy-addresses.

[...]

> So, I will propose that the DHC WG "drop this work" (mark the ID as
> dead). Objections? Comments?

I have no objection to abandoning it.  But I wouldn't be opposed to
publishing it either.  In that case Informational seems to be a good
choice.  My reasons follow:

As far as I understand it, the main value of this approach is:

1. allow DHCPv6-assigned addresses to be (much) less predicable, AND
2. make sure the same address is assigned to the same host in the same
   particular link over multiple DHCPv6 sessions

I guess we generally agree on the need for #1, especially for some
kind of deployment.  I also think value #2 would be considered very
useful, even if not critical - it will be convenient if I can get the
same address on my laptop or smart phone or tablet when I get back to
home.

So the question is whether this specific approach to achieve these
goals is worth an RFC.

As you pointed out, (unlike SLAAC) it would be much easier to do this
in the case of DHCPv6 *in practice*: just assign addresses randomly
for the first time but remember and reuse the binding beyond a single
DHCPv6 session as much/long as possible.  This approach is less
reliable than dhc-stable-privacy-addresses since the server could
discard the binding for some reason (storage/memory requirement, etc),
but it's probably good enough in practice (it at least provides the
same level of stability as that we have today for DHCPv4).  It will
also not work if the server is replaced with a new one, but again you
pointed out, such events would be rare enough in practice.  It may
also be difficult to achieve these goals with failover cases, but,
once again, failover itself is probably a less frequent event
(otherwise the network has a more serious issue than address
stability), and the operational cost with dhc-stable-privacy-addresses
to make this case work also seems to be non-negligible.

So, I tend to agree that the advantage of this particular proposal is
not so strong.  In that sense I have no objection to abandoning the
work.

Whether we still want to publish it would depend on whether we want to
show a solution that provides the value #1 and #2 above and that 100%
works without relying on server state or replacement.  Personally, I
don't see a strong need for that (practically good solution seems to
be enough), but if some other people want to have it, I wouldn't be
opposed to that desire.

In that case, I think it's better to publish it as an RFC (rather than
a personal blog or white paper or something like that) since one major
benefit of this approach is that it works even when we replace the
server, and to make it work different server implementations will have
to use the same algorithm.  And, in this case, I don't have a strong
opinion on which standard level is the best simply because I'm not a
standard-level police, but Informational seems to be good enough.
This approach does not affect protocol interoperability in its strict
sense, and unlike the SLAAC counterpart (RFC7217, to which the same
argument applies) we have a reasonable alternative for the expected
goal.  So the standard truck is probably too much for it.

--
JINMEI, Tatuya