Subject: [Dhcpv6bis] [dhcpv6bis] #154 (XML 3315): Meaningless 'reconfigure accept' option in reply messages?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 07 Jan 2016 19:24:38 -0000

#154: Meaningless 'reconfigure accept' option in reply messages?

 RFC3315 states in sections 17.2.2 (Creation and transmission of Advertise
 messages) and 17.2.3 (Creation and transmission of Reply messages):

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

 Does that make sense at all? Either the client supports reconfigure (and
 includes reconfigure accept in Solicit/Request) or it doesn't (then the
 server sending this option wouldn't change client's mind). Those sentences
 are still there in the current 3315bis text.

 In my opinion we should remove the capability of the server to include
 reconfigure accept option. If we want to keep it, we should clarify what
 the client is supposed to do, when it does not support reconfigure, but
 the server insists by sending this option. I have trouble coming up with
 any reasonable recommended text here. If the client doesn't support,
 there's nothing could be done and the option in server->client direction
 is useless. If the client is able to support reconfigure, but its support
 was somehow administratively disabled, the server can't really change
 client's mind.

 On a related note, I'd LOVE to see reconfigure being a mandatory feature.
 But I'm afraid it would be too much this time. Maybe we'll make that leap
 when secure-dhcpv6 is standardized.

-- 
----------------------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task                        |     Status:  new
 Priority:  P1 blocker                  |  Milestone:
Component:  XML 3315                    |   Keywords:
 Due Date:  31/03/2016                  |
----------------------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/154>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 7 Jan 2016 21:22:24 +0000

Tomek:

22.20 states:

   A client uses the Reconfigure Accept option to announce to the server
   whether the client is willing to accept Reconfigure messages, and a
   server uses this option to tell the client whether or not to accept
   Reconfigure messages.  The default behavior, in the absence of this
   option, means unwillingness to accept Reconfigure messages, or
   instruction not to accept Reconfigure messages, for the client and
   server messages, respectively.  ...

I'm not so sure that it is totally useless, as this allows:
- The client to request and the server to acknowledge the use
- The server to tell the client (in Advertise) that it should request a reconfigure key from the server.
- Also, the server could tell the client to stop accepting Reconfigure messages in a Renew (and later enable)?

Agreed that it might be overkill, but seems to be flexible enough and accommodates configuration changes on the server (i.e., to enable/disable reconfigure support on clients).

Though I it does look like our server doesn't do everything "expected" - we kind of use it as confirming to the client whether to support Reconfigure or not; but only if the client indicated its support. So, we'll only send a Reconfigure Accept if the client sent on it (and the server is configured to allow or require client reconfigure support).

> On a related note, I'd LOVE to see reconfigure being a mandatory feature.

It is already for CMs (and I think also for eRouter CPEs). But Tim can probably tell us from memory (I could look it up in the DOCSIS specs).

---

On the subject of the Reconfigure Accept support, it also wasn't completely clear whether this "negotiation" (include in Reply) should happen for Renew/Rebind (not just Solicit/Request). The text for the client including the Reconfigure Accept is only in the Solicit and Request sections - nothing about it in Renew/Rebind. Yet the Reply processing (17.2.3) has it in all cases.

Anyway, probably worth a future discussion (February team meeting?) ... we can certainly continue to discuss on ML too.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of dhcpv6bis issue tracker
Sent: Thursday, January 07, 2016 2:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Dhcpv6bis] [dhcpv6bis] #154 (XML 3315): Meaningless 'reconfigure accept' option in reply messages?

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

 Does that make sense at all? Either the client supports reconfigure (and  includes reconfigure accept in Solicit/Request) or it doesn't (then the  server sending this option wouldn't change client's mind). Those sentences  are still there in the current 3315bis text.

 In my opinion we should remove the capability of the server to include  reconfigure accept option. If we want to keep it, we should clarify what  the client is supposed to do, when it does not support reconfigure, but  the server insists by sending this option. I have trouble coming up with  any reasonable recommended text here. If the client doesn't support,  there's nothing could be done and the option in server->client direction  is useless. If the client is able to support reconfigure, but its support  was somehow administratively disabled, the server can't really change  client's mind.

 On a related note, I'd LOVE to see reconfigure being a mandatory feature.
 But I'm afraid it would be too much this time. Maybe we'll make that leap  when secure-dhcpv6 is standardized.

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis