RE: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind

Since it looks like this draft will need a revision, might we also want
to address the following issues?

1. When should a Client send a Reconfigure Accept (and the server
respond with Reconfigure Accept). RFC 3315 only mentions this for the
Solicit/Advertise and Request/Reply exchanges. Not for a Renew or
Rebind.

Should this be prohibited on a Renew/Rebind? Is it optional? If allowed,
what should a client do if the client previously received a Reconfigure
Accept (Request/Reply) but fails to in the Renew/Reply or Rebind/Reply
exchange? Should it disable Reconfigure support?

Note: Keeping the number of times that the Reconfigure Key is sent (in
the Auth option) to a minimum is a benefit since it makes it more
difficult for rogue clients to discover the key (possibly by snooping
traffic).

2. The text in RFC 3315 isn't clear about when the server sends a
Reconfigure Accept? In 18.2.1 (Receipt of Request Messages) in RFC 3315,
is written:

    The server includes a Reconfigure Accept option if the server wants
    to require that the client accept Reconfigure messages.

Does this apply even if the client has not sent a Reconfigure Accept
option in the Request message? That seems likely to be useless since the
client probably won't accept Reconfigure Accept (since if it did, it
would have sent the option in the Request).

In a brief private exchange with Ralph, he thought that a qualifying
clause is needed:

    The server includes a Reconfigure Accept option if the server wants
    to require that the client accept Reconfigure messages, if the
client
    sent a Reconfigure Accept option in the Request.

- Bernie

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg