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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-0.pdf) Andrew Yourtchenko volunteered as jabber scribe. Thanks! Sheng Jiang has been assigned as DHC secretary. He will take minutes, too. WG Update: - 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-7.ppt) 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: yes Tomek talking about the Client Rate Limiting issue Sheng: server should also be able to limit the request rate from the same client Tomek talking about filling link-address Ted: more detail should be given why and how to do it, may be a separated document 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-2.pdf) 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-1.pdf) 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 Maraus: support 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-8.pptx) Tomek presenting Customizing DHCP Configuration On the basis of Network Topology 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-5.pptx) Qi Sun talking about Dynamic Allocation of Shared IPv4 Addresses Ted: is this required for lightweight 4over6? Qi: no 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 mail list *** DHCPv6 Failover Update (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-4.pdf) Kim talking about DHCPv6 failover update No comments *** DHCP Privacy Considerations (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-6.pptx) 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 not 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 something deployable 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-3.pdf) 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 (http://www.ietf.org/proceedings/90/slides/slides-90-dhc-9.ppt) 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