Skip to main content

Rebind Capability in DHCPv6 Reconfigure Messages
RFC 6644

Yes

(Barry Leiba)
(Brian Haberman)
(Jari Arkko)

No Objection

(Benoît Claise)
(Gonzalo Camarillo)
(Pete Resnick)
(Ron Bonica)
(Wesley Eddy)

Recuse

(Ralph Droms)

Note: This ballot was opened for revision 09 and is now closed.

(Barry Leiba; former steering group member) Yes

Yes (for -09)

                            

(Brian Haberman; former steering group member) Yes

Yes (for -09)

                            

(Jari Arkko; former steering group member) Yes

Yes (for -09)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-04-08 for -09)
I have no objection to the publication of this document, but I
have a few comments that either reperesent my failure to grasp what
you are doing, or would make useful improvements to the document.

---

I would prefer that Section 3 did not include the format of the 
Reconfigure Message option. Rather than "update" the option with a
full replacement, isn't it enough to say that msg-type may now 
additionally take the value 6 to indicate Rebind?

---

Section 4

   The server MUST include a Reconfigure Message option (as defined in
   Section 3) to select whether the client responds with a Renew
   message, a Rebind message or an Information-Request message.

Include in what?

---

Section 4 is headed "Server Behavior"

   The Reconfigure message causes the client to initiate a Renew/Reply,
   a Rebind/Reply message exchange or an Information-request/Reply
   message exchange.  

Seems to be describing the client behavior. At least give a forward 
pointer to Section 5.
   
---   

Section 4

                      The server interprets the receipt of a Renew, a
   Rebind or an Information-request message (whichever was specified in
   the original Reconfigure message) from the client as satisfying the
   Reconfigure message request.

Presumably, only if threceived message matches the msg-tpe in the 
Reconfigure Message option? What if there is a mismatch? can the 
mismatch be caused by a race?

---

Section 5

How is a legacy client going to handle a Reconfigure Message option 
with msg-type set to Rebind? Presumably it is going to run some 3315
logic to drop or nack the message as "msg-type unknown, unexpected,
or unsupported".

I believe you should mention this as it impacts on server behavior.

(Benoît Claise; former steering group member) No Objection

No Objection (for -09)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -09)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -09)

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2012-04-11 for -09)
The introduction motivates some of these changes with a use case of a network administrator who is preparing to shut down a dhcpv6 server causing clients to move to a different server. Is it possible (if so, how easy would it be) to misconfigure the servers involved to cause them to enter a rebind war with each other? If this is something a client might experience, is there guidance to give the client implementations on how to react when it happens?

(Ron Bonica; former steering group member) No Objection

No Objection (for -09)

                            

(Russ Housley; former steering group member) No Objection

No Objection (2012-04-11 for -09)
  Please consider the editorial suggestions in the Gen-ART Review by
  Francis Dupont on 7-Apr-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07344.html

(Sean Turner; former steering group member) No Objection

No Objection (2012-04-10 for -09)
1) I support Stephen's discuss.

2) s4: I was having some issues tracking exactly which paragraphs in 19.1-19.3 were being updated/replaced.   Could you do the old/new so we knew which paragraphs were being replaced.  Ex (assuming I got this bit right):

4.1 Updates to Section 19.1

OLD:

 A server sends a Reconfigure message to cause a client to initiate
 immediately a Renew/Reply or Information-request/Reply message
 exchange with the server.

NEW:

 The server MUST include a Reconfigure Message option (as defined in
 Section 3) to select whether the client responds with a Renew
 message, a Rebind message or an Information-Request message.

3) s5: If the text replaces the text in s19.4 of RFC 3315 could you just say that? r/This section updates specific text in/This section replaces

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2012-04-19)
- 1st sentence of abstract seems odd, v. hard to read anyway and that's
not so good usually. How does the "Reconfigure Message" extend "the
Reconfigure Message"? (That's how I read it anyway)

(Wesley Eddy; former steering group member) No Objection

No Objection (for -09)

                            

(Ralph Droms; former steering group member) Recuse

Recuse (for -09)