Minutes IETF97: dhc

Meeting Minutes Dynamic Host Configuration (dhc) WG
Title Minutes IETF97: dhc
State Active
Other versions plain text
Last updated 2016-12-09

Meeting Minutes

    DHC WG (IETF'97 Seoul) Minutes (DRAFT)

Date: Friday, 2016-11-18 11:50
Location: Park Ballroom 2, Conral Hotel, Seoul, South Korea
Chairs: Bernie Volz & Tomek Mrugalski

DHC WG met on Friday 2016-11-18 afternoon during IETF'97. Being
the last session of the IETF meeting, the attendance was smaller
than usual.

1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...)
 Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc

Chairs gave an update regarding completed (1 RFC published) and
on-going (2 I-Ds sent to IESG, several WG drafts progressing). Tomek
Mrugalski asked whether people find the milestones useful. Suresh
Krishnan, the responsible AD, said he uses them for planning his
workload and telechat agendas. The conclusion was to continue
maintaining milestones. A note to draft authors: if you have an active
draft, but there are no milestones defined, please review milestones
defined for other drafts and propose similar ones for your draft(s).

2. lw4over6-dynamic-provisioning, Ian Farrer
    draft-fsc-softwire-dhcp4o6-saddr-opt Slides:

The first discussion led by Ian Farrer was about
draft-fsc-softwire-dhcp4o6-saddr-opt, which defines an extra option
for lw4over6. This work started in Softwires, but now seeks adoption
in DHC. Several people in the room, including Tim Chown, Suresh and
Tomek expressed support. Some support was raised on Jabber.  The
chairs assessed that the response was positive and will initiate
adoption call after next rev is published.

 3. DHCPv6bis Open Issues Discussion, Bernie Volz
    Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc

The second discussion was about draft-ietf-dhc-rfc3315bis, a primary
work of the WG. We had a very successful WGLC (more than 290 separate
comments received). DHCPv6bis team is working through them and
currently addressed around 210. Updated rev is expected around
January. Several issues were brought up to the WG attention:

RFC 7083 defines SOL_MAX_RT/INF_MAX_RT, but does not say what the
client is supposed to do when receiving different values from
different servers.

Ted Lemon: good idea to take the smallest length that you hear, to
avoid bad guy sending long values.

Suresh: idea was to allow changes to default, including reducing
traffic from it. Perhaps use default in cases of conflict?
Bernie Volz: Sounds plausible.  Also, when do you ever set it back to the
default?  RFC 7083 doesn't talk about that.  Should we address that?
Suresh: Do you keep track of which value comes from which server?
Tomek: Implementation-specific.
Tim Winters: We only see it in home gateways; most lose it when you
reboot. A couple keep it forever - interesting!  So might want to say
something about this to avoid applying a value for ever.
Suresh: Maybe should revert to default?
Ted: I like Suresh's suggestion. Not likely to be a problem in typical
use case; if cable modem sends a solicit, it's on the cable network,
so unlikely to get a 3rd party attack is slim.  So, good idea, but
not a serious issue. I suggest you discard values on link state
Bernie: Should these options be allowed in confirm/rebind case? Maybe
doesn't matter.

Proposal is to use the default value if different values are received.

Decision: Chairs will post this proposal to the list (see mail posted
on Nov. 23rd by Bernie, respond by 2017-01-12 if necessary)

The second issue was a clarification regarding multiple state
machines. In principle it is possible to have multiple state machines
for different IA containers on a single interface. A client could
talk to several servers, each handling a different IA. This mode is
technically valid, but discouraged strongly.

Proposal to allow multiple independent state machines on one
interface.  Hence the text is a SHOULD.

Bernie: Not sure we want to reword or remove.
Ted: If you have servers doing PD and NA, this will mean more
work. But not likely.
Bernie: Agree.

Decision: Chairs posted this proposal to the list (see mail posted
on Nov 23rd by Bernie, respond by 2017-01-12 necessary)

The third 3315bis issue was about IPSec encryption protocol. The
solution proposal is to use the text from

Decision: Chairs posted this proposal to the list (see mail posted
on Nov 23rd by Bernie, respond by 2017-01-12 necessary)

4. What do about DHCPv4 Forcerenew Extensions, Tomek Mrugalski
    Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc

The third presentation was done by Tomek regarding
draft-ietf-dhc-dhcpv4-forcerenew-extensions, which was inactive since
adoption. Authors were unresponsive and there was no interest
expressed on the ML in carrying forward with DHCPv4 extension. There
was no interest expressed in the room either, so pending confirmation
on the mailing list, this work will be dropped. (post meeting note:
Luyuan Fang, the original author, became active again. A refreshed
draft was published. Please send your opinion to the ML if you're
interested in this work).

 5. Resurrect draft-ietf-dhc-dhcpv6-agentopt-delegate - Bernie Volz
    Slides: https://www.ietf.org/proceedings/97/slides/slides-97-dhc

This was first written in 2005, and adopted by WG in 2006.  Last
version published in 2009.

Interest was lost due to:
 - out of order packets might cause issues
 - CableLabs specific and realys implemented snooping
   (so work was too late)
But might want to avoid relay snooping as used in DHCPv4; relay should
not need to look inside client's message, and security might make it

Might also want to reduce complexity for relays.

Design means relays no longer need to look into a client's message and
are explicitly notified of server actions. Problem is Secure DHCPv6
will prevent snooping. Many ways to tackle this - one way is to
resurrect this draft.

Ted: I like this. 
Ted: Active Lease query is a good thing to do in addition to this.
Bernie: Yes, could do.
Suresh: Park this for now and revisit periodically.
Bernie: Might be premature to do this now while Secure DHCPv6 isn't done.  
Suresh: Take another look in a year.
Bernie: OK.

The discussion gravitated towards not resurrecting until the sedhcpv6
I-D progresses further. We will reevaluate this once sedhcpv6 is done.

 6. DHC Related work in 6MAN

Tim Chown asked for people to look at DHC relevant bits of RFC6434-bis
work in 6man and comment there.

Meeting closed at 12:34pm. This was the shortest meeting in many years.