DHC WG (IETF-96, Berlin) Minutes Date: Wednesday, July 20, 2016, 10:00-12:30 Wednesday Morning session I (CEST) Location: Tiergarten Chairs: Tomek Mrugalski & Bernie Volz Secretary: Sheng Jiang These minutes are based on the Etherpad notes taken by Tomek with some edits from Bernie Volz. 1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 5 minutes 2. Secure DHCPv6 and Secure DHCPv6 Deployment, Ted Lemon - 20 minutes draft-ietf-dhc-sedhcpv6 draft-li-dhc-secure-dhcpv6-deployment Francis Dupont: increasing numbers is a problem for clients that don't have stable storage Ted Lemon: you can use stable storage or clock, the spec doesn't enforce one or the other Bernie Volz: suggestion to extend the sequence number field to 64 bits, so we could get millisecond resolution Ted: agree 3. Security of Messages Exchanged Between Servers and Relay Agents, Bernie Volz & Yogendra Pal - 10 minutes draft-volz-dhc-relay-server-security Suresh Krishnan: Look at RFC4107 to see if manual keying meets requirements. Hum indicates the those in audience support adoptiong this as a working group item; adoption call to be issued on WG ML in near future. 4. Next Steps for DHCPv6 failover, Tomek Mrugalski - 10 minutes draft-ietf-dhc-dhcpv6-failover-protocol Discussion about possible choices. Marcin Siodelski promised to review the draft. Ian Farrer: we came up with a different solution to the problem, so std solution is not needed. Hum indicates the WG prefers option A: redo the WGLC (the alternatives were: B - publish as experimental (silence), C - drop the work (silence)) 5. YANG Data Model for DHCPv6 Configuration, Linhui Sun - 15 minutes draft-ietf-dhc-dhcpv6-yang Discussion about options storage and how to define it. Francis: Need way to handle new dhcpv6 options and vendor options Yopendra: do you support context (any arbitrary set of data addigned) in the model? Linhui: no Marcin: comment about option storage. It's confusing to have 3 different ways to define options. We have option defintion in Kea and option values that use those definitions. Ian: the reason why we did 7227 options is because this was the recommendation of the WG last time. Yogendra: Raised question about context - will follow up on mailing list Alex Pertrescu: asking if the model was developed from scratch or from MIB. Suresh: There's a draft draft-ietf-netmod-opstate-reqs-04, you should look at. 6. DHCPv6 Prefix Length Hint Issues, Linhui Sun - 10 minutes draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Marcin: Slide 6 "must neglect" doesn't consider RFC7550 (Stateful Issues) if addresses also requested and provided by server. Ian: need to clarify the behavior of a client that needs exactly the prefix it hinted and any other prefix is not good enough. (The text on slide 3 is oddly worded and should reflect server's granting or not granting the client's requested delegated prefix.) Suresh: Is "SHOULD include" appropriate? Why not "MUST include"? 7. Generalize Client UDP Port Number of DHCP Relay, Naiming Shen - 10 minutes draft-shen-dhc-client-port Francis: as a reviewer of the code I confirm using source and destination ports is a nightmare. Ian: the number of packets in avergage network I saw is couple to tens of thousands, given the lease of a day this gives you couple packets per second. Do you really need many processes? Naiming: we have the WLAN controller that handles many APs. Marcin: the draft says it can run on any port, Normen Kowalewski: if there's a load balancer, you can split across ports or addresses. Is there a rationale for one over the other? Bernie: from my perspective, in IPv6 it's not a big deal, but in IPv4 it may be. (unknown):If you take a look at the average unix application, it doesn't ncessarily care about its source port, just the destination, so the returning packet is a problem. Bernie: do people think this is useful and whether we should adopt it. Not so strong hum for adoption support, silence for against adoption. 8. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes draft-ietf-dhc-rfc3315bis Issue #162 Marcin: I'm fine with option 2. Suresh: we should not go with 2, because of possible conflicts. I prefer 3. Consensus determination: DUID-LL humm (dead silence) Remove the restriction (some humm, but not very strong) Don't do anything (loud humm) #166 - text to update RFC 3315 in draft-ietf-6man-default-iids-13: Suresh: I don't like the replacement text. Brian: the draft being referenced in the replacement text. It uses the parameters based on something that has to be stable. The concern I have is that the server would have to keep it. The concern was that this draft brought comments about overspecifying what DHCP implementors do. I would prefer "these are the characteristics your allocation should follow (full stop)". Suresh: start with the current text and add references to RFC7136? The RFC5453 is two generations old. #167 - Use the term "Client" rather than "requesting router" from Lorenzo's email to WG: Ian: Relays glean the PD and do route injection. This is something that is not mentioned at all. Bernie: we discussed that during pre-meeting, and thought that maybe mentioning that the problem of route injection may appear and there are solutions that snoop the prefix from passing traffic. This will become more complicated if/when the sedhcpv6 is deployed. Marcin: if we decide to move delegating router => client, this will also affect the prefix-length-issue draft. Alex Petrescu: There's a draft already about relay-insertion-draft (https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem). Yogendra Pal volunteered to review the draft.