Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt

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

I'm going to answer one specific point first, as I think that's most
substantial and requires explicit attention from other wg members.

At Sun, 17 Jan 2016 17:11:18 +0800,
Lishan Li <[e-mail]> wrote:

> > - this protocol changes DHCPv6 message exchanges quite substantially:
> >   previously, the client first sends a Solicit message, gets possibly
> >   multiple Advertise messages, chooses the server (= sender of one of
> >   the Advertises) that would be best for the client, and then sends a
> >   Request to that chosen server.  Now the server selection is done at
> >   the key exchange phase (the initial Information-request and Reply
> >   exchange), and the Solicit can be sent only to a single server.  If
> >   the client doesn't like the Advertise it could restart the whole
> >   process, but it will be more expensive, and there's no guarantee
> >   that other servers can provide a better Advertise.
> >
> >   One might argue that it's okay as "secure DHCPv6" is an "optional"
> >   extension.  But, with keeping in mind that the current IETF trend is
> >   to make everything privacy-aware (often by making everything
> >   encrypted), I'd personally say we should consider it to be the
> >   standard mode of DHCPv6 operation even if users can still disable
> >   it.  From this point of view, I think we should either
> >   A. make the server selection behavior more compatible with the
> >      pre-encryption protocol, or
> >   B. accept we give up the previous server selection feature for
> >      privacy (after careful assessment of its effect and with clear wg
> >      consensus), and explicitly note that.  we might even have to
> >      reflect that in rfc3315bis.
> >
> > [LS]: In my opinion, we should give up the previous server selection
> feature for
> privacy. Compared with rfc3315 and rfc3315bits, secure DHCPv6 is another
> mode. rfc3315bis is clear-text mode. And the secure DHCPv6 is secure mode
> which achieves authentication and encryption. The server selection feature
> and configuration process are all different. And I think it is not
> necessary
> to reflect the character of secure DHCPv6 mode in rfc3315bis. Looking
> forward
> to your further guidance.

This basically seems to be what "one might argue" in my original
comment, so, obviously, I personally disagree on that rationale.  But
I wouldn't be surprised if the wg reaches to a different consensus
than my personal opinion, so I suggest you start a separate discussion
on this to form the consensus.

--
JINMEI, Tatuya