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

Welcome, Agenda Review and Status Update (WG Chair) -- 10 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

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

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

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

• 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

• 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

• new message to inform server of non-DHCPv6-assigned addresses

  • RFC 4862 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

• 1 minutes remaining
• please review documents and comment
• see you in Yokohama!