2.3.2 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 25-Jan-99

Chair(s):

Ralph Droms <droms@bucknell.edu>

Internet Area Director(s):

Jeffrey Burgan <burgan@corp.home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:dhcp-v4@bucknell.edu
To Subscribe: listserv@bucknell.edu
In Body: subscribe dhcp-v4 Your Name
Archive: Send email to listserv@bucknell.edu with HELP as the text.

Description of Working Group:

This working group will produce a protocol for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. Specific functions to be included in the protocol include:

o Automated allocation and recovery of IP addresses

o Automated configuration of all TCP/IP stack parameters, as described in the Host Requirements documents

o Interaction between DHCP and DNS dynamic update protocol (ddns)

o Automated configuration of other host parameters such as application layer services

o Inter-server communication for coordination of multiple servers

o Mechanisms for the authentication of clients and servers

A specification the Dynamic Host Configuration Protocol (DHCP) for IPv4 has been entered into the IETF standards track. As of 3/97, it has been accepted as a "Draft Standard". The working group is also developing a specification for DHCP for IPv6 (DHCPv6), which is currently available as an Internet Draft.

Goals and Milestones:

Done

  

Revise the DHCPv6 Internet-Draft for discussion at the Dallas IETF meeting.

Done

  

Submit the DHCP options specification to the IESG for consideration as a Draft Standard.

Done

  

Submit server-server protocol specification as an Internet-Draft.

Done

  

Submit FQDN, option 127 and option acceptence process documents to IESG for consideration as a Proposed Standard.

Done

  

Develop options for automated registration in DNS.

Done

  

Submit the DHCPv6 Protocol and options specification for WG Last Call.

Nov 97

  

Complete revisions to the DHCPv6 protocol specifications based on response to the IETF Last Call.

Dec 97

  

Submit the DHCPv6 protocol specifications to the IESG for consideration as a Proposed Standard.

Sep 98

  

Submit the DHCP Protocol specification to the IESG for consideration as an Internet Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1534

PS

Interoperation Between DHCP and BOOTP

RFC1542

PS

Clarifications and Extensions for the Bootstrap Protocol

RFC2132

DS

DHCP Options and BOOTP Vendor Extensions

RFC2131

DS

Dynamic Host Configuration Protocol

RFC2241

PS

DHCP Options for Novell Directory Services

RFC2242

PS

Netware/IP Domain Name and Information

RFC2485

PS

DHCP Option for The Open Group's User Authentication Protocol

RFC2489

  

Procedure for Defining New DHCP Options

Current Meeting Report

The DHC WG met twice in Minneapolis. The first meeting focused on DHCPv6 while the second meeting addressed several DHCPv4 issues. The minutes from both meetings are included here.

DHCPv6

Thanks to Kim Kinnear for compiling these minutes.

The purpose of this meeting was to review issues that had come up after the DHCPv6 specification went through WG last call.

Issues:

1. Use of exponential backoff in retransmission.

Done. See section 8 REPLY_MSG_TIMEOUT.

2. Use of "S", "LS", and "D" bits for "relayed packet" to distinguish the cases where a transaction went through a relay agent vs. direct communication. Suggestion from Thomas Narten (IBM) to replace the various bits with a single "R" bit that indicates when DHCP message has passed through a relay agent.

Thomas clarified his objection to the bits -- that it really wasn't their names he was objecting to, but rather that in different message types the way that you determine that they went through a relay agent.

Jim Bound (Compaq) said that much of the discussion was on the list, and got little to no comment.

WG consensus: leave unchanged

3. Should the source port be fixed or arbitrary.

WG consensus: allow arbitrary source ports

4. Numbering of status/error codes.

Authors left the status and error codes as is to permit grouping, said Charlie Perkins (IBM).

Mike Carney (Sun) suggested that the authors change the spec to make clear why they have the grouping they have, since there is some method behind the grouping.

WG consensus: Leave numbering unchanged, with clarifying text.

5. Uniqueness of link-local address and applicability as key value for client identification.

Fixed. See sections 4.1, 5.1, 5.2, and 6.0. Changed specification to use link local address and routing prefix as a pair for client identification.

Jim Bound wants to add routing -prefix to the advertisement so that the client can be sure to be sure to understand what its routing prefix was.

The server's "key" should be the link-local address and the routing prefix, period. This will require adding a new 7 bit field to the advertisement, but there are bits to do it.

Jim said that the reason that it is up to the client to know the prefix so that the server doesn't have to figure out the prefix for each client (which it could, but it requires additional implementation that isn't really required).

Jim further suggested that this was better long term, since the address type might change, and this would be more flexible.

6. Eliminate range of delay for initial Solicit message from client

The authors left the delay in, so that the protocol would scale. Mike Carney brought up that the exponential backoff should have a maximum time for backoff -- a maximum delay for solicitation.

There was considerable discussion about what happens if the client can't find a DHCPv6 server if told to do so by the router. If it can't find a server, then the client SHOULD be able to continue on. But it should keep trying with a maximum delay between solicitations.

Jim asked if the DHCPv6 client is in "wait" mode, with stateless up and a DHCPv6 client running trying to find a server, should the user know? WG consensus was yes.

Thomas Narten suggested that we should specify how long and how hard a client should try before it "gives up" and goes on without using DHCPv6. Certainly one solicit isn't enough, says Thomas.

Ralph Droms (Bucknell University) summarized WG consensus:

1. Add text to draft to specify minimum number of tries before "giving up and going on".
2. Change minimum dither delay to 0
3. Add text to draft to specify maximum exponential backoff.

7. A clarification: A RELEASE message MUST go to the original server from which it came from.

What happens if we extend the protocol, and should we change the MUST to a SHOULD "send it to a different server" to take into account possible protocol changes in the future. WG consensus was that we should leave it as a MUST, and if we extend the protocol in the future, we'll extend the protocol to make this a SHOULD.

Thomas Narten suggested that some extensions are defined to be released to the original server, and some do not. And yet the overall spec says that they all MUST be released to the original server. Jim clarified that there is only one extension that must be released now -- the IP address. Charlie said "Lets just take away this global text about sending all extension releases to the same server".

Ralph Droms suggested said that we might want a bit somehow to indicate that an extension is releasable, that such information is even more important for a client to know than the type. A client can handle not knowing the type, but it cannot handle getting an extension that is releasable and not knowing that.

Mike Carney pointed out that a client that didn't request it wouldn't get an extension that was releasable, so it should know it is releasable if it requests it. Ralph suggested problems might occur if a client got a releasable extension and didn't understand the semantics, then it would never get released.

The WG identified three choices:

1. Identify releasable extensions in the extension or with a partition of the type space.
2. Prevent a server from sending releasable extensions to a client that a client didn't ask for.
3. Require a client to release all unknown extensions whenever they are received they didn't ask for.

WG came to consensus on choice #2 except for IP addresses.

As an aside, Mike Carney asked "How does a DHCPv6 client do the equivalent of an INFORM without getting an IP address in the bargain"? Charlie replied that it was up to the server.

As a corollary to the consensus on choice #2 above, must a client ask for *all* releasable extensions? If yes, it will need to ask for IP addresses. Thomas Narten asked if the client will need to know many addresses it needs? If yes, this is a problem, because the client can't know for sure just how many IP addresses it needs. For example, a client won't need to know how many addresses to ask for if the server is handing out extra addresses during renumbering.

WG consensus:

Note that this allows a client to do an INFORM kind of request where they don't get any IP address.

8. Should the Reconfigure message carry information, or just be a trigger to cause the client to do a request and the reply will contain the information?

WG consensus is to include both mechanisms, as first semantics allows for multicast of common parameters without Request from each client, which improves scaling behavior.

We spent considerable time discussing how to distinguish the request that comes back as an ack from the request that comes requiring a reply from the server. The discussion also uncovered a subtle difference between the two styles of Reconfigure - with the 'N' bit set, the response from the client confirms that the client has received its new configuration parameters. When the 'N' bit is not set, the server does not receive an explicit acknowledgment that the client received the response to its Request.

The WG expressed a preference for a new message to acknowledge Reconfigure messages.

9. Does the client copy the transaction ID from the reconfigure message or choose a new transaction ID for its response to the server.

