[dhcwg] *DRAFT* minutes from dhc WG meeting, IETF 56

Included below are *DRAFT* minutes from the dhc WG meeting in SF.  Please respond with additions, deletions or corrections before 4PM EDT, Fri 4/11.

- Ralph

-----
		  Minute of dhc WG Meeting, IETF 56
		  =================================

Administrivia, agenda bashing, WG progress report - Ralph Droms
---------------------------------------------------------------

Progress report since last WG meeting:

RFCs published:
  The Classless Static Route Option for Dynamic Host Configuration
    Protocol (DHCP) version 4, RFC3442
  Dynamic Host Configuration Protocol (DHCP) Option for
    CableLabs Client Configuration, RFC3495

Accepted as Draft Standard:
  DHCPv6
  Link Selection sub-option for the Relay Agent Information Option
    for DHCPv4

Passed last call:
  Security Ticket Control Sub-option for the CableLabs Client
    Configuration Option
  DNS Configuration options for DHCPv6
  NIS Configuration Options for DHCPv6
  Time Configuration Options for DHCPv6
  DHCP Options for Internet Storage Name Service
  IPv6 Prefix Options for DHCPv6

Review of new charter, request for milestones - Ralph Droms
-----------------------------------------------------------

Droms announced that charter had been accepted by IESG and posted to
www.ietf.org.  He noted that draft authors will be asked to supply
milestones for posting with the charter.

DHCP security review team report - Barr Hibbs
---------------------------------------------

Review team has made progress but did not publish draft prior to
pre-IETF deadline; team will publish initial draft after IETF
blackout.  Focus is currently on DHCPv4, but results may be applicable
to DHCPv6 as well.  Vipul Gupta has agreed to re-publish earlier draft
on certificate-based DHCP authentication.  Ted Lemon and Michael
Richardson have published a draft using SIG(0) keys (see below).

'Securing DHCP with DNSSEC bourne public keys' - Ted Lemon
<draft-richardson-dhc-auth-sig0-00.txt>
----------------------------------------------------------

This draft was published just before the IETF deadline and is
incomplete.  The fundamental idea in this draft is to perform DHCP
authentication using DNS SIG(0) keys.  The WG accepted the draft as WG
work item.

Authentication of relay agent options - John Schnizlein
-------------------------------------------------------

Schnizlein volunteered at previous IETF to conduct comparison of two
proposals for securing communication between a relay agent and server
(draft-ietf-dhc-auth-suboption-01.txt, Stapp and Lemon;
draft-droms-dhcp-relay-agent-ipsec-00.txt, Droms).  His conclusion is
that the proposals are each applicable in different situations.
Thomas Narten questioned whether the WG should advance two mechanisms
that address the same problem.  The authors of the two drafts and
Schnizlein said the two proposals may be appropriate in different
environments, if IPsec is already available on all the participating
components, the IPsec-based method may be usable with no additional
configuration or software updates; the authentication has better
scalability (key management) properties when IPsec is not already
deployed.  Narten suggested we could flip a coin to choose between the
two proposals.  Droms observed that, while there is some overlap
between the applicability of the two proposals, there are significant
cases in which only one of the two is appropriate.  The WG will
continue to work on both proposals.

VPN-ID option and sub-option -  Kim Kinnear
<draft-ietf-dhc-vpn-option-02.txt>
<draft-ietf-dhc-agent-vpn-id-02.txt>
-------------------------------------------

Narten asked about the requirements for these options - what problem
spaces do they apply to?  What are the situations in which the server
sends the option to the client/relay agent and what are the situations
in which the client/relay agent sends the option to the server?  Erik
Nordmark asked about security considerations.  John Schnizlein
suggested the use of "VPN" in the name might be confusing - this
option is intended to pass a VPN identifier as additional information
about a client, rather than use a VPN in any kind of security.  These
two drafts are ready for WG last call after a name change and addition
of an example case.

DHCP server MIB - Barr Hibbs
<draft-ietf-dhc-server-mib-08.txt>
----------------------------------

