Skip to main content

DHCP Server Identifier Override Suboption
RFC 5107


(Jari Arkko)
(Margaret Cullen)

No Objection

(Bill Fenner)
(David Ward)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Scott Hollenbeck)


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

Jari Arkko Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

Margaret Cullen Former IESG member
Yes () Unknown

Bill Fenner Former IESG member
No Objection
No Objection () Unknown

Brian Carpenter Former IESG member
No Objection
No Objection (2006-02-27) Unknown
John Loghney's Gen-ART review comments:

1) Intro says:

   There are many situations where the DHCP relay is involved and can
   insert a relay agent option with appropriate suboptions easily into
   DHCP DISCOVER messages.  

Of course, this begs the question - what are those situations?  Anyhow,
I think the intro is a bit short on motivation for this suboption.

[BC. Agreed, but not enough to hold the document.]

2) IANA Section says:

5.  IANA Considerations

   IANA is requested to assign a suboption number for the Server
   Identifier Override Suboption from the DHCP Relay Agent Information
   Option [3] suboption number space.  None.

I don't understand what the 'None.' refers to.

[BC. Indeed. I presume it should be deleted]
Dan Romascanu Former IESG member
No Objection
No Objection (2007-07-03) Unknown
None of the issues raised in Bert Wijnen's DISCUSS on 2/28/2006 relative to version 03 seems to be addressed in version 04.
David Ward Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Jon Peterson Former IESG member
No Objection
No Objection () Unknown

Lisa Dusseault Former IESG member
No Objection
No Objection (2007-07-03) Unknown
The latest draft seems to address Ted's concern years back about how the situation is handled when the DHCP server doesn't understand the option sent.  I think it also now handles Ted's security concerns but I don't know enough about DHCP security to be certain.  

FYI, the IANA Considerations section ends with "None." as a complete sentence which seems like a bug.  

Re: the sentence "In a situation where the DHCP Relay is configured to forward packets to more than one server, the DHCP Relay should forward all DHCP packets all servers":  Missing 'to', and should SHOULD be SHOULD.
Magnus Westerlund Former IESG member
(was Abstain) No Objection
No Objection (2007-07-02) Unknown

Mark Townsley Former IESG member
No Objection
No Objection () Unknown

Ron Bonica Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Ross Callon Former IESG member
No Objection
No Objection () Unknown

Russ Housley Former IESG member
No Objection
No Objection () Unknown

Sam Hartman Former IESG member
(was Abstain, No Objection) No Objection
No Objection (2006-03-02) Unknown
I'm abstaining because Allison's comments made it clear that I don't
understand DHCP well enough to evaluate the issues and to say there
are no problems with this document.  If requested to do so I can come
up to speed on DHCP enough to either vote yes or to maintain an
abstain on this document.
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2007-07-02) Unknown
From Steve Hanna's SecDir review:

On the last line of page 5, I think the phrase "all DHCP packets
all servers" should be "all DHCP packets to all servers".

The document should reference essential docs earlier, no later
than section 3. For example, RFC 3046 is not actually referenced
at all, although clearly section 5 intends to do so.

This document should reference DHCPv6, since it is referred to.

The references should be divided into normative and informative.

The reference in section 5 should be to [6] not [3].
Allison Mankin Former IESG member
Abstain (2006-03-02) Unknown
The claim is made that this brings DHCPv4 in line with DHCPv6:
   In short, this new suboption allows the DHCPv4 relay to function in
   the same fashion as the DHCPv6 relay currently does.

I sent email to the IESG list about my abstention, forwarding a pretty
devastating comment on this draft, which had no followup that I could find:

I think the WG didn't do much about this document.
Issues about its problematic impact were raised by the
by the WG folks as well.

Nov.  It didn't go onto the Vancouver agenda.  AD's what was
up with the discussion of this document?

I can't find any WGLC discussion, but my personal archive may
not be complete.

IMO, IESG be generally supportive of duly chartered work and WG consenses.

But DHC auto-charters.  There is never review for the architectural
foundations of the new documents and extensions that they take up.
And if the WG consensus of a document is not great when
it comes to the IESG...we get here.

I don't want to leave a Discuss behind me.  What I'd propose  
for action items would be:

 - New review of the concerns by discussants in the working
   group; were they addressed? do they* think the document needs
   a revision before returning to the IESG?  In other words,
   a return to WGLC 
 - A re-charter of DHC should look at the way extensions grow, 
   particularly how new work is adopted.


------- Forwarded Message

Date:    Wed, 09 Nov 2005 00:22:31 +0000
From:    "David W. Hankins" <>
Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-03.txt

Since this isn't on the agenda this week, I wanted to comment on this
again before I forget.

[you can find the rest in the archive]
Bert Wijnen Former IESG member
(was Discuss) Abstain
Abstain (2006-03-02) Unknown
Section 6 seems not inline with the IPR words we require these days.
It is in fact redundant give the IPR text on page 10.

References are not split in normative and informative.

Sect 5. Last word "none" probably should be removed?
Chris Newman Former IESG member
Abstain (2007-07-19) Unknown
I am carrying forward Ted's abstain vote.  I have reviewed the document
in depth, including the changes between -03 and -04 and do not believe
a serious effort was made to address Ted's legitimate concerns.  Indeed
between -03 and -04 it appears only 4 paragraphs were added all largely
unrelated to Ted's concerns.

To elaborate on Ted's concerns in my own words, this is a profound
model change to the security of DHCP.  The relay agent gains the
ability to intercept all DHCP traffic even if network topology might
not otherwise permit that.  The server MUST include the relay agent's
server identifier instead of its own regardless of the security
consequences of doing so.  And the client loses the ability to
identify the server that is actually processing the request.

Such a profound change should be motivated and the consequences
discussed in more detail.  The document would also be improved by
discussing the additional logging/diagnostic requirements this
introduces above those of a previous DHCP relay agent deployment.
Cullen Jennings Former IESG member
Abstain (2006-05-27) Unknown
This document was reviewed by Allison and I am simply  taking over her position with little to no review. Mostly I have tried not to force documents though multiple reviews since each review only seem to uncover more problems. If you think I would come to a significantly different position than Allison and it turns out that my position is relevant to the disposition of this document, feel free to request that I review this.
David Kessens Former IESG member
Abstain (2006-03-01) Unknown
I will abstain from this document for the following reason:

This option makes this relay-server interaction again more complicated,
while the motivation why we need this option is poorly documented (see Brian's comments).

I wonder whether it is in the interest of the DHCP users and operators that this protocol becomes more and more complicated while the perceived benefits are
unclear as they are insufficiently documented and motivated.

Is this feature in the interest of vendors to make it harder for competitors to
design fully standards compliant DHCP servers and relays ? Is there a real
need among operators to make their DHCP deployments even more complicated and
thus more prone to misconfiguration or security issues ?
Ted Hardie Former IESG member
Abstain (2006-02-27) Unknown
I've chosen to abstain on this.  There are two basic reasons.  I believe this makes a fundamental change to the DHCPv4 security model with respect to relay agents, and I think the draft neither motivates this sufficiently nor handles the new role behavior particularly well.  I also believe the case where the relay agent sends this and it is not understood by the server is handled poorly, as it amounts to "make sure it doesn't happen."