Minutes for DHC at IETF-92
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes for DHC at IETF-92|
|Other versions||plain text|
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
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
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,
Privacy analysis drafts have been adopted as Informational WG
Question: should wait for mitigation drafts.
Marcin: mitigation drafts would give more feedback for analysis
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
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
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
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.
Lishan: not yet, but may plan.
Ian: needs to get implementers involved. Use common names.
Bernie: people support to move forward?
5. Bing Liu, DHCP YANG Model - 10 minutes
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
6. Sheng Jiang, Secure DHCPv4 - 10 minutes
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
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
#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
#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
#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
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.