Minutes for DHC at IETF-92
minutes-92-dhc-2

DHC WG Agenda for IETF-92 (Dallas)

   Date: Thursday, March 26, 1300-1500 CDT, Room: Far East
   Chairs: Tomek Mrugalski & Bernie Volz
   Secretary: Sheng Jiang
   Presentations materials:
   https://datatracker.ietf.org/meeting/92/materials.html#wg-dhc

1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...)
   - 10 minutes

   WG status update
   Stateful issues draft is in RFC Queue
   Lease-query and Sedhcpv6 drafts need another minor update

   DHC privacy documents adopted

   3315bis adopted before the meeting

   dhc-addr-registration - failed WGLC, Suresh indicated that
   there's no intention to work on it anymore, will mark as dead

   Chairs will work with authors after IETF-92 to update WG
   milestones.

   Future DHC Hackathon, may be in IETF 93.

   New AD for DHC will be Brian Haberman.

2. Tomek Mrugalski et al, DHCP Privacy Considerations
   - 10 minutes, draft-ietf-dhc-dhcp-privacy,
   draft-ietf-dhc-dhcpv6-privacy,
   draft-mrugalski-dhc-dhcpv6-privacy-mitigation

   Privacy analysis drafts have been adopted as Informational WG
   documents.

   Question: should wait for mitigation drafts.

      Marcin: mitigation drafts would give more feedback for analysis
      drafts.

      Sheng: should wait for one or two IETF meeting to be mature, but
      not necessary to group with mitigation drafts.

   Question whether use temporary address. - no consensus.

      Marcin: every client should have the same behavior clearly defined
      by standards?- such as for "randomizing" hostname.

   Merge into draft-huitema-dhc-anonymity-profile

   Bernie: maybe a privacy guidance for the future DHC options

   Chris: no, we will be careful, that's it.

3. Christian Huitema, DHCP Anonymity Profiles - 15 minutes
   draft-huitema-dhc-anonymity-profile

   MAC/DUID/IP Address must be changed at the same time to give privacy.

   Lorenzo: have different IP address

   Chris: it is only in IPv6, not in IPv4

   Jabber: will another draft for MAC address randomization?

   Chris: that's not IETF work

   Sheng: should also document the reference and status to MAC address
   randomization

   Kim: be careful for "must", "should"

   Lorenzo: only stateful has the issues; don't understand the benefit
   or the goal.

   Chris: threat is location tracker

   Med: Who is the bad guy, and what is the use case, WiFi network?
   fixed IP address is often and useful feature for network operators.
   Chris: Mostly for WiFi, random hot spots. the mobile devices does
   not normally need this. The fixed network should not use this.
   They do not have privacy request.
   Med: the use case should also be documented.

   Kim: SHOULD vs. MUST issue. Mostly might be MUST. Regarding to
   "trust environment", if it is in it, then don't need this. The draft
   is talking minimizing logs to meet the clients' wishes, but you
   should not know what the wishes are.

   Bernie: this focuses on a different kind of device, not aimed at
   cable modems and CPEs.
   Ted: use case is good. Many discussions are out of scope.

4. Lishan Li, DHCPv6 YANG Model - 5 minutes
   draft-cui-dhc-dhcpv6-yang

   Kim: will someone config client?

   Ian raised hand.

   Sheng: it is better for separated models for client, relay and
   server, instead for one model with sub-models

   Bing: how about a relay device acting as a DHCP-PD requestor.
   (Bing's comment while editing the notes: if the PD requestor is
   embedded in the DHCP client, when a DHCP relay acts as a PD
   requestor, it has to configure a whole DHCP client parameters.
   This might not be efficient. We can also consider making PD
   requestor and responder as separated roles along with client,
   relay and server.)

   Kim: there is no pool-binding in server model.

   Bernie: technical details should be in mail list.

   Marcin: implementations?

   Lishan: not yet, but may plan.

   Ian: needs to get implementers involved. Use common names.

   Bernie: people support to move forward?

   Many hands.

