Minutes for DHC at IETF-96
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes for DHC at IETF-96|
|Other versions||plain text|
DHC WG (IETF-96, Berlin) Minutes
Date: Wednesday, July 20, 2016, 10:00-12:30 Wednesday Morning session I (CEST)
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
Francis Dupont: increasing numbers is a problem for clients that don't have
Ted Lemon: you can use stable storage or clock, the spec doesn't enforce one or
Bernie Volz: suggestion to extend the sequence number field to 64 bits, so we
could get millisecond resolution
3. Security of Messages Exchanged Between Servers and Relay Agents,
Bernie Volz & Yogendra Pal - 10 minutes
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
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
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
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
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
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
Marcin: I'm fine with option 2.
Suresh: we should not go with 2, because of possible conflicts. I prefer 3.
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
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
Yogendra Pal volunteered to review the draft.