Minutes IETF98: dhc
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes IETF98: dhc|
|Other versions||plain text|
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)
Based on Etherpad Minutes recorded by Ian Farrer. Prepared by Bernie Volz.
1. Co-Chairs - Administrativa (Agenda Bashing, WG Status, ...) - 10 min
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
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
TL - Can I ask you to expand the acronyms?
SFF - Service Function Forwarder
SF - service Function
NSH - Network Service Header
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.
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
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
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
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?
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
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)
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
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