►
From YouTube: IETF114-DHC-20220728-2130
Description
DHC meeting session at IETF114
2022/07/28 2130
https://datatracker.ietf.org/meeting/114/proceedings/
B
B
Here's
the
ietf
notewell,
if
you
haven't
seen
it
by
thursday,
you're
lucky.
I
guess
please
take
a
look
at
it
and
please
read
it
if
you
don't
recognize
it
and
follow
all
the
rules
in
it.
Additionally,
we
ask
that
you
keep
your
mask
on
if
you're
not
presenting
or
actively
drinking
doing
any
of
those
things.
Everyone's
been
doing
a
great
job
this
week,
so
keep
that
up.
B
No
well
blue
sheets.
So
if
you're
in
the
room
there's
a
there
was
a
qr
code,
it's
gone
now,
but
there's
a
qr
card,
please,
if
you're
in
the
room
physically
just
go
to
the
on-site
tool,
click
on
it
and
mark
yourself,
as
here
that
gives
us
accurate
counts
for
who's.
Here.
Note
takers,
bernie's
agreed
to
start
him
off
and
I'll
be
filling
in
when
he's
presenting.
B
But
additionally
there's
the
markdown
hedge
doc
notes
feel
free
to
add
your
own
notes
as
we
go
through
we'll
clean
them
up
at
the
end
and
zulup
is,
and
jabber
is
kind
of
like
a
merged
thing
now.
So,
if
you're
in
the
meat
echo
tool,
there's
a
little
chat
bot,
it
shows
up
very
nicely
so
feel
free
to
use
that
and
I'm
tim
and
bernie's
remote
hanging
out
with
us
from
from
lovely
new
hampshire.
A
B
A
B
B
B
So
I'll
do
this
one
bernie
since
you're
going
to
talk
a
lot
in
a
minute,
so
our
current
working
group
status
is
we
don't
have
any
working
group
documents
at
the
moment
we
finally
got
the
yang
model
through
after
some
trials
and
tribulations
thanks
to
ian.
I
don't
know
if
he's
online,
but
ian
did
a
lot
of
work
for
that
to
get
that
over
the
hump,
but
we
did
get
it
over.
B
C
B
A
A
Okay,
so
the
motivation
for
advancing
dhcp
v6
to
enter
its
standard
from
what
it
currently
is,
which
is
proposed,
is
really
because
of
the
charter
and
the
charter
that
we
did
many
years
ago
we
figured
it
was
a
worthwhile
endeavor
to
do,
and
that
was
also
the
reason
we
wrote
rc
84
15,
which
really
consolidated
the
base
specification
from
the
you
know:
three
core
documents:
3315
and
the
two
others.
You
know
the
iapd
and
stateless
plus
a
few
others
into
a
totally
new
document.
A
A
There
are
no
errata
against
the
specification
that
will
cause
a
new
implementation
to
fail
to
interoperate
with
deployed
ones.
There
are
no
unused
features
in
the
specification
that
greatly
increase
implementation,
complexity
and
four.
If
the
technology
required
to
implement
the
specification
requires
patented
or
otherwise
controlled
technology,
then
the
set
of
implementations
must
demonstrate
those
two
independent,
separate
and
successful
uses
of
the
licensing
process.
A
So
let's
go
through
each
of
those
to
indicate
where
we
are
today.
You
know
we,
I
think,
there's
no
disagreement,
that
we
have
lots
of
independent
implementations
that
are
interoperating
today.
You
know
pretty
much.
We
have
things
from
cable
modems
to
home
gateways,
to
routers
to
servers
to
laptops,
even
quite
a
few
handheld
devices.
A
You
know
mobile
devices
and
things
like
that
all
seem
to
be
able
to
interoperate
and
work,
and
you
know:
do
the
ghp
v6
standard,
you
know
everybo
everything
appears
to
operate
well
from
both
the
previous
usg
v6
testing.
That
was
done
at
the
unh
interoperability
lab
and
previously
at
cable
labs
field
deployments
like
comcast's
broadband
service,
which
is
ipv6
based
and
also
things
like
the
itf
midi
network
offers
dhp
v6.
A
A
A
We
kind
of
asked
that
this
came
out
and
should
have
been
included.
So
that's
a
pretty
minor
thing
just
add
another
reference.
Let's
quickly
go
through
the
errata,
because
those
are
potentially
sticky
items.
One
is
just
a
typo
where
section
six
is
missing
and
closing
parenthesis.
I
don't
think
that
causes
any
interoperability
issues
and,
depending
on
what
we
do,
if
we
do
a
8415
biz
and
if
we
drop
temporary
addresses
the
section.
A
Would
disappear
anyway,
so
it
might
be
a
non-issue
to
begin
with
and
we
do
have
another
type
o
in
section
1838,
which
uses
the
word
client
instead
of
server.
You
know
it's
like
it's
talking
about
what
the
server
does
and
it
says
the
client
generates
a
packet.
Well,
no,
it
meant
the
server
generates
a
packet.
I
think
it's
easily
understood
to
be
a
typo
and
probably
is
not
that
significant.
Yes,
it
should
be
fixed
and
you
know
we'll
do
that,
should
we
need
to.
A
Then
we
have
this
errata,
which
is
a
bit
more
involved,
and
this
is
an
inconsistency
as
to
whether
survey
server
unicast
can
be
used
by
information
request
messages
and
it
it
seems
like
the
intent
was
that
they
could,
and
so
there
are
a
couple
sections
that
have
some
incorrect
list
of
messages.
Where
you
know
information
request
message
should
be
removed
or
or
included,
and
there's
also
an
inconsistency
as
to
whether
server
unit
test
option
can
be
used
in
a
reconfigure
message.
A
A
And
you
know
this
could
arguably
cause
some
interoperability
issues,
although
I'm
not
sure
that
it
really
has
to
to
date.
But
you
know
if
a
client
were
to
use
a
server
unicast
in
an
information
request
and
the
server
disallowed
it
then.
Obviously
the
server
is
going
to
probably
send
back
a
malformed
or
dropped
the
packet,
and
therefore
you
know
no
progress
would
be
made
by
the
client
to
to
get
an
answer
to
its
information
request.
A
A
So
this
is
a
discussion
that
we
need
to
have
in
the
working
group
as
to
whether
we
should
deprecate
this
or
or
not.
You
know,
the
other
question
is:
are
there
any
other
things
in
the
document
that
might
be
considered
to
obsolete?
You
know
we
did
obsolete
some
things
from
3315
and
I
don't
think
there's
anything
else,
but
it
is
a
question.
A
You
know
that
might
be
something
that
the
the
remaining
co-authors
consider
in
working
on
the
biz
documents
and
who,
who
would
be
included.
The
the
work
is
fairly
small
to
integrate
the
errata.
You
know,
removing
the
iata
temporary
addresses
is
likely
a
bit
messy.
I
mean
it's
pretty
straightforward,
but
there's
you
know,
there's
quite
a
few
places
where
the
text
would
get
some
sort
of
changes.
A
A
You
know
one
of
the
goals
is
to
be
very
careful
to
minimize
the
changes,
though,
because
that
will
make
our
job
as
a
working
group
to
review
the
document.
Much
simpler.
You
know
when
you
look
at
the
diffs,
you'll
you'll
be
able
to
say
yeah.
You
know
I
can
see
that
the
you
know
the
either
I
were
corrected
and
other
things
were
done.
A
So
this
is
my
straw,
for
you
know
a
what
I
think
is
a
fairly
aggressive
but
doable
schedule,
and
that
would
be
to
publish
an
updated.
You
know:
biz
8415
biz
document
a
zero
zero
version
of
it
before
the
november
ietf
deadline.
You
know
again
it's
it's
not
a
lot
of
things
to
do,
but
there
are
a
few
area,
a
few
things
that
we,
the
working
group
and
the
authors
need
to
discuss
about.
What
do
we
do
both
for
fixing
the
errata
and
for
like
removing
the
iatas?
A
A
A
A
A
B
A
A
B
D
Hi
mike
ackerman,
my
question
is
about
iata
and
with
the
focus
on
security
which
that
is
intended
to
do.
I
think
why
would
it
be
a
good
idea
to
take
that
out
now
and
I
know
you're
going
to
say
nobody's
using
it,
but
the
folks
that
we
use
the
most
would
be
enterprises
like
myself
and
we're
not
doing
anything
in
ipv6
yet,
but
when
we
do,
this
could
be
important.
So
I
guess
that's
my
question.
A
D
D
A
B
E
Thank
you
so
bernie
just
couple
of
things.
I
think
one
of
the
things
I'm
really
worried
thanks.
So
one
of
the
things
is
really
like.
You
know
this
is
like
a
really
long
process
and
and
if
you're
going
through
with
this,
I
think
there's
like
some
other
stuff.
We
need
to
look
at
so
there's
a
couple
of
things
that
kind
of
caught
my
eye
right,
like
you
know,
like
some
of
the
late
rfcs
right,
like
you,
know,
seoul
max,
rt
and
stuff
like
that.
E
F
E
A
Well,
so
yeah,
so
the
vocalist
query
just
to
say,
is
that's
a
separate,
rfc
and
dot
covered
in
the
base
8415.,
but
things
like
the
information.
Sorry,
the
the
solicit
refresh
timer
and
things
like
that.
Those
are
in
there
and
yes,
we
do.
I
I
do
know
that
there
are
devices
out
there
using
that,
and
you
know
they
they
seem
to
to
work.
F
B
Yeah
so
I'll
talk
a
little
bit
about
this
and
kind
of
make
a
plug
for
my
friends
at
the
unh
iol.
So
what
we've
you
know?
The
ready
logo
has
a
new
dhcp
logo
we're
working
on.
We
put
it
out
for
public
review.
I
said
some
notes
about
this
on
the
list.
The
general
idea
there
is
to
cover
all
the
new
things
that
got
included
in
8415,
like
soul,
max
rt,
stateful
issues,
a
couple
of
those
things
that
weren't
in
a
3315
standard,
client
or
server.
B
B
You
know
drop
it
off
there,
they're
just
looking
for
interoperability
partners
to
make
sure
that
people
have
implemented
some
of
those
more
corner
test
cases,
because
a
little
bit
of
concern,
I'm
hoping
by
november,
we'll
have
better
we'll
have
better
results
to
say.
Yeah
we've
got
a
bunch
of
people
that
have
done
this.
I
think.
A
B
E
E
Like
hey
like
you
know,
this
is
where
it's
implemented
and
so
on,
because,
like
we
kind
of
remove
the
implementation
status
and
everything
from
the
rfcs
right,
so
it'll
be
good
to
kind
of
have
this
information
ready,
because
this
is
a
really
long
process
and
I
I
did
8200
like
and
it's
like,
and
and
it's
like
really
tough
on
the
80.
So
it's
it's
probably
good
to
kind
of
have
a
good
idea
of
like
you
know
what
is
really
yeah
out
there
like.
A
Yeah,
we
probably
need
you
know,
we'll
probably
need
to
develop
some
kind
of
feature
matrix
or
something
to
to
see.
You
know
have
have
these
combinations
been
tested,
especially
about
some
of
the
newer
non-basic
sort
of
stuff.
So
you
know
what
what
can
you
do
to
help
in
the
short
term?
Well,
for
the
you
know,
co-authors.
I
need
to
hear
from
you
whether
you're
interested
in
working
on
this
or
not,
and
you
know
if
anybody
has
else-
has
a
strong
interest.
A
Let
me
know
you
know
you
can
send
to
dhc
chairs
if
you
are
interested
that
way,
tim's
aware
of
it
as
well
and
the
other
thing
is,
you
know
if
you
have
any
issues
that
you've
had
with
rc
8415
any
typos
errors,
you
know
more
severe
mistakes
or
whatever
you
know,
do
report
them.
Ideally
it's
best
if
you
report
them
as
the
you
know,
using
the
errata
stuff,
but
if
you
don't
want
to
do
that,
you
can
send
them
to
dgchairs
at
itf.org
for
now
as
we'll
collect
them.
A
A
B
F
C
H
C
I
I
I
I
I
I
Distribute
the
locate,
subnet
routine
locally
and
distributes
the
local
located
sub
subnets
routines
to
arsenals
in
the
network
and
the
the
force
when
the
locator
prefix
is
released.
The
brush
deletes
the
locate
subnets
rotis
here
the
brass
need
to
enable
the
hcp
v6
pd
server
or
dhcp
v6
release
agent
service.
I
I
I
I
I
I
I
I
I
I
Second,
generate
the
locate
subnet
routine
locally.
The
third
distribute
the
locate
subnets
routine
to
other
ipv6
node.
So
it's
very
simple
and
the
second
scenario
brass
works
as
the
htcp
basics
really
agent.
It's
also
very
simple:
the
behavior
like
that
first
release,
dhcp
basics,
pd
allocation
messages;
the
second
generate
the
locator
subnet
routine
locally.
The
third
distribute
the
locate
prefix
rotates
to
us,
ipv6
node.
So
that's
the
basic
behavior
for
a
really
agent.
A
A
So
you
know,
if
so,
a
client
sends
this
new
option
in
a
request,
or
you
know
solicit
things
and
a
server.
That's
aware
of
this
option
would
send
one
in
a
reply.
So
you
you
know
the
client
can
know.
Oh
yeah,
okay,
the
server
understood
this,
but
if
a
server
that
doesn't
understand
this
new
option,
it
will
respond
with
a
prefix,
because
this
is
going
to
look
and
say,
oh
see,
I
said
I
see
a
request
for
a
prefix.
A
Oh
I'm
going
to
assign
you
a
pre-tax,
and
so
now
what
does
the
client
do
with
that?
Prefix
that
it
got
that?
It's
not
you
know
it
it.
It's
not.
It
doesn't
have
this
your
new
option
in
it,
the
ia,
srv
or
whatever
it
was
called
yeah
srv6
locator
option
in
it.
So
the
client
will
go
well.
This
isn't
an
srv6
thing.
A
So
is
the
client
going
to
turn
around
and
release
it?
You
know
so
I
think
that's
something
that
needs
to
be
thought
out
is
how
does
how
does
a
client
make
sure
that,
when
it
asks
for
one
of
these
things
that
it
unders
it
knows
it
got
one
and
it
that
I
think
you've
got
the
check
on
that,
but
if
it,
how
does
it
know
or
how
does
it?
What
does
it
do?
How
does
it
deal
with
it?
I
A
I
A
A
I
A
Yeah-
and
you
know
I'm
not
I'm
not
going
to
I-
I
can't
say
whether
this
is
a
good
or
bad
idea,
because
I'm
not
really
an
srv6
expert,
and
so
you
know,
I
think
that
there
it
will
be
good
at
some
point
to
get
some
input
from
some
people
that
have
more
of
this
experience.
Because-
and
and
you
know
I
mean
this-
is
a
protocol
option,
probably
if
especially
if
it's
an
ia,
and
so
it
should
be
done
in
the
dhc
working
group,
but
we
are
going
to
need
some
expertise
to
help
us.
J
J
Run
real
quick
actually
because
I
think
bernie
said
everything
I
wanted
to
say.
I'm
just
gonna
say
I
think
the
dhc
idiomatic
way
of
doing
it
is
probably
to
define
a
new
option
which
bernie
suggested
I'm
going
to
go
ahead
and
guess
that
the
reason
that
maybe
you
didn't
propose,
that
is
because
the
b-raz
might
not
be
able
to
be
updated.
B
K
K
So
this
is
registering
self-generated
ipv6
addresses
using
dhcp
v6,
and
thank
you.
This
is
who
we
are.
The
draft
is
actually
based
on
an
earlier
document
from
suresh
and
rajiv
and
some
others,
but
you
know
it's
myself
lorenzo
jen
at
some
point.
So
that's
us
next
slide.
Why
are
we
doing
this
because
eventually
asking
people
have
you
tried
turning
it
off
and
on
gets
really
old?
K
K
He
calls
up
and
he's
really
annoyed
people
look
in
the
dhcp
logs.
They
find
the
iep
address
based
on
the
mac.
They
ping.
The
printer,
they
you
know
things,
work
out
and
they're
happy
if
you're
doing
ipv6
with
slack
the
ceo
calls
up
and
says
he
can't
print
to
his
printer
and
you
say:
have
you
tried
turning
it
off
for
none
again
and
he
says
yes
and
you
say:
have
you
tried
turning
it
off
and
run
again
and
he
says
yes
and
then
you
go
post
your
resume
on
monster
right.
K
If
you
just
have
the
mac
address,
it's
really
hard
to
figure
out
what
ipv6
address
somebody
has
next
one.
The
other
common
use
case
is
security
operations.
Folk
have
something
where
you
know
last
thursday,
at
2
43
they
have
some
ids
log
that
shows
that
some
machine
uploaded
their
entire
source
tree
to
stack
overflow.
K
What
they'd
like
to
know
is
which
employee
had
this
ip
address
at
this
time
or
what
machine
had
this
ip
address
at
this
time
with
ipv4?
The
obvious
thing
is
you
have
the
ip
address?
You
go.
Look
in
the
dhcp
logs,
you
find
the
mac
address
and
then
hr
goes
along
and
visits
the
employee
and
says
you
did
what
with
v6.
What
you
say
is
that's
not
good.
I
have
no
idea
who
used
that
address:
they
assigned
it
to
themselves
with
slack
and
then,
once
again,
you
post
your
resume
on
monster.com
next.
G
K
So
obviously
you
know
the
problem
is
that
a
lot
of
people,
a
lot
of
devices,
run
slack
and
don't
use
dhcp
for
doing
address
assignment.
That's
actually
what's
happening
on
this
network.
When
your
machine
joins
this
network,
you
do
slack
and
you
get
an
address
and
the
network
doesn't
really
know
what
it
is
like.
The
network
devices
do,
but
there's
no
central
tracking
of
it.
Anything
like
that.
K
K
As
I
say,
this
was
based
on
an
earlier
draft
which
was
suresh
rajiv,
and
I
can't
remember
who
else
wrote
it
yep,
which
was
basically
doing
registering
self-generated
ipv6
addresses
in
dns
using
dhcp
v6,
and
it
went
along
fairly
well,
but
then
it
got
stuck
in
working
group
last
call
and
as
far
as
I
can
tell,
almost
all
of
the
unhappiness
was
about
the
dns
part
of
it.
So
how
do
you
take
this
address
and
authenticate
it
that
this
client
should
be
able
to
update
that
dns
address?
K
This
solves
the
helpdesk
use
case
when
the
help
desk
wants
to
figure
out
what
ip
address
a
certain
mac
address
has
it
looks
in
the
dhcp
logs.
It
also
solves
the
secops
problem.
If
they
want
to
know
what
mac
address
an
ip
address
was
a
while
back,
they
look
in
the
logs
or
what
other
sort
of
tooling
is
around
the
dhcp
server.
K
The
way
it
does.
This
is
it's
fairly
simple.
There's
a
dhcp
v6
address
notification
message
which
just
says
hey
I'm
using
this
address.
Please
make
note
of
it.
Does
this
actually
actually
solve
the
secops
problems?
Well,
only
kind
of
because
of
reasons
what
you
actually
get
with
dhcp
v6.
Is
you
get
the
duid
yeah
and
that's
a
whole
site
better
than
nothing
at
all?
K
K
K
K
K
L
If
there
is
a
more
bit
set,
an
array
indicating
there
is
a
dhcp
server,
because
I
definitely
don't
want
clients
to
send
those
messages
if
there
is
no
dhcp
in
the
network
whatever
so,
but
we
still
client
still
has
no
way
to
know
what
server
actually
supports.
So,
just
I'm
sending
kate
if
you're
happy
to
log
it
log
it
or
drop
it
to
yeah,
it's
stateless.
It's
the
whole
idea,
like
client
will
like
really
to
inform
server
and
server
willing
to
do
whatever.
L
It
goes
like
if
you,
if
you're
sending
career
with
mo
you
kind
of
indicate
into
client,
is
there
is
a
dhcp
somewhere
client
sending
it
to
all
dhcp
link
local
multicast.
So
again,
if
there
is
no
such
thing
on
the
segment,
it
will
just
go
nowhere.
If
there
is
a
relay
agent,
it
means
the
network
operator
kind
of
expects
something.
K
K
K
K
It's
like
does
it
time
out
in
four
hours
or
a
day
or
whatever
is?
Is
that
like
deciding
the
best
answer?
That's
a
bit
tricky,
but
it
times
up
it's
not
infinitely
growing.
It's
also.
If,
for
example,
your
disk
gets
full,
the
dhcp
server
is
allowed
to
throw
them
away
or
if
it's
having
a
bad
day,
it's
a
best
use
only
that.
H
K
Yep
yep
you're
allowed
to
ignore
them.
If
you
feel
like
it
and
yes,
they
will
time
out.
Part
of
the
thing
is:
there's
like
17
different
timers
that
we
could
base
the
time
out
on,
and
is
it
like
the
lowest
of
this
one
unless
it's
more
than
x
versus
you
know,
so
the
exact
number
is
d,
the
to
be
decided.
Actually
that
sounds
better
any
other.
M
Hazel
smith,
I
was
wondering
if
this
had.
If
this
did
have
an
act,
then
conceivably
you
could.
If
you
were
designing,
you
know
access
switches,
you
could
use
this
sort
of
ip
source
card,
v6
and
basically
say
like
if
you've
actually
got
a
lease
from
the
atp's
v6.
You
can
use
this
address
or
if
you've
sent
an
announcement
saying
a
notification
saying
I'm
going
to
use
it
and
the
http
responded
sure
fine
with
me,
then
you
allow
it.
M
E
Yeah
thank
and
thanks
hazel,
like
I
think
one
of
the
worries
is
that
right,
the
dcp
server
doesn't
support
it
and
you're
waiting
for,
like
the
dhcp
server
to
say
it's,
okay,
that
that
could
lead
to,
like
you
know
somebody
not
having
access
to
that.
Sorry,
that's
the
worry
and
that's
why
it's
kind
of
going
as
best
effort
to
go
through,
but
I
I
think
it's
like
fairly
available.
E
If
you
have
like
a
controlled
system-
and
this
is
something
that
you
know
it's
going
to
happen-
we
can
probably
like
you
know,
set
up
something
like
regard
kind
of
thing
right.
It
can
hook
up
to
something
like
regard
and
to
do
that
but
yeah,
but
otherwise,
like
it's
going
to
be
a
bit
tough
to
like
lock
it
down
too
much
right.
This
is
the
best
effort,
yeah
yeah,
so
can.
L
I
quickly
just
follow
up
on
this.
There
is
a
other
concern.
We
expect
the
client
only
report
preferred
addresses,
which
means,
by
the
time
you
send
this
applications
might
already
want
to
send
traffic.
So
if
you
want
to
do
something
like
savvy,
it's
better
to
use
dad
on
sales
stations
or
any
other
form
of
client
willing
to
get
an
address,
and
it
might
be
way
too
late
here
to
do
anything
based
on
dhcp
registration.
K
And
I
guess
I'll
add
something
to
that,
like
one
of
the
other
bits
on
my
badge
is
like
knock
monkey
and
we've
been
having
a
lot
of
entertainment
at
this
meeting
with
ipv6
and
dad
and
the
network
devices
going.
Oh,
I
don't
think
you
should
really
have
that
on
that
port
I
mean.
Actually
what
it's
doing
is
it's
sending
its
like
device
tracking
message
from
colon
colon
because
of
entertaining
bugs
so
like
the
whole,
your
switch
can
do
mac,
address,
learning
and
locking
down,
just
as
like
terrifying,
but
that's
my
personal
vendors
love.
K
G
H
G
B
K
Yeah
somebody
suggested
that
you
know
a
device
that
sees
somebody
using
a
mac
and
ip
could
send
this.
I
think
that
that
sounds
like
a
really
bad
idea,
mainly
because
it
seems
like
a
lot
of
complexity
like
a
router
could
be
like.
I
saw
this
guy
using
this
ip
and
mac
I'll,
send
it
off.
I
think
that
bad
mojo,
but
it
could
be
done.
Okay,.