[dhcwg] whether/how to support Confirm with sedhcpv6

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

While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that
probably requires a discussion: whether/how to use sedhcpv6 for
Confirm.  To avoid distraction I'm raising it separately from the full
review I'm planning to submit later.

When a client might want to send a Confirm, it should be reasonably
possible that the client has moved and would be talking to a different
server.  In that case it doesn't make sense to encrypt the Confirm
message and encapsulate it in an Encryption-query message; the actual
server would silently discard it, and the client can't tell whether
it's because it has moved or the message is simply lost.  So I think
we need some special case handling here.  A couple of choices I can
think of are:
- say sedhcpv6 can't support Confirm (I don't like this option)
- have the client perform a separate information-request/reply
  exchange to see if the currently recognized server and its public
  key are still usable (if not, the client should basically not send
  the Confirm, following the sense of RFC7844).

(There may be other options.)

--
JINMEI, Tatuya