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

Meeting Minutes Dynamic Host Configuration (dhc) WG
Title Minutes for DHC at IETF-92
State Active
Other versions plain text
Last updated 2015-04-08

Meeting Minutes
minutes-92-dhc

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.