5. Bing Liu, DHCP YANG Model - 10 minutes
   draft-liu-dhc-dhcp-yang-model

   Tomek: did you work with DHCPv6 Yang to make them similar,
   like same names?

   Bing: will do.

   Bernie: assume the same interests in DHCP Yang.

   Ted: I'm not opposing this work, but I'm less interested in DHCPv4
   than DHCPv6.

6. Sheng Jiang, Secure DHCPv4 - 10 minutes
   draft-jiang-dhc-sedhcpv4

   Bernie: 16-bit length field is not accepted in DHCPv4. The long
   field should be split into multiple instances.

   Sheng: will apply it in the next update.

   Bernie: adoption may be straightforward after secure DHCPv6.

7. Tomek Mrugalski, Bernie Volz, Marcin Siodelski,
   DHCPv6bis Discussion - ~60 minutes
   draft-dhcwg-dhc-rfc3315bis

   Tomek: should ticket notifications: dhcpv6bis or dhc

   Marcin, Ted & Sheng: dhcpv6bis

   Suresh: it is WG draft now. The modification/update should be
   known by WG members

   Ted: should use the WG virtual interim meetings

   Sheng: jitsi tool may have problems, should at least set up webex as
   backup.

   #142 - Reorganize server/client behavior? (Slide 5) - No objections

   #144 - Clarify unknown options handling (Slide 6) - No objections

   #81 - Should protocol options be included in ORO? (Slide 7) - Ted
   suggested we might want to request IANA to add a new column to the
   options table as to whether it MUST be in ORO for the client to
   receive. This seemed like a good way to solve this problem. The
   default needs to be "YES" unless the option definition document
   says otherwise. Perhaps this should be done as a separate draft
   (Bernie's suggestion while working on this summary).

   #18 - Is ORO mandatory? (Slide 8)
   - Servers MUST accept messages without an ORO. SOL_MAX_RT MUST be
   in ORO, if ORO is included, for Solicit/Request/Renew/Rebind
   (INF_MAX_RT MAY be). INF_MAX_RT MUST be in ORO, if ORO is included,
   for Information-Request (SOL_MAX_RT MAY be).

   #68 - Prefix Length of Addresses (Slide 9) - Yes, this should be
   documented. See DHC WG discussion thread starting with
   http://www.ietf.org/mail-archive/web/dhcwg/current/msg16391.html.

   #82 - IA_ADDR with:: Address (Slide 10) - Discourage use of IA_ADDR
   and IA_PREFIX with all 0s (no hints or requested address/prefix).

   Ted suggested we document how clients get new addresses - by using
   a new IA_ID with an IA_NA or IA_TA.

   #114 - Clarify "hints" (Slide 11)
   - This has to do with clients requesting a prefix delegation prefix
   length. Bernie to send an email to WG to clarify issues and suggest
   text changes.

   #70 - Validate addresses in IA (Slide 12) - The participants felt
   that there was no need to add anything more or otherwise make changes
   in this area.

   #86 - Information-request in Delayed Authentication Protocol (DAP)
   (Slide 13) - Ted suggested we remove DAP from DHCPv6bis as it is not
   known to have been deployed by anyone. As far as we can tell, there's
   only one implementation. (Tomek comment added during writing those
   minutes: I did implement it in Dibbler. The mechanism, including
   option formats, was underspecified and I had to make judgement
   decisions that would likely prevent interop. I'm not aware of any
   other implementations or deployments that use DAP in Dibbler).

   Reconfiguration Key Auth. Protocol will be retained. This seemed like
   a good way to solve this issue and reduce the size / complexity of
   the document.

   Tomek's comment while editing those notes. I strongly support this
   proposal. That is especially important if our original plan to
   promote DHCPv6 to Internet Standard still applies. In particular,
   RFC6410, section 2.2 defines the maturity requirements for a standard.
   Note item 3:

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   Delayed Authentication Protocol matches this description. It is
   unused (has anyone heard about anyone deploying this feature beyond
   lab tests? I haven't.) and it has significant implementation
   complexity. Since nobody deployed it in 11 years, then it's not
   usable. Let's get rid of it.