Skip to main content

Handling Unknown DHCPv6 Messages
RFC 7283

Yes

(Barry Leiba)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Kathleen Moriarty)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)

Abstain


Recuse

(Ted Lemon)

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

(Barry Leiba; former steering group member) Yes

Yes (for -06)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -06)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Brian Haberman; former steering group member) (was Discuss, Yes) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2014-03-25 for -06)
The document needs a revision to address suggested changes being made in the discussion that followed Suresh Krishnan's Gen-ART review.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -06)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -06)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -07)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -07)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -05)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-03-22 for -06)
Two very nitty/minor comments. Feel free to ignore them.

Is it worth noting the potential for loops here? That'd need
a server to also re-tx a received message to a relay (who'd
send it back) or for the server to generate a new message
(or even better two new messages:-) in response to receiving
one from a relay. I doubt it'd happen so probably not worth
a mention unless there's some DHCP specific behaviour that
might trigger such a loop. (I know of none.)

In a similar vein, is there any DHCP mechanism where a relay
would send out the unknown message to two or more servers as
some form of load balancing?  If there were, then maybe it'd
be worth just sending unknown message types to one server
and not to all? If it went to all, and each server then
"occasionally" pinged the relay to see if had been updated
and each ping gets sent to all servers... Again probably not
worth a mention since I don't see it being a bad loop, so
just in case it rings a bell with you.

(Joel Jaeggli; former steering group member) (was Discuss) Abstain

Abstain (2014-03-26 for -07)
was 

.  Problem Statement

   When a relay agent receives a message, it decides to send the message
   either toward the server or toward the client.  However, RFC 3315
   does not explicitly describe how the relay agent can determine
   whether it should send a message toward the server or the client,
   although this is implied by the message definitions in RFC3315.

Imho this is untrue.

A relay agent receives two kinds of messages, messages it is configured to relay to a dhcpv6 server, e.g. because it is configured for a specific subnet, or because it is configured a relay for relays, replies or messages constructed with relay -replies contain the information necessary for them to be forwarded.

3315 section 20

The problem statement covers message routing however section 4. and later are not  in fact about message routing but rather about that handling of unknown message types which seems orthogonal to the problem statement. in fact it would seem better if the problem statement reflected the problem the draft is trying to address.

(Ted Lemon; former steering group member) Recuse

Recuse (for -05)