dhc WG minutes, IETF 57
 

DHCP PXE Suboptions                                Ralph Droms
<draft-johnston-pxe-options-00.txt>

   This document was prompted by the review of unused DHCP option codes.  It 
documents the three options Intel defined for use by the "Pre-Boot 
Execution" (PXE) protocols.  The history of these options is that they were 
brought to the dhc WG several years ago, but no specification was ever 
published.

   The WG agreed to take the document as a WG work item.  There was some 
discussion about whether to publish the document as standards track or 
informational.  After a review of the history of the document, the 
consensus was to publish the document as informational.

Site Specific Options for DHCP for IPv6            Ralph Droms

<draft-volz-dhc-dhcpv6-site-options-00.txt>

   Droms reviewed this document for the author, Bernie Volz.  The 
document reserves some DHCPv6 option codes for use as 
site-specific options (like option codes 128-254 in DHCPv4).  The WG 
agreed to take the document as a work item, for standards track 
publication.
   
Vendor-Identifying Vendor Options for DHCPv4       Ralph Droms
<draft-littlefield-dhcp-vendor-00.txt>

   Droms reviewed this document for the author, Josh Littlefield.  The 
document defines new vendor-specific options in which the vendor (the 
option namespace) is identified in the option itself, rather than 
implicitly from the vendor class option.  Droms cited DOCSIS devices, 
which need DOCSIS defined options as well as vendor defined options, as a 
use case.  The WG agreed to take the document as a work item, for 
standards track publication.

IPv4 Network Attachment Detection                  Bernard Aboba
<draft-aboba-dhc-nad-ipv4-00.txt>

   Based on research into problems related to recognition of network 
attachment and assignment of IPv4 link-local addresses (IPv4LL), Aboba 
published this document, which summarizes his findings about hints a host 
can use to determine network attachment and problems with current IPv4LL 
assignment mechanisms.  The document also points out some details in RFC 
2131 that need clarification.  This presentation preceded the dna 
("Detecting Network Attachment") BOF, where the document was also 
scheduled to be discussed.  There was consensus to work with the dna BOF 
(and WG, if one is formed) to develop input to the IPv4LL 
specification from the zeroconf WG.

DHCPv4 Threat Analysis                             Carl Smith

<draft-ietf-dhc-v4-threat-analysis-00.txt>

   Smith conducted a final review of this document; ready for WG last 
call.  The following three documents all address the requirements and 
issues from the threat analysis.

RFC3118 Delayed Authentication Using PANA          H. Tschofenig

<draft-tschofenig-pana-bootstrap-rfc3118-00.txt>

   This document describes a mechanism for establishing a DHCP SA 
(between client and server) through PANA (assuming PANA is invoked before 
DHCP).  The scenario is:

      * host establishes SA with PANA
      * PAA does key distribution to host and DHCP server
      * host and server use key for authenticated DHCP

   There was some discussion about the mechanism through which the PAA 
would get keying information to the DHCP participants.  The WG 
requested that the draft be revised to provide additional detail, and will 
reconsider the draft after the revisions are published.

DHCP RSA/DSA Authentication using DNS KEY records  Ted Lemon
<draft-ietf-dhc-auth-sigzero-00.txt>

   This document describes a mechanism for authentication of DHCP 
messages through public keys in SIG(0) RRs.  Olafur Gudmundsson (as chair of 
dnsext WG) opined that use of SIG(0) for DHCP authentication would be an 
acceptable use of the key in a SIG(0) RR.  It was noted that this 
mechanism would require the DHCP servers to have a SIG(0) RR, in 
addition to the hosts (which presumably would have a SIG(0) RR for DDNS).  
There was a request for more detail about the protocol in the 
document, especially a sketch of the participants and message 
exchanges.  Also, this mechanism provides only authentication, not 
authorization.

Flexible Authentication for DHCP Messages          Ralph Droms
<draft-gupta-dhcp-auth-02.txt>

   Very few members of the WG had read this draft.  Discussion will be 
continued on the WG mailing list.

DHCP-DDNS interaction                              Ralph Droms
<draft-ietf-dhc-ddns-resolution-05.txt>
<draft-ietf-dhc-fqdn-option-05.txt>
<draft-ietf-dnsext-dhcid-rr-06.txt>

   The WG came to consensus on the resolutions in the following list of 
issues (which had been discussed in the dhc and dnsext WG mailing 
lists):

   * Reserve DHCID RR for DHCP participants (1, 2): yes, reserve for DHCP 
   * Interaction between DHCPv4 and DHCPv6 needs to be defined (3): 
participant does lookup first to determine type of DHCID RR and then acts on 
that type
   * FQDN should carry 12 bit RCODES (4): RCODES will be dropped from FQDN 
option; RCODE fields in FQDN option will be declared "reserved" to 
preserve backward compatibility with deployed implementations
   * Internationalization (5): no changes to protocol; add references to 
internationalization RFC
   * RR TTLs need careful attention (6): rationale and 
recommendations to be clarified and moved to appendix