NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Ralph Droms <rdroms@cisco.com>
Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Thomas Narten <narten@raleigh.ibm.com>
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.
Other Lists:
A separate mailing list is used for discussing the IPv6 version of dhcp: dhcp-v6@bucknell.edu.
This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard" (RFC2131, RFC2132). The working group now has four main objectives:
* Revise and submit the DHCP specification for acceptance as a Full Standard
* Develop a roadmap for the review and acceptance of new options, define a new option syntax, develop an accurate list of assigned option codes and identify option codes that can be safely reassigned
* Develop a specification for DHCP for IPv6
* Develop an inter-server communication for coordination of multiple servers
* Review new options for DHCP, as deemed appropriate by the working group chair and/or the Internet area directors; specific options currently under review in the working group include:
o Mechanisms for the authentication of clients and servers
o Interaction between DHCP and DNS dynamic update protocol
o Definition of a DHCP MIB for management of DHCP servers through SNMP
o Definition of an LDAP schema to provide a standardized format for the storage and retrieval of DHCP information, primarily configuration and lease data; this schema will be developed in coordination with the Policy Frameworks Working Group as appropriate.
o Options through which DHCP relay agents can pass information to DHCP servers
o Other options: user class, server selection, domain search
Jun 99 |
|
Submit Internet-Draft on subnet selection option in time for Oslo IETF |
Jun 99 |
|
Submit Internet-Draft on DAP schema for DHCP in time for Oslo IETF |
Jun 99 |
|
Submit Internet-Draft on DHCP authentication in time for Oslo IETF |
Jun 99 |
|
Submit Internet-Draft on failover protocol in time for Oslo IETF |
Jun 99 |
|
Submit Internet-Draft on relay agent options in time for Oslo IETF |
Jun 99 |
|
Submit Internet-Draft on DHCP-DNS interaction in time for Oslo IETF |
Jul 99 |
|
Submit Internet-Draft on DHCP authentication for WG last call |
Jul 99 |
|
Develop plan for review of DHCP specification and acceptance as Internet Standard. |
Sep 99 |
|
Submit DHCP server MIB specification for WG last call |
Sep 99 |
|
Submit subnet selection option specification for WG Last Call |
Nov 99 |
|
Submit DHCP server MIB specification for IESG consideration as a Proposed Standard |
Nov 99 |
|
Submit LDAP schema specification for WG last call |
Mar 00 |
|
Submit LDAP schema specification to IESG for consideration as a Proposed Standard. |
· Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
· Dynamic Host Configuration Protocol (DHCP) Server MIB
· The Classless Static Route Option for DHCP
· DHCP Option for PacketCable VoIP Client Configuration
· Resolution of DNS Name Conflicts Among DHCP Clients
· Addition of Device Class to Agent Options
· Triggering AAA from DHCP Relay Agents
· Extensions to DHCP for Roaming Users
· Subnet Selection sub-option for the Relay Agent Information Option
· VPN Identifier sub-option for the Relay Agent Information Option
RFC |
Status |
Title |
RFC1534 |
DS |
Interoperation Between DHCP and BOOTP |
RFC1542 |
DS |
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 |
RFC2563 |
PS |
DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients |
RFC2610 |
PS |
DHCP Options for Service Location Protocol |
RFC2939 |
Procedure for Defining New DHCP Options and Message Types | |
RFC2937 |
PS |
The Name Service Search Option for DHCP |
RFC3004 |
PS |
The User Class Option for DHCP |
RFC3011 |
PS |
The Subnet Selection Option for DHCP |
RFC3046 |
PS |
DHCP Relay Agent Information Option |
RFC3074 |
PS |
DHC load balancing algorithm |
RFC3118 |
PS |
Authentication for DHCP Messages |
DHC - Wednesday, 3:30PM
=======================
Thanks to Stuart Cheshire for taking the notes on which this summary is based.
Ralph gave a summary of WG status and activities:
* The DHCP Reconfigure Extension has been reviewed by IESG; it was subsequently revised and resubmitted by the authors. The draft is now waiting IESG re-review.
* Ralph asked if there are any existing or planned implementations of DHCP Reconfigure. None are existing. One person said they had a planned implementation.
* Several drafts are ready for WG Last Call:
-* Encoding Long DHCP Options
-* The Classless Static Route Option for DHCP
-* DHCP Domain Search Option
-* The DHCP Client FQDN Option
-* Resolution of DNS Name Conflicts Among DHCP Clients
-* Subnet Selection sub-option for the Relay Agent Information Option
-* Addition of Device Class to Agent Options
* Ralph will initiate WG last call for these drafts after IETF-51.
* Ralph asked for someone to volunteer to write a document listing all known DHCP vendor options. Barr Hibbs volunteered.
Failover Protocol, Mark Stapp
(draft-ietf-dhc-failover-09.txt)
------------------------------------
Mark asked whether draft is ready for last-call. The hum from WG indicated the WG thinks it is. Ralph will initiate a WG last call after IETF-51.
802.1X WEP Key Management using DHCP, Bill Arbaugh
(draft-ietf-dhc-key-management-00.txt)
--------------------------------------------------
Bill's draft proposed doing key management via a DHCP option. Every time client renews its lease it gets a new WEP key. This could allow the WEP key to be changed fairly frequently - e.g. every five minutes.
Stuart Cheshire asked if this functions duplicates 802.1X functionality? Answer: Yes, but 802.1X is not widespread yet, and we want this now. However, it's not clear how long this will take to get deployed. For example, the Mac OS 9 DHCP client would need to be updated to request this new option, and no new updates are planned forOS 9 now that all Apple's efforts are focused on OS X. In contrast, an 802.1X client can be implemented by any third-party without any special support from the OS, so it is likely that 802.1X could be implemented far quicker than this DHCP extension.
Mark Stapp thought the draft was worth pursuing.
Erik Nordmark expressed concern that pursuing this option confuses users by providing two ways to do key management, and ultimately slows adoption of either. It is better to focus efforts on deploying 802.1X.
Show of hands for who would like work to continue on this draft: Only Ralph raised his hand.
DHCP mDNS Enable Option, Erik Guttman
(draft-guttman-dhc-mdns-enable-01.txt)
--------------------------------------
Erik presented a summary of client mDNS default behavior and the function of a proposed option to enable the use of mDNS.
Stuart Cheshire pointed out that the proposed default behavior, if the DHCP server does not support this option, is that Multicast DNS should not be used. This basically means that today, Multicast DNS will not be allowed to work on any network where DHCP servers are present, which in turn means that there is no incentive for anyone to implement Multicast DNS.
Resolution - zeroconf WG will cotinue work on this option; dhc WG will review any option on standards track
LDAP Schema for DHCP, Vijay Nanjundaswamy
(draft-ietf-dhc-ldap-schema-00.txt)
-----------------------------------
Vijay K. N. spoke about the latest LDAP schema definition. Mark Stapp noted that including lease information has huge performance implications. Ted Lemon gave the opinion that if the schema can be defined to accommodate the DHCP server data and work at some scale, then the schema is valid and the performance problem should be tackled separately.
The schema recommends isolating leases in a container object to improve manageability. There is a server-specific extension that holds information that is only relevant to one particular implementation server. Mark Stapp asked if the authors had surveyed DHCP implementations to see if there is enough common configuration or operational information to make an interesting schema. Erik Guttman notes that the DMTF stays away details like this schema for individual services. Vijay identified an action item to survey existing servers to determine common functions.
Ted Lemon pointed out that claiming improved reliability through the use of and LDAP store just moves the single point of failure from the DHCP server to the LDAP server.
Mark Stapp asked if there is enough commonality between the configuration options and features of different DHCP Servers for a common LDAP schema to be useful? Authors responded that they will do a summary of existing servers to determine applicability of a common LDPA schema.
Erik Guttman asked who actually wants this?
Ted Lemon suggested that the authors should try implementing it first before talking about publishing it as an RFC.
The authors have received comments from the WG and modified the draft according to those comments (where appropriate). The authors have also made some other changes independent of WG feedback.
VPN Identifier sub-option for the Relay Agent Information Option, DHCP VPN Information option Mark Stapp
-----------------------------------------------------------------
These drafts carry similar information through a DHCP option and a relay agent sub-option. The drafts give two encodings for VPN identifier: vrfs and RFC2685 vpn id. No response from WG.
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Jim Bound, Ralph Droms
(draft-ietf-dhc-dhcpv6-19.txt)
------------------------------------------------------
This draft is currently the highest numbered draft in the ID directory.
Ralph proposed to go through list of action items and try to establish where we have consensus.
Mark Stapp suggested the WG should discuss structure of IA option first, because it affects other discussion.
* Mark Stapp suggested a number of problems have arisen because of "C struct"-like structure of IA option. Mark suggests a solution like that used in failover: IP address marks a "frame", in which options specific to that address follow the IP address; IA option then marks start of a frame that carries options specific to the IA. Ted Lemon said that the current structure of the IA option is quite complicated. It would be good to simplify it. Ted suggested that, since we're under time pressure, we should establish a deadline, and if we don't have a new proposal by then, we just go with the old IA option.
WG consensus: Bernie, Mark and Ted will develop text defining new IA structure. The draft text will be complete and submitted to the WG for review by 8/24. WG will review and definition will be integrated into -20 draft if approved by WG.
* Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes?
WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message
* Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration)
WG consensus: yes; prefix advertisement is handled through ND
* Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses.
Open issue - hold for new IA definition (WG has already agreed that client can ask for regular or temporary addresses)
* Define separate IA option for temporary addresses rather than indicate the type of address in a single IA option
Open issue - hold for new IA definition
* How and when does the client use DAD on addresses in Advertise and Reply messages?
WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use)
* Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option
WG consensus: yes
* Should we consider a "quick" handshake for allowing a client to assign an address in a single exchange of two messages?
WG consensus: defer for later reconsideration
* Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default as T1/T2 are fields in IA header and must be supplied by server
WG consensus: Mark, Ted and Bernie will do it...
Open issue: what about selection of T1/T2 with temporary addresses and with addresses whose lifetimes won't be extended; e.g. addresses to be deprecated/discarded due to renumbering.
Notes: T1/T2 are independent of "regular"/"temporary" characteristic. T1/T2 might even be used for clients that do not have any assigned addresses for periodic renewal of other information
* The semantics of the use of IA must be clarified (see Volz message of 7/19). In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Request containing a new IA?
Open issue: rules about when to reuse old IA or use new IA
WG consensus: When the client submits an IA that the server has seen in the past, the server should interpret the request as a request for the current state of the existing IA. When the client submits an IA that the server has not seen before, the server should interpret the request as a request for additional addresses to be assigned to the new IA.
Discussion to continue on WG mailing list
* Simplify Release and Decline so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses.
WG consensus: Wait for Bernie to fix in IA definition
* Add "NAK" function:
If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message.
WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server.
* Define DUID to be one of:
- Link-layer address plus time
- Vendor-assigned unique ID
- Link-layer address
- IMSI
- IMEI
WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion
* Use IPsec for secure agent/server communication
WG consensus: yes; add text to draft
* Add an "error code" option, to indicate errors not connected with a specific option
WG consensus: yes; should allow inclusion of text message
* Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client.
WG consensus: yes
* Reply to a Confirm should be a simple ACK/NAK without changing any values in options
WG consensus: Discussion to be taken to mailing list
Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm
* Reply to Decline or Release should carry no options
WG consensus: yes
* Restrict options in Decline or Release to IA with text to allow other options in the future
WG consensus: no; this is an overspecification
* Server does not respond to Solicit when client wants addresses and server has no addresses
WG consensus: Server should be allowed to respond
* Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix
WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft.
* Add 'secs' field to fixed header
WG consensus: if client retransmits, MUST send option called "milliseconds"
* Make the preference field an option
WG consensus: yes
* Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec
WG consensus: yes
* Discard the client unicast or recheck the entire spec for consistency in reference to message transmission
WG consensus: yes, authors to fix spec
* Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent-)server message. Server responds to source from IP header (whether agent or client).
WG consensus: Yes
None received.