(Back to dhcp.org home) (Back to 3/99 meeting page)
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:
-------------
1. Don't send *any* releasable extension to a client if the
client doesn't ask.
2. This requires clients to request IP addresses.
Note that this allows a client to do an INFORM kind of
request where they don't get any IP address.
3. Send a reconfigure with multiple address extensions to tell the
client how many addresses it should request.
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.
1. It cuts dramatically the number of the operations for
something like a renumber.
2. It allows the server to know the client has not only
received the request to reconfigure, but also to know that the
client has received its new configuration information.
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:
o DHCP servers and clients should be able to detect and resolve
host
name collisions.
o Use a "KEY" RR to associate client with a DNS name.
o 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:
* Load balancing based on hash of link-layer addresses
* TCP to be used for data transmission, UDP for polling
* Time synchronization to be suggested but not required; poll messages
will transmit current time to allow determination of drift
* A straw-person security mechanism based on a shared secret, message
digests and sequence numbers.
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:
1. What happens if a bunch of devices in, say, a house get
addresses from a DHCP server across the network, and then the
network goes down? What happens to the devices in the house that
would like to talk to each other over the still, intact, network
that is running inside the house?
2. What about when a DHCP client sends a DISCOVER and that is
broadcast, and the kid-next-door gets the broadcast and responds
with an bogus address?
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.