DHC WG, IETF-93 (Prague)
Date: Thursday, July 23, 2015, 13:00-15:00 (CEST)
Location: Berlin/Brussels Room
Chairs: Tomek Mrugalski & Bernie Volz
Secretary: Sheng Jiang
Presentations materials: https://datatracker.ietf.org/meeting/93/materials.html#wg-dhc
1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 5 minutes
Hackathon on July 18 & 19, a group of participators went through Stateful issues (RFC7550)
and tested Secure DHCPv6 interoperated with two implementations.
Calling topics for Hackathon in IETF-94, Yokohama, besides DHCP4o6 (RFC 7341)
6o4 - Marcin / Francis /
2. Stable Privacy Addresses next steps - 10 minutes
Bernie: there is few discussion on this draft since adoption.
Lorenzo: Just leave it up to server implementers. It doesn't optimize for server memory.
There is not much value in this.
Marcin: also little value.
Ted Lemon: useful to have an algorithm to prevent bad algorithms e.g. privacy leakage
Fernando: it is useful
Tomek (no hat): a small amount of value - not standards track - prefer informational
Christian Huitema: stable is against privacy
Ted Lemon: do this algorithm if you want privacy - Applicability statement.
Eric: First paragraph of section 4 is controversial
"DHCPv6 server implementations conforming to this
generate non-temporary IPv6 addresses using the algorithm specified
in this section."
Bernie: there is one use case for CPE.
Dead/Standards/Info (consensus of hum for dead, standards silence, Info soft)
Bernie: it seems the WG prefers to kill it.
Ted Lemon: should not kill this, otherwise IA-NA should also be deprecated, too.
Post Meeting Action: Confirm dead decision on WG mailing list.
3. Secure DHCPv6 and DHCPv4, Sheng Jiang - 10 minutes
Adapt SeND timestamp format that was proposed
during the hackathon/WG
discussion. And other terminologies need to be fixed.
Received comments on supporting multiple
certs. Question to WG/SAG: Do we
need to support multiple certs?
Ted Lemon: no point in multiple - do sequentially
UDP Frag issues if present should be raise
in Security Considerations, but
not fixed in this doc. It is generic for UDP not for DHCPv6 specific.
Bernie: UDP/IP is a service to DHC
Christian H: still worries about fragmentation.
Ted Lemon: We can't solve this problem in
this WG. Best is the enemy of
The coauthor is given a report and calling
help in SAG for generic security
Issue. But it we could not solve these issues, the document should still go forward
Brian: Slide 4: need describe where this is
used. Different trust model
enterprise vs. coffee shop - be aware of timing difference
Just changes report no questions
Order work on Marcin: V6 before V4
Bernie: the WG would process Secure DHCPv4 after Secure DHCPv6 stabilized.
Post Meeting Action: Confirm switch to SeND time format.
Profile Implementation & Deployment results,
Christian Huitema - 15 minutes
Marcin: basically in good state.
- Wake-up behavior is not clear. Just do discover as otherwise you leak address.
Lorenzo: Why not just send hello+mac or something?
Chris: no sending simpler, invent new name
is a lie with compatibility issue; the name
should not be reversible.
Lorenzo: switching on same ssid - does it burn down DHCP server?
WGLC after next draft
Post Meeting Action: Make any last edits to
3 documents related to privacy, then initiate
WGLC on all 3 together.
5. DHCPv6bis update & issues discussion, dhcpv6bis team - 25 minutes
No points for encapsulated options – rfc's say
what MUST be there.
- Lots of implicit updates?
Prefix length hint
Ole: bad initial design
Suresh: same concern
Ted Lemon: not require special cases in the server
Drop lifetime hints; server ignore it
Ole: Supports dropping. How to hint renumber wanted?
Ted Lemon: client initiate renumber: request
new prefix then release old one once
you have the new one
Bernie: will make this more explicit in document
Marcin: move #81 forward as soon as possible and combine if possible
How to grow PD is an important issue
Marcin: more info on how to do this
Ted: solution is to renumber into bigger.
6. YANG Data Model for DHCPv6, Linhui Sun - 15 minutes
Bernie: how does this apply to hackaton?
worried about how well this works with existing implementations - and
updates to them - will do careful review
?: needs to cover light weight relay agent.
Bernie: worried if this will fail like older
Is this implementable/usable? Need feedback from implementers (expected
to be part of the IETF'94 hackathon)
Chair: Bernie: is there interest from the WG? Dozen or so hands
Tomek's note: around 20 people interested.
Post Meeting Action: Nothing specific;
authors and interested parties should review
document and develop mappings to several implementations to confirm Yang model.
and Encryption Mechanism for DHCPv6,
Tianxiang Li - 15 minutes
Eric: could you do encryption without certificate? Certificate has privacy issue
Christian: without authentication, security
is meaningless. Encryption to the server
only protects when you trust server.
Discussion about server trust.
Francis: go talk to crypto experts.
Chair: Bernie: interest in proceeding? Some not huge
Tomek's note: around 10 people interested.
Post Meeting Action: Solicit input to concept and details from security area (Francis
and co-authors to initiate). Revised draft expected before possible adoption call.
WG co-chairs will discuss this work item with AD to gauge level of interest in
potentially adding to charter.
8. 4o6 Bulk and Active Leasequery, Tianxiang Li - 10 minutes
No clarifying questions/discussion
9. Relay Initiated Release, Sunil M Gandhewar - 5 minutes
this will cause problems - Client will think it has a lease but it has gone
Ted Lemon: why for v6? Merge drafts.
Meeting Action: Authors should follow up with commenters and address
their concerns (mostly around why this is needed and to assure it will not
cause problems if implemented with state possibly retained in clients).