This draft is ready for WG last call; the MIB doctors who reviewed the
draft will be asked to comment during WG last call.

Option code recovery - Ralph Droms
<draft-ietf-dhc-unused-optioncodes-00.txt>
------------------------------------------

This draft will be revised to edit out option codes related to PXE
standard and to add more words about the plan for the use of draft;
the document will then be ready for WG last call.

Option code extensions - Bernie Volz
<draft-volz-dhc-extended-optioncodes-00.txt>
--------------------------------------------

This document resurrects an old proposal from Droms about using option
codes 126 and 127 for options that would extend the DHCP option code
space with 16-bit option codes.  Volz proposes redefining option codes
in the range 128-223 as DHCP option codes (managed by IANA), leaving
option codes 224-254 as site-specific options codes.  The WG accepted
this document as a WG work item.

Review of DHCP RFCs - Barr Hibbs
draft-ietf-dhc-implementation-00.txt
------------------------------------

Hibbs is collecting references to text in the DHCP RFCs that is
confusing, contradictory, incomplete, conflicted with other RFCs,
difficult to implement, or could only be resolved by consensus at
connectathons.  The objective is to document these issues and suggest
clarifications and corrections where necessary.  The final document
will be used in moving DHCP to full Standard.  Rob Stevens is
co-editor; the work was started three years ago by Mike Carney.  Hibbs
asked for more input.

Failover protocol - Kinnear
draft-ietf-dhc-failover-12.txt
------------------------------

Kinnear reported on changes since last revision and discussion.  There
was a meeting of failover authors and implementors in Atlanta, IETF
55: Kim Kinnear, Scanner Luce, Bernie Volz, Mark Stapp.  Notes from
that meeting are available at
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01902.html.
Narten suggested publishing as Experimental.  There are at least 6
implementations and at least two implementors reported customer
interest in failover that will interoperate between DHCP servers from
different vendors.  One vendor (Lucent) noted that there has never
been a request for their implementation. Droms asked if Experimental
could be a step towards Standards track.  Narten responded that SRV
started as Experimental.  Kinnear said he had no problem with
Experimental; the important issue is to get a stake in the ground for
implementors to work toward.  WG responded that Proposed Standard is
appropriate.  Draft is now ready for WG last call.

Lease query protocol - Kim Kinnear
draft-ietf-dhc-leasequery-05.txt
----------------------------------

Kinnear described changes to draft and noted that there have been
questions about the functions provided by the most recent document
relative to the problem statement in the introduction.  Narten
expressed concern about feature creep; that is, using this mechanism
to supply information to a network element that wouldn't be available
to the network element through DHCP messages.  Kinnear will revise
draft to provide information retrieval capability identical to what
could be obtained through reading DHCP messages.  Document will then
be ready for WG last call.

DHCPv6 status - Ralph Droms
draft-ietf-dhc-dhcpv6-28.txt
draft-ietf-dhc-dhcpv6-interop-01.txt
------------------------------------

The base protocol specification has been accepted as Proposed
Standard.  Several options have passed WG last call and are ready to
be forwarded to the IESG.  Two rounds of interoperability testing have
been conducted (TAHI and Connectathon), resulting in identification of
several minor editorial and clarification issues.  These issues have
been published in draft-ietf-dhc-dhcpv6-interop-01.txt and will be
announced to IETF.  The changes documented with the issues in that
draft will be made before publication of the RFC.

IPv4 Link Local addressing issue from zeroconf WG - Lemon
---------------------------------------------------------

Ted explained that there is a dependency between IPv4LL and DHCP: the
current specification for IPv4LL restricts an interface to be
configured with either a routable IPv4 address or an IPv4LL address.
However, transition from DHCP-assigned address to an IPv4LL address
will require a change to RFC2131, to cause a DHCP client to drop its
routable address in favor of an IPv4LL address when INIT-REBOOT
fails.  Ted will publish a summary of the issue to the DHC WG mailing
list.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg