# DHC IETf 115 {#dhc-ietf-115} Date: TUESDAY, November 8, 2022, 15:00 - 16:00, Tuesday Session IV Location: Mezzanine 10-11 Chairs: * Timothy Winters, QA Cafe, tim@qacafe.com * Bernie Volz, Unaffiliated (Retired) , bevolz@gmail.com (unable to participate) # Agenda {#agenda} ## Welcome, Agenda Review and Status Update (WG Chair) -- 10 mins {#welcome-agenda-review-and-status-update-wg-chair--10-mins} ## DHCPv6 - RFC 8415 to Internet Standard -- 15 mins {#dhcpv6---rfc-8415-to-internet-standard--15-mins} Tim Winters https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc8415bis/ ## Call for Working Group Adoption {#call-for-working-group-adoption} ### Distribute SRv6 Locator by DHCP -- 10 min {#distribute-srv6-locator-by-dhcp--10-min} Weiqiang Cheng/Yuanxiang Qiu https://datatracker.ietf.org/doc/draft-cheng-dhc-distribute-srv6-locator-by-dhcp/ ### Registering Self-generated IPv6 Addresses using DHCPv6 -- 10 mins {#registering-self-generated-ipv6-addresses-using-dhcpv6--10-mins} Jen Linkova https://datatracker.ietf.org/doc/draft-wkumari-dhc-addr-notification/ Next Steps and Wrap Up(WG Chairs w/AD Support) -- 10 mins # Minutes {#minutes} ## Advancing DHCPv6 to full Internet standard {#advancing-dhcpv6-to-full-internet-standard} * Independent Implementation Status * several exist (see slides) * some feedback from IANA to incorporate * WGLC reviews wanted by Feb 2023 * in time for March IETF 116 in Yokohama * Suresh Krishnan volunteers to be shepherd * Updates from Philadelphia * errata closed * IA\_TA removed * Server Unicast remoed * referenced [RFC 7943][1] * Questions for -01 * should we reduce background material? * should we remove all text related to unicast transmission? * should we deprecate `UseMulticast` status code? * Working Group Adoption * email your position on this document! (support, not support, *other?*) * review, review, review *please* ## SRv6 Locator option {#srv6-locator-option} * 50k+ CPEs in some SRv6 domains within telecom IP networks * CPEs can move attachment, but without a mobility protocol * Proposal * DHCPv6 allocate SRv6 prefix, similar to PD * SRv6 SID format * Locator, Function, Args * `IA_SRV6_LOCATOR` option * options define Locator length, Function length, Args length, ... * functions similar to PD * BRAS can allocate to CPE * BRAS can relay to a DHCPv6 server and snoop reply * next steps * seeking feedback from DHC and from SPRING * Questions * \[Tim\] have you presented at SPRING * \[Weiqiang\] have not presented at SPRING yet * \[Tim\] definitely need some coordination and interest from SPRING * \[Tim\] how should a client handle multiple prefixes in a reply? some text would be good * \[Weiqiang\] ack * \[Weiqiang\] SPRING may not be interested in this draft -- it more for operators * \[Eric Vyncke\] important to get interest and support for this from SPRING and SPRING chairs * \[Weiqiang\] ack ## DHC Address Registration {#dhc-address-registration} * new message to inform server of non-DHCPv6-assigned addresses * [RFC 4862][2] SLAAC * statically assigned * changes: address feedback from the list * message `MUST` be sent from the address registered * FCFS SAVI -using networks can do some extra validation here * message `MUST` be sent from the interface on which the address is configured * `MUST NOT` be sent for DHCPv6-configured addresses * server can assess if "the address is not appropriate for the link" * TBD: server `SHOULD` or `MAY` mark the address an allocated * retransmit behavior * no ACK from the server * refresh messages sent at `min(4 hours, 1/3 value PIO lifetime)` * proposal: * use DHCPv6-standard backoff (IRT, MRT, MRC, MRD) * not in the current draft version * next steps * rename "registration" to "inform" * adotion call? * discussion * \[Éric Levy-Abegnoli\] if you want to inform DHCP just use DHCP * \[Jen\] only inform about valid global addresses * \[É L-A\] if we do this, consider the implications of multicast on Wi-Fi * \[Lorenzo\] the DHCP server had better not be on WiFi, so multicast is generally from the client to the server only * \[E L-A\] sometimes the server will not be able to register the address. if there are messages you are saving some messages * \[Jen\] we could consider that, yes * \[E L-A\] it would be nice if clients release rather than waiting to timeout * \[Ted Lemon\] agree with the point about acknowledging; stop xmit if you hear it, otherwise restrans * \[T L\] w.r.t.one message per address, with temp addrs there might be a lot of churn. might be able to use `INFORM` to see the client can communicate unicast, with TCP, and flooding might be less of a problem * \[Jen\] still need one message sent per address * \[T L\] TCP 3-way handshake could give the network some validation as well * \[T L\] and if get back some info that the server doesn't support this you can exit early and not send any registrations (because they're wasted) * \[T L\] not currently any support for TCP in DHCP, but this is kind of a different situation, and you can get the Line ID insertion on the discover * \[Ryan Globus\] a boolean from the server might be helpful, optional not required, as an ack * \[Jen\] can be considered but the mechanics are getting more complicated now * \[T L\] `INFO_REQUEST` would let you learn the capability of the server and avoid all registrations * \[Suresh Krishnan\] telling clients to stop sending registrations seems good * \[S K\] temp addrs can fill up the cache, can learn when the number of addresses is exhausted (?) * \[Lorenzo Colitti\] there are several differences between server log and ND cache * \[Tim\] but marking it unvailable would be more state, if `SHOULD` mark as unavail then we need a release signal * \[L C\] on the release, the server needs to time things out because clients just disappear. releases a very small number of messages * \[Tim\] for forensics, you can see when a client left * \[L C\] you'd have to send from the source address you're saying you're not using anymore * \[Eric Vyncke\] release might be a nice signal in the logs * \[E V\] why only have this behavior for endpoints? sending it from SAVI switches would be good too * \[Jen\] it's not a complete security solutions * \[L C\] let's just say that switches `MAY` do this on behalf of clients that don't do this * \[Jen\] do we now have a client on the switch? the relay does this, I guess * \[Tim\] definitely reuse the builtin retrans logic * \[Tim\] based on the interest we should do an adoption call ## AOB {#aob} * 1 minutes remaining * please review documents and comment * see you in Yokohama! [1]: https://www.rfc-editor.org/rfc/rfc7943.html [2]: https://www.rfc-editor.org/rfc/rfc4862.html