IETF 118 DHC WG Agenda

Date: Wednesday, November 8, 2023, 13:00 - 14:00, Wed Session II  
Location: Bohemia 1/2/3

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

Agenda:  
Welcome, Agenda Review and Status Update – 5 mins

Tim went over note well, asked for note taker (Bernie Volz will do),
agenda review and current WG status.

Tim Winters  
DHCPv6 (RFC 8415) to Internet Standard – 5 mins  
Tim Winters  
https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc8415bis/  
In WGLC, ends November 20, 2023 17:00 EST

Bernie updated the group on the current status - authors are hopeful
that this finishes this work and we can send it off to IESG.

Registering Self-generated IPv6 Addresses using DHCPv6 – 20 mins  
Jen Linkova  
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/

Jen presented the slides.

Jen reviewed changes since IETF-117 (5 new versions). During WGLC, there
was a concern about excessive multicast (i.e., in networks that don't
make use of registration notification). Added new
Information-request/Request exchange to have client determine whether
network (servers) support registration in -05 to address WGLC concerns;
if so, mechanism (as per -04) is then used. Discussed why this mechanism
was chosen as to others that were proposed during WGLC (such as send
registration in Information-request itself).

Jen also discussed the registration refresh goals and mechanism as this
was a change since IETF-117.

Next steps? Some text cleanup needed, cleanup option names and IANA
review - looking for other comments. Then we need to do a WGLC.

Bernie raised comment that if multiple servers configured differently,
it will be random what clients do depending on which Reply they receive
first (as it is unlikely that clients would process "all" replies).

Tim Chown asked about PD per host and how this interacts - would host
act as a relay for "downstream" clients? Lorenzo, Tim, and Jen discussed
some and perhaps some tweaks in the document are needed (such as what
does address appropriate for the link mean). Tim Winters suggested to
leave it a bit vague to allow for more work on this in the future.

Markus Stenberg commented on chat: "If I'm given /64 (e.g. via PD), it
feels bit weird to need to talk to someone about every IPv6 within it if
I'm fronting bunch of other nodes (or have containers with lively
networking life). Any auditing or whatever should be really for the /64
and not the /128s within."

Mobile Subscription Info in DHCP and Router Advertisement - 15 mins  
Yiu Lee  
https://datatracker.ietf.org/doc/draft-muthusamy-dhc-mobile-sub-info/

Saravanan Muthusamy presented the slides.

Problem statement is how to provide mobile subscription information to
allow device to connect to service provider's WiFi network. Add a new
option that is requested by client and server would return option with
URL (server may also send without client requesting); client then
exchanges subscription inforamtion via HTTPS. Options defined for both
DHCPv4 and DHCPv6, as well as Router Adveristment. This design is based
on Captive-Portal model.

Lorenzo asked about how client knows when to ask for this - client
should likely always request option.

Lorenzo asked about multiple provision domains and whether this should
go into PVD information for RAs.

Eric Vyncke asked about why not send in ethernet layer 2 beacon
messages?

Missed two speakers at mic.  
Piotr Zadroga: the section 2.1 missing what should the DHCPv6 client do.

Bernie asked about where this work should be done as for DHC WG it is
very standard "data" option (requested in ORO/PRL and server sends if
configured). Should this be done in 6man? Or?

Layer 2 Relay Agents in Cellular Fronthaul   
Networks – 10 mins  
Claudio Porfiri  
https://datatracker.ietf.org/doc/draft-porfiri-dhc-dhcpv4-l2ra-fronthaul/

Claudio presented the slides. Presented problem case - for DHCPv6, LDRA
works pretty well to discover topology but there is no good solution for
DHCPv4. Objective of draft is to introduce mechanism to provide for
hierarchy of Relay Agents (as for DHCPv6).

Eric Vyncke - wonders whether DHCPv4 is the proper protocol to do this?
For example, if layer 2 network there is a spanning tree and why not
access that information? Claudio responds that there is no way to
identify a "cable". Suresh understands the problem and that it works
well for DHCPv6; there was a draft long ago about LRA and is not clear
why work was abandoned. Suresh sees that we could restart that work?
Claudio says they only need subset of what that work covered? Also
discussion about why not move to v6 instead?

David Lampster ...

Jari Arkko -

Eric Vyncke suggested LLDP tables might be a way to obtain this
information. Claudio agrees there may be different ways to do this, but
is here to see if old DHCPv4 work could be used as DHCPv6 has worked
well to accomplish this.

Next Steps and Wrap Up (WG Chairs w/AD Support) – 5 mins