Minutes for DHC at IETF-89

Meeting Minutes Dynamic Host Configuration (dhc) WG
Title Minutes for DHC at IETF-89
State Active
Other versions plain text
Last updated 2014-04-11

Meeting Minutes

   Minutes for DHC WG at IETF-89 (London), March 3, 2014 0900-1130.

DHC WG met on Monday March 3 at 0900. The session was attended by 60 people and
lasted 2 hours and 32 minutes. The working group co-chairs, Tomek Mrugalski and
Bernie Volz lead the session.

The meeting materials are available at

Bernie provided a brief working group status: since IETF-88, we had one RFC
published (7083, Modification of default values of SOL_MAX_RT and INF_MAX_RT),
one I-D is in review queue, 4 I-Ds sent to AD and/or IESG.

Tomek discussed that the chairs were concerned that WGLCs receive not enough
reviews, just handful of +1s and reviewed several options

Ted: stateful issues draft is a bad one to make a policy on, you have to read
it carefully, think carefully to understand what effect it has. Comparing -
DNS-PD is straightforward. So my main concern with the way stateful issues LC
went - it was around for a while , I was WG chair when it was adopted. The
reason there was not enough response during the LC maybe because everyone who
was interested, already responded. If you went back in the history you might
find there was more support on it. So you might go back and prod the people who
had discussed it, rather than multicast.

Tomek: The LC was done for this specific version; the fact someone read it half
a year ago is useful but not enough.

Francois Dupont: Should have a review team

Tomek: We will find who is willing to review it and we will the names down.

The decision was to not start WGLC until there is enough review volunteers.

There was a brief discussion on interest and next steps for

Sheng Jiang: think it is useful work. Can volunteer to review it

Ted Lemon: I think the document is mature, though will need more work.
Definitely needs work from someone else. Ole thought it is useful?

Ole Troan: Was thinking the discussion with homenet chairs, if it makes sense.

Ted: DHC did adopt it before we changed the charter, not convinced it is in the
charter anymore. But definitely interesting in homenet, so if we find someone
to do it it is off DHC plate

Ole: We will find someone to do it.

Next, Tomek gave a status update for the DHCPv6bis design team work. Good
progress but slow process. Team published an XML2RFC version of 3315 as
draft-dhcwg-dhc-rfc3315bis-00 which will server as baseline. Also team produced
xml of 3363. Tomek re-iterated that the stateful issues draft constitutes quite
a few items on the tracker and is important for this work. Tomek announced that
the design team will meet on Wednesday, March 5 at 1400-1600 in the Praed Room.

Tomek's second presentation was about DHCPv6 Failover. The failover-design
draft reached AD review, but was essentially rejected. Authors and AD decided
to split it into trimmed down failover-design (info) and failover-spec (std)

Tomek then presented on draft-ietf-dhc-topo-conf-01 and asked whether the WG
should pursue this work. 10 people expressed interest, no one suggested it
should be dropped. The chairs asked for volunteers to review this work. The
following agreed to review the existing version and send comments to the
mailing list: Tomek, Simon Perreault, Andre Kostur (via jabber), Sheng Jiang,
Cong Liu, Suresh Krishnan, and Bernie Volz.

The plan is after a revision, it will be last called.

Sheng Jiang presented draft-ietf-dhc-sedhcpv6-01 and believes it is ready for

Michael Richardson: Is that appropriate for the server that does not support
leap of faith to return its size of the faith list zero.

Sheng: Yes, we can just say "return nothing" but that means the client has  to
wait for a while.

Martin Shuravski: I read the draft a couple of times, was not immediately clear
what we were auth issues in 3315 that this addresses; would be useful to have a
session with the issues from 3315, and a section referring to that saying "this
proposal addresses this issue, etc." Some more clarification would be  useful.
Section 3 tells a lot about ability to dynamically exchange the keys so you do
not have to manually configure every host, but it does not give enough though
to security issues.

Another: Does it give a thought if the client supports this mechanism and the
server does not - and does this have any implications for the client?

Sheng: Yes, server may still choose to process in the unsecured way.

Ted Lemon: This is the same question as I was asking yesterday - about the
applicability statement; is to state "this is where it is used" and later "this
is how it is used" re. faith model - it might be good to have an error code -
"I’m am not accepting the cert", "I am not willing to accept the certificate
but you can try another", and "i am not willing to accept any of your

Another thing you could do: If the server has a record of the client id and the
key it could propose the key to use.

Bernie: It would be a security issue.

Ted: It’s not gonna send the key, it will send the name of the key. Probably it
is not a big issue if sending the name.

Francis dupont: Is there any IPR about this proposal? There is one for the
first draft.

Sheng: No there is no IPR as far as I know.

Conclusion: The next version to be written and reviewed, then might be ready
for LC. 6 volunteers signed up for review, so chairs will go ahead with WGLC

The reviewers were: Marcin Siodelski, Suresh Krishnan, Ted Lemon, Michael
Richardson, Tomek Mrugalski, and Qi Sun.

Bernie presented on DHCPv6 Load Balancing for Andre Kostur. Work has been
resume after spending more than a year in limbo. There was WGLC over a year
ago, but there were several comments, so updated rev was published on Monday.
We have 4 volunteers for review: Sheng Jiang, Andrew Yourtchenko, Bernie Volz,
Tomek Mrugalski. That's less than chairs would like to have, but since this
draft has been around for a long time and is very similar to its
v4-counterpart, it is enough and we'll go with another WGLC.

