DHC WG (IETF'97 Seoul) Minutes (DRAFT) ---------------------------------------- Date: Friday, 2016-11-18 11:50 Location: Park Ballroom 2, Conral Hotel, Seoul, South Korea Chairs: Bernie Volz & Tomek Mrugalski DHC WG met on Friday 2016-11-18 afternoon during IETF'97. Being the last session of the IETF meeting, the attendance was smaller than usual. 1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc -administrivia-02.pdf Chairs gave an update regarding completed (1 RFC published) and on-going (2 I-Ds sent to IESG, several WG drafts progressing). Tomek Mrugalski asked whether people find the milestones useful. Suresh Krishnan, the responsible AD, said he uses them for planning his workload and telechat agendas. The conclusion was to continue maintaining milestones. A note to draft authors: if you have an active draft, but there are no milestones defined, please review milestones defined for other drafts and propose similar ones for your draft(s). 2. lw4over6-dynamic-provisioning, Ian Farrer draft-fsc-softwire-dhcp4o6-saddr-opt Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc-dhcpv4-over -dhcpv6-source-address-option-00.pdf The first discussion led by Ian Farrer was about draft-fsc-softwire-dhcp4o6-saddr-opt, which defines an extra option for lw4over6. This work started in Softwires, but now seeks adoption in DHC. Several people in the room, including Tim Chown, Suresh and Tomek expressed support. Some support was raised on Jabber. The chairs assessed that the response was positive and will initiate adoption call after next rev is published. 3. DHCPv6bis Open Issues Discussion, Bernie Volz draft-ietf-dhc-rfc3315bis Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc -dhcpv6bis-open-issues-discussion-01.pdf The second discussion was about draft-ietf-dhc-rfc3315bis, a primary work of the WG. We had a very successful WGLC (more than 290 separate comments received). DHCPv6bis team is working through them and currently addressed around 210. Updated rev is expected around January. Several issues were brought up to the WG attention: RFC 7083 defines SOL_MAX_RT/INF_MAX_RT, but does not say what the client is supposed to do when receiving different values from different servers. Ted Lemon: good idea to take the smallest length that you hear, to avoid bad guy sending long values. Suresh: idea was to allow changes to default, including reducing traffic from it. Perhaps use default in cases of conflict? Bernie Volz: Sounds plausible. Also, when do you ever set it back to the default? RFC 7083 doesn't talk about that. Should we address that? Suresh: Do you keep track of which value comes from which server? Tomek: Implementation-specific. Tim Winters: We only see it in home gateways; most lose it when you reboot. A couple keep it forever - interesting! So might want to say something about this to avoid applying a value for ever. Suresh: Maybe should revert to default? Ted: I like Suresh's suggestion. Not likely to be a problem in typical use case; if cable modem sends a solicit, it's on the cable network, so unlikely to get a 3rd party attack is slim. So, good idea, but not a serious issue. I suggest you discard values on link state transition. Bernie: Should these options be allowed in confirm/rebind case? Maybe doesn't matter. Proposal is to use the default value if different values are received. Decision: Chairs will post this proposal to the list (see mail posted on Nov. 23rd by Bernie, respond by 2017-01-12 if necessary) The second issue was a clarification regarding multiple state machines. In principle it is possible to have multiple state machines for different IA containers on a single interface. A client could talk to several servers, each handling a different IA. This mode is technically valid, but discouraged strongly. Proposal to allow multiple independent state machines on one interface. Hence the text is a SHOULD. Bernie: Not sure we want to reword or remove. Ted: If you have servers doing PD and NA, this will mean more work. But not likely. Bernie: Agree. Decision: Chairs posted this proposal to the list (see mail posted on Nov 23rd by Bernie, respond by 2017-01-12 necessary) The third 3315bis issue was about IPSec encryption protocol. The solution proposal is to use the text from draft-ietf-dhc-relay-server-security-01. Decision: Chairs posted this proposal to the list (see mail posted on Nov 23rd by Bernie, respond by 2017-01-12 necessary) 4. What do about DHCPv4 Forcerenew Extensions, Tomek Mrugalski draft-ietf-dhc-dhcpv4-forcerenew-extensions Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc -next-steps-for-draft-ietf-dhc-dhcpv4-forcerenew-extensions-00.pdf The third presentation was done by Tomek regarding draft-ietf-dhc-dhcpv4-forcerenew-extensions, which was inactive since adoption. Authors were unresponsive and there was no interest expressed on the ML in carrying forward with DHCPv4 extension. There was no interest expressed in the room either, so pending confirmation on the mailing list, this work will be dropped. (post meeting note: Luyuan Fang, the original author, became active again. A refreshed draft was published. Please send your opinion to the ML if you're interested in this work). 5. Resurrect draft-ietf-dhc-dhcpv6-agentopt-delegate - Bernie Volz draft-ietf-dhc-dhcpv6-agentopt-delegate Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc -resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf This was first written in 2005, and adopted by WG in 2006. Last version published in 2009. Interest was lost due to: - out of order packets might cause issues - CableLabs specific and realys implemented snooping (so work was too late) But might want to avoid relay snooping as used in DHCPv4; relay should not need to look inside client's message, and security might make it impossible. Might also want to reduce complexity for relays. Design means relays no longer need to look into a client's message and are explicitly notified of server actions. Problem is Secure DHCPv6 will prevent snooping. Many ways to tackle this - one way is to resurrect this draft. Ted: I like this. Ted: Active Lease query is a good thing to do in addition to this. Bernie: Yes, could do. Suresh: Park this for now and revisit periodically. Bernie: Might be premature to do this now while Secure DHCPv6 isn't done. Suresh: Take another look in a year. Bernie: OK. The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. 6. DHC Related work in 6MAN Tim Chown asked for people to look at DHC relevant bits of RFC6434-bis work in 6man and comment there. Meeting closed at 12:34pm. This was the shortest meeting in many years.