Minutes for DHC at IETF-90
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes for DHC at IETF-90|
|Other versions||plain text|
DHC Working Group Minutes
Last edit: 08/15/2014 10:40 EDT
DHC WG meeting started at 9am, Saloon room B, Wed 23 July 2014, Toronto.
Bluesheets - 20+24 = 44 attendees
*** Working Group Administrativia
Andrew Yourtchenko volunteered as jabber scribe. Thanks!
Sheng Jiang has been assigned as DHC secretary. He will take minutes, too.
- CER document will be handled by Homenet, not DHC.
- DHCPv6 router options document is not for DHC WG; notify authors. Probably
needs to be 6man or similar (they should discuss with ADs).
- Captive Portal ID in DHCP/RA - Not DHC WG document; notify authors. See above.
- Sheng's stateful reconfigure is "dead for now".
Sheng: we haven't found solid use case of Stateless Reconfiguration
Sheng: more reviews on address registration draft would be helpful. Authors
solved all comments received. WG should go second WGLC later.
Bernie Volz: WG is going through a minor recharter
Ian Farrer: introduce Yang Model for DHCPv6 client
*** DHCPv6bis Update
Tomek: report on 3315bis work
Ted Lemon: should adopt first, and then require consensus process work
Bernie: the authors would like to get consensus internally in the group and
address all known issues before adopt, then people can review a complete
version during adoption call
Tomek talking about the server may ignore the hint from client
- Client & server policy - client should be able to operate with hint
length that doesn't match PD.
- Don't ignore everything else
- Graceful renumber (renew with existing but request hint, which
server could honor).
Ole Troan: prefix length as a hint should also be able to be ignored
Tomek: it is not intended that server must accept what the client requested,
might need some rewording.
Ted: should split the cases
Bernie: client should be survive if it does not get what the hint required,
would make this clear in the document
Suresh Krishnan: it may be out of scope. The client implementation could be:
give me what I want or nothing.
Bernie: in general clients should accommodate what are form operators
Ted: provide another scenario (maybe a separated draft)
Lorenzo Colitti: how this hint relevant to SLAAC should also be considered
Michael Abrahamsson: a use case for client-initiated renumbering, e.g.
customers don't want the current assigned prefix, and to get a new one
through some mechanism
Bernie: it is not clear how the hint should be handled generally
Ole: is it ok to ask container option without suboptions?
Tomek talking about the Client Rate Limiting issue
Sheng: server should also be able to limit the request rate from the same
Tomek talking about filling link-address
Ted: more detail should be given why and how to do it, may be a separated
Bernie: just a recommendation that basically you should use a Global or
Unique Local address for relay
Fred Templin: give an example
Bernie: Link-addr SHOULD not be the link-local address
Tomek talking about "confirm no longer mandatory"
Bernie, Ted: it should be a "SHOULD"
*** DHCPv6 Stateful Issues
Bernie talking about stateful issues
Sheng: update to 3315 and 3363 should also be in 3315bis
Bernie: has not been included in 3315bis, until WGLC
Tim Winters: there are clients that actually doesn't accept top-level status,
but they do handle status in IA_NAs.
Reviewers Fred Templin, Leaf Yeh, Francis Dupont, Jason Weil, Ian Farrer,
Andrew Yourtchenko, Qi Sun, Cong Liu
*** Secure DHCPv6
Dacheng Zhang talking about Secure DHCPv6 with public key
Daniel: add trust anchor is not that difficult, leap of Faith is enough to
make sure client connect to the same server
Lorenzo: not sure what the threat model is, if there is strong L2 security,
might not need this
Maraus: prefer option 4 (drop certificate from this draft totally)
Daniel: it is useful for client to authorize server
Ted: server authorize client is also useful, though not very clear
Lorenzo: l2 security may be enough and better
Ted: client authorize server is more useful. Secure DHCPv6 regardless
server or client is good
Francis: URL for certificate may be help
Lorenzo: should get data to continue this work
Bernie: at least one use case that the client authenticates the server
Suresh: how to prove a DHCP server out of leap of faith
Ted: the point is to talk to the same server that the client has talked before
Suresh: Leap of faith make sense, others don't
Bernie: the authors could summarize the discussion and come back to mail list
for WG consensus
*** DHCP Configuration based on Network Topology
Tomek presenting Customizing DHCP Configuration On the basis of Network
Suresh: ask a question regarding to normative reference, DHCP base reference
was moved to informative, it should remain normative
Bernie: Add DHCP RFCs back as normative references/not informative
The feeling in the room is that the draft is ready for WGLC
*** Dynamic Allocation of Shared IPv4 Addresses
Qi Sun talking about Dynamic Allocation of Shared IPv4 Addresses
Ted: is this required for lightweight 4over6?
Ted: this seems softwire WG requirement
Suresh: as softwire chair, read this draft, but not have made up mind yet.
Ian: explain the history of the document
Bernie: Suresh to review with possible updates and then initiate WGLC on
*** DHCPv6 Failover Update
Kim talking about DHCPv6 failover update
*** DHCP Privacy Considerations
Tomek talking about DHCP privacy considerations
Tomek: is the WG interested in working on this?
Bernie: first step is to write a document
Ted: useful work
Daniel Gillmor: happy to help from outside of DHC WG
Lorenzo: the work is too difficult; recommend not working on this
Daniel: if so, we should document the difficult
Francis: analysis first, don't jump to any solution yet
Suresh: there are spaces within DHCP to improve (The document Daniel mentioned
is RFC 6973 - Privacy Considerations for Internet Protocols)
Ted: IESG is interested in privacy, even give some hint whether using DHCP or
Lorenzo: support analysis work first, disagree analysis and solutions doing
at the same time
Mikeal Abramhamsson: SEND is hardly ever alive in practice, so please develop
Bernie: Look at RFC 6973 and 7285
Tomek: who is interested to work on it?
Suresh, Sheng, Tomek, Andrew, Daniel Gillmor, Ted raise hands
*** DHCP for Dynamic GRE Tunnel
Li Xue talking about DHCP for dynamic GRE tunnel
Bernie: question for AD, is DHC WG right place for this work?
Ted: where the requirements come from?
Li Xue: OPS open WG
Ted: need OPS AD to request this
Ian: 1. many terms in the draft makes the draft hard to understand
2. There is no standard track for GRE over IPv6
Andrew: CAPWAP may be better option
*** Support for Multiple Provisioning Domains in DHCPv6
Suresh talking about support for multiple provisioning domains in DHCPv6
Suresh: it is an ongoing work in MIF WG
Ian: DHCPv6 relay agent supporting OPTION_PVD_ID would be useful