Then, Bernie presented on the stateful issues draft. This draft fixes several
important snags in stateful DHCPv6. Since those changes would affect everyone,
chairs felt that the bar is set higher than for average draft. There was very
few reviews and only a handful +1s during WGLC, so chairs decided to fail it.
This appears to made an impact as 8 people promised to do the review. That
should be more than enough to pass a new WGLC once chairs announce one. The
volunteers were: Tim Winters, Marcin Siodelski, Cong Liu, Sheng Jiang, Suresh
Krishnan, Jason Weil, John Brzozowski, and JINMEI, Tatuya,

Timothy Winters: I posted about the client issue if NA got declined what we do
with PD. This is important for the CPEs, so having some clarification with this
document is helpful.

JJB: Would like to see sooner. As the deployments continue, we will see
dhcp-related issues related to other environments. Question about the document
itself: is the goals documenting awareness and then rolling in the changes ?

Bernie: The goal is to document what changes should occur in 3315. The doc says
"replace x text with y text" and gives the rationale. But it only does it in
3315 context, which makes it hard to make it explicit about NA/PD because PD
does not exist in 3315. Maybe it makes sense to say "here is how it should
work" as opposed to having the text.

JJB: Would be happy to help out.

Sheng presented on Stateless reconfiguration (individual submission). There are
some improvements since last meeting, but it is still not clear whether the WG
is willing to work on it. The work will continue as individual for now.

Bernie: you’re proposing multicast - it may be problematic… also the
registration - maybe some registration that might happen to either use
multicast or not. Maybe think about some of those ways.

Ted Lemon: Couple of things.
1) Multicast is not as big as you making it up to be, we would not expect it
too much. This is more of an exceptional situation. 2) Objection I heard here
that was most plausible: "you need to add this to the clients". Given the
existence of the IRT, this is very fine polish.  Generally speaking, network
administrator does not have to make emergency changes. They can keep it running
for the IRT period, and that’s why we did IRT. I think there is maybe value in
the particular case for the cable modem?

Sheng: One, yes, emergency change may not be worth. But to correct the error
configuration earlier. If you set up the initial parameters wrong.

Ted: Rogue server model brings up the security model. Then the clients need to
figure the trust model. And the amount of security is substantial. The client
needs to preconfigured with the key or have done with a key, so this is a whole
sequence of events that needs to happen in order to create this situation.

Andrew: Clear the O flag, then reset it again. Maybe worth discussing this kind
of behaviour.

Lorenzo: The mechanism is not reliable because it relies on the hosts getting
updated; also for the DNS server info is in the RA already.

Sheng: I can’t answer your question, maybe we should take to the list.

Lorenzo: If we do not remember the use cases maybe we should not be doing this.

Michael: If we go with the multicast, then SAVI group needs to be informed.

Bernie: It's an individual submission.

Yusuke DOI: We have a use case - it’s about LLN (?) - it’s for the mesh network
nodes. We have a network security mechanism based on (?PANA?) we can distribute
pre shared keys to make the trust management. So, we think this draft fits our
mesh network-based use case.

Lorenzo: I forgot to ask - the security model is null - right ? in the stateful
case you need to update the nonse, and in case some random server shows up then
they can not reconfigure. So you can silently update the hosts with null config
an they are gone.

Sheng: My fault, last IETF we agreed to use PKI-based, and I forgot to update

Lorenzo: We should say that the mechanism MUST be secured.

Sheng: Maybe too strong, maybe there is a security underneath.

Ted: It triggers a denial of service attack.

Then, the Customer Edge Router ID option was presented by Michael Kloberdans.
It's a proposal that overlaps Homenet, HIPNET and generic CPE deployment. The
draft has some DHCP issues (tries to do auth by itself, rather than using
standard auth option or reusing secure-dhcpv6 being developed). The AD will
follow up to determine the best place for this work to proceed.

There were several issues raised on the CER draft:
- Why authentication as part of this option and how does this relate to
standard DHCPv6 AUTH support? (Ted and Marcin raised this issue). - How to
handle multiple edge routers (Michael & Ted)? - What is CER ID used for and
what is the scope for this; all routers? (Mark Townsley)

Daniel Migault presented on the Homenet Naming DHCP Options draft. It is
intended for Homenet WG, so it was presented in DHC as info only. Several
DHCP-specific comments were provided: - Use either address or FQDN (Ted). -
Lorenzo raised some issues regarding zone transfers. - There was a discussion
on TSIG / SIG(0) security.

A new draft about dynamic Allocation of shared IPv4 address was presented by Qi
Sun. This is DHC-specific part of the solution. It is expected to be reused by
other solutions being developed in Softwires. The room was inclined to adopt
that work. Will do adoption call on the mailing list soon. This document
extends RFC 2131.

DHCPv4 over DHCPv6 source address option is an extension to the
DHCPv4-over-DHCPV6 solution that is sent to IESG. This is a very fresh
proposal, there was not enough time for thorough discussion and no discussion
on ML, so this topic will be discussed further.

The last 4 minutes presentation was delivered by Tsinghua University, which
implemented DHCPv4-over-DHCPv6 server and client. It is a nice data point for
the draft that is awaiting IESG review now.

These minutes were compiled by Bernie Volz from his own notes, those taken by
Andrew Yourtchenko, and the INTAREA Wiki summary written by Tomek Mrugalski.
Thanks much to both Andrew and Tomek for what they provided.