DHC WG Minutes for IETF-98 (Chicago, IL USA) Date: Thursday, March 30, 2017, 17:40-18:40 CDT Location: Montreux 3 Chairs: Tomek Mrugalski (TM) & Bernie Volz (BV) Secretary: vacant Based on Etherpad Minutes recorded by Ian Farrer. Prepared by Bernie Volz. 1. Co-Chairs - Administrativa (Agenda Bashing, WG Status, ...) - 10 min draft-ietf-dhc-rfc3315bis-07 Presentation Ted Lemmon (TL) - Sounds like you're saying relay agents should filter any packets they don't know BV - No quite the opposite. They should not forward 2 message types TL - Is there any values? BV - That's the question TL - Sounds like a new req. with no value BV - May be best to be silent about it TL - Or you could say may discard Francis Dupont (FD) - This morning we discussed a new use for PD in 6man. I would like someone to check with 6man that we don't need to change PD for use in this next context. BV - That work's going to be interesting. Maybe they shouldn't call it PD as it's not the same FD - As it's not traditional PD, they open the door for problems Tim Winters (TW) - I agree we should talk about it. There's things we can do to clear it up or we can chase it up and go read all the drafts. We're open to making changes. BV - And you're on the 3315-bis team Suresh Krishnan (SK) - Keep me posted. I want to be involved Eric Kline (EK) - Were there changes to make it work on hosts BV - There were some changes made to the wording to make it work on hosts so that non-router devices could do PD EK - PIO-X and PD could exist at the same time Fred Templin (FT) - I've been doing PD to hosts for 2 years it works great, but to make it secure you need the stuff we're about to talk about (secure dhcp) 2. Discussion of seDHCPv6 and RAAN - Chairs - 10 min draft-ietf-dhc-sedhcpv6 (discussion of WGLC issues) draft-ietf-dhc-dhcpv6-agentopt-delegate (resume work on this document?) TL - I think we should do a 05 version as a WG doc FT - I agree with TL BV - Any objections? No objections raised Actions: seDHCPv6 will likely not pass WGLC as there were several issues raised. The RAAN draft should be published (with motivation for why this work is now important (seDHCPv6). 3. DHCP option for NSH in SFP, Venkata Subba Rao Gorrepati (VSRG) - 10 min draft-ypal-sfc-dhcp-option-for-nsh-for-sfp Slide 2 TL - Can I ask you to expand the acronyms? SFF - Service Function Forwarder SF - service Function NSH - Network Service Header Slide 3 BV - We are just seeing this to evaluate the DHCP. The technology is being developed in the SFC WG SK - I agree with you Bernie. Slide 4 TL - Can you tell me what the reserved field is for VSRG - In case we need it in the future TL - If you need a new structure in the future, wouldn't you just define a new DHCP option format VSRG - We'll check it in the next version Slide 6 XF - I recall there's a WG document for control plane that says the control plane sets up the forwarding. What's the relationship/ This SFP control plane is not standardized. We don't want to put control plane into the data plane. TM - How big is the SFP info that will be sent? VSRG - The service point information. TM - 20 bytes, 50? 100? VSRG - Yes. It depends on how many nodes there are TM - The biggest option in DHCPv4 can be 255 bytes BV - Not correct, we can use concatenation (see RFC 3396) TM - True, but if you have to use it you might have other problems Actions: The Service Function Chaining (SFC) WG should take on this work, notifying DHC when there are significant changes/WGLC. 4. DHCP v4 YANG update, Gang Yan (GY) - 10 min draft-liu-dhc-dhcp-yang-model Ian Farrer (IF) - Have you modelled all of the options which are available? We had a lot of discussion about this for the DHCPv6 YANG draft and have modelled all of the current options. It would make sense to align. GY - We can talk offline TM - I don't think you need to worry too much about new messages in DHCPv4! BV - Should we adopt or leave as an individual submission? No comments BV - We'll leave it as an individual submission for now Actions: None. The authors are encouraged to continue this work (and follow up on the options issue per the DHCPv6 Yang model). The WG will continue to focus on the DHCPv6 Yang model for now. 5. Multi-requirement Extensions for DHCPv6, Lin He (LH) - 10 min draft-ren-dhc-mredhcpv6-00 Jinmei Tatya (JT) - About slide 4 - This is not the main issue but to clarify, I don't think NS messages are forwarded by routers. It's a single link protocol. If you're saying that DAD is not very scalable, that's probably true though. EK - Broadly, I think this is a bad idea for the RAs. If you're using SLAAC then you don't have any business telling people how to create an address. Also, you need to take it to 6man The ND exhaustion attack should be solved at L3 EK - I also wanted to say that client's with autoconfigured address could register it. It was suggested by SK and was shot down by BV saying that DHCP is not a logging protocol. SK - I wrote that draft. You would use some kind of logging protocol - if you're going to register your DNS name, you can register your address. You need to take it to 6man. I think the DHCP part of this is suspect. Actions: None. If this work continues, it would require taking it to 6man and perhaps other WGs. And additional presentation was added to the agenda: 6. DHCPv6 Options for Discovery of NAT64, Jordi Palet (JP) draft-li-intarea-nat64-prefix-dhcp-option-01 EK - Personally, I think if you've reached this point, have you designed the network wrong? It seems complicated and obscure. JP - We see this as being necessary in many different scenarios. I think this way is simpler EK - Is there a document describing how you've solved these problems? JP - Workarounds for 3-5000 customers, but for bigger networks, it won't scale. EK - If you need all this NAT64, you're not moving away from v4 Simon Perrault (SP) - We already have a NAT64 discovery mechanism. Why doesn't that work? JP - Slide 2 - It's for different v4 destinations. It's in the draft. Actions: None. This was informational as this work is being done in the IntArea WG.