Minutes IETF115: dhc: Tue 16:30
minutes-115-dhc-202211081630-00
Meeting Minutes | Dynamic Host Configuration (dhc) WG | |
---|---|---|
Date and time | 2022-11-08 16:30 | |
Title | Minutes IETF115: dhc: Tue 16:30 | |
State | Active | |
Other versions | markdown | |
Last updated | 2022-11-14 |
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
- email your position on this document! (support, not support,
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
orMAY
mark the address an allocated
- TBD: server
-
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 useINFORM
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!