IETF 116 DHC WG Agenda

Date: THURSDAY, March 30, 2023, 15:00 - 16:00, Thursday Session III

Location: G412-G413

Chairs:

*   Timothy Winters, QA Cafe, tim@qacafe.com
*   Bernie Volz, Unaffiliated (Retired) , bevolz@gmail.com (unable to
    participate)

Agenda

*   Welcome, Agenda Review and Status Update (WG Chair) -- 5 mins
*   Registering Self-generated IPv6 Addresses using DHCPv6 -- 15 mins
*   Distribute SRv6 Locator by DHCP -- 10 min
*   DHCPv6 - RFC 8415 to Internet Standard -- 15 mins
*   Next Steps and Wrap Up (WG Chairs w/AD Support) -- 5 mins

Agenda bashing: no comments

## Registering Self-generated IPv6 Addresses using DHCPv6   {#registering-self-generated-ipv6-addresses-using-dhcpv6}

https://datatracker.ietf.org/doc/draft-wkumari-dhc-addr-notification/  
Lorenzo Colitti (LC) presenting.

Éric Vyncke: could the switch relay the message? Use the maintained
states in snooping table, generate a "spoofed" message and relay to DHCP
server.

Lorenzo Collitti: (... some discussion) one of the reasons was that
existing logging / information feeding mechanisms are not well-liked to
try to parse this information out of

Sheng Jiang: as a standard document, I'd like to have that possibility
\[snooping switches interacting\]. At least leave it as MAY.

Lorenzo Collitti: Switch shouldn't try to generate something, racing
against the client; would be missing options that the client wants to
add.

David Lamparter: the way this would work, the switch would add something
to messages being relayed, not generate messages on its own. But Draft
needs to say what SAVI switches are supposed to (not) do with these
packets.

Lorenzo Collitti: REPLY from DHCPv6 server is also Unicast directly to
host, unlike other situations DHCPv6 server does not know host LL
address.

Hermin Anggawijaya: Would like a per interface flag to disable this
ability on the client side, to avoid unnecessary multicast in networks
that don't care about this mechanism.

*Draft proceeding to adoption call*

(at end of session)

Lorenzo Collitti: Draft is experimental, but maybe that's the wrong
goal.

Tim Winters: Wondered the same thing.

Éric Vyncke: Would be a mistake to adopt draft as Experimental, choose
different goal and include in adoption call.

(agreement to switch to Proposed Standard)

## Distribute SRv6 Locator by DHCP   {#distribute-srv6-locator-by-dhcp}

https://datatracker.ietf.org/doc/draft-cheng-dhc-distribute-srv6-locator-by-dhcp/

Weiqiang Cheng presenting.

*No content comments*

Tim Winters: There's not a lot of extra DHC stuff here, need to talk
with SPRING chairs.

Éric Vyncke: You should request adoption in the SPRING as all DHC
options for a WG are done in their respective WGs.

Tim Winters: Agree, this is not DHCP protocol changes, SPRING is
preferable. Are there implementations/deployments?

Weiqiang Cheng: Yes, we plan to deploy it, others are planning to
implement. Have done some lab tests. Asking for next step?

Tim Winters: Next step, I'll send the email we feel it should be SPRING
I-D.

## DHCPv6 - RFC 8415 to Internet Standard   {#dhcpv6---rfc-8415-to-internet-standard}

https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/  
Tim Winters presenting.

Tim Winters: specifically asking for comments on dead references to
UseMulticast.

Lorenzo Collitti: Would be very beneficial to new implementations to
remove. Figuring out unicast is going away took some time & knowing that
it isn't around enables some use cases.

Alan DeKok: Can you add us (FreeRADIUS)?

Tim Winters: You can add yourself!

Alan DeKok: Running in production, just not officially released yet.

Tomek Mrugalski: Please update the table, and your documentation doesn't
list DHCPv6 support yet.

Alan DeKok: DHCPv6 is supported by upcoming version that's already
tested in production, will update FreeRadius docs soon.

Tim Winters: Not much left to do other than UseMulticast removal, please
read the draft and send a mail to the mailing list, even (or especially)
if it is just "Have read, looks OK."

Eric Vyncke: One thing to do before requesting publication is to do Last
Call.

## Next Steps and Wrap Up (WG Chairs w/AD Support)   {#next-steps-and-wrap-up-wg-chairs-wad-support}

Eric Vyncke: Future of the working group? My intention is to keep the
DHC WG dormant.

Tim Winters: Inclined to agree, keep it in dormant state, maybe not meet
every meeting but keep the WG around.

Lorenzo Collitti: 3 drafts on the slides; similar to 6man: "we're
around, come here if touching these things". Question of Stewardship,
but not expecting a lot of arguing about keeping DHC WG around.

Tim Winters: The difference is that to do RA option, you need to go
through 6man. For DHC, is to serve-yourself (define DHC options in your
own WG)

*some discussion going back to self generated address registration,
included above*