Minutes IETF117: dhc: Tue 00:30
minutes-117-dhc-202307250030-00

IETF 117 DHC WG

Date: MONDAY, July 24, 2023, 17:30 - 18:30 PDT, Monday Session IV
Location: Plaza B

Chairs:
• Timothy Winters, QA Cafe, tim@qacafe.com
• Bernie Volz, Unaffiliated (Retired), bevolz@gmail.com (remote
participant)

Agenda
• Welcome, Agenda Review and Status Update (WG Chair) -- 5 mins
Minutes Taker: Ben Patton
• Registering Self-generated IPv6 Addresses using DHCPv6 -- 20 mins
◦ Jen Linkova
◦ https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/
• DHCPv6 - RFC 8415 to Internet Standard -- 15 mins
◦ Tim Winters
◦ https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/
• Next Steps and Wrap Up (WG Chairs w/AD Support) -- 5 mins

Welcome, Agenda Review and Status Update (Tim Winters)

• Tim presented chair slides
• Tim asked about changes / additions to agenda - none
• Tim mentioned docs to be discussed, also SRv6 locator option doc

Registering Self-generated IPv6 Addresses using DHCPv6 (Jen Linkova)

• Jen presented slides

• Bernie brought up (in relation to transaction IDs) that they are
  useful for the client in some situations

  • Matching up reply that comes for a given request
  • Jen said draft does clarify how client handles replies (matching
    transaction IDs)
  • Bernie brought up that it's not terribly useful for Servers, but
    will examine draft and give further comments later

• Tim asked if there were any known implementations

  • Lorenzo said they plan to put a client implementation together
    for this, will update the list when something is available

• Eric brought up the topic of a hackathon for this

  • Lorenzo said they can definitely come up with a basic proof of
    concept before next meeting

• Some further discussion on security considerations

  • Jen says spoofing clients might be tricky, so that might not be
    a path to go down now

  • Tim C. Also security implications of including DNS information
    in these messages (verifying client's hostname in registration?)

    • Lorenzo clarifies that the direction was "people could do
      this", but not a recommendation/requirement one way or
      another

  • More discussion on MAY/SHOULD language for accepting(?) DNS info
    from clients

• Bernie brought up using ISC Kea as a baseline implementation that
  could be extended for a proof of concept

DHCPv6 - RFC 8415 to Internet Standard (Tim Winters)

• Bernie presented slides on DHCPv6 to Internet Standard

  • Some mention from Bernie during this on RFCs that describe
    operational suggestions

• Arran brought up RFC 9096 in relation to the issue where a CPE may
  release PD prematurely

  • Suggested to re-use text from that RFC for this in 8415
  • Tim talked about other drafts related to clients that do PD, but
    will it be widely deployed?
  • Bernie suggested being careful about adding more text rather
    than referring to other informational/operational RFCs
  • More discussion to happen on list

• Arran also wonders why unicast option was deprecated. Could be a
  situation where a relay is involved and we may want to specify an
  upstream server

  • Bernie gave some context that server unicast options may not be
    widely used, and using it could cause other operational concerns
  • Arran requested more discussion for mechanisms about unicasting
    packets

• Eric asks about whether new documents that provide operational
  guidelines are informative or normative

Next Steps and Wrap Up

• Lorenzo requesting that folks take a look at v6ops draft for
  signaling PD availability on LAN

Session wrapped up at 16:10.