Minutes for DHC at IETF-94
|Meeting Minutes||Dynamic Host Configuration (dhc) WG|
|Title||Minutes for DHC at IETF-94|
|Other versions||plain text|
DHC IETF'94 Meeting minutes (DRAFT)
The DHC WG met on Thursday (2015-11-05) for 2 hours in Yokohama.
1. Co-Chairs - Administrivia (Agenda Bashing, WG Status, ...) -
15:20 - 15:25 (expected time) +2mins over
Tomek Mrugalski summarized the DHCP Hackathon. This time we worked
on DHCP4o6 implementations. There were three implementations (1
server - Kea) and two clients (wide-dhcpv6 and DT's client, which
as in Germany). We managed to interoperate wide-dhcpv6 with kea.
We tried to do the same with the remote client, but encountered
problems (response packet was dropped by a firewall somewhere en
2. YANG Data Model for DHCPv6 Configuration, Linhui Sun - 15 minutes
15:25 - 15:40 (expected time) -1min
Linhui presented the major changes since last meeting.
Bing Liu: relay server group is an important feature in carrier
Linhui: prefer not to include this feature, because it is a
Sheng Jiang: You should cover all deployment scenarios, including
Linhui: I think this is something vendor-specific?
Sheng: no, not vendor specific; its carrier specific
Bing: two approaches, one is to include all possible features, the
other is to only include the features among different scenarios,
either works for me.
Ian Farrer: next slide, the generic options can fulfill Bing's
comments of customized option?
Bing: need to examine it later
Bernie Volz: It is helpful to include the intended coverage of
Ian: prefer to consider CPE requirements, then scale-up to
carrier, rather than scaling-down.
Ted Lemon: I need to look at the Nominum implementation.
Marcin Siodelski: I did review it and sent to the list, partial
review, will continue reviewing it.
Next steps/chairs' comments: Authors will continue working on
I-D. Reviewers are requested to deliver on their promises.
3. Relay Initiated Release, Sunil M Gandhewar - 15 minutes
15:40 - 15:55 (expected time) finished ~16:05
Chris Huitema: do you have stats of user sessions?
Sunil: do not have data of how much time the subscriber remains,
only have some SP stats data as in early slides
Chris: according to your goal, I'd like to see stats of how long
the subscribers stay.
Sunil: some SP have a keep-alive mechanism to check the clients
are there or not.
Suresh Krishnan: to Chris: it's not about how long the clients
keep the lease. Some use cases e.g. CPE is replaced.
Ted: what's the possibility of this issue? Are the devices
updatable or not?
Keep-alive is needed.
Chris: this is not really relevant to relay.
Ted: the draft should specific the client behavior.
Bernie: the motivation here is misbehavior.
Next steps/chairs' comments: This proposal is a controversial one.
On one hand there are operators with significant (multi-million)
deployments reporting a problem. On the other hand, the bulk of
opposition is against breaking the fundamental promise of DHCP
that the lease, once granted, is valid for its full duration.
There was a heated discussion during the meeting, followed by
side discussions afterwards.
Here's the sketch of a possible way forward discussed by a few
after the WG session (Sunil, Ted, Bernie, Tomek):
The goal of the proposed mechanism is not to release the address
per se, but to release all other resources (circuit info, routing,
firewall rules, etc.) by the relays. Therefore we did discuss an
alternative approach. The first relay that detects client's
disconnect sends a message (let's call it ClientStateChange for
now) indicating that client is now disconnected. This is sent to
the next relay, which forwards it further to the next relay or to
the server. The server sends back an acknowledgement of reception,
but takes no other action. This will ultimately reach the original
relay that sent it. All relays receiving such a message may use it
to release any resources they allocated for the client. The server
may take administrative actions (also release resources), but must
not release the address.
This is only a napkin design at this stage and needs more work.
Authors are encouraged to think whether such a proposal would
address their needs and send proposed text to the WG for
discussion. In particular, it's useful to reach out to people who
opposed previous proposal and ask whether this new one is more
4. Moving forward on Secure DHCPv6, Tomek Mrugalski (intro), Lishan
Li (main presentation) - 30 minutes
15:55 - 16:25 (expected time)
Tomek summarized the historic efforts and current status on DHCPv6
security. The conclusion of discussion before the meeting:
combine encryption and authorization to be new single solution.
Tomek clarified that TOFU is out of scope for now, hopefully will
be pursued in future drafts.
Francis Dupont: encryption only is not good.
Chris: when moving around, you don't know to which dhcp server
you're speaking. I'd like a deep deployment model to understand
Randy Bush: one reason of NOT to do TOFU was, as the IESG review
said, there is not a deployment constraint. TOFU expands the space
we haven't known well.
Ted: there's RFC7435 that says otherwise (as response to Francis'
Randy: It is even worse if no encryption and authorization at all.
16:16 - Lishan presents Secure DHCPv6
Bernie and a few guys think it is good way to forward.
Marcin: rebind case should be considered.
Bernie: failover, out of band, some services could do this
Ted: both server on the wire use the same certificate, there'll be
Bernie: there should be solution on this. Same way applies to
Jinmei Tatuya: this also applies to the solicit
Ted: in the case of solicit, the normal selection mechanism if do
info request, probably need solicit to each individual server
Brian Haberman: relay should be think about. I assume there is a
relationship between certain kind of messages. One example, if I
get an address in the secure channel, do I expect relay messages
come over secure channel?
Randy: there is a clear credential issue. If the relay is
releasing because the client has gone to Florida.
Bernie: relay cannot get info from the encrypted messages (may
require revisiting RAAN - see old
Randy: if the client has not given the relay sufficient credential
to revoke, and the client gone to Mexico, you're not going
John Brzozowski: I see no strong reason to deploy this in cable
Suresh: this will also break anti-spoofing DSLAM functionalities.
Ted: many other scenarios such as server does not send back cert.
secure DHCPv6 deployment scenarios - started around 16:35
Room favors to drop authenticated-only mode.
Room favors to keep TOFU out of scope for now.
Room favors to continue to
Next steps/chairs' comment: Authors of both drafts are requested
to work together on the merge and publish it as dhc-sedhcpv6-09.
Once the merge is done, we need to address the cases raised: how
server selection and Rebind mechanism is supposed to work. Authors
are also encouraged to continue working on
secure-dhcpv6-deployment draft. Once you feel it is of sufficient
maturity, please clearly say so and chairs will start adoption
5. DHCPv6 Failover Update, Bernie Volz - 10 minutes
16:25 - 16:35 (expected time), started 16:42, ended 16:52
Ted and Marcin agreed to review. Jinmei may review partially.
Shawn Routhier also volunteered on jabber.
Next steps/Chairs' comment: Reviewers are requested to deliver on
their promise. Once their comments are addressed in upcoming
revision, WGLC seems to be the next step here. If there are people
willing to work on the dhc-dhcpv6-failover-design draft, they're
encouraged to step forward at this time. Its current status is
"replaced by dhc-dhcpv6-failover-protocol". If we don't see any
volunteers, the draft will be kept that way and abandoned.
6. DHCPv6 Prefix Length hint issues, Lishan Li - 15 minutes
16:35 - 16:50 (expected time) started, 16:52
Four options were presented (slide 7 in slides-94-dhc-1.pdf)
Ted: I prefer 5th option: if the server can assign a new prefix
and not mention the previous prefix at all. (Comment for slide 7)
Bernie: another thing Ole Troan mentioned is whether this has to
be std and the conclusion was that it's more info.
Macin: the use case client get a new prefix and keep the old
prefix, release the old prefix. Server may reject two prefixes
John Brzozowski: there are some operational impacts for options 2
and 4. Operationally speaking, we need to make sure that the new
prefix is as close to the old one.
Marcin: the presentation is better structured: problem-solution,
problem-solution than the draft (problem, problem, problem,
solution, solution, solution)
Next steps/Chairs' comment: It seems the WG is interested in this
work. Authors are requested to update their draft to address
comments. Once updated version is published, it seems the document
should be ready for adoption call.
7. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes
16:50 - 17:05 (expected time) started 17:04
Client Option Handling
Ian: client behavior is unpredictable now, good to have this
Ted: it sounds Ian has data on this, would be great if you could
Release Delegated Prefix
Ted: some work is relevant 6man.
Next steps/Chairs' comment: The issues discussed will be sent to
mailing list for further discussion on proposed actions before
updating document. While number of outstanding items is getting
smaller, there's still plenty of work outstanding. 22 tickets are
still open, with well over 100 already closed. DHCPv6bis team will
continue its work.
If time permits:
A. Forcerenew Reconfiguration Extensions for DHCPv4, Luyuan Fang -
17:05 - 17:15 (expected time)
Unfortunately, we ran out of time. As a generic reminder, the best
way to ensure you get a slot is to discuss the proposal on mailing
list and request your slot early.
The meeting concluded at 17:20.