[dhcwg] *DRAFT* Minutes from dhc WG meeting at IETF 57

[Ralph Droms <[e-mail]>]

Here is a draft of minutes from the dhc WG meeting at IETF 57 in 
Vienna.  Please review and comment by 9AM EDT, Monday Aug 4.

- Ralph

=====

		       dhc WG minutes, IETF 57
			       (DRAFT)


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): no, for backward
      compatibility
    * 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


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg