home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
dhc
/
dhc-minutes-96jun.txt
< prev
next >
Wrap
Text File
|
1996-10-07
|
5KB
|
101 lines
Editor's note: These minutes have ont been edited.
DHCPv4
Ralph Droms gave a status report on the DHCPv4 documents. The four
core documents - DHCP specification, DHCP options, BOOTP
clarification and DHCP-BOOTP interaction - are on track for promotion
to Draft Standard. The FQDN option and extension option documents
are on track for acceptance as Proposed Standard. The graceful
renumbering (from Lowell Gilbert) and DHCP-DNS interaction (from
Yakov Rekhter) documents are in revision. The authentication and
server-to-server protocol documents are in development.
The WG agreed on several small changes to the DHCP documents prior
to publication as Draft Standards:
* Clarify text so "user class" interpretation is not a MUST requirement
for
servers
* Change text so lease time MUST NOT/SHOULD NOT requirements in
DHCPINFORM
are consistent
* Change text in section 4.4.2 so that the known IP address MUST be
inserted (to match table)
Several other protocol details and extensions were discussed:
* Should DHCPDECLINE be unicast (NO! WG has concluded [several
times!} that
DHCPDECLINE must be broadcast (DECLINE implies client has no IP
address) * In response to an inquiry about ISP/session-oriented
parameters, there
will be a discussion on the mailing list to begin development of options
for such parameters
* After a discussion of an mechanism to indicate the "preference" of
configuation parameters - e.g., existing vs. new lease, primary vs.
backup server, static vs. dynamic allocation - the WG concluded that
such a mechanism could be developed as an option. This option will be
proposed in a separate I-D through the new option acceptance
procedure. * Jim Bound discussed hs proposed solutions to the problem of
configuring
remote subnets through, e.g., on-demand, dial-up router service. A
document will be developed that will either be added to the DHCP
FAQ or published as a DHCP-related RFC.
* Discussion of a DHCP MIB will be started on the DHCP mailing list.
The server-to-server and authentication protocols were discussed. An
ad hoc group met briefly right after the WG meeting to review the
presentation about the server-to-server protocol given at the WG
meeting in Los Angeles. Ted Lemon volunteered to begin an I-D defining
the server-to-server protocol. Ralph Droms will expand the
authentication I-D into an option specification; this specification will
allow for other authentication mechanisms in addition to the private
key mechanism described in the authentication I-D.
DHCPv6
Jim Bound and Charlie Perkins have issued new versions of the
DHCPv6 protocol spec and extensions I-Ds. The specification I-D
includes bug and architecture fixes, authentication extensions,
movement of the "L" bit, multicast RECONFIGURE message handling,
multicast address for server addresses and a comparison between
DHCPv6 and DHCPv4. The extensions I-D includes bug fixes, inclusion
of each address/name as a separate extension, specification of the
multicast RECONFIGURE extension, an extension for renumbering
servers and a description of the authentication extension.
The WG discussed a couple of proposed features:
* Unsolicited advertisements by servers/relay agents - rejected as
unneeded.
* Hints to client about preference levels (as in DHCPv4) - seems to be
needed
* Relay agents check off-link servers periodically - needed to prevent
forwarding stale information about servers to clients
There was a discussion of the DHCPv6 relay agent architecture in
which relay agents cache server information rather than passing
solicit requests through to servers. As there is no implementation
experience on which to make a decision (based on traffic, difficulty of
implementation, etc.), the WG agreed to accept the mechanism as
described in the current I-D; however, this architecture may be
reconsidered in the future.
Authentication is seen as crucial, especially in preventing attacks
through the RECONFIGURE message. The DHCPv6 authentication
mechanism is based on IPv6 mecahnisms and will prevent
authentication, verification and replay protection.
Future plans for DHCPv6:
* Begin implementation - including DNSIND, IPSEC and the
authentication
extension)
* Inlcude DHCP in the UNH bakeoff in November, 1996 * Revise the
specification and submit for Proposed Standard after San Jose
IETF meeting (December, 1996)
Once again, thanks to Shawn Mamros for taking the notes on which
these minutes are based.