Thomas Narten explained that this is a reliable multicast issue here. If the Reconfigure message is sent to all clients and the server retransmits with a short delay, the server will receive many acks or requests.

Bottom line: Server can't use just multicast; can use multicast initially and then follow up with unicast.

The meeting ran out of time, with some issues not yet covered.

DHCPv4

Thanks to Kim Kinnear for compiling these minutes.

DHCP-DNS -- Mark Stapp (Cisco)

Mark will submit a new draft that will include a new section 3.4 for handling name collisions:

- DHCP servers and clients should be able to detect and resolve host name collisions.
- Use a "KEY" RR to associate client with a DNS name.
- Method describes use of "KEY" RR in prerequisites.

Open issues: Is this an adequate solution? Is use of KEY RR correct?

Olafur Gudmundsson (TIS) suggested that we might need to define some unique protocol id when we get to using public keys in the KEY record. Mark pointed out that Stuart Kwan (Microsoft) has suggested putting some sort of ACL information in the record as well, but that Mark hasn't moved forward on that.

DHCP Authentication Status -- Bill Arbaugh (University of Pennsylvania)

Bill discussed open issues with the current draft:

1. Over specified key usage.

Will be taken care of by changing SHOULD's to MUST's.

2. PKI Usage.

Olafur volunteered to give some examples. He will do so. Examples demonstrating the use of shared secret HMAC are already in the draft. Kerberos could use this too according to Ted Lemon (ISC).

3. Securing relay agent interaction.

This will be easy to fix by examining a few fields and will be addressed in the next draft.

4. Global replay protection.

Adequate protection can be obtained by moving some fields up to the front of the packet and will be addressed in the next draft.

5. Client-id -- how to identify the client.

This is a more difficult problem. Mike Henry's (Intel) UUID (option 61) could solve the problem if made mandatory in DISCOVER's when requesting authentication.

GUID (Leach/Salz draft) has expired, but there is an open group standard that Mike referenced.

6. Kiosk Problem

The "kiosk problem" arises when a previously unregistered computer tries to use DHCP authentication in a network where it doesn't know what key to use. Solving the kiosk problem is not practical without changes to the protocol state machine. The WG concluded that the kiosk problem is not easy to solve at the interim authentication meeting in Redmond last year. Trying to do this without livelock or deadlock is hard.

The kiosk problem is solvable outside of the protocol if there is a truly unique global UID, because client can register out of band ahead of time.

Another possibility would be to leverage EAP if we changed the protocol to send ACK/NAK after DISCOVERs (for instance).

If solving the kiosk problem requires changes to the DHCP protocol, then the problem won't be solved soon. WG came to consensus not to support a solution to the kiosk problem and not to change the DHCP protocol.

7. EAP (authentication used in PPP).

(See above for reference to EAP authentication)

New issues in DHCP Authentication:

* Mark Stapp asked "What about RELEASE, INFORM, etc? These messages don't seem to be mentioned in the draft". Bill said that he would add text to specify authenticated RELEASE and INFORM in the next draft.

* Someone asked "What is the basic idea behind the "key-id""? Bill answered that this was put in before some other part of the protocol was designed. There may not be a 1-1 mapping from keys to clients. This allows multiple clients to share keys -- which some people think is a bad thing, but the real answer is that it is useful sometimes and not useful sometimes. The secret-id field is type dependent, and exists only for the HMAC today.

When a client sends a request, the client gets back a key-id from the server, and then the client knows what key to send to the server. Bill said that he would clarify that in the next draft.

Bill said that he would update the draft in the next month, send it to the list, and allow the list to respond. Bill doesn't see any further outstanding issues. The draft will go to WG last call after Bill completes the next revision of the draft.

DHCP Schema Meeting Report -- Bernie Volz (Process Software)

Bernie listed the attendees. Andy Bennett will update the draft and send it out to the attendee list.

A couple of issues:

1. Is this the right group to develop a DHCP schema? The people at the schema meeting felt that keeping this in the DHC WG group was a good idea. Bernie Volz and Ralph Droms (Bucknell University) will talk offline about how to extend the DHC group charter to include the DHCP schema.

