►
From YouTube: IETF115-DHC-20221108-1630
Description
DHC meeting session at IETF115
2022/11/08 1630
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
Yep
Janice
it's
next
door,
if
you
guys
can
see
that
last
thing.
So
I
can
remember.
A
Okay,
yeah:
we
have
her
at
the
at
the
end
at
the
end,
just
to
think
of
what
you
do.
C
D
F
A
E
A
All
right
as
people
trickling
we'll
deal
with
that
people
online,
can
someone
write
in
the
chat
room?
If
you
guys
can
hear
me.
A
A
You
sign
this
when
you're
registered,
but
here
it
is
again
please
read
it
over
and
follow
all
of
the
policies,
including
you
know,
code
of
conduct
and
IPR
the
two
we
always
want
to
talk
about
and
make
sure
that
people
are
following
both
of
those.
So
if
you're
not
sure,
this
group
is
always
been
good
to
me,
so
I
expect
that
to
continue
the
note
well
went
on
if
you're
not
at
the
mic.
A
Please
wear
a
mask.
That's
been
going
on
all
week.
That's
the
policy
of
the
community.
That's
the
policy
of
this
event.
So
thanks
everybody
I
think
people
have
been
doing
a
good
job
this
week
for
blue
sheets.
Bernie
still
leaves
that
in
there
meat
Echo
does
does
that
for
us.
So
please
make
sure
if
you're
in
the
room
that
you're
signed
into
me,
Deco
that
you're
clicking
on
the
right
button
note
taking
I've
started
a
doc.
People
could
help
out
with
that.
That
would
be
great.
A
A
Eric
would
like
a
volunteer
because
we
can't
start
the
meeting
until
there
is
a
scribe
in
this
case.
You
know
I'm
solo
up
here
chairing
so
I
won't
be
able
to
do
it.
So
if
we
could
have
somebody
start,
the
notes
or
somebody
online
or
even
in
the
room
would
be
great
foreign.
A
A
A
Please
don't
do
that.
It's
gonna
be
a
real
short
meeting.
A
A
A
A
Anyone
have
any
problem
with
that
agenda.
I
want
to
change
it.
Jen
is
in
a
different
meeting,
so
I
have
her
at
the
end.
So
I
don't
want
to
move
that.
If
people
want
to
move
anything
else
at
the
court,
we
can
do
that.
A
Status,
we
don't
actually
have
any
working
group
documents
at
the
moment.
I
think
we're
going
to
have
soon
a
bunch
after
this
meeting,
but
we
currently
don't
have
any
so
there's
not
much
for
me
to
talk
about
there.
There
are
three
related
documents
right
now,
all
of
which
are
presenting
today.
So
that's
good.
Everyone's
made
updates
and
they're
all
moving.
So
that's
good.
A
Just
a
quick
thing
we
put
on
the
slide
is
the
Milestones
we're
aiming
to
have?
Oh
that's
a
typo
3315
Bays
should
be
84
15
days.
Sorry
we're
aiming
to
have
that
done
in
January
of
2020
23.
A
and
then
after
we're
done,
that
we
can
talk
about
rechargering
and
shutting
down
whatever
makes
the
most
sense
all
right.
Let
me
switch
slides,
so
I'm
gonna
talk,
I
guess
the
mic
is
still
on
I'm,
going
to
talk
a
little
bit
about
advancing
DHCP
V6
to
an
internet
standard.
A
A
So
last
meeting
in
Philadelphia
we
decided
to
take
this
on
just
a
quick
reminder:
here's
all
the
requirements
for
everyone
to
read.
You
can
go
read
these
later,
but
these
are
all
the
things
we
have
to
do
as
part
of
the
process
of
moving.
G
A
Independent
implementation
status,
so
on
that
slide
there
was
a
Implement.
You
know,
implementations
that
have
to
exist
here.
We
have
lots
of
lots
of
implementations,
exist
of
DHCP,
B6
I,
don't
think,
there's
a
problem.
There
there's
a
little
bit
of
trickiness
here:
measuring
8415
compliance
versus
3315
compliance,
but
ultimately
there's
a
lot
of
DHCP
out
in
the
world
and
it's
being
used.
So
that's
good.
A
The
proposed
schedule
for
84
15
Biz,
so
we
just
published
0
0
of
this
document.
We
started
a
working
group
last
call
that
ends
next
week.
Sorry,
work
and
group
adoption
call
thank
you
in
this
book.
Yes,
we're
in
group
adoption
call
that
ends
on
the
18th.
We
haven't
seen
much
on
that.
So
that's
going
to
be
one
of
my
pleas
today
is
everybody
take
a
look
at
it
and
you
know
I
think
this
obviously
makes
sense
as
a
DHCP
working
group
graph,
I
think
it's
something
we
should
work
on.
A
So
I'd
like
to
hear
some
noise
in
the
mailing
list
about
that.
We're
going
to
publish
that
republish
that
document.
As
a
working
group
document,
we
actually
got
some
feedback
from
Bad
links
from
Ayanna.
Thanks
for
their
review,
they
did
some
so
I
think
we'll
probably
stick
those
in
the
zero
zero
one
that
goes
to
the
working
group.
So
that's
good
news,
we're
hoping
to
put
01
out
in
mid-December
with
any
changes
for
as
part
of
the
working
group.
Last
call
working
group
adoption
call
geez
review.
A
We
want
everything
wrapped
up
by
February,
8th
we'll
do
as
many
updates
in
between
there
and
March.
16Th
is
what
we're
aiming
for.
Yeah,
yes,
23
I
have
not
built
a
time
machine.
Yet,
yes,
it
does
it's
wrong.
A
It's
one
of
those
days
yep,
so
20
I'll,
slash
that
through
sorry,
yes,
2023
February,
so
we're
aiming
to
have
this
all
wrapped
up
by
a
March,
ietf
I.
Think
if
there's
anything
lingering,
we
can
deal
with
that
in
at
the
March
GF,
it's
kind
of
our
game
plan.
A
One
thing
to
note
here
is
we're
going
to
need
a
Shepherd
for
this.
That
is
not
one
of
the
two
co-chairs,
because
both
of
the
co-chairs
are
our
authors.
So
that's
something
we'll
be
looking
for
if
you're
interested.
Please
come
talk
to
me
about
that
I
think
Suresh,
so
I
should
volunteers
to
Shepherd
that
that's
awesome
Okay,
so
things
in
the
8415
Biz
that
we've
done
since
we
last
talked
in
Philly,
we
addressed
all
the
erratas
we
removed
iatas.
A
We
discussed
removing
them
for
8415
when
we
did
the
update
from
3315
and
this
time
they're
really
gone.
We
took
those
out.
We
also
took
out
the
server
unicast
option
because
don't
find
it,
we
didn't
find
many
use
cases
for
it
that
also
additionally
resolved
one
of
the
erratas.
It
was
out
for
it
so
that's
been
removed
and
then
we
added
a
reference
to
79.43
or
the
those
are
the
four
things
we
did
any
questions
about.
Any
of
that.
A
So
there
was
a
couple
of
things
we
wanted
to
get
some
feedback
on.
One
of
them
was
the
reduce
the
background
material
sections
in
one
one
and
one
two.
A
We
talked
about
potentially
bringing
those
down.
There's
a
lot
of
extra
stuff
in
there
that
I
think
can
get
removed.
Now,
I,
don't
know
if
anyone
has
any
opinions.
A
I
guess
I'll
go
through
these
one
at
a
time,
if
no
one
runs
to
the
mic
I'm
going
to
take
these,
as
we
should
probably
do
these.
This
is
going
to
be
my
position
on
this,
or
so
is
there?
Does
anyone
have
any
strong
opinions
about
leaving
the
background
material
in
no
one's
running
to
the
mic?
A
We
should
remove
all
texts
related
to
unicast
Transmissions,
so
we
took
out
the
server
unicast
options,
but
there's
a
lot
of
text
about
what
to
do
in
unicast
situations.
We
could
potentially
remove
them
all
of
that
text.
We
could
leave
it
in
there.
It's
a
little
odd
that
you
tip
out
that
option
which
almost
I'm
going
to
ask
the
next
question
as
well
is:
should
we
deprecate
the
use
of
the
multicast
status
code?
A
So
the
one
thing
that's
here
that
I
wanted
to
see:
if
anyone
had
any
opinions
on
was
if
it's
an
84-15
proper
device,
it
might
be
using
multicast
and
a
new
server
might
not
respond
with
use.
So
I
don't
know
we're
not
aware
of
any
deployment.
So
I
don't
think
it's
a
problem,
but
if
somebody
really
wants
we
can
leave
the
use,
multicast
status
code
and
all
the
text
to
unicast
in
case
there
is
what
would
become
a
legacy
device.
A
That's
out
there
trying
to
use
unicast,
I
I,
you
know
personally
I
think
Bernie
was
leaning
towards
removing
all
of
that.
I
I
think
that's.
Okay,
but
I,
don't
know
if
anybody
really
knows
if,
if
any
use
of
the
unicast
status
code,
Tomah
confirmed
that
KIA
doesn't
support
it
at
all.
A
I
know
that
there's
other
servers
that
do
support
it,
but
it's
not
used.
So
anyone
have
any
opinions
on
any
of
that.
A
Oh
okay,
I,
I,
guess
what
I'm
taking
from
this
is
we're
going
to
go
ahead
and
do
all
of
these
changes.
Unless
we
hear
something
for
one
one.
A
This
is
the
play
I
was
talking
about
earlier.
Please
send
an
email
if
you're
in
support
of
this
becoming
a
working
group
document,
please
send
an
email
if
you're
not
in
support
of
this
becoming
a
document.
Please
say
something
about
this
I'll
I'll
pack,
again,
probably
after
this
meeting
but
yeah.
Ultimately,
we
want
to
adopt
this,
and,
and
so
we
can
move
forward.
A
Yeah
I
mean
obviously
when
you're
looking
at
it
for
the
group
to
adopt
it.
Please
feel
free
to
review
or
looking
for
reviews
I
think
that's
my
next
slide
yeah.
My
next
slide
what
you
can
do
to
help
review
the
document
when
published
and
Report
any
issues
to
the
author's
working
group,
anything
the
faster.
We
get
these
issues
and
quicker.
We
can
get
these
things
resolved.
A
So
if
you
find
anything
you
think
anything's
out
of
place,
please
let
us
know
I
think
we'll
make
all
those
changes
in
o1
that
we
talked
about
that
I
just
talked
about
we'll
see.
If
anyone
has
any
issues
with
that
and
I
think
that's
everything.
So
the
main
thing
here
is:
please:
do
the
adoption
call
and
then
review
the
document,
any
other
questions
about
8415,
all
right,
I'm,
gonna,
move
on.
D
A
Looks
like
online
guys
see
both
of
you
are
on
there,
I'm,
not
sure
who's
presenting
based
on
the
request.
So
one
of
you
guys
want
to
jump
on
into
the
queue
so
I
can
admit
you.
A
D
Yeah,
so
you
will
help
me:
pay
Jeff,
okay,
the
yep.
D
Okay,
I
think,
let's
begin
from
this
page,
so
the
draft
have
been
present
in
last
ITF
meeting
and
according
to
the
comms,
we
updated
the
draft
Johnson
from
Channel
mobile.
So
next
page.
D
Yeah
I
will
go
through
the
slides
quickly
because
most
of
the
diamonds
have
been
revealed
in
last
meeting.
So
the
background
for
this
draft
is
that
the
operators
began
to
deploy
ASAP
six
in
major
Network.
D
Covered
the
whole
city
with
High
Mobility,
however,
the
normally
normally
the
CPS
don't
deploy
igp
so
operator
needs
some
way
to
this,
distribute
the
i76
locators
dynamically
to
simplify
the
configuration
next
page.
D
D
Is
separated
to
two
parts
located
block
and
locate
a
node
one
DHCP
server
allocate
the
locator.
The
structure
was
a
post-original
seat
and
a
comprised
the
seed
should
be
covered
next
page.
D
D
Under
the
new
IA,
we
Define
the
iae
as
RS6
locator
options
field,
which
will
be
used
to
specify
the
srv6
located
as
a
figure
should
the
post
original
and
the
comprised
s760.
The
structure
are
covered
next
page.
D
The
encapsulated
format
of
the
new
IA
as
you
need
the
thicker
and
I
a
Sr
V6
locator
option
may
appear
only
have
IE
as
rb6
locator
option.
More
than
one
I8
i76
locator
option.
You
can
papaya
in
a
single
I
I
cyber
six
locator
option.
D
What
works
as
a
dgcp
server
the
behavior
we
choose
here:
it
will
allocate
locator
subnet
prefix
from
the
prefix
poll
and
then
generate
the
locator
sum
item,
router
locally
and
distribute
the
local
subnet
router
to
other
Athletics
note,
so
it's
very
simple
and
next
page.
D
D
D
So
here
we
choose
what
we
have
updated
compared
to
the
origin
of
the
revision.
D
A
lot
of
them
so
fortunately
we
Define
the
new
IA
option
inside
of
using
the
option
in
the
IE
prefix
option.
The
second
day
point
is
that
we
Define
IA
i76
locator
option
to
specify
a
Services
located
associated
with
our
I,
as
I
was
six
located.
D
So
it's
a
just
a
scene
with
the
comments
received
the
last
meeting
next
page.
D
So
we
are
seeking
for
the
comments
in
DHCP
working
group
as
well
in
the
spring
working
group.
D
D
A
Yeah
one
of
them
is
a
procedural
question:
have
you
presented
at
Spring
about
this?
Yet
what
is
the
status
of
the
spring
working
group
with
this
document.
D
So
no,
we
we
have
another
priority
in
Spring
and
we
send
the
request
to
the
working
group
of
chairs
before
the
meeting,
but
we
did
not
get
a
slot.
Maybe
we
need
some
further
message:
exchange
with
the
spring
group
and
shares.
A
Okay,
yeah
I
mean
I
think
we
definitely
need
to
do
some
coordination.
We
don't.
We
don't
want
to
make
this
option
if
the
spring
group
has
no
interest
in
and
making
this
work,
so
I
I
think
we
would
need
to
see
some
interest
on
the
spring
working
group
before
we
would
do
anything
more
with
this
document.
A
Another
question
I
had
about
this
one
was
I,
didn't
see
what
to
do
if
the
when
they
send
out
the
solicit,
if
they
get
multiple
answers
back
from
different
servers,
I
don't
know
if
you
want
to
write
some
text
about
that.
I
know
in
this
case
it's
probably
not
normal
with
B
Razz's,
but
it's
definitely
possible.
A
So
that
might
be
something
you
want
to
consider.
Adding
to.
The
document
is
what
brows
should
do
if
it
gets
more
than
one
of
these
IA
sr6
locators
and
how
it
can
choose
or
how
it
deals
with
that,
whether
it
sends
them
all
down
or
how
that's
dealt
with
more
than
one
server
answers.
It
I
didn't
see
that
anywhere
in
the
document.
I
could
have
been
wrong,
but
that
might
be
something
for
you
to
consider
as
well.
D
Yeah
I
think
you
are
corrected
and
we
should
considered
multiple
locator
of
multiple
other
options.
I
think
we
can
add
some
text,
as
you
just
mentioned
after
the
meeting
and
then
generator
new
Revision
in
the
at
the
same
time.
I
do
think
the
spring
work
group
is
not
interested
in
this
draft.
I
think
this
draft
day
is
very
useful
for
operators.
D
We
may
try
to
send
some
email
to
swimming
working
group
to
trigger
some
discussion
on
that.
I
think
this
is
a
very
interesting
topic
for
the
spring
guys.
A
F
D
Sure
we
will
try
to
trigger
some
discussion
there.
Thank
you.
A
Okay,
I
think
that's
everything,
I
have
so
yeah
get
some
I
guess
our
feedback
is
talk
to
Spring,
see
if
you
can
get
interest
there
and
then
come
back
to
the
DHCP
working
group
and
we'll
continue
to
work
with
you
on
this.
A
E
C
H
Hello,
I
think
I
know
almost
everyone
right,
I'm
Jen
next
slide,
please
so
we're
talking
about
how
to
use
dhcpv6
to
record
and
addresses
which
were
not
assigned
by
the
HTTP
V6
quick
recap
to
what
Warren
said
last
time
in
Philadelphia.
So
the
usual
scenario
is
yeah.
H
You
have
slack
or
even
statically,
assigned
addresses
Jose
using
it,
but
some
administrators
prefer
to
use
dhcpv6
as
a
kind
of
login
system,
so
they
could
easily
find
out
who
was
using
what
so
it
would
be
nice
if
they
might
want
to
have
all
the
information
in
one
place,
so
they
could
look
it
up
for
troubleshooting
forensics,
whatever,
like
I,
want
to
know
yeah
what
what
particular
device
was
saying
in
that
particular
traffic.
H
So
there
was
a
link
to
the
slides
and
obviously
there
is
a
video
of
really
nice
presentation
by
Warren.
So
next
slide
so
yeah
next
slide.
So
what
we've
done
in
the
last
few
months,
we
try
to
address
feedback
received
on
the
list.
I
do
hope
we
address
most,
if
not
all
of
it.
So
let's
go
straight,
so
we
clarifying
how
the
registration
message
supposed
to
be
sent.
First
of
all,
we're
saying
that
it
must
be
sent
from
an
address
being
registered.
H
That
would
help
on
infrastructure,
which
has
some
form
of
layer,
2
security
Savvy
to
prevent
spoon.
So
you
cannot
register
something
you
do
not
own
well
in
IPv6,
especially
in
slack
own
means
a
lot
of
things,
but
at
least
you
kind
of
responding
to
ND
for
that
address,
which
also
implies
that
you
cannot
register
multiple
addresses
in
one
message.
So
it's
going
to
be
a
message
per
address.
H
Secondly,
host
sends
that
message
from
the,
inter
through
the
interface
which
has
that
address.
So
if
you
have
multiple
home
hosts
with
multiple
interfaces,
we
need
to
make
sure
we
are
sending
it
to
the
right
place
and
well
obviously,
we
signed
and
create
four
addresses
which
are
not
provided
by
the
xcpv6,
which
means
slack
or
statically
configured
that
the
changes
next
slide.
Please.
H
I
learned
something
I
did
not
know.
There
is
already
definition
for
address
being
appropriate
for
a
link
which
kind
of
means
the
DHCP
server
needs
to
know
something
about
topology.
So
basically,
we
kind
of
the
server
should
validate
that
the
host
is
supposed
to
have
that
address.
So
if
you
are
on
v1x
with
that
slash
64,
you
should
not
be
sending
something
completely
ridiculous
in
the
registrator
message.
H
So
what
to
do
when
the
server
receives
this
the
whole
ID?
Basically,
let's
log
it,
let's
keep
it
somewhere,
so
administrator
could
look
it
up
later,
so
the
server
is
supposed
to
log
it
somehow
and
draft
currently
says,
should
Mark
addresses,
unavailable
and
do
not
offer
it
actually.
Is
that
the
question
to
the
audience
should
we
have
shoot
here
on
May,
because
it
kind
of
requires
additional
capabilities
for
the
hcp
server
besides
just
login,
so
it's
a
kind
of
going
slightly
more
further,
not
just
let's
track
addresses
next
slide.
Please.
H
Retransmits
we
now
actually
have.
Is
it
sub
the
dated
slides
but
anyway,
that's
it
retransmit.
So
prop
oh
yeah
proposed
approach,
which
is
currently
in
the
draft
and
I'll
talk
about
another
option
which
we
are
discussing
as
well,
so
just
send
and
packets
by
default,
three
with
some
delay
between
them,
preferably
jittered
and
let
administrator
to
change
those
variables
if
they
don't
like
it,
so
why
we
are
not
I
can
because
there
is
no
real
point
of
having
acknowledged,
because
initially
you
still
can't
rely
on
that
right.
H
We
deploy
this
on
the
client
and
most
likely
the
server
would
not
support
it
in
the
wild.
So
you
don't
know
if
the
server
does
not
support
it
or
it's
just
not
hacking.
It
next
slide,
please
so
for
refresh
you
registered
it
like
three
three
packets
in
three
seconds,
but
obviously
you
need
to
kind
of
remind
the
server
that
you
are
still
alive
so
again
proposed
solution
is
to
send
the
message
either
when
one
third
of
valid
lifetime
in
initial
Pio.
H
H
So
it
might
you
might
get
into
situations
when
you
never
sent
an
update
because
it
keeps
changing
otherwise
you're,
also
like
getting
them
in
the
past
and
refresh
messages
should
better
transmitted
using
the
same
logic
and
messages
in
10
seconds.
Next
slide.
Please,
however,
I,
like
being
it
right
here,
we've
had
a
lot
of
discussion
in
the
lobby,
so
there
is
another
proposal
which
is
not
in
the
draft,
but
Bernice
I
think
suggested
it
on
the
list
yeah.
H
So,
let's
use
standard,
DHCP,
retransmission
logic
with
exponential
back
off
and
actually,
if
you're
backing
it
off
up
to
one
hour
or
four
hours,
whatever
magic
number
we
want
to
put
here,
it
basically
automatically
takes
care
of
refreshing,
so
you
just
start
changing
it
faster
and
then
you
slow
down
and
then
you
send
it
every
hour
or
four
hours
or
whatever.
Then
we
don't
need
to
separate
refresh
from
initial
retransmits
and
we're
also
probably
minimize
the
chances
of
packet
being
lost
so
again
think
about
it.
H
I
don't
know
I,
don't
have
strong
opinions
on
what
which
is
better
it
just
but
remember
this
option
is
not
in
the
text,
yet
it
just
okay
next
slide,
please
yeah.
So
this
is
probably
the
main
changes
done
since
Philadelphia.
So,
as
I
said
to
like
questions
here,
it's
about
rear
transmit
strategy
also
about
here
shall
we
stop
giving
the
registered
address
to
anything
else
and
by
the
way
another
idea
came
up.
H
The
hcpv4
has
inform
message,
so
maybe
this
should
be
called,
not
registration,
but
in
form,
and
besides,
that
the
authors
would
like
the
working
group
to
consider
adoption.
If
there
are
no
objection,
strong
objections,
sir,
that's
it
questions,
comments.
E
Eric
clivia
Cisco
yeah
I
have
a
couple
of
concerns
with
this.
The
first
one
released
on
the
principle
I
I
feel
like
if
you
want
the
HTTP
to
know
about
your
address,
just
has
for
an
address
and
they
will
be
a
lot
simpler
than
generating
your
address
and
then
registering
it
and
you
won't
need
to
have
I
mean
yet
another
mechanism,
I
I,
see
one
exception
to
to
that.
I
would
be
link
locals,
but
I
mean
you
never
talk
about,
link,
Lookers,
I!
Guess
you
don't
want
to
register
link
it.
E
So
so
that
was
kind
of
my
first
concern:
should
I
follow
with
the
next
one
or.
H
E
H
E
H
Wi-Fi
Wi-Fi.
E
Yeah
I
didn't
see
the
reply
yeah,
so
it
looks
and
and
in
particular
the
draft
also
States.
Well,
that's
the
only
message
in
DHCP:
that's
not
going
to
work
with
request
reply.
Always
you.
E
Looks
to
me
would
be
a
lot
more
efficient
if
you
just
send
your
registration
and
get
your
acknowledgment
basically
or
some
sort
of
acknowledgment
which,
by
the
way,
could
also
tell
you
that
the
DHCP
server
has
you
know
you
somewhere.
It
mentions
that
there
could
be
a
an
issue
on
the
server,
with
the
link
not
being
adequate.
H
H
First
of
all,
clarifying
questions.
In
this
case
again,
we
cannot
rely
on
acknowledgment
because
it's
quite
possible
that
DHCP
server
does
that
support
that
stuff
right.
So
what
I'm
supposed
to
do,
if
I'm
not
getting
an
acknowledgment
and
how
it's
different
from
not
having
acknowledgments
at
all
that
not.
E
H
Well,
with
the
exponential
book
of
probably
not
so
many
but
yeah
I
guess
I,
don't
know
I
don't
feel
strongly
about
that
yeah.
So
we
definitely
can
consider
that
I,
don't
think
it's
a
like
critical
here,
yeah
and
and.
E
Yeah,
my
last
point
was
if
the
the
client
is
getting
a
temporary
address,
which
is
quite
common
these
days,
it
would
be
nice
to
release
the
address
when
it's
done
with
it,
rather
than
you
know,
relying
on
the
fact
that
it
doesn't
feel
fresh
after
a
third
of
the
life
cycle.
H
You
say:
release
like
as
I
did
it
is
we
you
mean
when
you
get
rid
of
Sandy.
E
C
So
a
couple
things
one
I
actually
agree
with
the
point
about
acknowledgment
I.
Think
there's
no
real
downside
to
acknowledging
you
know
it
just
you
know
you
get
the
acknowledgment,
you
stop
transmitting.
If
you
don't
you
don't
so
it
seems
like
a
useful
thing
and
also
it
gives
people
an
incentive
to
actually
put
a
server
there.
That's
going
to
listen
and
acknowledge
I,
don't
really
care
a
whole
lot
about
releasing,
but
you
know
it
is
a
nice
little
cleanup.
There
was
one
thing
I.
It
was
a
couple.
C
It
was
one
of
the
early,
slides
and
I
can't
remember
exactly
what
the
point
was.
Could
we
go
back
one
more
yeah,
so
I
mean
one
way
to
well.
One
thing
that
occurs
to
me
is
a
way
to
make
this
a
little
bit
more.
C
So
actually
it
was
I
think
it
was
a
slide
before
this
sorry
yeah.
So
so
this
thing
about
sending
one
message
for
Iana
I
mean
we're
probably
going
to
have
like,
especially
if
we're
doing
temporary
addresses
we're
going
to
have
like
a
fair
amount
of
of
churn
here.
C
It
might
actually
be
nice
to
say
that
that
you
know
we
send
a
message:
it's
like
a
DHCP
and
form
style
message,
and
we
ask
for
some
information
about
how
to
how
to
communicate
with
the
server
using
TCP
and
then
do
that
instead
of
doing
like
all
these
multicasts
I
mean
it's
true
that
we
should
probably
not
be
sending
multicast
to
the
to
the
Wi-Fi.
But
it's
not
clear
that
that's
always
going
to
be
the
case,
particularly
if
you're
in
a
home
network
or
something
like
that.
C
I,
don't
know
what
the
home
network
is
going
to
do
with
a
multicast,
so
it'd
be
kind
of
nice.
If,
if,
if
there
are
a
way
to
to
make
the
communication
be
unicast-
and
it
doesn't
seem
like
it's
that
hard
a
problem
and
then
like
doing
this,
suddenly
just
becomes
a
non-problem.
It
was
this
that
kind
of
triggered
me
to
think
about
that
I
mean
I,
don't
know
how
important
this
is,
but
it
just
sort
of
feels
to
me
like
it'd,
be
better
to
do
these
with
unicast.
C
C
Correct
right,
but
but
it's
it's
pretty
low-key,
if
you're
using
TCP
to
do
these
registrations
one
per
address,
whereas
if
you're,
if
you're
using
UDP
and
you're
using
multicast,
then
potentially
depending
on
the
network,
it
could
actually
be
problematic,
so
it
just
seems
like
it
would
be
lower,
lower
key
and
you
know
I
think
it.
You
know
we're
talking
about
inventing
something
new
here
and
also
you
know.
If
you
don't
get
back
an
answer
saying
yes,
I
can
I
can
accept
these
things.
Then
you're
done
right.
C
You
basically
only
have
to
do
this
for
one
message,
like
your
message
is
going
to
be
high.
I
want
to
be
able
to
registration,
can
I
do
that
and
you
only
have
to
do
that
once
like
or
that
is
to
say
there
you
don't
have
to
do
that.
You
don't
have
to
multiply
it
by
the
number
of
addresses
you
have
you're
just
going
to
do
it
for
any
given
interface.
You
can
only
send
one.
H
C
Yeah,
no,
no,
this
would
be
Greenfield,
but
you
know
we're
it
we're
adding
we're
adding
new
capability
anyway.
So
it's
not
like
I
mean
there's
a
reason
why
DHCP
does
what
it
does
with
with
with
with
multicast
right
and
the
reason
it
uses
relays
the
way
it
does,
but
this
is
kind
of
a
different
situation.
If
we
can
establish
the
link
to
the
DHCP
server,
then
that
gets
us
our
topology
information.
We
know
where
the
client
is
coming
from.
C
C
C
B
Here,
yeah
I
just
want
to
add
a
quick
point.
If,
if
we
are
going
to
do
Acts
or
some
sort
of
acknowledgment
from
the
server,
it
could
also
be
useful
to
have
like
a
Boolean
just
business
to
like
yes,
I
am
using
this
I'm
locking
it.
Please
keep
sending
this
when
your
address
changes
or
no
I'm
not
using
this.
So
you
don't
need
to
do
the
every
four
hours
resend
or
send
it
again
when.
B
H
Because
I
have
nothing
to
do
with
implementions
of
stuff.
I
have
a
question
how
much
complexity
we
are
already
like
willing
to
add
for
this.
Well,
because
login,
a
message
is
just
one
thing:
with
some
minimal
validation
versus
billion
causes,
State
machine
and
other
stuff
I
have
again
fine
with
either
option
because
I
don't
have
to
do
this,
but
yeah.
B
A
C
Thanks
tell
them
I
just
wanted
to
I
just
wanted
to
add
something
to
this,
which
is
that
so,
if
you
now,
it's.
C
Of
my
head,
sorry,
so
we're
talking
about
it's.
C
Right,
so
so,
if
the
server,
if
you're,
if
you're,
sending
the
message
to
the
server
and
the
server
oh
right
yeah,
this
was
the
thing.
So
so
one
of
the
problems
that
we
have
with
with
this
current
spec
is
that
you
could
have
a
DHCP
server
on
the
link,
but
it
doesn't
support
this
message,
and
so
it
doesn't
reply
to
it
right.
C
On
the
other
hand,
if
we
do
the
Discover
thing
that
I
suggested
that
could
be
done
in
a
DHCP
in
form,
and
now
you
get
an
act
back,
you're
always
going
to
get
an
act
back.
It
might
not
have
the
information
you
need
if
it
doesn't.
That
means
it's
not
supported
info
request,
yeah,
whatever
DHCP
before
yeah
the
details
details,
so
so
that
that
would
actually
that
would
actually
allow
you
to
optimize
out
a
lot
of
Transmissions,
because
you're
gonna
you're
gonna
get
back
that
information
that
says
yeah.
C
I
Thanks
so
there's
two
things,
I
think,
like
you
know,
Eric,
you
had
a
really
good
point
right
like
about
the
you
know
the
ability
to
kind
of
stop
at
some
point
right.
One
thing
this
is:
this
is
supposed
to
be
a
best
best
effort
mechanism.
Right,
like
you
know,
the
idea
would
be
to
kind
of
keep
it
simple
and
say:
hey
I'm,
forming
an
address
with
Slack
I
want
to
try
to
see.
I
If
somebody
wants
to
log
this
right,
because
in
most
cases
it's
not
going
to
be
recorded,
like
you
know,
in
home
networks
and
stuff,
like
that,
it's
not
going
to
happen
right.
So
it's
going
to
be
a
managed
Network!
That's
going
to
use
this
right.
So
that's
one
thing,
but
the
second
thing
was
like,
like.
H
I
No
Eric
Eric
Levy
exactly
Okay,
so
good
one.
Thank
you
thanks,
Lorenzo,
so
I
think
the
problem
exists
with
or
without
this
right.
H
Actually,
speaking
of
multicast,
if
like
where
shark
on
my
machine
now
amount
of
neighbor
Discovery
multicast
packet,
sent
by
a
host,
will
probably
will
like
much
higher
than
what
we
see
in
in
this
case
anyway.
So
like
I'm,
just
yeah,
I'm,
fine
I
just
said:
can
we
actually
not
adding
too
much
of
multicast
here,
comparing
to
all
other
things,
UIC
and
right
like
like?
If
you
have
V6
only
Network
and
host
doesn't
know
about
that
amount
of
our
multicast
stuff?
It's
saying
you
can
get
just
ridiculous
anyway,.
G
Yeah,
so
for
them,
I
think
for
there's
a
very
important
distinction
between
the
ND
cash
size
and
this
this
is
received
by
the
server
committed
to
a
log
or
not,
and
then
it
doesn't
need
to
be
kept,
whereas
the
ND
cache
does
need
to
be
kept.
A
G
If
you
had,
but
you
know
like
in
theory,
dad
will
take
care
of
that,
because
you
know
we
have
this
problem
today
with
slack
and
hpv6,
where
in
theory
like
the
dhpv6
server
can
hand
out
whatever
it
wants,
and
anyone
can
form
slack
with
whatever
on
some
of.
A
F
A
G
The
release,
actually,
that
is
what
I
like
one
thing,
I
want
to
say,
is
like
yeah.
We
we
try
to
make
this
as
simple
as
possible.
Also
too,
and
you
know
particularly
also
to
ensure
that,
like
you
know,
it
wasn't
a
barrier
to
implementation
on
the
release.
I'm,
not
like
sure
I
understand
how
it
would
work
because,
like
the
server
needs
to
un
like
needs
to
obviously
Time
stuff
out
when
when
like,
because
like
clients
can
just
disappear
right,
and
so,
if
it
doesn't
do
that,
then
it
runs
out
of
space.
G
You
know
like
basically,
and
the
other
thing
is
so
I'm,
not
sure
what
a
release
would
accomplish
like
you,
basically
like
save,
like
maybe
one
message,
but
that's
it
really,
because
you
do
still
have
to
refresh
it
while
you're
still
there.
H
Be
honest,
practically
I,
don't
know
how
often
actually
privacy
extensions
expires
versus
client
dropping
off
the
network
going
home
coming
back
next
day
with
different
privacy.
I
just
don't
have
data
because
I
would
expect
I,
don't
know.
What's
the
what's
the
Privacy
extensions
lifetime
like
at
24
hours,
yeah
yeah,
not
so
many
clients
actually
stay
in
for
like
some
snow,
but.
G
There's
another
you
know,
there's
another
obviously
issue
with
sending
the
releases
that,
like
you,
if
you
have
to
send
it
from
The
Source,
address
that
you're
currently
that
you're
not
using
you
have
to
do
that
before
you
release
it,
but
but
I
guess
we
could
I
mean
it
would
also
like
require
an
additional
message
type.
So
I
I
really
think
about
it.
I
really
yeah
I'm
really
not
sure
about
the
trade-off
here,
but
yeah.
It's
not
opposed
to
adding
release.
It's
just
I'm,
not
sure
it's
that
useful
yeah,
yeah,
yeah
yeah.
F
So
everything
without
any
yet
not
even
the
head
of
somebody,
we've
reviewed
the
draft
right,
so
I
didn't
read
it.
He
said
the
slides,
so
release
I
think
it's
it's
nice
to
have
it.
It
may
mean
in
the
in
the
locks,
because
if
you
see
this
address
coming
up
later,
you
know
something
fishy
has
happened,
but
anyway.
F
F
H
You
know
what
I
I
try
to
say
this
is.
The
draft
is
not
a
silver
ballet.
We
post
to
be
a
single
source
of
information
about
all
addresses
used
in
the
network,
especially
if
you
start
talking
about
forensics
perspective
right.
Ideally,
what
you
have
you
have
this?
You
have
your
neighbor
cash
entry
from
routers.
You
have
your
Savvy
information.
All
together
will
give
you
a
reasonably
full
picture
about.
What's
going
on
right,
so
doing
it
from
the
switches?
Well,
I!
F
A
G
Eric
might
be
saying
is
like
just
have
just
let's
say
in
the
draft:
that
switches
can
send
this
on
behalf
of
clients
that
don't
implement
this
right.
I
I!
Think
that
that's
yeah!
That's
why
I
say
you
don't
think
you
understand,
but
and
that's
I
think
it's
okay,
except
technically,
as
worded
that
the
address
has
to
come.
The
message
has
to
come
from
the
source
address,
and
so
the
switch
would
have
to
spoof
it,
but
maybe.
H
G
A
Something
to
think
about
okay,
so
two
minutes
left
good
job.
The
only
thing
I'm
gonna
add
is
this
is
a
DHCP
participant.
I
would
definitely
use
the
DHCP
retransmit
timer
having
tested
boatloads
of
clients,
they
barely
get
that
right,
I
think
adding
another
one
would
be
problematic
at
best
would
be
my
advice,
but
you
you
do
what
you
want,
but
I
I'm
sort
of
with
Bernie.
H
On
that
computer,
smart
people
and
suggestions
yeah,
that's
why
we're
here
yeah.
So
it's
basically
eight!
That's
why
we
put
it
on
the
slides
because
we
realize
it
might
be
better
hiding,
yeah,
okay,.
A
A
A
There
are
some
chats,
also
I,
see
now
sorry
Vicky
in
the
chat
room
about
that
draft
too.
That
Jen
you
guys,
should
go.
Take
a
look
at
okay,
all
right!
That's
everything.
A
Okay,
I'll
see
you
guys
all
in
Japan
in
March
and
thank
you
bye.
Everybody
online
yeah
I
won't
yeah
the
chat's
on
you
can
go
to
the
chat
anyway.
It's
on
Zulu.