DHC IETF'94 Meeting minutes (DRAFT) The DHC WG met on Thursday (2015-11-05) for 2 hours in Yokohama. 1. Co-Chairs - Administrivia (Agenda Bashing, WG Status, ...) - 5 minutes 15:20 - 15:25 (expected time) +2mins over Tomek Mrugalski summarized the DHCP Hackathon. This time we worked on DHCP4o6 implementations. There were three implementations (1 server - Kea) and two clients (wide-dhcpv6 and DT's client, which as in Germany). We managed to interoperate wide-dhcpv6 with kea. We tried to do the same with the remote client, but encountered problems (response packet was dropped by a firewall somewhere en route). 2. YANG Data Model for DHCPv6 Configuration, Linhui Sun - 15 minutes draft-ietf-dhc-dhcpv6-yang 15:25 - 15:40 (expected time) -1min Linhui presented the major changes since last meeting. Bing Liu: relay server group is an important feature in carrier network. Linhui: prefer not to include this feature, because it is a general model Sheng Jiang: You should cover all deployment scenarios, including carrier network. Linhui: I think this is something vendor-specific? Sheng: no, not vendor specific; its carrier specific Bing: two approaches, one is to include all possible features, the other is to only include the features among different scenarios, either works for me. Ian Farrer: next slide, the generic options can fulfill Bing's comments of customized option? Bing: need to examine it later Bernie Volz: It is helpful to include the intended coverage of this model. Ian: prefer to consider CPE requirements, then scale-up to carrier, rather than scaling-down. Ted Lemon: I need to look at the Nominum implementation. Marcin Siodelski: I did review it and sent to the list, partial review, will continue reviewing it. Next steps/chairs' comments: Authors will continue working on I-D. Reviewers are requested to deliver on their promises. 3. Relay Initiated Release, Sunil M Gandhewar - 15 minutes draft-gandhewar-dhc-v6-relay-initiated-release draft-gandhewar-dhc-relay-initiated-release 15:40 - 15:55 (expected time) finished ~16:05 Chris Huitema: do you have stats of user sessions? Sunil: do not have data of how much time the subscriber remains, only have some SP stats data as in early slides Chris: according to your goal, I'd like to see stats of how long the subscribers stay. Sunil: some SP have a keep-alive mechanism to check the clients are there or not. Suresh Krishnan: to Chris: it's not about how long the clients keep the lease. Some use cases e.g. CPE is replaced. Ted: what's the possibility of this issue? Are the devices updatable or not? Keep-alive is needed. Chris: this is not really relevant to relay. Ted: the draft should specific the client behavior. Bernie: the motivation here is misbehavior. Next steps/chairs' comments: This proposal is a controversial one. On one hand there are operators with significant (multi-million) deployments reporting a problem. On the other hand, the bulk of opposition is against breaking the fundamental promise of DHCP that the lease, once granted, is valid for its full duration. There was a heated discussion during the meeting, followed by side discussions afterwards. Here's the sketch of a possible way forward discussed by a few after the WG session (Sunil, Ted, Bernie, Tomek): The goal of the proposed mechanism is not to release the address per se, but to release all other resources (circuit info, routing, firewall rules, etc.) by the relays. Therefore we did discuss an alternative approach. The first relay that detects client's disconnect sends a message (let's call it ClientStateChange for now) indicating that client is now disconnected. This is sent to the next relay, which forwards it further to the next relay or to the server. The server sends back an acknowledgement of reception, but takes no other action. This will ultimately reach the original relay that sent it. All relays receiving such a message may use it to release any resources they allocated for the client. The server may take administrative actions (also release resources), but must not release the address. This is only a napkin design at this stage and needs more work. Authors are encouraged to think whether such a proposal would address their needs and send proposed text to the WG for discussion. In particular, it's useful to reach out to people who opposed previous proposal and ask whether this new one is more acceptable. 4. Moving forward on Secure DHCPv6, Tomek Mrugalski (intro), Lishan Li (main presentation) - 30 minutes draft-ietf-dhc-sedhcpv6 draft-li-dhc-secure-dhcpv6-deployment draft-cui-dhc-dhcpv6-encryption 15:55 - 16:25 (expected time) Tomek summarized the historic efforts and current status on DHCPv6 security. The conclusion of discussion before the meeting: combine encryption and authorization to be new single solution. Tomek clarified that TOFU is out of scope for now, hopefully will be pursued in future drafts. Francis Dupont: encryption only is not good. Chris: when moving around, you don't know to which dhcp server you're speaking. I'd like a deep deployment model to understand the issues. Randy Bush: one reason of NOT to do TOFU was, as the IESG review said, there is not a deployment constraint. TOFU expands the space we haven't known well. Ted: there's RFC7435 that says otherwise (as response to Francis' comment) Randy: It is even worse if no encryption and authorization at all. 16:16 - Lishan presents Secure DHCPv6 Bernie and a few guys think it is good way to forward. Marcin: rebind case should be considered. Bernie: failover, out of band, some services could do this Ted: both server on the wire use the same certificate, there'll be problem Bernie: there should be solution on this. Same way applies to Confirm. Jinmei Tatuya: this also applies to the solicit Ted: in the case of solicit, the normal selection mechanism if do info request, probably need solicit to each individual server Brian Haberman: relay should be think about. I assume there is a relationship between certain kind of messages. One example, if I get an address in the secure channel, do I expect relay messages come over secure channel? Randy: there is a clear credential issue. If the relay is releasing because the client has gone to Florida. Bernie: relay cannot get info from the encrypted messages (may require revisiting RAAN - see old draft-ietf-dhc-dhcpv6-agentopt-delegate) Randy: if the client has not given the relay sufficient credential to revoke, and the client gone to Mexico, you're not going anywhere. John Brzozowski: I see no strong reason to deploy this in cable network. Suresh: this will also break anti-spoofing DSLAM functionalities. Ted: many other scenarios such as server does not send back cert. secure DHCPv6 deployment scenarios - started around 16:35 Room favors to drop authenticated-only mode. Room favors to keep TOFU out of scope for now. Room favors to continue to refining draft-li-dhc-secure-dhcpv6-deployment. Next steps/chairs' comment: Authors of both drafts are requested to work together on the merge and publish it as dhc-sedhcpv6-09. Once the merge is done, we need to address the cases raised: how server selection and Rebind mechanism is supposed to work. Authors are also encouraged to continue working on secure-dhcpv6-deployment draft. Once you feel it is of sufficient maturity, please clearly say so and chairs will start adoption call. 5. DHCPv6 Failover Update, Bernie Volz - 10 minutes draft-ietf-dhc-dhcpv6-failover-protocol 16:25 - 16:35 (expected time), started 16:42, ended 16:52 Ted and Marcin agreed to review. Jinmei may review partially. Shawn Routhier also volunteered on jabber. Next steps/Chairs' comment: Reviewers are requested to deliver on their promise. Once their comments are addressed in upcoming revision, WGLC seems to be the next step here. If there are people willing to work on the dhc-dhcpv6-failover-design draft, they're encouraged to step forward at this time. Its current status is "replaced by dhc-dhcpv6-failover-protocol". If we don't see any volunteers, the draft will be kept that way and abandoned. 6. DHCPv6 Prefix Length hint issues, Lishan Li - 15 minutes draft-cui-dhc-dhcpv6-prefix-length-hint-issue 16:35 - 16:50 (expected time) started, 16:52 Four options were presented (slide 7 in slides-94-dhc-1.pdf) Ted: I prefer 5th option: if the server can assign a new prefix and not mention the previous prefix at all. (Comment for slide 7) Bernie: another thing Ole Troan mentioned is whether this has to be std and the conclusion was that it's more info. Macin: the use case client get a new prefix and keep the old prefix, release the old prefix. Server may reject two prefixes request. John Brzozowski: there are some operational impacts for options 2 and 4. Operationally speaking, we need to make sure that the new prefix is as close to the old one. Marcin: the presentation is better structured: problem-solution, problem-solution than the draft (problem, problem, problem, solution, solution, solution) Next steps/Chairs' comment: It seems the WG is interested in this work. Authors are requested to update their draft to address comments. Once updated version is published, it seems the document should be ready for adoption call. 7. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes draft-ietf-dhc-rfc3315bis 16:50 - 17:05 (expected time) started 17:04 Client Option Handling Ian: client behavior is unpredictable now, good to have this defined. Ted: it sounds Ian has data on this, would be great if you could share it. Release Delegated Prefix Ted: some work is relevant 6man. Next steps/Chairs' comment: The issues discussed will be sent to mailing list for further discussion on proposed actions before updating document. While number of outstanding items is getting smaller, there's still plenty of work outstanding. 22 tickets are still open, with well over 100 already closed. DHCPv6bis team will continue its work. If time permits: A. Forcerenew Reconfiguration Extensions for DHCPv4, Luyuan Fang - 10 minutes draft-fang-dhc-dhcpv4-forcerenew-extensions 17:05 - 17:15 (expected time) Unfortunately, we ran out of time. As a generic reminder, the best way to ensure you get a slot is to discuss the proposal on mailing list and request your slot early. The meeting concluded at 17:20.