2. Andrea from Microsoft helped bring the CIM model and the network working group inside of the DMTF into perspective for the DHCP Schema task force.

3. There was significant discussion about whether or not to store leases in the schema. WG expressed consensus to do so, because they are sometimes used for other tools. Decision was to allow but not require this update, and certainly not to require it to be used as an authoritative store.

The group working on the DHCP LDAP schema has made good progress; there is lots of work left to do.

DHCP Failover Meeting Report -- Kim Kinnear (Cisco)

There was an interim meeting on the failover protocol February 10th and 11, 1999. The minutes from the meeting were distributed on the dhcp-serve@bucknell.edu mailing list and are available at http://www.dhcp.org. There will be a new draft published to accommodate the changes resulting from the interim meeting work.

Summary of changes discussed at interim meeting:

Suggestions:

1. Try for dynamic load balancing.

2. Bernie Volz asked "What about when we have TCP and UDP w/different transmission speeds -- and we send state in the messages.". Kim Kinnear responded that we should just not put state in the TCP messages.

3. Servers should not assume that clients only send INIT-REBOOTs when they have time remaining on their lease. The DHCP RFC must be edited to clarify that a client MUST NOT send an INIT-REBOOT to a server unless it believes that it has time left to run on its lease for the IP address.

Ralph Droms (Bucknell University) noted as an aside that the DHCP RFC 2131 could go to the next step of the standards process anytime someone volunteered to edit in the considerable number of changes that Ralph has collected since the last publication.

Subnet Selection Option Status -- Glenn Waters (Nortel)

This option allows the for a DHCP proxy service, especially in cases where the DHCP server cannot route at all to a network for which it is supplying IP addresses.

Mark Stapp asked why not do an option to change to whom to send the packet and use giaddr to select the subnet. This entirely equivalent to the proposed option, but might generalize differently.

Kim Kinnear pointed out that giaddr is used for two different things today, to select the subnet and to decide to whom to send the reply packet. Glenn's approach is to use a separate option to override the subnet selection aspect of the giaddr, but leave the "to whom to send the reply" part of it the same. One could, as Mark suggests, use an option to alter the "to whom to send the reply" part of the giaddr instead. The consensus of the group was to leave it way it was.

Glenn said that he would update the draft to make it not "subnet specific" but network segment specific.

Relay Agent Options Report from IESG -- Harald Alvestrand

IESG sent the relay agent options draft back to the working group. Harald spoke to the WG to discuss the objections that came up at IESG.

Having read the scenario at the beginning of the relay agent options draft, Harald has some global concerns with the scenario described (not with the specifics of the relay agent options themselves). His two primary concerns are:

Harald will accept the relay-agent-options draft if it discusses the above problems that can occur when using the scenario outlined in the draft. Hopefully the draft will do more than warn people about these problems, and will also suggest some solutions. He would be satisfied with two sentences, but really would prefer two paragraphs.

Kim suggested that there are solutions to at least some of these problems in the DOCSIS documents. Kim Kinnear volunteered to inform Mike Patrick of Motorola about these issues and let him know what he needs to do to move the draft forward.

DHCP Options For Host System Characteristics -- Mike Henry (Intel)

The DHCP Options for Host System Characteristics draft , draft-dittert-host-sys-char-03.txt, has been revised. Options 93, 94 and 97 will be replaced with options 60 and 61, with a six year grace period for the transition. The document will go to WG last call and publication as an informational RFC.

Connectathon Report -- Mike Carney

Lots of people went. Two issues came up around the draft:

1. How is parameter request list used? Must it be the same each time? Mike is suggesting that it not be required, and that servers move more and more into sending only what clients ask for.

2. Issues around asking for very long addresses. Some clients always ask for a permanent address just to see if they can get one, and expect the server to limit them. This caused problems for some server limitations, and Mike noted that people may want to test this sometimes.

Mike suggested ways to convince vendors to participate in Connectathon, since the more servers and clients that participate the better the whole event works for all concerned. He suggested that Ralph put up some information (like who attended) on the dhcp.org web site. He also suggested that we might try to get some cable modem clients to Connectathon next year.

Slides

None received.