Subject: Minutes from WG meeting in London

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Aug 2001 07:42:51 -0400

Please reply to the mailing list with any comments about the draft minutes (included below) from the DHC WG meeting in London.

- Ralph

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 for
OS 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