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.