Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

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

At Thu, 1 Dec 2016 19:46:06 +0800,
Lishan Li <[e-mail]> wrote:

> > This didn't answer my question.  Could you first answer the question?
> > If there's no such restriction in the base protocol, we cannot assume
> > it and can't assume it in designing sedhcpv6.
> >
> [LS]: I just think that it is a default fact. Could you please give an
> example that the client communicates with two DHCPv6 servers
> for the address configuration in the same time?

I don't have an example; I already noted it would be unlikely in
practice.  My point is that unless the restriction is specified in the
protocol we can't design a new protocol implicitly assuming that
restriction.  Otherwise someone may deploy the service with violating
the assumption, and we cannot blame them as it's invalid.  We should
either:
1. design the protocol (=sedhcpv6) so it can work without the
  assumption, or
2. explicitly state it's a restriction that this protocol assumes

BTW, on thinking about the reconfigure case more, I realized that
including a key tag option for the client public key in the Encrypted
Reply is probably a bad idea, as it could be used for client-tracking.
So, in the end, option #2 above may be the least bad option anyway.
The assumed restriction wouldn't be that restrictive in practice, and
the client can still try all possible key pairs (if it uses multiple
pairs) in the rare corner cases.

--
JINMEI, Tatuya