Subject: [Dhcpv6bis] ticket #91

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jan 2015 09:21:39 -0500

re: http://tools.ietf.org/group/dhcpv6bis/ticket/91
   > However, it is not clear from the RFC what the server should do if
   > the client breaks this rule.

My conclusion is that the server fails to authenticate the message, and the
message is discarded, and that's really the end of it.  I think that we
already said this.

The server decides on the keyIDs to use in the protocol.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Jan 2015 09:56:30 -0800

At Wed, 07 Jan 2015 09:21:39 -0500,

> The server decides on the keyIDs to use in the protocol.

I already forgot exactly what I intended 8.5 years ago, but on my
fresh reading of Section 7 of
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01
I guess this is mainly about clarifying the meaning of "the server
does not know the key identified by the 'key ID' field".  Maybe I
thought this could read as if the server is considered to "know the
key" if the specified ID is currently being used by some other
client.  And, hence the suggested clarification text that follows.

If you guys think this is too obvious from the current text, that's
fine.  If you think the suggested text catches the original intent and
(if slightly) is clearer than the original text, feel free to use it.

--
JINMEI, Tatuya