(Back to dhcp.org home)
(Back to 7/00 meeting page)

Minutes from the DHC (Dynamic Host Configuration) working group meetings
in Pittsburgh, PA, DC.

Meeting Manager: Ralph Droms (WG Chair)

Minutes prepared by Richard Jones

Monday, Jul 31 at 1930-2200 (DHCPv4)
====================================

ANNOUNCEMENTS

Ralph officially announced that he has taken a position with
Cisco Systems in the Boston area. He has taken a one year leave
of absence from Bucknell University, but expects it to extend
beyond that time frame. He stated that acting as DHCP Working
Group Chair is now officially a part of his job, so expects to
devote more time to it.

ACTIVITIES

RFC 2855 (DHCP for IEEE 1394) is accepted by the IESG as a
Proposed Standard.

Drafts draft-ietf-dhc-nsso-05.txt  and
draft-ietf-dhc-authentication-14.txt have been submitted to the
IESG for considerations as Proposed Standards.

draft-ietf-dhc-new-opt-msg-02.txt is accepted by the IESG as a
Best Current Practice (BCP) document.

The following drafts have been returned, with comments, by the IESG
for further revision:
draft-ietf-dhc-subnet-option-06.txt
draft-ietf-dhc-userclass-09.txt

draft-ietf-dhc-pv4-reconfigure-01.txt will be revised based on
feedback from WG Last Call before being submitted to the IESG.

The DHCPv6 specification and the server-to-server drafts are
currently under construction.

DRAFT OPEN ISSUES

Draft: DHCP-DNS Interaction
Presenter: Mark Stapp

The original draft has been broken out into two drafts, based on
feedback from the Adelaide IETF meeting: the 'fqdn draft',
draft-ietf-dhc-fqdn-option-00.txt, and the 'resolution' draft,
draft-ietf-dhc-ddns-resolution-00.txt. The resolution draft
references a dnsext draft, draft-ietf-dnsext-dhcid-rr-00.txt,
which refreshes an expired draft.

It is expected that these drafts will undergo one or more revisions
before being ready for WG Last Call.

It was suggested that a bit flag be added to the fqdn option
format that allows a client to request that the server do no
DNS updating at all for this request. Current option flags only
specify that the client can request the server not update the
A RR. The consensus was that this is fine, but that the server
reserve the right to override the client request.

It was suggested that the DHCID Resource Record be encoded in
Base 64 rather than hexadecimal format. This was agreed upon, with
Andreas Gustoffson volunteering to provide existing 'boilerplate'
documentation for this provision.

The question of having the server update other RR's than the A and
PTR records was raised again. Also, the possible need for multiple
PTR records was raised. It was agreed that these need to be discussed
on the mailing list in greater detail.

The question of whether or not a client can send multiple fqdn
options in a request was raised. The prevailing opinion seemed
to be opposed to this, especially since the current convention for
multiple options in a DHCP packet only deals with options having
lengths greater than the maximum option size, meaning that the
values of all the multiple options are concatenated (which would
not be the case here). This question will also be referred back
to the list.

Mark placed the following issues before the group:

1. Was the draft division the right thing to do?
2. Are there use cases (or scenarios) that need to be added to
the resolution draft?
3. Who has implementation experiences they can share that will
contribute to refining the draft?

ACTION ITEMS - DHCP-DNS interaction

AUTHOR: Add the flag bit to the fqdn option as requested. Change
the encoding scheme for the DHCID RR as requested. Initiate
mailing list discussions of the questions brought up in the meeting,
and the ones the author brought to the meeting.

Draft: DHCP Authentication using Kerberos
draft-smedvinksy-dhc-kerbauth-00.txt
Presentor: Poornima Lalwaney

Poornima gave a detailed presentation of the draft. There is an
existing Kerberos DHCP draft (draft-hornstein-dhc-kerbauth-02.txt).
Poornima contrasted the two drafts, stating that the Hornstein
draft posits a tight coupling between the DHCP server and the
Kerberos state machine(s). The Medvinksy draft de-couples the
server to a large degree by placing initial key management
responsibilities on an 'iakerb proxy', which is specified in
a current kerberos draft (draft-ietf-cat-iakerb-03.txt).

The Medvinsky draft proposes using the client's hardware address
in AS_REQ and TGS_REQ host address fields by using a negative
value in the 'host address type' field, as specified by the
IAKERB draft. The 'source IP address' field would be left at 0.

It was noted that in order for the Medvinsky draft to succeed,
the iakerb proxy draft must be modified. The proxy draft implies
(but doesn't state explicitly) that the GSS API must be used
to access proxy mechanisms. The Medvinsky draft would extend the
proxy draft to allow 'raw' kerberos messages to be handled by
the proxy as well.

Ted Lemon advocated adoption of the Hornstein draft, because he
feels that requiring modification of server behavior is preferable
to requiring modification of client and/or relay behavior. It was
noted that the authors of the Hornstein draft are not moving it
forward; Ted offered to assume that responsibility.

It was noted that there is not currently working group consensus
on which draft to move forward.

ACTION ITEMS - DHCP Authentication using Kerberos

AUTHORS: The authors (or representatives) of both Kerberos drafts
will prepare motivation/discussion documents that will be
presented to the mailing list for discussion, with the goal of
determining which draft should be moved forward. The documents
will be available to the list by October 1, 2000, with this
discussion to be resumed at the next IETF Meeting.

WORKING GROUP CHARTER AND MILESTONES REVIEW
Presentor: Ralph Droms

The five main charter points were agreed upon by the group with the
following changes/additions:

1. The issue of DHCP authentication is to be moved from a sub-
category to a full charter requirement.

2. The LDAP and DHCP MIB projects will be added as full charter
requirements.

3. The interaction between the DHCP WG and the IPV6 autoconf WG,
while a major issue, is covered in the DHCPv6 charter point.

The milestones list is outdated. Ralph will get date information
from several people on the status of their respective drafts.

Specific milestone issues include:

     a list of open issues concerning the review of the DHCP protocol
     for Standard is needed. This might be accomplished by
     publishing the list as an intermediate or informational I-D.

     The Classless Static Routes and NameServer Search drafts will
     shortly be ready for Working Group Last Call.

     The New Options Guidelines draft has been split into two drafts,
     and the goal is to have them ready for WG Last Call in the near
     future (i.e., before the next IETF meeting).

ACTION ITEMS - Charter and Milestones

AUTHOR: Ralph will modify the Charter and submit it to the list
for comment. He will solicit date information from draft authors
who are represented in the milestones list, update the milestones
list and submit it to the list for comment.

DRAFT: LDAP Schema
draft-ietf-dhc-schema-02.txt
Presentor: Bernie Volz

A new version of this draft, based on detailed feedback from a couple
of sources, will be issued in late August.

ACTION ITEMS - LDAP Schema

AUTHOR: will issue -03 version of the draft.

DRAFT: Load Balancing
draft-ietf-dhc-loadb-02.txt
Presentor: Bernie Volz

The -02 version of this draft has been published. It consists mostly
of wording changes and cleanup. Bernie asks that this draft be sent
to WG Last Call.

DRAFT: Failover
draft-ietf-dhc-failover-07.txt
Presentor: Bernie Volz

The -07 version of this draft has been published. It consists mostly
of editorial changes, with minor technical changes. The draft's
author was unable to attend, so discussion of the draft was postponed
to the list, and likely to a conference call meeting to be held in
the fall.

Bernie stated that more discussion (and draft language) is needed to
deal with the issue of reserved address handling, based on Cisco's
current implementation experiences. The open issues, which are
listed in the draft, are generally straightforward, and should be
dealt with in the interim meeting.

Area Director Thomas Narten stated that the IESG requires substantial
advance notice for interim Working Group meetings, and a consideration
of time constraints and convenience on a global level, to make
working group meetings internationally inclusive. He clarified that
this was not a criticism of the DHC group's handling of meetings, but
rather a reiteration of requirements for how they should be announced
and conducted. In general, meeting announcements should be made
around a month in advance when possible, and in any case more than
a week in advance. They should also try to take into account the
problems of time zone differences between interested parties, in the
case of conference calls.

ACTION ITEMS - Failover

AUTHOR: The draft's main author, Kim Kinnear, will post a meeting
notice to the mailing list no later than early October. The format
of the meeting will most likely be a conference call.

DRAFT: DHCP Server MIB
draft-ietf-dhc-server-mib-04.txt
Presentor: Richard Barr Hibbs

Barr stated that a new revision of this draft will be submitted
in mid to late August. There have been delays due to disagreements
over MIB content and implementation issues which are still in the
process of resolution. The draft should be ready for WG Last Call
after one more round of feedback on the upcoming revision, followed
by a succeeding revision.

It was asked whether or not the server MIB draft was considered a
gating item for the DHCP protocol to go to Standard.  Thomas stated
that the IESG does not consider it so.

ACTION ITEMS - Server MIB

AUTHORS: prepare the next revision for submission before the end
of August.

DRAFT: DRCP
draft-itsumo-drcp-00.txt
Presentor: Subir Das

Subir gave a detailed presentation on the Dynamic Registration
and Configuration Protocol (DRCP). The primary objectives are
improvement over DHCP in the areas of real-time speed, a reduction
of bandwidth, and a minimization of broadcast usage. These objectives
are primarily intended to benefit wireless- and mobility- oriented
customers.

The main differences of DRCP are: significantly reduced packet size,
the possibility for a two-message rather than four-message exchange,
and a difference in header format between client-to-server and
server-to-client messages.

The draft is still in its early stages. Subir stated that the
authors are still working to refine their objectives and debating
basic issues.

The group responded by asking how many of these ideas could be
considered for incorporation into the existing DHCP protocol. It was
also pointed out that many of the ideas presented in this draft have
interesting possibilities with regard to the DHCPv6 drafts.

ACTION ITEMS - DRCP

AUTHORS: The draft authors will work with Ralph to prepare a list
of DRCP features that might be candidates for integration with the
existing protocol. This will be submitted to the mailing list (time
frame was not specified) for discussion.

Submitted by Richard Jones, 2 August, 2000.

-------------------------------------------------------------------

Tuesday, Aug 1 at 0900-1130 (DHCPv6)
====================================

Meeting Manager: Ralph Droms (WG Chair)
Presenter: Mike Carney, with Charlie Perkins and Jim Bound

The agenda was:
1. Determine the DHCPv6 I-D drafts' readership

2. Discuss open issues with the drafts

3. Determine the next step for the drafts

Mike established that fewer than ten per cent of the meeting
attendees have read the latest DHCPv6 drafts, which were
published in May of this year (draft-ietf-dhc-dhcpv6-15.txt, and
draft-ietf-dhc-dhchpv6exts-12.txt).

OPEN ISSUES

Issue 1: Releasable resources

Mike referred to a discussion section in the draft that treats
the use of 'releasable resources' in a generic manner. In fact,
the only releasable resource currently defined is IP address.
There was a concern that the draft's treatment of the subject
may be confusing, so Mike asked the group if the text should be
changed. There was no comment, so the text remains as is.

Issue 2: Client requests for multiple addresses, and any-time
requests for addresses/parameters

The draft protocol allows for, but does not require, that
clients be capable of requesting multiple addresses in a
transaction, and that they be able to contact a server and
request addresses and/or parameters at any time. There was
agreement that this adds complexity to the draft (see Complexity
issue below). There was not consensus on whether or not this
constitutes a gating issue, or how (or if) it should be
approached.

Issue 3: Client requests to multiple servers

The draft protocol allow for, but does not require, that
clients be able to make requests for addresses and parameters
to different servers. When asked, Mike asserted that the
capability was optional. Jim asserted that the draft is
sufficiently clear on this. Mike suggested that the draft be
reorganized to have clear sections for a 'core', or minimal,
application of the protocol, followed by clearly-delineated
sections describing more sophisticated possibilities. One
meeting participant agreed strongly. There were no dissenting
opinions.

Issue 4: Dynamic client reconfiguration

Mike asked the group if this issue has been adequately treated
in the draft. He mentioned the two sections discussing passive
and active renumbering scenarios, including the ability to
limit the number of reconfigured clients by using recyclable
multicast addresses. One comment was that the number of clients
to be reconfigured may not be known beforehand, making the use
of multicast difficult. The matter was left for further
consideration.

Issue 5: Clients, Duplicate Address Detection and address release

The draft calls for clients who deduce address conflicts using
a DAD mechanism to send a release message to the server, using
a 'bad address' status. Mike asked the group if this would be
adequate. There was no comment, so it was assumed to be okay.

Issue 6: Enumeration of legal extensions for each message type

Mike asked the group if the draft should explicitly list all
valid extensions for each message type. It was pointed out that
this approach doesn't scale well when new extensions are
adopted. The suggestion was made and approved that the draft
follow the technique of the DHCPv4 failover draft, which lists
the 'options' that are mandatory for each message type, the
'options' that must NOT be supplied, and leaves all others as
'optional'.

Issue 7: Multi-link subnets are explicitly not supported

Mike asked the group for consensus on the explicit non-support
in the draft for multi-link subnets. It was suggested that since
the real issue here is that client DAD does not work in this case,
that specific language be added to the draft to explain the
non-support's motivation. Suggestion was approved.

Issue 8: Do extensions need to be padded or aligned?

Mike asserted that extensions are explicitly not to be padded,
since the length field of an extension makes their size clear.
String instances of extensions are not to be null terminated, and
byte- or bit-alignment is not a requirement. It was suggested and
approved that specific language to this effect be added to the
extensions draft.

Issue 9: Relay agents are not allowed to modify the contents of
a message in flight.

Mike asked the group if this was too restrictive. The consensus
was that it is too restrictive, especially in the light of the
DHCPv4 relay agent option (currently draft status) that explicitly
has a relay agent adding to the 'options' field of a message.
However, it was strongly suggested that language be added to the
draft stating that having a relay agent modify a message has major
implications for end-to-end authentication and integrity checking.

Issue 10: More detailed description of client behavior when a
transaction fails

The draft currently provides little direction for clients when
they receive a non-zero status after a transaction. Charlie stated
that there is no protocol mechanism for this instance, and asked
the group for guidance. There were suggestions made for and against
having the client 'call somebody', with no clear agreement. There
was agreement, though, that there should be a detailed mapping
between error status values and some form of human-interpretable
message, to make troubleshooting a reasonable proposition.

Issue 11: Which method of DHCP authentication should be used?

The current DHCPv6 draft has provisions for authentication
methods. Mike asked the group to decide if these should stay, or if
another method should be referenced. The consensus appeared to be that
the draft's authentication mechanism should be removed and the current
V4 DHCP authentication draft should be referenced. This draft is due
to be considered for Proposed Standard by the IESG in the near future,
and was considered a good bet. Ralph cautioned that things such as a
relay agent modifying a message must be dealt with explicitly in the
v6 draft. It was also suggested that a section be added to the
extensions draft covering the translation from DHCPv4 option format
to v6 extension format for the proposed authentication option.

Issue 12: Implementation state diagrams

Mike stated that there had been a request for state diagrams, but
they have not been drawn up yet. The suggestion was made that the
term 'implementation' is misleading, and should be changed. The
term 'protocol state diagram' was suggested. There appeared to
be consensus on that name.

Issue 13: The extension carrying the DHCPv6 protocol version is
missing

Issue 14: Almost no feedback on the draft. Why?

This issue was discussed in several ways throughout the meeting.
There are several important sub-issues, which appeared to break
down into two main themes: protocol complexity, and working group
process.

Protocol complexity

There were several complaints concerning the complexity of the
draft, and the difficulty of reviewing it. While it was pointed
out that there are many more complicated drafts and standards,
it was acknowledged that this draft could stand to be organized
more clearly along the lines of what is 'core' protocol and what
is 'allowable to a sophisticated client'. There did not appear
to be consensus on whether or how this should be done, largely
due to perceived serious time constraints on getting the draft
to Proposed Standard.

There were also many perceived 'barriers to implementation'. One
problem cited was that of determining the 'core protocol'.
Another was the perception of unnecessary complexity, e.g. the
different header sizes for each message, and the potential presence
or absence of header fields based on bit flags in the same
header.

The draft also leads people to infer that there is an API implied
that interfaces applications and a DHCPv6 client. The authors
agreed with this, but did not agree on how or whether the
'implicit' API should be treated in the draft. Two current
implementations of the protocol were cited; one that exercises the
'full' protocol, and one that is partial. It was strongly
pointed out that many more implementations are needed asap to
gain more knowledge of the protocol's strengths and weaknesses. It
was also pointed out that interoperability is crucial to the
success or failure of the protocol.

Working group process

Observations were made that some non-author working group members
feel that historically the DHCPv6 process has been non-inclusive,
and that feedback, when given, has not been acknowledged or acted
upon. The authors agreed to seriously consider this issue, and look
quickly for solutions.

Ralph suggested that perhaps the group should go back to an analysis
of the differences between DHCPv4 and v6 in an effort to solidify
and simplify the v6 draft. This was favored by some and viewed as
a likely distraction by others, so consensus was not reached.

It was pointed out that IPV6 development is accelerating rapidly.
The time frame of six months was given as a  practical limit for
getting a Proposed Standard for DHCPv6 with much hope of having
it be widely implemented. While the exact time frame was not agreed
upon, there seemed to be consensus that there is not sufficient
time for another major draft revision.

It was suggested that an interim meeting between seriously concerned
group members be scheduled approximately three weeks from this
meeting date (around Aug. 21, 2000). Meeting participants are
expected to have thoroughly studied the drafts, and to have well
organized lists of expectations for how to proceed from here, so
the next steps can be negotiated.

ACTION ITEMS

Issue 1: no action to be taken.

Issue 2: no consensus. This remains a major open issue.

Issue 3: no action to be taken.

Issue 4: further consideration is needed to decide if the current
draft's treatment of the issue is adequate.

Issue 5: no action to be taken (draft language to be left as is).

Issue 6: revise the extensions draft to use the enumeration technique
suggested.

Issue 7: add language to the protocol draft to express the reason for
explicitly not supporting multi-link subnets.

Issue 8: add language to the extensions draft reinforcing the length
parameter's use, non-null termination of strings, and that byte-
or word- alignment is not a requirement.

Issue 9: change draft language to allow relay agents to modify
messages in flight, but add strong cautionary language concerning
the implications to authentication and integrity checks.

Issue 10: solicit group input on client behavior in the case of
'transaction failure'. In the meantime, provide human-interpretable
feedback that maps directly to the possible 'bad' status values.

Issue 11: remove sections of the protocol draft specifying authentication
behavior, and replace with a reference to the DHCPv4 authentication
draft. Add language to the extensions draft making the translation from
DHCPv4 'options' to v6 'extensions' to support the authentication draft,
and add language concerning message fields that must be zeroed for
integrity checks. This includes specific language dealing with the
DHCPv4 relay agent option (currently draft).

Issue 12: create 'Protocol State Diagrams'.

Issue 13: add the protocol version extension to the extension draft.

Issue 14: ALL CONCERNED GROUP MEMBERS: study the draft (if not already
done), and prepare a list of concerns, suggestions and expectations.
Prepare for an interim meeting, either in person or via conference call,
towards the end of August, 2000. AUTHORS: consider methods of 'outreach'
in order to get quality feedback in sufficient quantity. Ralph has
offered to consult with the authors on ways to do this.

Submitted by Richard Jones, 2 August 2000.