►
From YouTube: IETF97-DHC-20161118-1150
Description
DHC meeting session at IETF97
2016/11/18 1150
A
C
E
E
E
And-
and
it
would
be
appreciated
if
you
could
help
with
not
taking
on
the
inner
part,
so
we
already
introduced
ourselves,
we
used
to
have
a
working
group
secretary,
but
shank,
step
down.
So
if
you
are
interested
in
helping
a
bit
with
the
working
group,
the
position
is
open.
Okay.
So
this
is
the
agenda
for
today,
Ian
asked
to
go
to
the
second
slide
because
he
has
a
plane
to
catch.
E
So
we
will
go
through
the
library
for
over
six
dynamic
provisioning.
Then
we
do
the
HP
v6
update
I
will
provide
an
update
regarding
the
forestry
meal,
extensions
and
finally,
Bernie
will
talk
about
an
old
draft
that
possibly
could
be
resurrected.
Okay,
so
working
group
status,
we
had
one
Fc
pub
topic
on.
E
We
are
making
progress,
there's
a
separate
presentation,
so
I
won't
go
into
the
details
and
a
young
draft
it's
progressing
forward,
but
my
kink
it's
slowly
with
the
security
HP
v6
the
work
continues.
There
were
several
versions
published
and
we
had
some
discussion
on
deep-sea
mailing
list
and
also
on
sag.
E
E
There
are
two
drafts
that
were
adopted,
Dixie
rely
part
and
the
Dixie
realize
server
security
and
there's
technically
there's
the
last
call
on
the
second
one
is
in
progress
because
I
haven't
summarize
it
up.
There
were
very
few
responses,
actually
only
bang
you
responded,
I
think
so.
If
you
have
some
comments,
please
do
send
them
to
the
list.
E
E
Okay
and
the
last
update
regarding
the
working
group
is
about
milestones,
so
we
recently
completed
two
milestones.
We
still
have
too
much
since
opened
the
first
one
is
and
that
we
should
reach
outer.
This
would
probably
make
sense
after
we
finish
our
work
on
2315
and,
of
course
we
have
the
second
milestone.
So
I
have
a
question
to
the
working
group.
So
do
you
guys
consider
the
milestones
useful
at
all?
Have
you
looked
at
them
and
follow
them
later
them.
F
Association
I
think
it's
useful
to
update
the
milestones
because
it
helped
me
plan,
like
you
know,
when
the
documents
come
through,
so
I
don't
get
like
a
sudden.
I
have
like
suddenly
14
documents
in
my
queue
in
the
last
two
weeks,
and
it's
not
it's
very
difficult
for
me
to
plan
to
get
them
until
it
shuts
and
everything
so
I
I
I
want
to
have
an
approximate
idea
when
something
is
going
to
be
done
so
I
think
it's
good.
Ok,.
E
G
Good
morning,
in
far
from
Georgia
telecom,
first
slide,
please
so
second
slide
technical,
so
I
I
think
I
presented
this
a
few
meetings
back
in
the
HCHO,
probably
probably
going
on
a
couple
of
years
now,
but
a
quick
refresher
about
the.
G
There
is
the
what
and
the
wise
so
can
you
go?
Can
you
go
to
the
first
slide,
just
to
sort
in
Greece?
What
this
is
so
for
soft
was.
We
need
to
have
fee
for
configuration
and
we
need
to
build
a
tunnel
in
v6,
so
we've
got
a
few
parameters
that
need
to
be
provisioned
to
the
client.
Last
year
we
published
a
static,
provisioning,
dhcp
address
which
deals
with.
G
Essentially,
you
have
pre
configured
and
kind
of
deterministic
ways
of
assigning
these
addresses
to
clients,
and
you
know
that
cell
that's
implemented
and
working,
but
some
obviously
with
any
color
static
and
pre-configured
configuration
model,
isn't
here
and
wastage
in
there
and
it's
a
not
possible
to
you
know,
gets
a
good
well
address,
sharing
an
aggressive
use
of
the
remaining
before
it
sources
that
you've
got.
Another
particular
thing
that
needs
to
be
solved
with
soft
wires.
G
Is
that
you
need,
as
an
operator
to
know
what
the
clients
tunnel
endpoint
these
six
address
is
going
to
be
so
I
mean
there's,
there's
a
way
of
kind
of
pre,
calculating
that
that
we've
used
in
the
in
the
static
provisioning
model,
but
this
provides
a
way
that
the
client
can
just
simply
tell
the
server
in
a
parameter.
This
is
what
I'm
going
to
use
and
then
the
server
stores
that,
alongside
the
lease
information,
so
that
you've
got
a
kind
of
single
point
in
the
network
that
you
can
say.
G
This
is
all
the
information
I
need
for
v4
v6
and
I
can
use
up
to
provision
the
other
elements
in
the
architecture.
Next
slide,
please
so
yeah.
This
has
been
around
in
software
for
some
time,
but
hasn't
really
moved
very
far
in
there,
because
essentially,
everything
that's
described
in
here
is
dhcp
44,
/,
dhcp,
6
related.
G
So
there's
two
RFC's
that
have
already
been
published
both
worked
on
in
DHC,
so
that's
73,
41
and
76
1876
18
deals
with
address
sharing
in
v4
least
addresses,
and
so,
as
this
is
kind
of
the
final
part
that
makes
the
whole
thing
come
together,
it
made
more
sense,
or
hopefully
it
makes
more
sense
to
put
it
in
DAC
next
slide.
Please,
alright!
G
So
here's
a
kind
of
a
rough
overview
I
mean
it
doesn't
show
the
full
DHCP
message
flow
here,
but
some
if
you're
familiar
with
DHCP
for
over
6,
it
all
starts
off
by
receiving
an
option
from
the
dhcp
server
that
will
either
either
enable
it
will
contain
a
unicast
address
for
the
DHCP
for
over
6
server.
You
then
have
a
new
message
flow,
which
is
the
DHCP
for
over
6
1
and
in
there
you're
carrying
DHCP
for
messages
inside
a
particular
DHCP,
six
message
type.
G
So
within
the
flow
we
pass
from
the
server
to
the
client
a
hint.
This
is
in
the
form
of
an
IP
version,
6
prefix,
and
this
is
to
essentially
help
the
client
to
find
the
right
address
or
the
right
prefix.
Out
of
all
the
one
that's
got
available
so
that
it
can
have
a
chance
of
getting
a
SoftWIRE
built
on
the
right
place,
that's
going
to
be
rootable
and
whatever
else
the
client
then
builds
an
address
on
that
prefix
and
indicates
back
to
the
server.
G
G
The
AFT
are
using
what
we're
using
that
come
for
this,
but
we
talked
about
using
things
like
both
of
these
query
and
things
like
that
for
it,
and
at
that
point
you've
got
a
fully
functioning
soft
wire
and
a
dynamically
confited
address
that
can
be.
You
know,
works
under
normal
dhcp
for
kind
of
thumb,
leasing.
G
Okay,
next
slide,
please
so!
There's
two
new
options
in
here:
the
first
one
being
the
Prince
of
the
hint
option,
which
is
just
simply
a
v6
prefix,
and
the
second
one
is
the
128-bit
address.
That
will
be
used
as
the
tunnel
endpoint
that
the
client
pass
back
to
the
server
next
slide.
Please
this
is
the
kind
of
a
ya
the
minute,
a
of
what
exactly
happens
at
each
step,
and
you
can
see
that
it's
aligned
with
the
DHCP
for
message
flow.
G
So
these
messages
are
the
additional
new
options
that
I'm
talking
about
here
are
carried
along
with
the
corresponding
v4
message,
as
it
goes
through
the
ER
than
or
dhcp
for
leasing
process
next
slide,
so
we're
working
on
an
implementation
at
the
moment
and
it's
not
completed,
but
there's
already
some
feedback.
That's
coming
back
from
there
about
the
text,
that's
in
so
I
submitted
the
06
update
I
think
two
days
ago
that
took
into
account
some
of
those
those
things.
G
There's
also
some
other
comments
that
have
come
back
from
from
our
implementer
and
some
yeah,
those
those
will
be
up
on
the
list
shortly.
There
was
another
review
that
came
in
fringe
in
May
overnight,
so
some
other
comments
that
need
to
be
addressed.
There,
there's
I
think,
there's
still
quite
a
few
things
to
be
considered
in
here
at
the
moment.
So
I
don't
think
it's
near
to
being
done,
but
you
know
hopefully,
we've
been
in
DAC
it'll
get
the
the
attention
from
the
right
people
that
it
needs
next
slide.
F
F
Something:
okay,
I'm
perfectly
fine!
If
you
do
pose
to
take
it
up
good.
E
C
G
C
So
just
as
a
reminder
to
sort
of
where
we
are
today.
The
05
version
was
published
in
june.
We
initiate
a
working
group
last
call
in
July
which
lasted
a
while,
and
it
ended
in
august
and
we
got
approximately
290.
You
know
comments,
it
wasn't
290
separate
emails,
but
we
kind
of
took
everybody's
comments
and
and
chop
them
up
into
individual
items
that
were
tracking
on
a
Google
sheet,
and
you
know,
obviously
there
were
duplicates
in
there,
but
most
of
them
are
probably
unique.
There
are
were
16,
serious
reviewers.
C
You
know
that
that
generated
on
the
order
of
10
to
you
know,
30
comments
each.
So
there
was
very
you
know:
I
really
thank
everybody
that
reviewed
it.
You
guys
did
a
fantastic
job.
This.
This
is
the
way
working
through
blessed
calls
should
work
and
it
got
excellent
coverage.
So
you
know
that
was
good.
C
Obviously,
the
bad
news
is
that
we
have
290
issues
to
go
through
and
you
know
well,
I'll
talk
a
little
bit
more
about
some
of
them,
but
you
know
the
problem
is:
is
that
it's
just
a
lot
of
stuff
to
go
through
we've
addressed
about
200
the
comments,
but
there's
more
to
go
there?
You
know
in
that
last
set
there's,
probably
some
duplicates
as
well.
Next
line.
C
Many
of
the
comments
were
minor.
You
know
clean
up
text,
fix
typos,
formatting
issues
or
inconsistencies
where
the
documents
in
one
part
said
one
thing
and
kind
of
contradicted
itself
in
another
section,
usually
just
stuff
that
we
had
done
when
when
we
edited
it,
we
didn't.
You
know,
edit
all
the
text
in
certain
sections,
there
were
a
bunch
of
comments
about
clarifying
sections,
adding
new,
more
definitions
and
even
reorganizing
the
text
to
improve
its
presentation,
and
you
know
logical
flow,
and
we
have
a
few
potential
changes
that
we
want
your
input
on.
C
So
the
first
of
those
is
the
soul,
mix
RT
and
also
impacts
RT.
You
know
that
the
RC
78
III,
which
we
never
really
caught
during
this,
is
that
it
never
really
clarified
how
the
options
should
be
updated.
If
there
are
multiple
you
know,
advertised
or
replies
received.
C
Okay,
you
know
if
the
client
accepts
an
advertised
should
have
used
just
that
the
options
from
that
and
ignore
the
others,
but
you
know
what
if
it
didn't
contain
options,
but
others
did
and
what
happens
if
no
advertisers
accepted
and
multiple
multiple
advertisers
are
receive.
So
it's
a
question
of
you
know
we
can
either
just
say:
well,
nobody
cared
it
79-78
III,
so
we'll
leave
it
alone
and
just
copy
the
text
in
here
or
we
can
try
to
address
this.
C
You
know
legal
there's,
some
boundary
checks
that
are
specified
in
seventy.
Eighty
three,
you
know
I
should
point
out
that.
Probably
this
is
a
minor
issue,
because
on
a
properly
operating
Network
you
would
expect
the
last
bullet
to
apply
and
that
they're
there
all
the
servers,
if
there
are
multiple
servers,
are
gonna
use
the
same
values.
But
you
know
that
may
not
always
be
the
case
mm.
B
And
I
have
a
comment
on
that
particular
bullet
I
think
that,
as
a
way
of
avoiding
attacks,
which
you
know
probably
wouldn't
happen
on
a
really,
you
know
secure
network,
but
it
certainly
could
happen
on
a
less
secure,
Network
like
a
home
net.
It
is
almost
certainly
a
good
idea
to
do
the
take
the
smallest
length
that
you
here,
because
otherwise
somebody
can
just
sit
there
and
send
you
the
you
know,
super
long,
sull
max
RT
and
bam
you're
off
the
wire
for,
however
long
right
and.
C
I
mean
it
that
sounds
like
a
plausible
solution.
You
know.
The
one
thing
that
we
have
to
remember
is
that
a
client
isn't
necessarily
going
to
wait,
for
you
know
lots
of
them
to
come
by
either
so,
but
I
think
if
it
does
receive
conflicting
values
may
be.
The
best
thing
to
do
is
you
say
is
just
say:
use
the
default
and
and
leave
it
alone
right,
and
it.
F
C
And
that
I
didn't
bring
it
up
on
this
slide,
but
there
you
know,
there's
there's
another
little
complexity,
and
that
is
what
you
know.
When
do
you
ever
set
so
max
RT
back
to
the
default,
suppose
you
get
a
large
value
or
different
value.
Ok,
when
are
you
supposed
to
set
it
back
because
it
never
really
that
70
83
never
really
talked
about
that
issue
I,
you
know,
since,
since
you
kind
of
stepped
a
little
bit
into
it,
I
figure-
maybe
it's
work
also
trying
to
address.
F
Also,
another
thing
is
like
maybe
tom.
I
can
answer
this
like
do
you
keep
track
of
where
you
got
the
solar
max
Hardy
from
from
itself
right,
because
if,
if
the
server
it
solves
changes
the
solar
max
RT
like
you
need
to
know,
if
it's
it's
an
inconsistency
other
so
just
change
the
solar
max
RT
right,
yeah,.
J
Really
learn
it
I
do
have
to
that,
keep
it
forever
and
that's
been.
Oh,
that's
been
interesting,
so
we
might
want
to
say
something
about
this,
because
I
suspect
more
people
will
just
take
whatever
new
value
they
get
and
apply
it
forever
and
it's
nasty.
It
is
nasty
if
you
set
it
to
a
high
value.
It's
going
to
sit
for
a
while,
but
I
mean
I
will
say.
C
B
Lemon
so
a
couple
things
one
I
think
suresh's
suggestion
is
great.
If
we
get
conflicting
values,
use
use
the
default.
Yes,
I
think
that
it's
actually
not
likely
to
be
a
problem
in
the
typical
use
case
for
this,
in
the
sense
that
you
know
if
your
cable
modem
goes
and
sends
out
a
solicit,
it's
on
a
cable
network.
There
is
relatively
tightly
constrained
and
controlled,
and
so
the
likelihood
of
you
getting
an
attack
from
some
third-party
on
that
network
is
pretty
slim
and
it's
not
a
bad
idea
to
have
this
this.
B
You
know
this
fall
back,
but
but
I
don't
think
it's
a
really
serious
I
issue,
it's
more
of
a
serious
issue
on
a
home
net,
but
on
home
that
you
know
I.
Think
Suresh
is
solution,
works
fine
and
I'm
going
to
say
sorry
or
your
second
point
was
about
oh
right.
I
think
that
the
time
to
discard
the
value
is
whenever
you
see
a
link
state
transition
right
and
implicitly
also
that
means
on
a
reboot,
because
otherwise
you
know
certainly
for
for
cable
modems
you're,
not
likely
to
ever
see
link
state
transition.
C
And
that
that
does
raise
a
funny
question
about
you
know
should,
should
these
options
then
be
allowed
in
in
the
confirm
you
know
refined
case
right,
because
that's
what
you're
going
to
do
when
the
link
yeah
flips?
C
So
another
request
that
we
received
was
to
remove
the
following
paragraph
from
section
17
1,
10
1,
and
we
believe
this
is
to
allow
to
run
multiple
independent
state
machines
on
a
single
interface.
Oh,
this
isn't.
The
updated
slides
but
anyway
is
to
discourage.
But
allow
is
what
I
think
we
wanted
to
say
to
run
multiple
independent
state
machines
on
a
single
interface,
and
we
got
to
feel
that
this.
You
know,
if
you're
going
to
do
something
as
complicated
as
that,
you
should
take
that
text
with
a
grain
of
salt.
C
You
know
the
the
all
required
leases
and-
and
that
means
just
those
for
which
that
state
machine
is
kind
of
running,
because
we
kind
of
say
at
the
beginning
of
this
document
somewhere
I
think
we
kind
of
talked
about
that.
You
know
this
is
sort
of
a
single
instance
of
a
dhcp
client
and
you
would
run
a
different
one
on
each
interface
and
things
like
that.
So
it
I'm
not
sure
we
want
to
remove
this.
This
paragraph
or
even
reword.
It.
B
So
Ted
lemon.
My
only
reason
for
not
loving
this
text
is
that
it
does
have
the
effect
that
if
you
are
running
to
DHCP
servers
on
a
link,
one
of
which
is
doing
neighbor,
discover
sorry,
one
of
which
is
doing
PD
and
10,
which
is
doing
na.
Then
this
is
going
to
make
you
do
a
lot
more
work.
But
well
we
don't
really.
C
Support
you
ibly
not
a
great
thing
to
be
doing
anyways
right
and
it's
not
a
problem,
and
it's
not
really
the
you
know
the
this
7550
staple
issues,
kind
of
route
them
anyway,
okay
and
I.
Think
if
you,
if
you
want
to
build
a
client
that
does
that
I,
don't
think
you're
prohibited
from
doing
that
right
and.
C
C
You
know
that
the
data
in
there
is
not
generally
considered
confidential,
and
you
know
that's
that's
very
debatable
today,
because
there's
a
lot
of
issues
with
the
iesg
about
this,
and
that's
why
I
wrote
the
relay
server
security
draft,
which
did
mandate
but
kind
of
highly
recommended
ipsec
usage.
So
you
know
I'd
like
to
just
drop
the
text
in
from
that
document,
but
that
document
is
in
working
group
last
call:
well,
they
kind
of
technically
expired,
but
hasn't
yet
really
been
processed
and
I.
C
C
So
I
will
send
something
Colless
on
this
as
well,
but
again,
I
think
the
solution
is
support.
The
working
group
last
call
on
the
relay
server
security
draft
and
then,
if
everybody
supports
that,
we
can
probably
just
copy
that
text
and
that
will
also,
I
think,
make
the
iesg
happier
that
we
have
a
bit
stronger
statement
about
security
and
things.
C
Ok,
that's
all
I
had
for
that.
The
next
steps
for
the
document
are
that
you
know
a
what
was
it
yeah
thanks
for
all
the
comments?
But
you
know
if
you
have
some
that
our
cellar,
it's
not
too
late,
we'll
take
them.
You
know
we
did
publish
the
06,
which
has
some
of
the
updates
and
it's
possible
that
we
made
some
mistakes
and
stuff
so
we'll
continue
to
work
on
it
will
hopefully
publish
in
07.
C
E
You
ok
so.
E
E
We
tried
to
reach
the
outers,
also
primary
alto
liu
yuan.
She
used
to
work
for
microsoft,
but
she's
now
in
a
different
team,
so
our
site
of
microsoft
and
the
draft
has
expired
so
when
next,
so
the
question
is,
are
we
still
interested
in
this
work?
We
I
think
we
try
to
reach
the
other
routers
three
times
and
nobody
responded.
E
B
C
Okay,
so
I'd
like
to
talk
about
possibly
resurrecting
an
old
draft
that
we
started
work
on
next
slide
back
in
2005
of
October
was
when
the
original
draft
was
written.
It
was
adopted
by
the
working
group
back
in
January
2006
kind
of
lingered
there
for
several
years
and
in
January
09
the
04
was
was
published,
which
is
the
current
version.
It
obviously
has
long
since
expired
and
interest
was
primarily
lost
because
there
were,
if
I,
if
I
remember
correctly,
there
was
a
concern
about
out
of
order.
C
Packets
might
cause
issues,
and
the
other
issue
was
that
CableLabs
had
had
specified
in
relay
agents
were
starting
to
implement
just
doing
relay
snooping,
just
to
say
done
with
dhcp
v4,
because
it
worked
great
for
v4.
So
why
not
use
it
for
v6?
So
the
working
group
was
a
bit
too
late
in
sort
of
doing
this
work
next
slide.
So
why
now?
Well
you
know
the
original
motivation
was
we
wanted
to
avoid
relay
snooping.
C
You
know
they
shouldn't
need
to
look
really
shouldn't
need
to
look
inside
the
individual
client
messages
to
determine
what
Lisa's
the
client
was
assigned,
or
what
other
actions
like
you
know
when
a
client
release
Elise
that
that
the
least
was
removed,
and
today
the
or
the
original
argument
was
that
if
we
had
strong
security,
some
at
some
point
security
might
make
this
impossible.
C
We
also
want
to
reduce
complexity
for
relays
because
some
relay
messages
I.
Sorry,
some
reply
messages
do
not
have
details
on
what
the
client
did,
for
example,
a
release.
Doesn't
you
know
the
release
message
going
to
the
server?
Has
a
list
of
addresses
and
prefixes
that
might
be
released,
but
the
reply
coming
back
has
nothing.
C
Now
we
could
have
a
relay
echo
option
if
we
want,
you
know,
I,
sorry,
a
real,
a
request
option
if
we
wanted
to
an
RR
0
instead
of
an
Oro,
but
it
probably
isn't
you
know,
I,
don't
see
the
value
of
doing
that,
because
it's
clear
where
this
this
message,
this
option
would
be
in
the
relay
forward.
Part
of
the
message
not
in
the
clients
message
and
the
server
added
this
option
to
the
real,
a
reply
with
all
the
addresses
and
prefixes
in
use
by
the
client.
The
pretty
much
the
you
know.
C
C
C
They
won't
may
be
able
to
support
secure
dhcpv6
option,
maybe
not
a
big
deal,
but
you
know
it
is
it?
Is
there
another
option
which
is
the
one
I'm
proposing?
Is
we
resurrect
this
draft
and
I?
Think
some
of
the
issues
that
were
raised
about
it
are
probably
pretty
minor,
because
relay
snooping
can
suffer
from
the
same
out
of
order
packet,
delivery
issues
and
things
like
that
and
has
been
done
very
successfully
without
to
my
knowledge,
any
significant
problems
or
any
problems
at
all.
So
I
think
that
that
was
probably
an
overrated
issue.
C
You
know
was
a
nice
conceptual
issue,
but
it
wasn't
probably
a
realistic
issue.
You
know,
another
option
is:
if
you
do
secure
dhcpv6,
maybe
the
you
have
to
provide
the
relay
the
server
certificates,
but
Suresh
shakes
his
head,
and
I
agreed
that
I
don't
think
that's
a
very
good
idea
either.
You
know
there
are
other
options
like
having
the
real.
I
used
actively
square
e
to
keep
up
with
updates
which
that
that
would
be
a
fairly
workable
solution.
C
Potentially
you
know,
and
we
could
develop
yet
another
protocol,
but
I
don't
think
we
want
to
do
that
either
so
next
slide.
C
B
Telemon
so
I
actually
kind
of
liked
your
active
lease
query
idea,
the
reason
being
that
it
eliminates
the
concern
about
timing
right
because
now
you're
having
an
actual
communication
between
the
real
agent
and
the
server,
and
it's
also
something
that
real
agents
that
do
snooping
are
likely
to
want
to
do
anyway.
Right.
C
B
So
that
said,
I
don't
have
any
objection
to
doing
the
other
solution.
I
just
I,
just
think
that
we
should
seriously
think
about
it's
probably
worth
actually
thinking
about
how
plausible
a
solution
it
is
to
use
active
lease
query.
If
we
think
that
it's
not
really
going
to
work,
then
we
shouldn't
do
it,
but
we
should
at
least
answer
that
question
before
we
develop
a
new
thing,
because
you
know
we
are
now
putting
more
junk
into
the
dhcp
packet,
and
you
know
if
there's,
if
there's
a
better
way
to
do
it.
B
C
So
I
think
that
would
be
the
only
concern
that
you
know
might
exist,
because
if
you
do
want
to,
you
know
if,
like
on
a
CMT
s
where
you're
installing
a
bunch
of
other
state,
when
you
get
this
stuff,
they
would
really
like
to
do
it.
Sort
of
as
the
packet
goes
back
to
the
client
and
so
that
that's
the
only
benefit.
I.
Think
for
the
this
option
is
that
it's
it's
you
know
will
happen
at
the
same
time.
Yeah.
B
F
Suresh
krisshnan
I
don't
have
any
particular
thing:
either
I,
just
don't
three
and
five,
so
I'm,
okay
with
like
12
and
four
and
I,
would
really
like
to
wait
until
security
ICP
v6
like
gets
out
and
to
see
if,
like
people
have
issues
before
we
do
it
like
because
and
they
had
similar
things
with
send.
You
know
like
there's
like
lot
of
stuff
done
and
it
never
got
the
plight.
So,
like
I,
don't
know
like
it's
I'm
fine,
with
like
continuing
working
on
this,
but
I'm.
F
Just
wanna
see
like
uptake
before
doing
this
really
yeah.
C
And
I
think
it'll
be
I.
I
agree
that
I
think
you
know.
We've
had
a
very
long
road
with
the
secure
dhcpv6
work,
and
so
it
may
be
still
be
a
little
bit
premature
to
start
something
because
we
don't
know
how
it's
gonna
end
yet
right,
but
hopefully,
hopefully
one
of
these
days
we'll
get
a
security
mechanism
that
works
right,
I
mean
so
yeah,
but
so
I
think
that
your
recommendation
is
that
we
we
sort
of
park
this
for
now
and
revisit.
F
C
Though,
for
exact
okay
and
I'm
perfectly
happy
with
that,
I
think
you
know
I
think
yeah
I,
you
know,
was
a
little
bit
leery
about
bringing
this
up
this
early
because
I
don't
know
how
secure
d
cv
v6
is
going
to
work
out
there.
There
are
you
know
some.
There
are
some
subtle
benefits
for
this
because
it
solves
like
the
release
problem
and
things
like
that.
So
there
are
some
advantages
in
using
this
or
the
active
least
square
solution,
because
the
the
relay
does
get
more
more
up-to-date
information.
H
H
H
C
You
know
that
might
be
encrypted
with
ipsec,
but
that's
a
that.
You
know
the
relays
and
and
stuff
will
know
how
to
do
that.
So
all
right.
Thank
you.
Thank.
E
E
C
H
Tintern,
so
I
shouldn't
mention
this.
If
you
want
to
get
away
now,
there
is
a
discussion
in
six-man
about
updating,
RFC
6434,
just
the
node
requirements
document,
and
there
are
some
words
in
there
about
DHC
and
support
for
THC,
and
there
are
some
people
in
six-man
that
have
suggested
that
the
heb
support
should
be
a
May
and
not
assured
that
type
of
thing.
I.
H
Don't
necessarily
think
this
point
having
a
discussion
here
now
with
10
people,
but
if
people
hear
that
our
interested
can
take
a
look
at
the
DHT
relevant
bits
in
6434
and
suggest
some
words
either
that
they
think
those
are
still
fine
or
suggests
words
to
replace
those
chunks
in
6434.
That
would
be
useful.
Thank.