IETF 120

Date: TUESDAY, July 23, 2022, 17:30 - 18:30, Tuesday Session IV
Location: Regency A/B

Chairs:

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

1. Welcome

Welcome, Agenda Review and Status Update (WG Chair) -- 10 mins

2. DHCPv6 - RFC 8415 to Internet Standard -- 15 mins

    Tim Winters
    https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/
    Completed, WGLC

3. DHCPv4 over DHCPv6 Relay - 15 mins

    Claudio Porfiri
    https://datatracker.ietf.org/doc/draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra/

Next Steps and Wrap Up(WG Chairs w/AD Support) -- 10 mins

Tim has started the meeting. And asking for notetakers (Bernie and Tomek).

Presented agenda and DHC WG document status. 2 WG docs, 5 related in
other WGs.

DHCPv6 - RFC 8415bis - Advancing to Internet Standard

Tim presenting

05 recently published with 2 changes - clarified UDP (source) port usage
and removed text saying IA Address option must only be in IA_NA
(leasequery and address notification use it differently).

Plan is to ship this on to request publication (to IESG) in two weeks.

No comments raised. Suresh is still willing to be document shepherd.

DHCPv4 over DHCPv6 Relay presented by Claudio Porfiri (from Italy, early morning)

New requirement coming from OpenRAN. Ideally want hierarchy of Relay
Agents like DHCPv6 for DHCPv4; also there is no Layer 2 Relay Agent in
DHCPv4.

Would like to use DHCPv4 over DHCPv6 (DHCP4o6 - RFC7341). But
implementing this at the client is a problem in this network (lots of
vendors for the clients). So, want DHCP4o6 in the Relay Agents (thus
clients do not need to change).

RFC7969 has some information related to this use case and may be
referenced instead of the more complex RAN model.

David Lamparter: Question about diagram. Claudio clarified the server is
supposed to be DHCP4o6, not plain DHCPv4.

David: As a someone who will probably implement this, I think it's fine.

Bernie Volz: You should be cautious about the DHCPv4 renewals going back
directly to the DHCPv4 server, bypassing relays. We have server-override
and other methods to mitigate this problem.

Bernie: You should do one or two revs before doing adoption call.

Tim: Agree with Bernie.

Suresh Krishnan: If all the open issues are resolved, can we do adoption
call in the next rev?

Tim: The RAN use case is confusing, draft would be clearer without it.
But doesn't have strong opinion on this.

Mirja Kühlewind: I'd prefer to move the RAN case to an appendix.

Bernie: Agree.

Michael Richardson: I just didn't understand the RAN case, but it
doesn't mean it should be removed. Clearer after presentation and
discussion.

Tim wrapping up. Two weeks for (very) last comments for 8415bis.

Eric Vyncke: The plan was to close DHC after 8415bis is published, but
since there's more work coming, will keep DHC open for couple more IETFs
and then will see.

David Lamparter: Please don't close DHC as there may be options coming.

Josh Cohen:

• Raised security
• Option (v4) 254 for wpad? Never registered with IANA
• Are v4 and v6 option spaces common or separate?

Bernie: explaining the v4 and v6 option spaces are independent. v6 space
is cleaner. Security is a tough problem to solve.

Tim: Authenticating is a separate problem from preventing rogue servers
to appear. DHCPGuard mentioned.

Bernie: SAVI is another mechanism.

Thanks to primarily Tomek for these notes.