Minutes for DHC at IETF-94
minutes-94-dhc-2

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, ...) -
    5 minutes
    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
    route).

 2. YANG Data Model for DHCPv6 Configuration, Linhui Sun - 15 minutes
    draft-ietf-dhc-dhcpv6-yang
    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
    network.
    Linhui: prefer not to include this feature, because it is a
    general model
    Sheng Jiang: You should cover all deployment scenarios, including
    carrier network.
    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
    this model.
    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
    draft-gandhewar-dhc-v6-relay-initiated-release
    draft-gandhewar-dhc-relay-initiated-release
    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
    acceptable.

 4. Moving forward on Secure DHCPv6, Tomek Mrugalski (intro), Lishan
     Li (main presentation) - 30 minutes
    draft-ietf-dhc-sedhcpv6
    draft-li-dhc-secure-dhcpv6-deployment
    draft-cui-dhc-dhcpv6-encryption
    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
    the issues.
    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'
    comment)
    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
    problem
    Bernie: there should be solution on this. Same way applies to
    Confirm.
    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
    draft-ietf-dhc-dhcpv6-agentopt-delegate)
    Randy: if the client has not given the relay sufficient credential
    to revoke, and the client gone to Mexico, you're not going
    anywhere.
    John Brzozowski: I see no strong reason to deploy this in cable
    network.
    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
    refining draft-li-dhc-secure-dhcpv6-deployment.

    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
    call.

 5. DHCPv6 Failover Update, Bernie Volz - 10 minutes
    draft-ietf-dhc-dhcpv6-failover-protocol
    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
    draft-cui-dhc-dhcpv6-prefix-length-hint-issue
    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
    request.
    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
    draft-ietf-dhc-rfc3315bis
    16:50 - 17:05 (expected time) started 17:04

    Client Option Handling
    Ian: client behavior is unpredictable now, good to have this
    defined.
    Ted: it sounds Ian has data on this, would be great if you could
    share it.

    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 -
    10 minutes
    draft-fang-dhc-dhcpv4-forcerenew-extensions
    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.